2. 1 김 수 동 Dept. of Computer Science Soongsil University Tel. 820-0909 Fax. 826-0909 sdkim@comp.ssu.ac.kr www.object.ssu.ac.kr sdkim@comp.ssu.ac.krwww.object.ssu.ac.kr An Overview of eXtreme Programming (XP) April 4, 2001

3. eXtreme Programming ©2001 Soo Dong Kim 2 Contents Motivation and Characteristics of XP RolesRoles XP Life-Cycle

4. eXtreme Programming ©2001 Soo Dong Kim 3 Motivation and Characteristics of XP

5. eXtreme Programming ©2001 Soo Dong Kim 4 Motivation  Software development fails to deliver, and fails to deliver value.  This failure has huge economic and human impact.  Requirement are changed.  Issue of Risk Management

6. eXtreme Programming ©2001 Soo Dong Kim 5 Risks  Schedule slips  Project canceled  System goes sour  Defect rate  Business Misunderstood  Business changes  False Feature Rich  Staff turnover

7. eXtreme Programming ©2001 Soo Dong Kim 6 XP addresses the risks  Schedule slips  Short release cycles, a few months at most, so the scope of any slip is limited.  Within a release, XP uses one to four-week iterations  Project Canceled  Customer chooses the smallest release that makes the most business sense.  System goes sour  XP creates and maintains a comprehensive suite of tests, which are run and re-run after every change.

8. eXtreme Programming ©2001 Soo Dong Kim 7 XP addresses the risks  Defect Rate  Function-by-function test by Programmers  Feature-by-feature test by Customers  Business Misunderstood  Customer to be an integral part of the team  Specification of the project is continuously refined during development, so learning by the customer and the team can be reflected in the software.

9. eXtreme Programming ©2001 Soo Dong Kim 8 XP addresses the risks  Business Changes  XP shortens the release cycle, so there is less change during the development of a single release.  False Feature Rich  XP insists that only the highest priority tasks are addressed.  Staff turnover  Programmers estimate.  Encourages human contact among the team.

10. eXtreme Programming ©2001 Soo Dong Kim 9 Extreme Programming  Discipline of software development with values of simplicity, communication, feedback, and courage.  In XP, the emphasis is on programming.  Build the system in small releases.  Base the program on simple, clear design.  Focus on the roles of customer, manager, programmer and accord key rights and responsibilities to the people in those roles.

11. eXtreme Programming ©2001 Soo Dong Kim 10 Four Values of XP  Communication  Simplicity  Feedback  Courage

12. eXtreme Programming ©2001 Soo Dong Kim 11 Cost of Change  The cost of changing a program rises exponentially over time. RequirementsAnalysisDesig n ImplementationTestingProduction Cost of Change

13. eXtreme Programming ©2001 Soo Dong Kim 12 Cost of Change  With a combination of technology and programming practices, the curve can be quite the opposite. Time Cost of change

14. eXtreme Programming ©2001 Soo Dong Kim 13 Cost of Change  If change is ruinously expensive, …  If change stays cheap, the additional value and reduced risk of early concrete feedback outweighs the additional cost of early change.  In XP,  Smaller-sized Stories  A simple design  Automated tests  Lots of practice in modifying the design

15. eXtreme Programming ©2001 Soo Dong Kim 14 Roles

16. eXtreme Programming ©2001 Soo Dong Kim 15 Customer Role  Defining business value  Choosing among the stories with great flexibility  Deciding what to do now and what to defer until later  The team predicts how much work can be done in any given time period.  Defining the tests

17. eXtreme Programming ©2001 Soo Dong Kim 16 Programmer Role  Estimate the difficulty of all stories.  Analyze, design, test, program, and integrate the system.  Write all production code in pairs.  Keep the system integrated at all times.  Track the pace at which they can deliver stories to the customer.  Write all production code in pairs.

