1. System Analysis & Design Methods V Extreme Programming XP/dX

2. 2V Extreme Programming XP/dX A process: Extreme Programming (Kent Beck) and dX We describe the dX version of XP by Robert C. Martin © Copyright 2003.

3. 3V Extreme Programming XP/dX Extreme Programming (Kent Beck) and dX Structure Iterative development in general Iterative development in general Initial exploration (1st iteration) Initial exploration (1st iteration) Estimating features Estimating features Calibrating estimates Calibrating estimates Planning (2nd and after) Planning (2nd and after) Planning Releases Planning Releases Planning Iterations Planning Iterations Middle (adapting ambitions) Middle (adapting ambitions) Day 10: Feedback about speed: Day 10: Feedback about speed:

4. 4V Extreme Programming XP/dX Extreme Programming (Kent Beck) and dX Structure (continued): What happens in one iteration What happens in one iteration In general In general Practices or habits Practices or habits Pair Programming Pair Programming Acceptation stests Acceptation stests Unit Tests Unit Tests Refactoring Refactoring Open Office Open Office Continuous Integration Continuous Integration

5. 5V Extreme Programming XP/dX Iterative development Iterative development, in general Iterative development, in general Doing everything in 2 weeks : requirements, analysis, design, implementation, testing, documentation. Every 2 weeks end in executable code 1 exception: the first iteration is shorter ( maybe 3 days) and does not need to entail code. Initial exploration (3 days) Initial exploration (3 days) Determine requirements and priorities with the client. Determine user stories (=1 way to use the system) These activities will be repeated in every iteration

6. 6V Extreme Programming XP/dX Iterative development (continued) Initial exploration (continued) Initial exploration (continued) Estimating features Estimating features Every story is assigned an estimate in ‘points’, representing the work needed to implement the story. Every story is assigned an estimate in ‘points’, representing the work needed to implement the story. Dimensionless (unitless) number: you might use ‘perfect programming days’ Dimensionless (unitless) number: you might use ‘perfect programming days’ 1 to 2 team days per story 1 to 2 team days per story Calibrating estimates Calibrating estimates Initial exploration may or may not end in executable code Initial exploration may or may not end in executable code Goal: Determining how many days go into one point. Goal: Determining how many days go into one point.

7. 7V Extreme Programming XP/dX What happens in one iteration 1 iteration = 2 weeks In general In general Run through all phases: requirements, analysis, design & implementation Run through all phases: requirements, analysis, design & implementation ONLY for the user stories, selected by the client. ONLY for the user stories, selected by the client. This way, the most important stories get to be implemented first. This way, the most important stories get to be implemented first.

8. 8V Extreme Programming XP/dX What happens in one iteration (continued) Practices or habits: Practices or habits: Pair-programming Pair-programming 2 programmers per workstation 2 programmers per workstation 1 programmer stays with his task 1 programmer stays with his task change partners every day change partners every day Advantages: automatic code reviews, one person programs, the other one judges, enhances communication. It might reduce the amount of stupid mistakes. Advantages: automatic code reviews, one person programs, the other one judges, enhances communication. It might reduce the amount of stupid mistakes.

9. 9V Extreme Programming XP/dX What happens in one iteration (continued) Practices or habits (continued): Acceptation tests: Acceptation tests: Tests to find out whether the code meets the specifications. Acceptation tests are about the bigger picture (stories) Tests to find out whether the code meets the specifications. Acceptation tests are about the bigger picture (stories) Halfway through 1 iteration (after 1 week) they have to be available. Halfway through 1 iteration (after 1 week) they have to be available.

10. 10V Extreme Programming XP/dX What happens in one iteration (continued) Practices or habits (continued): Unit tests: Unit tests: Tests that run say every 5 minus, while you are programming. Tests that run say every 5 minus, while you are programming. They are automated. You don’t have to go through tens of screens; compare & report happen automatically. They are automated. You don’t have to go through tens of screens; compare & report happen automatically. You write these tests before you write the tested code. You write these tests before you write the tested code. They are a kind of specification documentation and an indication that the specs are met. The test code should have meaningful identifiers, e.g. not xy_132. They are a kind of specification documentation and an indication that the specs are met. The test code should have meaningful identifiers, e.g. not xy_132.

11. 11V Extreme Programming XP/dX What happens in one iteration (continued) Practices or habits (continued): Refactoring Refactoring =Enhancing the design of code without changing its behavior. ( Martin Fowler ) =Enhancing the design of code without changing its behavior. ( Martin Fowler ) Without automated tests, refactoring is risky. Without automated tests, refactoring is risky.

12. 12V Extreme Programming XP/dX What happens in one iteration (continued) Practices or habits (continued): Open Office Open Office Everybody works in the same office. The client too ! This enhances communication. Everybody works in the same office. The client too ! This enhances communication. Continuous integration (controversial) Continuous integration (controversial) No one can block source files. (Version Control) -> This forces every programmer to check in their work quickly, otherwise merges become too difficult. BTW: this issue is controversial but needed for the next point: No one can block source files. (Version Control) -> This forces every programmer to check in their work quickly, otherwise merges become too difficult. BTW: this issue is controversial but needed for the next point: Every programmer regularly runs all unit and acceptance tests. This is pointless if the work of other members is weeks old because they are blocking their source file for weeks. Every programmer regularly runs all unit and acceptance tests. This is pointless if the work of other members is weeks old because they are blocking their source file for weeks.