1. Extreme Programming (XP) Web Applications and Services

2. Agenda l Software Processes l What is XP? l XP Practices l Management Strategy l Facilities Strategy l Planning Strategy l Design Strategy l Development Strategy l Testing Strategy l When to use XP?

3. Software Processes l What is a software process? l Major models: The Waterfall model. The Iterative (Incremental) model. l An example of a new iterative software process: Extreme Programming (XP).

4. Waterfall Model Structure Analysis Design Code Test

5. Iterative Model Structure Analysis Design Code Test System Complete? Operation and Maintenance No Deliver IncrementYes Deliver System

6. What is XP? l “XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software”. -Kent Beck

7. XP is Different l Early, concrete, and continuous feedback from short-cycles. l Incremental planning approach. l Flexibility of scheduling the implementation based on changing business needs. l Reliance on tests written by the programmers. l Reliance on the collaboration of programmers.

8. Software Processes Analysis Design Code Test WaterfallIterativeXP Kent Beck 1999

9. XP Practices l Planning game. l Small releases. l Simple design. l Testing. l Refactoring. l Coding standards. l Pair programming. l Collective ownership. l On-site customer. l 40-hour week. l Open workspace. l Continuous integration.

10. Management Strategy l Be available as a development partner. l See long term refactoring goals. l Help programmers with individual technical skills like testing and refactoring. l Explain the process to upper level managers. l Keep track with software metrics.

11. Management Strategy- Meeting l Daily Stand-up Meeting Entire team Problems. Solutions. Stand in a circle Avoid long discussions. No side conversations.

12. Summary of Management Strategy l Coach: help, plan and manage. l Track software metrics. l Daily stand-up meeting.

13. Facilities Strategy l Open space. l Tables in the middle of the space. l Cubbies around the outside of the space. l A room with a nice view -if possible. Extreme Programming Explained 2000 The DaimlerChrysler C3 work area

14. Planning Strategy- Guidelines l Only plan -in details- for the next release. l Accepted responsibility. l The person responsible for implementation gets to estimate. l Planning for priorities vs. planning for development.

15. Planning: User Stories l User stories are written by the customers – features the system needs to do- l Much simpler format than traditional requirements specifications: 3 sentences written by customers. Non-technical terminology. l KEY: Stories that are most valuable to the customer are developed first.

16. Planning -Story Card Extreme Programming Explained 2000

17. Planning: Iterations l Developers give each user story an estimate of 1, 2, or 3 weeks. l Stories are then organized in order of importance to the customer. l The development schedule is divided into iterations of 1 to 3 weeks in length based on the user stories.

18. Planning: Releases l Releases are iterative versions of the system released by the development team to the customers. Released at the end of iteration. An integrated working system. Includes the latest successfully implemented, integrated, and tested story from that iteration.

19. Customer System Priority Organization of user stories Release 1Release 2Release 3 Story 1Story 2Story 3 Division of system into user stories Iteration 1 Iteration 2 Iteration 3 Story 2Story 3Story 1 Iterations assigned for the development of each story Working, tested system with story 2 integrated

20. Iteration Breakdown l Each iteration is broken down into programming tasks for developing the user story of that iteration. l Each task is 1-3 days in duration. l Each programming pair choose a task (or more). l The programming pair then design test cases and implement them.

21. Iteration Breakdown Test Case 1Test Case 2Test Case 3 Task 1Task 2Task 3 One iteration Development of one user story Integrate into the system Passed

22. Summary of XP Planning User Stories Priorities IterationsReleases Tasks Test Cases

23. Design Strategy -Rules l Always do the simplest thing that could possibly work. l Use CRC cards for design One card per object.

24. Design Strategy -Rules l Never add functionality early. “Only 10% of that extra stuff will ever get used, so you are wasting 90% of your time” “Concentrate on what is scheduled for today only” ExtremeProgramming.org l Refactor: replace anything complex with something simpler. Remove redundancy. Eliminate unused functionality. Enhance efficiency.

25. Summary of Design Rules The goal is simple code on time so: Keep things simple and clean. Refactor. Stick to the planned schedule.

26. Development Strategy - Guidelines l Collective code ownership Encourages all programmers to contribute to all segments of the project. l Coding standards Consistency saves time and money. Makes it easier for the entire team to code and refactor.