18. eXtreme Programming ©2001 Soo Dong Kim 17 Manager Role  Brings the customer and developers together and helps them meld into a smoothly operating team.  Remove obstacles.  Letting the workspace arranged effectively  Cause, coordinate and report  planning, designing, testing, coding, releasing

19. eXtreme Programming ©2001 Soo Dong Kim 18 Manager and Customer Rights  Right to an overall plan  User Stories, Small Releases  Right to get the most value out of every programming week  Iteration Planning  Right to see progress in a running system  Small Releases, Continuous Integration, Acceptance Tests

20. eXtreme Programming ©2001 Soo Dong Kim 19 Manager and Customer Rights  Right to change your mind, to substitute functionality, and to change priorities.  Refactoring  Right to be informed of schedule changes, in time to choose how to reduce scope to restore the original date.  Resource, Scope, Quality, Time

21. eXtreme Programming ©2001 Soo Dong Kim 20 Programmer Rights  Right to know what is needed, with clear declarations of priority  Right to produce quality work at all times  Pair Programming  Right to make and update your own estimates  Right to accept your responsibilities instead of having them assigned to you

22. eXtreme Programming ©2001 Soo Dong Kim 21 XP Life-Cycle

23. eXtreme Programming ©2001 Soo Dong Kim 22 XP Life-Cycle  Customers define, Programmers build. Customer Programmer Build value Choose value Estimate cost Define value Programmer Customer Learn

24. eXtreme Programming ©2001 Soo Dong Kim 23 Project Flow  An XP project begins with  On-site customer  Acceptance tests  Focus on small releases, each one defined by customer.  Work in short iterations, again working on the customer’s stories of highest business value.

25. eXtreme Programming ©2001 Soo Dong Kim 24 Project Flow  Programmer follow practices  Simple Design  Refactoring  Collective Code Ownership  Pair Programming  Unit Tests

26. eXtreme Programming ©2001 Soo Dong Kim 25 Practices  Planning  Quickly determine the scope of the next release.  Small releases  Put a simple system into production quickly.  Metaphor  Guide all development with a simple shared story of how the whole system works.  Simple design  The system should be designed as simply as possible at any given moment.

27. eXtreme Programming ©2001 Soo Dong Kim 26 Practices  Testing  Programmers continually write unit tests.  Customers write tests demonstrating that features are finished.  Refactoring  Programmers restructure the system without changing its behavior to remove duplication, improve communication.

28. eXtreme Programming ©2001 Soo Dong Kim 27 User story  A short description of the behavior of the system from the point of view of the user of the system  User story is the medium of analysis.  XP chooses informal analysis.  Write the story on a single card.  4x6 or 5x8 Unlined Cards  Each story is simple enough that programmers can understand it and can see how to implement it in a week or so.

29. eXtreme Programming ©2001 Soo Dong Kim 28 User Story  1 st Component  Writing the story in a couple of sentences and pointing to any supporting documentation  2 nd Component  A series of conversations that will take place between the customer and the programmers over the life story

30. eXtreme Programming ©2001 Soo Dong Kim 29 How Many Stories ?  Depends on the complexity of the system.  Rule of Thumb  At least one story / Programmer-Month  Two stories are preferred.  For ten people for six months, 60 to 120 stories  For planning purposes, stories should encompass a week or two of programmer time.

31. eXtreme Programming ©2001 Soo Dong Kim 30 Pair Programming  Two programmers are working together to write the program, side by side.  Driver and Partner  Partner is actively engaged and helping every minute.  Two programmers working together generate more code, and better code, than the same two programmers working separately.

32. eXtreme Programming ©2001 Soo Dong Kim 31 Pair Programming  Partner keeps track of things.  Spots simple errors.  Making sure that our strategy is consistent and reminds driver of the names of them methods and variables we’ve just defined.  Acts as the pair’s conscience, reminding us to keep the code communicative, to keep it formatted to the team’s standards, and to keep it tested.

33. eXtreme Programming ©2001 Soo Dong Kim 32 Q & A