This post is an introduction to Extreme Programming (XP), another of the Agile methods for software application implementation. Reading this post is a prerequisite to this post.
The underlying philosophy of Extreme Programming is to take the best elements of software engineering and bring them to an ‘extreme’ level. If a little is good, more will necessarily be better. XP believes that changes are unavoidable in project implementation. Hence, it does not make sense to define a stable set of requirements.
Core Practices & Values
Extreme Programming operates on 12 core principles:
- Planning Game – It is the planning process happening at the meeting happening at the beginning of an iteration. It includes release planning and iteration planning.
- Small Frequent Release – The iteration cycle is 1-3 weeks.
- System Metaphors – A user description of what the system should do. It helps drive the direction of the project and expectations. In the UML paradigm, this would be the set of use cases.
- Simple Design – This is Occam Razor’s principle applied to project implementation. The code should not do more than what satisfies requirements. If something is not needed, do not implement it.
- Testing – XP favors test driven development, where unit tests are executed frequently to check for any regressions. Users also define acceptation tests, to make sure required functionalities meet expectations. These should be automated and not require human intervention.
- Frequent Refactoring – Refactoring is either about producing clearer and clearer code, or modifying it to respond to new or revised requirements.
- Pair Programming – All code is created by two people working at the same working station (one creative mind and one pragmatic mind). It is not about mentoring. Pairs are not fixed and can be reorganized. One purpose is to increase productivity, the other is to spread the knowledge of the implemented project.
- Team Code Ownership – Everyone is responsible for all the code.
- Continuous Integration – All developers work on the same code base, to prevent integration issues.
- Sustainable Pace – It is about avoiding excessive stress which often leads to low quality or buggy code. Overall, speeding up the process too much leads to increased cost in debugging and improving bad quality code. An optimum speed has to be found. XP does not promote overtime.
- Whole Team Together – The team should operate from the same room. It is not only about the development team, the customer should be on hand at all times and available for questions.
- Coding Standards – The code that looks the same all over the application is easier to read and to understand.
The 4 values of XP are: communication, simplicity, feedback & courage.
Concepts
- Stories are written by the customer who describes what he does as part of his job. The closest concept in UML would be a use case.
- There are 6 main roles in XP:
- The customer writes stories and acceptance tests. He picks for them for product releases and iterations.
- Programmers write code, tests, refactors code, identifies tasks to be performed and estimates time to perform them.
- Testers help customer write acceptance tests.
- The Coach has the role of a teacher and checks the evolution of the process.
- The Tracker collects metrics, monitors progress.
- Consultant is usually any technical consultant.
- Release Planning Game is the process of defining which features should be part of the next software application release. Which stories should be included? Programmers estimate the difficulty of each task.
- Iteration Planning Game is the process of choosing stories to implement by the next iteration.
- Task lists are the set of task each developer must perform by the next iteration.
Practice
- XP does not promote the creation of an overall design specification document.
- Keep documentation to a minimum.
- Teams should be made of maximum 10 developers.
- Project should not last more than one year.
- Code reviews should be frequent.
- XP projects life cycles are made of several phases:
- Exploration – Prepare enough story cards for the first release, make sure the project is feasible (prototypes).
- Planning – Agree on date and stories for first release, perform release planning game, create more story cards if necessary.
- Iterations to 1st release – Implement tested system, perform iteration planning game, task definitions…
- Productionizing – Operational deployment, documentation, training…
- Maintenance – Enhancement, bug fixing, major releases (incremental or not)…
Conclusion
Extreme Programming is assuming that the customer is highly available and capable of expressing all his needs. Stories are not as precise as UML cases. Refusing to make detailed analysis when necessary can be counter-productive in many projects. Letting the customer make request changes informally does not help setting a sustainable pace too.
XP maximizes the division of work responsibilities and roles. It is consuming a lot of resources. It tends to focus more on efficiency than effectiveness. Pair programming is also not adapted to everyone’s psychology, and making everyone responsible for all the code is overkill in most project. People’s time is not always consumed efficiently.
To be efficient, XP requires an environment having a lot of resources and willing to live on the edge (like Formula 1 racing). It is not adapted to migration projects, or projects implementing complex systems including high security for example. Waterfall or Scrum will be more appropriate.
Reference: Introduction To Extreme Programming (XP) from our JCG partner Jerome Versrynge at the Technical Notes blog.
Grt web site.