27. Development Strategy - Guidelines l Write the test case before the code. l Continuous integration. l 40 hour week Projects requiring overtime will be late anyway. Avoid overtime. l Pair programming.

28. Pair Programming l Two brains are better than one. l Pairs consider more possible solutions to a problem. l Design alternatives increase.

29. Pair Programming 7.65.6Score 6.64.0Enjoy 30.242.6Time 6.53.8Confidence 5.64.2Functionality 2.01.4Readability Teams (mean)Individuals (mean) John Nosek, “The Case for Collaborative Programming,” Communications of the ACM, March 1998, Vol. 41, No. 3 pp. 105-108.

30. Summary of Development Strategy l Write the test case before the code. l Collective code ownership. l Coding standards. l Continuous integration. l Pair programming. l 40 hour week.

31. Testing Strategy –Unit Testing l Unit testing (test cases) Programmers write their own unit tests Create tests BEFORE the code. Programmers implement one unit test at a time. After 100% of unit tests are passed, that unit can be integrated. During integration, all previous tests are run to verify the overall system still runs.

32. Testing Strategy -Integration l Code integration One pair at a time. Prevents problems introduced when integrating modules. Maintain a latest version. Allows for parallel coding. Integrate often.

33. Testing Strategy -Acceptance Test l Acceptance tests User stories are the basis for acceptance testing. Black box testing.

34. Summary of Testing Pair Programming Continuous Integration 100% Unit Tests Passed Acceptance Tests Passed Create Unit Test Failed Passed End of Task Run all unit tests ExtremeProgramming.org

35. Customers l Customer availability On site customer. l Duties Write stories. Define the priorities of the stories. Define the scope or timing of releases.

36. XP Favorable Conditions l Dynamically changing requirements and functionality. l Small groups of programmers 2-12. l Input by customers and managers. l Testability.

37. XP is against “BigDesignUpFront” l The Code is the Design l “When the original phases of software development were laid down, they were just plain wrong. Requirements, Design, Implementation, and Test are not what we think they are. Design is not something that you do only before you code. Implementation is not the act of coding. We can see this if we look realistically at what they are in other engineering disciplines.” l "The final goal of any engineering activity is to create some kind of documentation.” l “After reviewing the software development lifecycle today, it appears that the only software documentation that actually seems to satisfy the criteria of an engineering design are the source code listings. “ l XP is often accused of not believing in comments. That’s not exactly true. They do believe heavily in “Self-documenting code” But they also believe “The position of the article was not that source code makes all other documentation obsolete, it is simply that the act of programming is designing.”

38. Ward Cunningham On Comments l We comment methods only after doing everything possible to make the method not need a comment. l We prefer to clarify the code directly over putting in an explanation of what the code could say it if were better done. We have written "literate programs", cf DonKnuth, and no one has used them. Too bad, really, they were cool.

39. Can this really work? l There are several Fortune 500 companies that are now using XP, including Ford, Daimler-Chrysler, and First Union. l But it only works ALL TOGETHER. “AlmostXP is like being AlmostAlive or AlmostSolvent.” The emphasis on readable code (even without comments) works because Pair Programming ensures readable code The integrating constantly is made possible by the Unit Tests The lack of up-front design effort works because the User is on-site, the user stories drive the effort, and there’s a high degree of communication among the team members

40. XP Path

41. XP Development

42. XP Collective Code Ownership

43. Lessons Learned

44. Companies That Use XP l Knowledge management software. l Chrysler. l Thought works. l Andrena objects. l EuropeLoan bank. l Evant solutions. l Acxiom. l Workshare technology.

45. References l Extreme Programming Explained: Embrace Change by Kent Beck l Planning Extreme Programming by Kent Beck, Martin Fowler l Extreme Programming Installed by Ron Jeffries, Ann Anderson, Chet Hendrickson, Kent Beck, Ronald E. Jeffries l Extreme Programming in Practice, by James W. Newkirk, Robert C. Martin l Extreme Programming Examined by Giancarlo Succi, Michele Marchesi

46. Websites l www.extremeprogramming.org l www.xprogramming.com l www.pairprogramming.com l www.xp123.com

47. Questions?