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. Planning - user stories Like use cases Written by the customers as things that the system needs to do for them Used for time estimation and release planning Avoid specifics (GUI layouts and such

8. Release planning meeting Creation of a release plan document Planning of individual iterations Estimation of user stories in terms of ideal programming weeks

9. Release plan Specifies exactly which user stories are going to be implemented for each system release and dates for the releases Stories are translated into acceptance tests

10. Make frequent small releases For valuable feedback Important features are introduced early - more time to fix them

11. Project velocity How many user stories were finished during the iteration Allows estimation for future iterations

12. Iterative development Don’t schedule tasks in advance Don’t look ahead and add anything that’s not scheduled for this iteration

13. Iteration planning meeting Customer chooses user stories from the release plan, that are most valuable to him These are translated into the programming tasks (1 to 3 ideal programming days) Project velocity is used to estimate if the iteration is overbooked or not.

14. Move people around Avoiding knowledge loss and coding bottlenecks Everyone knows enough about every part of the system

15. Daily stand up meeting Everyone stands up in a circle Prevents it from dragging on for too long Communications of problems, solutions and promotion of team focus

16. 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

17. Simplicity Needs no explanation Keeping a design simple is hard work, however

18. Choose a system metaphor Allows consistent naming of classes and methods Being able to guess how something is named is important (time saver)

19. CRC cards Class, Responsibilities and Collaboration Used to represent objects Class written on top Responsibilities on the left Collaborating classes to the right of each responsibility

20. Spike solution A very simple program to explore potential solutions Throw-away program

21. Never add functionality early Avoid the tempation Concentrate on what is scheduled for today only

22. Refactoring Rewriting a piece of program so that it does the same thing, but does it better Removing redundancy, elimination of unused code, getting rid of obsolete designs Helps keep the design simple and keeping code clean and concise

23. 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

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

25. Customer is always available To write user stories To select user stories Developers need to talk with the customer to get enough detail to complete a programming task Functional testing

26. Coding standards Self-explanatory

27. Code the unit test first It’s easier to create code after creating tests Tests define the requirements

28. Pair programming Sitting side by side in front of the monitor One person types and thinks tactically The other one thinks strategically

29. Sequential integration Solves problems of parallel integration Using a physical token or a dedicated computer

30. Integrate often Every few hours, not more than a day Helps detect compatibility problems early, promotes communication

31. Collective code ownership Everyone contributes ideas to all parts of the project (or fixes bugs or refactors) No one becomes a bottleneck The architecture is distributed among the team

32. Optimize last Don’t try to guess what the bottleneck is going to be Make it work right, then make it work fast

33. No overtime If it requires overtime, it will be late no matter what Use a release planning meeting to change the timing

34. 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

35. Unit tests Enables collective code ownership Enables refactoring Enables frequent integration

36. Unit testing framework A development tool, not a testing tool Helps formalize requirements, clarify architecture, debug, optimize and test Example: Junit - a unit testing framework for Java,

37. When a bug is found Create an acceptance test and unit tests to guard against it coming back

38. Acceptance tests Created from user stories Black box system tests Customer verifies the correctness of the tests

39. 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

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