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.
The functionalities of the system are described using stories, short descriptions of customer-visible functionalities. Stories also drive system development.
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.
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.
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.
Development teams should work in an open space, able to host the whole team, to maximize communication.
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.
The workspace should be provided with informative posters and other stuff, giving information on the project status and on the tasks to be performed.
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”.
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.
–All changes are integrated into the code base at least daily
–Tests have to run 100% both before and after integration
System should be built and all of the tests should be finished in ten minutes, in order to execute it often and obtain feedback.
–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:
–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!
–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
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.
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.
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.
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.
As the team becomes more capable and productive, keep its load constant but gradually reduce its size, send free members to form more teams.
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.
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.
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.
Sandeep Mukkara Joshua Daniel