Extreme Programming - Rules
Consider any sport that you play. You need to abide by the rules of that sport or game. In a similar way, in Extreme Programming as the entire project is driven by collaboration among the team members and with the business (who represents the customer), certain rules for the project need to be laid out at the beginning itself. These rules should be at par with the Extreme Programming practices.
The rules provide a common reference for everyone on the team so that they remind everyone of what and how they need to do when things go smoothly and also when they are not going well.
The game that we refer to in the Extreme Programming is Planning Game.
Rules of Planning Game
In Extreme Programming, the planning game begins with the first-release planning meeting and ends with the final release.
You must define the rules of the Planning Game in line with the Extreme Programming practices before the first release planning meeting and familiarize the rules to the business and the team. You must manage the project ensuring that the rules are adhered to.
However, in software development, there is no way that a simple set of rules apply in every project. They may have to vary according to the business and the team, not compromising on the Extreme Programming practices. Hence, a set of rules with the necessary goals can initially be put in place and they can be modified as the development progresses only if required.
The goal of the game is to maximize the value of software produced by the team. From the value of the software, you have to deduct the cost of its development, and the risk incurred during development.
The strategy for the team is to invest as little as possible to put the most valuable functionality into production as quickly as possible in conjunction with the design and coding strategies to reduce risk.
In view of the technology and business lessons of this first working system, it becomes clear to business what is now the most valuable functionality, and the team quickly puts this into production.
This process continues with iterations and releases till the entire development is complete.
The basic rules of planning game can be categorized into the following areas −
Planning
Managing
Designing
Coding
Testing
Planning
Planning is done during release planning and iteration planning. The rules are same for both.
In Release planning,
Business and the team are the players.
Story cards are used.
User stories are written by the customer on story cards.
User stories are written by the customer on story cards.
Business is decided on the priority of the functionality for implementation.
Estimates are given by the team based on the story cards.
Short (frequent small) releases are to be planned
Release schedule is to be created with mutual agreement.
The next release is to be divided into iterations.
Iteration planning starts each iteration.
In Iteration planning,
The team members are the players.
Task cards are used.
For each story selected for the iteration, the task cards are produced.
The team members have to estimate the tasks based on the task cards.
Each team member is assigned with task cards.
Each team member has to then re-estimate based on his or her assignment, for
Accepting the work.
Taking responsibility of the completion of the work.
Getting feedback about the actual time taken.
Improving the estimates.
Respecting those estimates.
Thus, the rules for who can make and change the estimates are clear.
Managing
The team is given a dedicated open workspace.
Each workstation is to be arranged such that two developers can sit side by side and easily slide the keyboard and mouse.
Sustainable pace is to be set (40-hour week and no overtime for more than one week) and managed.
Enforce the rules of the planning game.
Fixing any extreme programming practice when it breaks.
Ensure Communication among the Team.
Discourage Communication that is −
not helpful
not at the right time
done in great detail
Make people move around.
Measure the actual times and convey to team periodically so that each team member will know the performance as against prediction. This ensures that the team member improves in estimating.
Make food available to the team as and when required.
Designing
The rules of designing are −
Choose a metaphor for the system and evolve it as development progresses.
Keep the design simple.
No functionality is added early.
Put as much architecture in place now as you need to meet your current needs, and trust that you can put more in later
Refactor whenever and wherever possible.
Coding
The rules of coding are −
The business (who represents the customer) should always be available.
Developers should write all the code in accordance with rules emphasizing communication through the code.
Pair programming should be ensured.
Coding standards are to be followed.
All code must have unit tests.
Write a unit test first, before the code is written for each piece of the system so that it is much easier and faster to create your code. The combined time it takes to create a unit test and create some code to make it pass is about the same as just coding it up straight away. It eases regression testing.
When you are coding you should be wearing only one of the following four hats −
Adding new functionality, but only changing the implementation.
Adding new functionality, but only changing the interface.
Refactoring code, but only changing the implementation.
Refactoring code, but only changing the interface .
A dedicated integration workstation is provided for the entire team.
Only one pair integrates code at a time and ensures all the tests are passed.
Integration should be done often.
Collective ownership should be used.
Testing
The rules of testing are −
All codes must pass all unit tests before it is released.
Tests are to be written when a defect is found.
Acceptance tests are to be run often.
