1. Extreme Programming David Li CTO, DigitalSesame

2. Problem in Developing Software The Basic Problem - Risk –Schedule slips –Project canceled –System goes sour –Defect rate –Business misunderstood –Business changes –False feature rich –Staff turnover

3. Software Engineering Models Waterfall Approach –Sequential –Analysis, Design, Development, Test, and Release Spiral Approach –An iterative waterfall RUP (Rational Unified Process) –User-centered design –Business system modeling –Heavy investment up front on analysis

4. The Cost of Change In the past, the cost of changing software over time was exponential –Requirements: $1 –Analysis: $10 –Design: $100 –Implementation: $1,000 –Testing: $10,000 –Production: $100,000 In the present, XP inverts and flattens the cost change curve

5. System Control Variables Cost –Often he most constrained variable –Throwing more money at a problem does not always solve it Time –More time can improve quality and increase scope Quality –The most difficult control variable not as easy to measure –External quality and internal quality Scope

6. Variables Control External forces (managers, customers) get to pick the value of 3 of the 4 variables Development team picks the value of the 4th

7. The Four Values of XP Communication –Pair programming –On site customers Simplicity –“What is the simplest thing that could possibly work?” Feedback –“Have you written a test case for that yet?” Courage –it takes courage to fix architectural flaws 3/4 of the way through a project –it takes courage, and humility, to toss code

8. The Basic Principles Rapid feedback –from both customers and other developers Assume simplicity –solve today’s problems today, and tomorrow’s problems tomorrow Incremental change –solve problems with a series of the smallest changes that will make a difference

9. The Basic Principles Embracing change Quality work –of the 4 control variables, the only possible values are “excellent” and “insanely excellent”

10. Teach learning Small initial investment Play to win Concrete experiments Open, honest communication Work with people’s instincts, not against them The Basic Principles

11. Accepted responsibility Local adaptation Travel Light Honest measurement

12. The Basic Activities Coding –coding as learning –coding as communication Testing –“Anything that can’t be measured, doesn’t exist.” Lock, Berkeley, Hume –automated testing –unit tests and integration tests

13. The Basic Activities Listening –“Programmers don’t know anything.” Designing –creating a structure that organizes the logic in the system

14. The Practices The Planning Game Small Releases Metaphor Simple Design Testing Refactoring

15. The Practices Pair Programming Collective Ownership Continuous integration 40-hour week On-site customer Coding standards

16. Business people decide: –Scope –Priority –Composition –dates of releases Technical people decide: –Implementation estimates –Consequences –Process –Detailed scheduling The Planning Game

17. Small Releases Releases should be as small as possible

18. Metaphor Each project should be guided by a single overarching metaphor, I.e. desktop, business objects, such as customers and orders

19. Simple Design Passes all the tests Has no duplicated logic States every intention important to the team has the fewest possible classes and methods

20. Testing Automated tests are required for all program features

21. Is there a way of changing the existing program to make adding a new feature simple? Now that I’ve added the feature, can I do anything to make the program simpler? Refactoring

22. Pair Programming 2 people, 1machine, 1 keyboard, and 1 mouse 1 person is focused on the here and now, the other person is thinking of the bigger picture

23. Collective Ownership Anybody who sees an opportunity to add value to any portion of the code is required to do so

24. Continuous Integration Code is integrated and tested every few hours, not weeks or months

25. 40-Hour Week “Overtime is a symptom of a serious problem on the project”

26. A real live customer(future product user) must site with the team…being available to answer questions On-site Customer

27. Coding Standards it should become impossible to tell who wrote what code no duplicate code do it right, or don’t do it at all!

28. How to Make this Work Management Strategy –Phased delivery, quick and concrete feedback, clear communication of business needs, and specialists for special tasks Facilities Strategy –Open workspaces with a common programming area

29. How to Make this Work Planning Strategy –The Planning game has 2 players, business and development –Relies on the creation of Story Cards

30. Customer Story and Task Card Date: ________ Story Number: _______ Type of Activity: New: __ Fix: __ Enhance: __ Priority: __________________ Prior Reference: ____________ Functional Test: ____________ Task Description: Notes: Task Tracking: DateStatusTo DoComments _____________________________________

31. Engineering Task Card Date: ________ Story Number: _______ Engineer: _________________ Task Estimate: ____________ Task Description: Software Engineer’s Notes: Task Tracking: DateStatusTo DoComments _____________________________________

32. Relies on continuous integration Collective ownership Pair programming Coding standards Development Strategy

33. Design Strategy Always have the simplest design that runs the current test suite Refactoring

34. Testing Strategy Write tests before we code Derive tests from the customer’s perspective

35. XP Project Lifecycle Exploration –Complete when there’s enough material on the story cards to make a good first release Planning –Customers and programmers agree on a date by which the smallest, most valuable set of stories will be done The plan for the first release should be between 2 – 6 months

36. XP Project Lifecycle Iteration to First Release –Each iteration produces a set of functional test cases for each scheduled story 1 – 4 weeks in duration Productionizing –The end product of a release…feedback cycle is tightened, iterations are weekly or even daily

37. XP Project Lifecycle Maintenance –The normal state of an XP project –Requires simultaneously producing new functionality, keeping the existing system running, incorporating new folks into the team, and bidding farewell to other members Death –The customer can’t generate any new stories –Or…the system isn’t delivering

38. XP Team Roles Programmer –The heart of XP –Requires the habit of simplicity Customer –The other half of the essential duality of Xprogramming –Must write good stories –Must write functional tests

39. XP Team Roles Tester –Focused on the customer..helps the customer generate functional tests Tracker –The conscience of the team…responsible for making estimates

40. Coach –Responsible for the process as a whole –Must notice when team is deviating from the process and call it to their attention Consultant –XP Projects often do not require specialists XP Team Roles

41. Big Boss –Provides the team with courage, confidence, and occasional insistence that they do what they say they do

42. 20-80 Rule and XP The Rule: “80% of the benefit comes from 20% of the work” –This tells the XP Programmer to put the most valuable 20% of functionality into production, do the most valuable 20% of the design, and rely on the 20-80 rule to defer optimization

43. What Makes XP Difficult? It’s not the concepts, it’s the execution! –There are so many factors that can throw the process off course