1. XP (not Microsoft) e X treme P rogramming Can KOMAR can.komar@boun.edu.tr

2. eXtreme Programming2 23/11/2005 Contents Introduction Why XP? Values of XP Overview of XP Practices of XP Discussion

3. eXtreme Programming3 23/11/2005 What is XP? XP is a specific instantiation of an agile process XP combines best practices in a different way XP is a different approach to development XP provides a core process model XP is not intended to be a complete framework

4. eXtreme Programming4 23/11/2005 Cost of Change Req Analysis Design Code Test O&M XP View Cost of Change Req Analysis Design Code Test O&M Traditional View

5. eXtreme Programming5 23/11/2005 4 Values of XP Simplicity  KISS  Implement the simplest that works Communication  Use all means that enable better communication Feedback at various levels  minutes  unit tests, days  functional tests, weeks  early production  User stories determine the scope Courage  Refactor when needed  Throw away code when no longer needed

6. eXtreme Programming6 23/11/2005 Project Overview http://www.extremeprogramming.org

7. eXtreme Programming7 23/11/2005 Iteration Overview http://www.extremeprogramming.org

8. eXtreme Programming8 23/11/2005 Development Overview http://www.extremeprogramming.org

9. eXtreme Programming9 23/11/2005 “Circles of Life” On-site Customer Release Planning Small Releases Acceptance Tests Pair Programming Unit Tests Refactoring Simple Design Coding Standards Collective Ownership Continuous Integration Metaphor Sustainable Pace Customer – Team – Developer Pair – Team – Customer

10. eXtreme Programming10 23/11/2005 Customer – Team – Developer Pair – Team – Customer On-site Customer Release Planning Small Releases Acceptance Tests Pair Programming Unit Tests Refactoring Simple Design Coding Standards Collective Ownership Continuous Integration Metaphor Sustainable Pace “Circles of Life”

11. eXtreme Programming11 23/11/2005 On-Site Customer(s) Empowered to determine requirements, define functionality, set priorities, and answer questions for the programmers Daily, face-to-face customer interaction should…  reduce the amount of hard-copy documentation  and the high cost associated with its creation and maintenance

12. eXtreme Programming12 23/11/2005 Release Planning a.k.a. “Planning Game” Requires the XP "customer" to define the business value of desired features  User Stories Programmers (not just PM) provide cost estimates for those features Using this information, customer and developers perform a cost/benefit analysis of each feature  enables them to make intelligent decisions about which features to implement and which to defer

13. eXtreme Programming13 23/11/2005 User Story #1 A person registers with the agency by providing personal information, information,about the kind of person they are seeking, an alias to conceal Their true identity, and confidential contact details. Story 1

14. eXtreme Programming14 23/11/2005 User Story #2 A selection of matching clients is displayed, and an email may be sent to any one of them. A charge will be made for this service. Story 2

15. eXtreme Programming15 23/11/2005 Small Releases Put a simple system into production quickly, then release new versions on a very short cycle For example  Release might be 2-3 months  Each release might have multiple 2-4 week iterations Helps establish a “rhythm”  Customer and team knows when feedback will occur Allows the real business value of the product to be evaluated in a real-world environment

16. eXtreme Programming16 23/11/2005 Test-Driven Development a.k.a. “Test First”, “Test Infected”  ACCEPTANCE TESTS: Customers are asked to provide acceptance tests in advance of the development of the system. (automated?)  UNIT TESTS: Programmers write tests first based on user stories (requirements) and then create software that fulfills the requirements reflected in the tests. AUTOMATE, AUTOMATE, AUTOMATE (JUnit, XUnit)  By coding to meet test requirements, we ensure that mandatory features are provided

17. eXtreme Programming17 23/11/2005 On-site Customer Release Planning Small Releases Acceptance Tests Pair Programming Unit Tests Refactoring Simple Design Coding Standards Collective Ownership Continuous Integration Metaphor Sustainable Pace Customer – Team – Developer Pair – Team – Customer “Circles of Life”

18. eXtreme Programming18 23/11/2005 Refactoring Programmers restructure system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility Small steps Code, test, refactor, test, code, test, refactor  Beck suggests short cycle (10 minutes) Typical goal of refactoring is to move toward a design pattern

