In their book “Extreme Programming Refactored: The Case against XP” Stephens and Rosenberg (2003) outline their reasons for not liking XP as it is published, but they also outline what they do like and how risk can be reduced when using an XP like process. I found their book rather long (and the humour rather unentertaining) but they made some good points and I made a few notes about their conclusions.
Practices/Xtudes/Values/Tenets
Stephens and Rosenberg (2003) comment on the various XP practices, attitudes, values and tenets.
The Planning Game
The release plan is useful – broad view of progress with activity broken into fixed iterations. Estimating the effort for tasks and tracking project velocity are also useful.
Short Iterations
One month iterations (a la Scrum) are better than 1-3 weeks as they provide less distractions. However, progress should be tracked weekly regardless of length of the iteration.
Small Releases
Small releases are good because they provide useful feedback on the usability of the system, helps people form a view on how useful the functionality is, and helps generates requests for changes (faults and/or enhancemens) to the functionality. But not all releases have to be production ready. Most releases should be for internal consumption as production ready releases require more effort.
Metaphor
Metaphor is not a replacement for architecture.
Simple Design
Over engineering is bad but so is excessive refactoring. Do enough upfront architecture and design. Document it. This should be done by the developers on the team, not an architect who then leaves the project.
Refactoring
Refactoring is a useful practice, in moderation. Use refactoring to improve the quality of existing code. Don’t use it as a replacement for design, and don’t do it continuously.
Testing
Automated testing is good. Developers should test their code, and having a customer test is a good thing too, but you also need a separate test team.
Requirements Documentation
Handwritten “Stories” on index cards are insufficient documentation. Needs something fuller, stored electronically, and signed off. Possibly start with a short high level spec and break this into parallel subprojects which are fleshed out over time.
Colocated Team
Colocation is a good idea, but is hardly ever possible. Even when it is possible you need more documentation than XP suggests; when colocation isn’t possible you need a lot more documentation and more phone calls.
Pair Programming
Pair Programming is useful for solving hard problems, but shouldn’t be mandatory. It is not a replacement for code reviews.
Spikes
Prototypes are good. Do them as early as possible and do as many as needed to give confidence in the design.
Continuous Integration
Frequent integration is better – say once a day. This gives developers a chance to tackle bigger chunks of work and ensure they are working before the automated integration + test happens.
Sustainable Pace (40-hour week)
A sustainable pace is good, but there will be spikes in work flow.
On-site customers
An on-site customer is alright, but remember there are many sources of requirements (e.g. other users, management, project sponsor i.e. the person with the cheque book).
Collaborative Coding Standards
Coding standards are good. Should cover layout and good programming practice.
Additional Practices
Stephens amd Rosenberg (2003) suggest some addition practices.
The Stopgap
Get a release out early without putting the project into maintenance mode.
Additional Roles
– Technical Team Leader – like a coach but can say “just do it!”
– Quality Assurance, i.e. tester
– Interaction Designer
Documentation
Document the design.
Individual Ownership
Individual ownership is an effective alternative to collective ownership.
References
Stephens, M., & Rosenberg, D. (2003). Extreme Programming Refactored: The Case against XP. Apress.