Extreme Programming

1. Extreme Programming Alexander Kanavin Lappeenranta University of Technology

2. Some background • Lightweight vs heavyweight methodologies • Software Engineering Institute Capability Maturity Model (SEI CMM) • Extreme Programming

3. Basic ideas • Was put together as a response to the increasing difficulty of practicing heavyweight methodologies, especially in medium and small projects • Has very few rules and practices

4. Rules • Fall into four categories • Planning • Design • Coding • Testing

5. Rules for 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

6. Rules for planning 2 • Move people around • A stand-up meeting starts each day • Fix XP when it breaks

7. Design rules • Simplicity • Choose a system metaphor • Use CRC cards for design sessions • Create spike solutions to reduce risk • No functionality is added early • Refactor whenever possible

8. Coding rules • The customer is always available • Code must be written to agreed standards • Code the unit test first • All code is pair programmed • Only one pair integrates code at a time • Integrate often

9. Coding rules 2 • Use collective code ownership • Leave optimization till last • No overtime work

10. Testing • All code must have unit tests • All code must pass unit tests before it can be released • When a bug is found tests are created • Acceptance tests are run often and the results are published

11. Weaknesses of XP • Outstanding abilities of the team • Having customer on site • Doesn’t work in a large environment, with no contracting customer, few experts or simultaneous hardware development

12. Going further • http://www.extremeprogramming.org • Books: Amazon, Books.ru