19. eXtreme Programming19 23/11/2005 Refactoring while( no_matches < 20) { find_another_match(); }  Const int max_matches = 20; While(no_matches < max_matches) {

20. eXtreme Programming20 23/11/2005 Pair Programming All production code written with 2 programmers at 1 machine  One tactical, one strategic Pairing should be dynamic  Members in pair switch roles every 30-60 minutes  Change pairs each task Experiments showing effectivenes

21. eXtreme Programming21 23/11/2005 Pair Programming What does it buy you?  Continuous Code Review  Continuous requirements & domain knowledge reinforcement  Continuous skills training (Java, Design Patterns, Refactoring, CM or IDE tools, etc.) Developers have more trouble with this concept than managers  Need to try it a few times to see if it works  Takes time to get acclimated  More intense development experience

22. eXtreme Programming22 23/11/2005 Simple Design Based on philosophy that highest business value is derived from the simplest program that will meet current requirements. Don’t over-engineer a solution! While many preach K.I.S.S., this concept is one of the hardest to apply! 2 common philosophies of XP teams:  DTSTTCPW - Do The Simplest Thing That Could Possibly Work  YAGNI - You Aren't Gonna Need It

23. eXtreme Programming23 23/11/2005 Unit Tests Test a little, code a little…  “Test-first programming” Tests become the specification Tests give confidence in the system Tests give courage to change the system

24. eXtreme Programming24 23/11/2005 Unit Tests

25. eXtreme Programming25 23/11/2005 Customer – Team – Developer Pair – Team – Customer On-site Customer Release Planning Small Releases Acceptance Tests Pair Programming Unit Tests Refactoring Simple Design Coding Standards Collective Ownership Continuous Integration Metaphor Sustainable Pace “Circles of Life”

26. eXtreme Programming26 23/11/2005 Coding Standards Programmers write all code in accordance with rules emphasizing communication throughout the code Goal: Self-documenting code Because the “common language” is the code More than Javadoc; good Javadocs with clear inline comments

27. eXtreme Programming27 23/11/2005 Metaphor The XP concept of “architecture” Guide all development with a single shared story of how the whole system works Defines a "system of names" and guides the team's development and communication

28. eXtreme Programming28 23/11/2005 Continuous Integration Integrate & build the system several times a day Integrate every time a task is completed Let’s you know every day the status of the system

29. eXtreme Programming29 23/11/2005 Collective Ownership Any programmer can change any code anywhere in the system at any time This works best if using Coding Standards, Test- Driven Development and Pair Programming (Synergy) Gives the team more flexibility for vacation, sick leave, turn over  Progress doesn’t stop on a component because one of the team members is not present

30. eXtreme Programming30 23/11/2005 Sustainable Pace Tired programmers often write lower-quality code Minimizing overtime and keeping programmers fresh will produce higher-quality code in less time Set 40-45 hours as a rule  Based on team preference Corollary: Never work overtime a second week in a row  Avoid burnout

31. eXtreme Programming31 23/11/2005 A Day In XP

32. eXtreme Programming32 23/11/2005 References http://www.extremeprogramming.org http://www.xprogramming.com http://www.junit.org http://www.refactoring.com http://www.refactoring.com http://www.pairprogramming.com Extreme Programming Explained – Kent Beck Refactoring – Martin Fowler Planning Extreme Programming – Kent Beck et al Extreme Programming Installed – Ron Jeffries et al Extreme Programming Examined – Giancarlo Succi et al Extreme Programming in Practice – Robert C. Martin et al Extreme Programming Explored – William C. Wake Extreme Programming Applied – Ken Auer et al The Costs and Benefits of Pair Programming – Alistair Cockburn et al

33. eXtreme Programming33 23/11/2005 Discussion Is pair programming a good idea? Under what conditions can it be or vice versa? Do you really believe XP can solve dynamic requirements problem? Do you think involving the customer into the development area is a good idea? What are the (possible) pros and cons of XP? If you were a project manager what would you consider before adopting XP?

34. Thank you… Any questions?