Presentation on theme: "eXtreme Programming (XP)"— Presentation transcript:
1eXtreme Programming (XP) CSE301University of SunderlandHarry R. Erwin, PhD
2SourcesStephens and Rosenberg, 2003, Extreme Programming Refactored: The Case Against XP, Apress.Fowler, 2000, Refactoring: Improving the Design of Existing Code, Addison-Wesley.Martin, 2003, Agile Software Development: Principles, Patterns, and Practices, Prentice-Hall.Extensive discussions on comp.objectEbert 2000,
3Where do Agile Methods Fit? Projects where the risk is high.Where you or your customer don’t know where you’re going.Projects where you have to learn and adapt.Projects where the technology is evolving rapidly.
4Extreme Programming Defined (Beck, 1998, Cunningham’s wiki) Is defined by the following:ValuesPracticesActivitiesRolesIntended to flatten the cost of change curve.Just one of several agile methods.
5Manifesto for Agile Software Development (Martin 2003) “We are uncovering better ways of developing software by doing it and by helping others to do it. Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.”
6Principles behind the Agile Manifesto (from Martin 2003) “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.Business people and developers must work together daily throughout the project.
7Principles (II)“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.Working software is the primary measure of progress.Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
8Principles (III)“Continuous attention to technical excellence and good design enhances agility.Simplicity—the art of maximizing the amount of work not done—is essential.The best architectures, requirements, and designs emerge from self-organizing teams.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
9Problems Targeted by XP Lack of communicationRequirements volatilitySoftware development that isn’t used.Out of date documentationObsolescence
10XP Values Communication—verbal, with a collocated team. Simplicity—always do the simplest thing that can possibly work.Feedback—continuous from the customer.Courage—willingness to change.
11Communication—Verbal, with a Collocated Team. Reduces the chance of misunderstanding.Creates risks, however:Details get lost if they’re not written down.You’re vulnerable to loss of personnel.YMMV.
12Simplicity—Always do the Simplest Thing that can Possibly Work. You Ain’t Gonna Need It (YAGNI).Absolute simplicity isn’t always the best solution, so be as simple as possible but not too simple.Nonfunctional requirements will affect simplicity.
13Feedback—Continuous from the Customer. Go ask the customer—he’s sitting over there.Also used in design:Build a first-order prototypeTest itAdjust it until it’s right.A little bit of feedback can replace a lot of analytical work.
14Courage—Willingness to Change. Be willing to make design changes when they are right.It helps a lot to have an automatic test suite to tell you that you’re still OK.
16XP RolesProgrammerTesterTrackerCoachConsultantBig boss
17XP Practices Test-driven development User stories The planning game Whole teamShort cyclesMetaphorSimple designRefactor mercilesslyCollective ownershipPair programmingContinuous integrationSustainable paceCoding standardsAcceptance tests(Emergent design)
18Test-Driven Development ‘The test-driven development is the method of software development where tests specify interfaces of implementation and all code must have passed the tests.’ (Wikipedia)Martin (2003): ‘programmers work in very short cycles, adding a failing test, then making it work.’
19User Stories One or two sentences summarizing what the user wants. Describes how the system is supposed to workWritten on a card.Sufficient detail to support estimation.
20The Planning GameMartin (2003): “Planning is continuous and progressive. Every two weeks, for the next two weeks, developers estimate the cost of candidate features, and customers select those features to be implemented based upon cost and business value.”
21The Planning GamePlanning is an emotional minefield. Of course Development would like to program faster. Of course the project manager would like to be able to say exactly how fast Development can go. Of course Business would like to be able to say exactly what they want. Of course Business would rather not change its mind. When any of the participants in planning begin acting these wishes (or rather in accordance with the fears that lie behind each wish), then planning doesn't work well. (Wikipedia)
22How to Plan Maintain velocity. Merging and splitting stories: User stories should be ‘right-sized’.Prototyping sessions are called ‘spikes’. These allow the team’s velocity to be estimated.
23XP Life Cycle Evolutionary development Coding is continuousIterations of 1-3 weeksDesign -> Code -> Integrate -> TestRepeated several times a dayBased on ‘user stories’
24Whole TeamMartin (2003): “All the contributers to an XP project—developers, business analysts, testers, etc.—work together in an open space, members of one team. The walls of this space are littered with big visible charts and other evidences of their progress.”
25Short Cycles1-3 week cycles. Other processes suggest a month, with weekly tracking.
26MetaphorMartin (2003): “The team develops a common vision of how the program works.”
27Simple DesignMartin (2003): “The team keeps the design exactly suited for the current functionality of the system. It passes all the tests, contains no duplication, expresses everything the authors want expressed, and contains as little code as possible.”
28Simple DesignThe simplest design that can meet the current set of user stories.“You aren’t going to need it.”Once and only once—no code duplication.
29Refactor Mercilessly We’ve discussed this. Don’t churn the code. Keep it clean to support extension.
30Refactoring Deals with code ‘rot’. Refactoring is a technique to restructure code in a disciplined way. For a long time it was a piece of programmer lore, done with varying degrees of discipline by experienced developers, but not passed on in a coherent way. (Fowler)
31Collective OwnershipMartin (2003): “Any pair of programmers can improve any code at any time.”
32Pair ProgrammingMartin (2003): “All production software is built by two programmers, sitting side by side, at the same machine.”Boehm (2004) indicates that pair programming is about 10% slower, but the software fault rate of the resulting code is about 60% less. This is a ‘silver bullet’.
33Pair ProgrammingPair Programming (ExtremeProgrammingPractice) requires two engineers to participate in one development effort at one workstation. Each member performs the action the other is not currently doing: While one types in unit tests the other thinks about the class that will satisfy the test, for example. Studies have shown that, after training for the "PeopleSkills" involved two programmers are more than twice as productive as one for a given task. (Wikipedia)
34Continuous Integration Martin (2003): “The team keeps the system fully integrated at all times.”
35Sustainable PaceMartin (2003): “The team is in it for the long term. They work hard, at a pace that can be sustained indefinitely. They conserve their energy, treating the project as a marathon rather that a sprint.”
36Coding StandardsMartin (2003): “All the code in the system looks as if it was written by a single—very competent—individual.”
37Acceptance TestsMartin (2003): “As part of selecting each desired feature, the customers define automated acceptance tests to show that the feature is working.”
38Emergent Design The initial design and architecture will be wrong. If you can’t change it, you’ll have to live with it for years.Let it emerge through refactoring so it is right.
39Interaction Between Practices XP is believed to work only when all practices are followed.Then the weaknesses of one practices are covered by the strengths of others.For example:Use of emergent design is well-known to be risky. Constant refactoring protects against that risk.Constant refactoring is a time sink and a source of bugs—extensive unit testing protects against that.Reliance on unit tests does not validate the design. Pair programming protects against design errors.
40What Practices are Provably Good? The following practices should be followed independently of development model:Test-driven developmentShort cycles (early warning)Metaphor (leadership)Simple design (KISS)Refactor mercilessly (isn’t eclipse wonderful?)Pair programming* (more productive than alone)Sustainable pace (ever been ‘fried’?)Coding standards (for yourself if no one else)*except on homework projects…
41Conclusions If XP is the answer, what is the question? Certain kinds of problems, especially those where you don’t know where you’re going, are particularly suitable for XP, so be prepared for it, even if on other projects you have to use a heavy-weight process.