Extreme Programming practices explained

XP practices are categorized into two umbrellas as Primary and Corollary practices. Let's take a look at what these practices are trying to emphasize on. Let's quickly taste the essence of these practices explained in simple and short phrases.

Primary Practices

Stories:
  The functionalities of the system are described using stories, short descriptions of customer-visible functionalities. Stories also drive system development.

Weekly Cycle:
  Software development is performed a week at a time. At the beginning of every week there is a meeting where the stories to develop in the week are chosen by the customer.

Quarterly Cycle:
  On a lager time scale, development is planned a quarter at a time.
This is made up of reflections on the team, the project and the progress.

Slack:
  Avoid to make promises you cannot fulfil. In any plan, include some tasks that can be dropped if you get behind. In this way, you will keep a security margin, to be used in the case of un-forecasted problems.

Sit Together:
  Development teams should work in an open space, able to host the whole team, to maximize communication.

Whole Team:
  The team should be composed of members with all the skills and the perspectives needed for the project to succeed. They must have a strong sense of belonging, and must help each others.

Informative Workspace:
  The workspace should be provided with informative posters and other stuff, giving information on the project status and on the tasks to be performed.

Energized Work:
  Developers must be refreshed, so that they can focus on their job and be productive. Consequently, limit overtime working so everyone can spend time for his or her own private life. This practice in the old version of XP was called “sustainable pace”.

Incremental Design:
  XP opposes producing a complete design up front. The development team produces the code as soon as possible in order to obtain feedback and improve the system continuously. Design is indispensable to obtain good code. The question is when to design. XP suggests to do it incrementally during coding. The way helpful to obtain this is to eliminate duplications in the code.

Continuous integration:
–All changes are integrated into the code base at least daily
–Tests have to run 100% both before and after integration

Ten-Minute Build:
  System should be built and all of the tests should be finished in ten minutes, in order to execute it often and obtain feedback.

Pair programming:

• Two programmers work together at one machine
  
• Driver enters code, while navigator critiques it
  
• Periodically switch roles
  
• Research results:
  

                –Pair programming increases productivity
                –Higher quality code (15% fewer defects) in about half the                                                                   time (58%)
                –Williams, L., Kessler, R., Cunningham, W., & Jeffries, R.                     Strengthening the case for pair programming. IEEE Software, 17(3), July/August 2000
                –Requires proximity in lab or work environment

Test First Programming:

• Test first: before adding a feature, write a test for it!
  

              –If code has no automated test case, it is assumed it does not work

• When the complete test suite passes 100%, the feature is accepted
  
• Tests come in two basic flavors…
  
• Unit Tests automate testing of functionality as developers write it
  

              –Each unit test typically tests only a single class, or a small cluster of classes
              –Unit tests typically use a unit testing framework, such as NUnit (xUnit)
              –Experiments show that test-driven development reduces debugging time
              –Increases confidence that new features work, and work with everything
              –If a bug is discovered during development, add a test case to make sure it doesn’t come back!

• Acceptance Tests (or Functional Tests) are specified by the customer to test that the overall system is functioning as specified
  

              –When all the acceptance tests pass, that user story is considered complete
             –Could be a script of user interface actions and expected results
             –Ideally acceptance tests should be automated, either using a unit testing framework, or a separate acceptance testing framework 

Corollary Practices

Real Customer Involvement: 
  People whose lives are affected by your system must became a part of the team and they can contribute to quarterly and weekly planning.

Incremental Deployment:
  When replacing a legacy system, start to replace some functionalities right away and gradually replace all system. Avoid the approach of “All or nothing.”

Negotiated Scope Contract:
  Contracts for software development would have fixed time, costs, and quality, but the precise scope of the system would have to be negotiated during the same realization. Eventually it is better to have a sequence of short contracts in order to reduce risks.

Pay-Per-Use:
  Customer usually pays for each release of the software. This creates a conflict between the supplier and the customer, who would want fewer releases each containing a lot of functionalities. Connecting money flow directly to software development provides accurate, timely information with which to drive improvement.

   Lots of software is already pay-per-use. Telephone switches, electronic stock exchanges, and airline reservation systems all charge a fee per transaction. While pay-per-use has business advantages and disadvantages, the information it generates can help improve software development.

Team Continuity:
  The development teams must remain the same in several projects. The relationship they share in a project are precious and they do not have to be dispersed.

Shrinking Teams:
  As the team becomes more capable and productive, keep its load constant but gradually reduce its size, send free members to form more teams.

Root-Cause Analysis:
  Every time you find a defect, eliminate it and its causes. In this away, not just you will eliminate the defect, but also you will prevent making the same mistake again.

Code and Tests:
  Only code and tests are permanent artifacts and they have to be preserved. The other documents can be generated from code and tests.

Shared Code:
  Anyone in the development team must be able to change any part of system at any time. This practice was called “collective code ownership” in the original XP.

Single Code Base:
  There is only one official version of system. You can develop a temporary branch, but it doesn't live longer than a few hours.

Daily Deployment:
  Every night you must put new software into production. It is risky and costly to have a gap between the version of software released into production and ones you have in your computer.

With that we come to the end of XP practices. There is one more term closely tagged to XP, taken from DDD (Domain Driven Design) called Ubiquitous Language.

Ubiquitous Language:

• Ubiquitous Language is the term Eric Evans uses in Domain Driven Design for the practice of building up a common, rigorous language between developers and users. This language should be based on the Domain Model used in the software - hence the need for it to be rigorous, since software doesn't cope well with ambiguity.
  
• Evans makes clear that using the ubiquitous language between in conversations with domain experts is an important part of testing it, and hence the domain model. He also stresses that the language (and model) should evolve as the team's understanding of the domain grows.