Extreme Programming Rules
nirav June 13th, 2007
If you are familiar with Extreme Programming, these rules are not new to you. If you are not, they will certainly give you a lot of insight in good software development. We have been using many XP principles in our projects, and have had very good success.
Here are the XP rules, straight from the XP website.
Planning
- User stories are written.
- Release planning creates the schedule.
- Make frequent small releases.
- The Project Velocity is measured.
- The project is divided into iterations.
- Iteration planning starts each iteration.
- Move people around.
- A stand-up meeting starts each day.
- Fix XP when it breaks.
Designing
- Simplicity.
- Choose a system metaphor.
- Use CRC cards for design sessions.
- Create spike solutions to reduce risk.
- No functionality is added early.
- Refactor whenever and wherever possible.
Coding
- The customer is always available.
- Code must be written to agreed standards.
- Code the unit test first.
- All production code is pair programmed.
- Only one pair integrates code at a time.
- Integrate often.
- Use collective code ownership.
- Leave optimization till last.
- No overtime.
Testing
- All code must have unit tests.
- All code must pass all unit tests before it can be released.
- When a bug is found tests are created.
- Acceptance tests are run often and the score is published.
Sometimes I think these are too idealistic. The real world demands are to deliver working software fast. A team that’s tuned to extreme programming can certainly deliver good code quickly, but most programmers are taught differently. They are not tuned to pair programming or test driven development. Many managers too doubt the value of these principles. That makes it more difficult to implement them.
I am dreaming of a project where we can implement all these rules!
- programming , familiar , principles , projects , insight , rules , Recommended Reading , Business , extreme , success , Technology
- Comments(0)
