The traditional software development process is linear, with each stage of the lifecycle requiring completion of the previous stage. For instance, design starts only on completion of the entire analysis of the program, and coding starts only after completion and freezing of the design. This concept works well when customer requirements remain static, but in practice, requirements change frequently and cause frequent editing of programs leading to errors and software ‘rot.’
Extreme Programming (XP) turns the traditional software development process sideways. Rather than planning, analyzing, and designing in a linear fashion, XP programmers do all such activities a little at a time throughout the development phase. The approach bears resemblance to a jigsaw puzzle with the development of many small pieces or iterations that make no sense individually, but making for a complete package when combined. The biggest advantage of this approach is the resilience it provides, allowing for easy incorporation of changes.
The Extreme Programming software development process starts with planning, and all iterations consist of four basic phases in its life cycle: designing, coding, testing, and listening. The overriding values that drives the XP life cycle are continual communication with the customer and amongst the team, simplicity by harping on the minimalist solution, frequent feedback through unit and acceptance testing, and the courage to take on problems proactively and integrate testing and changes in the development phase.
Image Credit: Wikimedia Commons
The first phase of Extreme Programming life cycle is planning, where customers or users meet with the development team to create ‘user stories’ or requirements. The development team converts user stories into iterations that cover a small part of the functionality or features required. A combination of iterations provides the customer with the final fully functional product.
The programming team prepares the plan, time, and costs of carrying out the iterations, and individual developers sign up for iterations.
One planning approach is the critical path method, grouping iterations essential for project progress in a linear fashion, and arranging for completion of other iterations parallel to the critical path.
An iteration of XP programming starts with designing.
The guiding principles of this stage are:
- Thrust on simplicity by expressing a thing only once and not adding functionality in anticipation.
- Using systems metaphor or standards on names, class names and methods, and agreeing on uniform styles and formats to ensure compatibility among the work of different team members
- Using Software Class Responsibilities and Collaboration (CRC) Cards that allow for a departure from the traditional procedural mindset and make possible object oriented technology. Such cards allow all members of the project team to contribute ideas, and collate the best ideas into the design
- Creating spike solutions or simple programs that explore potential solutions for a specific problem, ignoring all other concerns, to mitigate risk
Coding constitutes the most important phase in the Extreme Programming life cycle. XP programming gives priority to the actual coding over all other tasks such as documentation to ensure that the customer receives something substantial in value at the end of the day.
Standards related to coding include:
- Developing the code based on the agreed metaphors and standards, and adopting a policy of collective code ownership.
- Pair programming or developing code by two programmers working together on a single machine, aimed at producing higher quality code at the same or less cost.
- Strict adherence to 40-hour workweeks with no overtime. This ensures the developers work in the peak of their mental and physical faculties.
- Frequent integration of the code to the dedicated repository, with only one pair integrating at a time to prevent conflicts, and optimization at the end.
Extreme program integrates testing with the development phase rather than at the end of the development phase. All codes have unit tests to eliminate bugs, and the code passes all such unit tests before release.
Another key test is customer acceptance tests, based on the customer specifications. Acceptance test run at the completion of the coding, and the developers provide the customer with the results of the acceptance tests along with demonstrations.
The basis of extreme programming is a continuous mechanism of customer involvement through feedback during the development phase. Apart from the customer, the developer also receives feedback from the project manager.
The basis of feedback is the customer acceptance tests. Each feedback of the customer that specifies revised requirement becomes the basis of a new design, and the process of design-coding-tests-listening repeats itself. If the customer remains satisfied with the test results the iteration ends there, and the design for the new iteration starts, which again follows the design-coding-testing-listening cycle.
- Hutagalung, Wilfrid. Extreme Programming. https://www.umsl.edu/~sauterv/analysis/f06Papers/Hutagalung/
- Jarvis, Bob & Gristock, Stephen. Extreme Programing (XP), Six Sigma and CMMI How they can work together. https://www.sei.cmu.edu/library/assets/jarvis-gristock.pdf
- Paulk, Mark C. Extreme Programming from a CMM Perspective. Software Engineering Institute, Carnegie Mellon University. Retrieved from ftp://ftp.sei.cmu.edu/pub/documents/articles/pdf/xp-from-a-cmm-perspective.pdf [PDF] on September 25, 2010
- Rengarajan, M. S. Extreme Programming. Retrieved from https://www.tagonline.org/files/33_ExtremeProgramming_RR.pdf [PDF] on September 25, 2010