Extreme Programming Method
To help illustrate what it really means to follow an Agile method, let’s look at the specifics of the most popular one, known as Extreme Programming (XP). While the creators emphasized that it is not a one-size-fits-all method, and that it should be applied selectively, there are a core set of fundamental principles that form the basis of the method:
- Pair Programming – the software is written by pairs of programmers working together around a single computer.
- Simple Design – the idea is to design and build only what you need right now and not for some potential future need.
- On-site Customer – the developers have a customer that represents what the product needs to do, sitting with the team and constantly available for clarification and decisions.
- Incremental Development – the strategy is to start small and do many “mini-releases” to rapidly evolve the product to where it needs to be.
- Scheduling and Planning – estimates are provided by the engineers and the customer decides scope and timing for each release.
- Continuous Code Review – based on the pair programming model, the developers are constantly reviewing each others’ work.
- Continuous Testing – the technique is to have the developers write unit tests as they code, and the customer writes functional tests as use cases are defined, and these tests all are run on an automated, ongoing basis.
- Continuous Build – the software is constantly built, integrated and tested so that problems are found early and the system is always kept in a buildable state.
- Continuous Refactoring – the software developers continually work to simplify and improve the implementation by refactoring the code, while keeping all the tests running.
- Collective Code Ownership – rather than the model where each developer “owns” his own section of code, in the XP model every developer can improve any code anywhere in the system anytime he sees an opportunity and need.
- Open Workspace – the idea is that the team works together in a large room with the developers in the center.
- 40-hour Weeks – the belief is that overtime should be limited so that quality remains high.
- Documentation via Code – the belief is that the most useful documentation is the software itself, and that the team needs to follow coding standards.
