XP (Extreme Programming)
Extreme Programming, or XP, is an Agile software development approach first originated by Kent Beck in mid-1990’s. XP is based on principles of simplicity, communication, feedback, and courage. Originally, XP was designed for use with small teams who need to develop software quickly in an environment of rapidly-changing requirements. However, many organizations around the world, including StarSoft, have found that XP is capable of scaling to tackle large scale development projects.
The core XP practices are:
- The XP planning process allows the XP "customer" to define the business value of desired features, and uses cost estimates provided by the programmers, to choose what needs to be done and what needs to be deferred. The effect of XP's planning process is that it is easy to steer the project to success. Release Planning is a practice where the customer presents the desired features to the programmers, and the programmers estimate their difficulty. XP teams build software in 2 to 4 week iterations, delivering running, useful software at the end of each iteration. During Iteration Planning, the customer presents the features desired for the next 2 (4) weeks. The programmers break them down into tasks, and estimate their cost at a finer level of detail than in Release Planning.
- XP teams put a simple system into production early, and update it frequently on a very short cycle. The goal is to release running, tested software, delivering business value chosen by the customer, in every iteration. The customer can use this software for any purpose, whether evaluation or even release to end users. The most important aspect is that the software is visible, and given to the customer, at the end of every iteration. This keeps everything open and tangible.
- XP teams use a common "system of names" and a common system description that guides development and communication.
- A program built with XP should be the simplest program that meets the current requirements. There is not much building "for the future". Instead, the focus is on providing business value now. For practice to work, it is necessary to ensure that you have a good design. In XP, this is brought about through "refactoring", (see below)
- XP teams focus on validation of the software at all times. Programmers actually write tests first, and then write the software that fulfills the requirements reflected in the tests. Customers provide acceptance tests that enable them to be certain that the features they need are provided.
- XP teams improve the design of the system throughout the entire development. This is done by keeping the software clean: without duplication, with high communication, simple, yet complete. Interestingly, the adjective most commonly used in literature on XP in conjunction with the term ‘refactoring’ is ‘merciless’. Refactoring is, of course, strongly supported by comprehensive testing to be sure that as the design evolves, nothing is broken.
- Often (although not necessarily all the time) XP programmers write production code in pairs, with two programmers working together at one machine. Pair programming has been shown in many instances to produce better software at similar or lower cost than two programmers working separately.
- As part of presenting each desired feature, the XP customer defines one or more automated acceptance tests to verify that the feature is working. The team builds these tests and uses them to prove that the feature is implemented correctly. Just like unit tests, once written, the team keeps these tests running while adding new functionality to make sure that the system only improves and never backslides.
- All the code belongs to all the programmers: anyone can improve any code at any time. This means that all code gets the benefit of many people's attention, which increases code quality and reduces defects. This also lets the team go at full speed, because when something needs changing, it can be changed without delay.
- XP teams integrate and build the software system multiple times per day. This keeps all the programmers on the same page, and enables very rapid progress. Perhaps surprisingly, integrating more frequently tends to eliminate integration problems that plague teams who integrate less often.
- Tired programmers make more mistakes. XP teams do not work excessive overtime, keeping themselves fresh, healthy, and effective. This means that XP teams sometimes work overtime when it is effective, but normally they work in such a way as to maximize productivity every week without the need for overtime.
- An XP team must include a business representative – the ‘customer’ – who provides the requirements, sets the priorities, and steers the project. It's best if the customer is a real end user who knows the domain and what is needed. The team will have programmers, and may also include testers, who help the customer define the customer acceptance tests. Analysts may also assist the customer, with requirements definition.
- For a team to work effectively in pairs, and to share ownership of all the code, all the programmers need to write the code in the same way, with rules that make sure the code communicates clearly. The specifics of the standard are not important; what is important is that all the code looks familiar, in support of collective ownership.
