1. Extreme Programming: Introduced Matthew Heusser Excelon Development – xndev.com - matt@xndev.com Presented to CS 611 at GVSU, 4/6/2005

2. Surfin’ the waterfall The Caste System The factory mentality Scientific Management ‘Managing Scope Creep’ and other bad ideas Can we have predictability without demeaning people?

3. Enter XP If our software development groups could just provide visibility and consistency, maybe customers, management, and coders could share the uncertainty. “Extreme Programming is a discipline of business and software development that focuses both parties on common, reachable goals. XP teams produce quality software at a sustainable pace. The practices that make up “book” XP are chosen for their dependence on human creativity and acceptance of human frailty.” – Kent Beck, Extreme Programming Installed

4. Implications XP is a from-scratch development model that expects change and tries to share risk, instead of forcing it onto one group or another. The Truth is always a good thing. Even when it’s bad news. Self-Determination (Content, Collaboration, and Choice) The central person in the story of development is the CODER.

5. ‘Book’ XP Whole Team Small Releases Simple Design Test-First DevelopmentDesign Improvement Coding StandardMetaphor Sustainable PaceContinuous Integration Pair Programming Planning Game Collective Code OwnershipCustomer Tests

6. Agile requirements … Customer and Developers write stories Developers estimate stories in “Points”; –1-3 points per story Customers Prioritize Stories Developers break Stories into tasks Developers sign up for work 1 st iteration: Roughly 3 weeks

7. Iterations Iterative Feature-Based Time boxed Incremental –Jim Highsmith, Agile Project Management, 40 Inch-Pebble Concept

8. Releases However often you need to realease 3 months sounds about right (or does it?)

9. ‘Whole’ Team Concept Customers are members of the team Co-Location Who needs a ‘spec’?

10. “When will you be done?” 3 weeks Implications

11. Velocity V = D/T Velocity = Points Accomplished/Weeks Velocity normalizes over time Points for a story – “About the same size as” heuristics get better over time

12. On estimating Simple Working System Feature at a time Spikes as risk management

13. Design Sessions Two guys at a Whiteboard Emergent design (3 weeks ain’t that long) Very few, high-value artifacts Focus on design, documentation, etc in working code (you ain’t gonna update it)

14. Coding sessions Pair Programming One Task at a time / Continuous Integration Integration Machine Test Everything that could possibly break AUTOMATED, Test Driven Development – Unit, Integration, System

15. More coding Collective Code Ownership Coding Standard Simple Design Refactoring

16. Code Standards Indentation Capitalization Hungarian Notation (Variable Names) Curly-Brace Placement Function Names

17. Problems with frequent release Regression Testing

18. Test Driven Development Objects and Functions have unwritten, contracted behavior Mis-understanding about expected behavior causes integration defects Automated tests establish and evaluate expected behavior

19. More TDD Test-First Development (see handout) Maintenance programming: Find a defect, write a test for it, fix it, make sure it passes the test After the fix, automatically regression test the entire system

20. The XP Life-Style Sustainable Pace Rarely work 1 week of mild overtime Minimal Coding Simplest solution Least number of interfaces, modules, classes, functions Do not "design for extensibility" Refactoring Get Rid of Duplicate Code

21. “Steering” Requirements & Priorities Change Estimates change – Truth is good Steer the iteration/steer the release by managing velocity, stories, and bugs

22. When do you release? Customer-derived acceptance test No QA Department! No V&V! Iterate until the customer is happy or the money runs out. (Shippable at any time; always deliver business value.)

23. No Testers? 3. Cease dependence on mass inspection Eliminate the need for mass inspection as the way of life to achieve quality by building quality into the product in the first place. Require statistical evidence of built in quality in both manufacturing and purchasing functions. - Dr. Deming’s 3 rd Point of TQM Note that this requires massive, constant peer review. (Pair Design, Pair Programming, Pair Test Script Writing …)

24. XP Values Simplicity, Communication, Courage, Feedback You ain’t gonna need it Simplest thing that could possibly work

25. Tailoring XP Few people do ‘book’ XP Use what works for you Apply context-driven principles No Testers?

26. Cons Probably best for small-to-medium projects Involves change and investment (time) in learning new methods of testing Culture Problems (“We don’t need no silly pair programming”) May have problems with shrink-wrapped development

27. Conclusions XP is a collection of mutually supportive practices that optimize the shared mental model and keeps developers working on code.

28. Discussion

29. References http://www.xprogramming.com Extreme Programming Installed Extreme Programming Explained Planning Extreme Programming Agile Project Management