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

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, 11.10.00 Hubert Baumeister

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, 11.10.00 Hubert Baumeister

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, 11.10.00 Hubert Baumeister

Dagstuhl, 11.10.00 Hubert Baumeister

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

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, 11.10.00 Hubert Baumeister

“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, 11.10.00 Hubert Baumeister

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, 11.10.00 Hubert Baumeister

80-20 Rule Dagstuhl, 11.10.00 Hubert Baumeister

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, 11.10.00 Hubert Baumeister

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

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

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, 11.10.00 Hubert Baumeister

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, 11.10.00 Hubert Baumeister

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

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, 11.10.00 Hubert Baumeister

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