1. eXtreme Programming (XP) and eXtreme Modeling (XM)
Hubert Baumeister
LMU Munich

2. What is XP? Lightweight software development methodology
Common practices put to the extreme
Developed by Kent Beck & Ward Cunningham
First used in Chrysler C3 project
Dagstuhl,
Hubert Baumeister

3. Scope of XP Small projects: 2-12 programmers
Vague, changing requirements
Programs must be easily testable
Programming environment must allow for easy change
Programmers must be on one place
Dagstuhl,
Hubert Baumeister

4. Assumption of XP Cost of change curve is less steep because
Simple design
Refactoring
Automated tests
Better tools: IDE, Debugger
PL support for abstraction, encapsulation
OO, Modules, etc.
Dagstuhl,
Hubert Baumeister

5. Dagstuhl,
Hubert Baumeister

6. Testing Unit Tests (programmer) Functional Tests (customer)
Automated Tests
xUnit (SUnit, JUnit)
Always test
Test first
Dagstuhl,
Hubert Baumeister

7. Simple Design Use the simplest design to achieve the actual task
Requirements may change!
No duplicated logic
States every intention important to the customer
Fewest possible classes and methods
Dagstuhl,
Hubert Baumeister

8. “Change the structure of the system while keeping its functionality”
Refactoring
“Change the structure of the system while keeping its functionality”
Before implementing a functionality
After implementing a functionality
Tool: RefactoringBrowser (Smalltalk)
Dagstuhl,
Hubert Baumeister

9. Pair Programming Any production code is programmed by pairs
Constant code review
Pairing is dynamic
Helps spread knowledge
May require change in work environment
Dagstuhl,
Hubert Baumeister

10. 80-20 Rule
Dagstuhl,
Hubert Baumeister

11. Project Lifecycle Elaboration (several weeks - months)
Can estimate User Stories
Planning (1-2 days)
Iterations (1-4 weeks)
1. Iteration defines architecture
subsequent iterations defined by the programmer
functional tests are running
Productionizing (first release (2-6 months))
Maintenance (new releases)
Death
Dagstuhl,
Hubert Baumeister

12. Planning Game Split business and technical responsibilities
Customer defines User Stories
Programmer estimates User Stories
Customer selects User Stories for releases and iterations
Dagstuhl,
Hubert Baumeister

13. Development Cycle Get task Select teammate for pairing
Implement test-cases
Implement functionality
Run tests
Refactor
Integrate
Dagstuhl,
Hubert Baumeister

14. Diagrams / Documentation in Design
Diagrams are not forbidden
mostly used for first understanding what to implement
throw away
Observation: Diagrams are not up-to-date
Test and Code provide documentation
Simple design
Collective code ownership
Coding standards
Diagrams for communication
Pair programming
Tasks can be defined to produce diagram
Dagstuhl,
Hubert Baumeister

15. Risks addressed by XP Schedule slips (small releases)
Project canceled (small releases)
System goes sour (simple design)
Defect rate (tests)
Business misunderstood (Customer on-site)
Business changes (continuous integration)
False feature rich (Customer selects User Stories)
Staff turnover (Pair Programming, 40-hour day)
Dagstuhl,
Hubert Baumeister

16. XP not suitable for Projects where
Programmers are on different locations
Project exceeds a certain size
Collaboration between lots of different departments required
Dagstuhl,
Hubert Baumeister

17. eXtreme Modeling (XM) Marko Bogner et. al. XP 2000
Executable UML models (Petri Nets)
state-, activity-, collaboration-, and sequence diagrams
Integration with programming language (Java)
Tests
Diagrams to test diagrams
Diagrams to test programs
Programs to test diagrams
Dagstuhl,
Hubert Baumeister

18. Literatur eXtreme Programming eXtreme Modeling Kent Beck: XP explained
Ron Jeffries: XP installed
Proceedings of XP 2000
Martin Fowler: Refactoring: Improving Design of Existing Code
eXtreme Modeling
Marko Bogner et al: Extreme Modeling, Proc. XP 2000
Stuart Kent’s Web-site
Dagstuhl,
Hubert Baumeister