Extreme Programming - Evolving Practices

---

---

Extreme Programming has been evolving since its inception and Extreme Programming practices are being found to be effective in the other agile methodologies also.

Following table shows how the Extreme Programming practices are being evolved.

On-Site Customer – Whole Team

Extreme Programming relies on a project community with emphasis on team-centric approach. All the contributors to an Extreme Programming project, including the customer are one team.

The customer provides requirements, sets priorities and steers the project. This enables the customer to understand the practical details of development and set the priorities and expectations accordingly. This changes from “As customer asks the development” to “As the customer understands and cooperates with the development”.

The project goals are a shared responsibility and the development is an ongoing conversation across the whole team. It is a cooperative game of invention and communication. It is found that face-to-face communication is the most efficient and the most effective method in the path of development and eliminates wait times and delays.

Planning Game – Release and Iteration Planning

Incremental project planning is found to be effective since it promotes accurate plans. More and better information is learned as the development progresses based on the actual performance. Develop a rough plan first and refine it incrementally.

Release planning sets long-term goals, with an overall big-picture at hand. The customer presents required features, the developers estimate and the release dates are mutually agreed and committed. As the release plan is revised after every release, it becomes more precise as the project progresses.

Iteration planning sets short-term time-boxes with iterations, typically ranging from 1 week to 1 month. The main objective of iteration planning is a working software at the end of each iteration. The developers choose the features/stories for the iteration, break them down into tasks, estimate tasks and commit to the allocated tasks. Sustainable pace is ensured by balancing the load factor across the team, considering 40-hour week.

Acceptance Testing

The customer writes one or more automated acceptance tests for a feature, to ensure that the system implements the desired features correctly. The acceptance tests are written along with the stories and provided prior to implementation.

Team automates these tests to verify that a feature is implemented correctly. Once the test runs, the team ensures that it keeps running correctly thereafter, at the time of regression, by executing all the acceptance tests implemented till then.

Acceptance tests provide non-ambiguous specifications of functional requirements. Further, the percentage of acceptance tests passing measures the release completion, with no last-minute surprises.

The system always improves and never backslides.

Unit Testing

The developer writes unit tests with sufficient coverage, incorporating the intent and usage of the code modules and methods. Unit tests are automated, with clear pass/fail. Most languages have a xUnit framework (e.g., nUnit, jUnit).

All unit tests are executed very frequently and the code cannot be checked-in until all unit tests pass. The unit test results also help in refactoring.

Test Driven Development

Test Driven Development is being considered as the most innovative Extreme Programming practice.

In Test Driven Development, the developer writes a unit test prior to writing code. The intent is to make the unit test fail. As the code is not yet implemented, the unit test fails. The developer writes just enough code to make the unit test pass and then, the developer refactors to ensure that the code is simple and clean (with no duplications and complexity).

The developer iterates till the coding is complete and the acceptance test passes.

The Unit Tests are all collected together and each time a pair integrates and releases code to the repository, the pair needs to ensure that every test runs correctly. If any test fails, the pair knows that it is their code that needs to be corrected as the prior integrations passed without any defects.

Test Driven Development tends to result in 100% unit test coverage and ensures the code to be simple and minimal.

Refactoring – Design Improvement

Refactoring allows the design to evolve incrementally keeping it simple, removing the duplications and complexity as you notice. It improves the design of the existing code without changing its functionality by refactoring.

Refactoring should be driven by learning from new implementations. It is advised to do the Refactoring just after writing new code. Refactoring drives the code towards higherlevel design patterns and is supported by testing.

40-Hour Week – Sustainable Pace

Work at a pace that can be sustained indefinitely. Sustainable Pace ensures the human contribution to the success of the project, considering the facts that −

• Fatigue and stress reduce productivity and also the quality of the product. It may lead to staff-turnover.

• Development does not stop with a sprint, and it should be aiming at long term objectives

• Unless the team agrees on expectations there will not be commitment and accountability.

• Exact hours are not as important as the ability to perform.

• Micro-management should be avoided, while ensuring availability as and when required