Agile Development Methods: Philosophy and PracticeHistory of Agile MethodsSlide 312 Principles behind the Agile ManifestoSlide 5Slide 6Slide 7Individuals and Interactions over Processes and ToolsWorking Software over Comprehensive DocumentationCustomer Collaboration over Contract NegotiationResponding to Change over Following a PlanExtreme Programming (XP)Extreme Programming PracticesSlide 14Slide 15Slide 16Slide 17SCRUMSCRUM PracticesSlide 20Slide 21Slide 22Slide 23Other Agile MethodsDrawbacks and Challenges of Agile MethodsResources UsedAgile Development Methods:Philosophy and PracticeCPSC 315 – Programming StudioSpring 2009History of Agile Methods•Particularly in 1990s, some developers reacted against traditional “heavyweight” software development processes.•New methods were being developed and tested, –e.g. extreme programming, SCRUM, Feature-driven development–Generally termed “light” processes•“Representatives” from several of these methods got together in Utah in 2001–Settled on term “Agile” as a way to describe these methods–Called themselves the “Agile Alliance”–Developed a “manifesto” and a statement of “principles”–Focuses on common themes in these alternative methodologiesManifesto for Agile Software DevelopmentWe are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas© 2001, the above authorsthis declaration may be freely copied in any form, but only in its entirety through this notice.12 Principles behind the Agile Manifesto1. Our highest priority is to satisfy the customerthrough early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.12 Principles behind the Agile Manifesto4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.12 Principles behind the Agile Manifesto7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility.12 Principles behind the Agile Manifesto10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.Individuals and Interactions overProcesses and Tools•People make biggest impact on success–Process and environment help, but will not create success•Strong individuals not enough without good team interaction.–Individuals may be stronger based on their ability to work on a team•Tools can help, but bigger and better tools can hinder more than help–Simpler tools can be betterWorking Software overComprehensive Documentation•Documentation important, but too much is worse than too little–Long time to produce, keep in sync with code–Keep documents short and salient•Focus effort on producing code, not descriptions of it–Code should document itself–Knowledge of code kept within the team•Produce no document unless its need is immediate and significant.Customer Collaboration overContract Negotiation•Not reasonable to specify what’s needed and then have no more contact until final product delivered•Get regular customer feedback•Use contracts to specify customer interaction rather than requirements, schedule, and costResponding to Change overFollowing a Plan•Environment, requirements, and estimates of work required will change over course of large project.•Planning out a whole project doesn’t hold up–Changes in shape, not just in time•Keep planning realistic–Know tasks for next couple of weeks–Rough idea of requirements to work on next few months–Vague sense of what needs to be done over yearExtreme Programming (XP)•One of the most well-known agile methods•Developed in 1990s–Kent Beck, 1996–Chrysler Comprehensive Compensation Project–Published book in 1999Extreme Programming Practices1. On-Site Customer–Customer is actively involved with development process–Customer gives “User Stories”•Short, informal “stories” describing features•Keep on “story cards”2. Planning Game–Developers and customers together plan project–Developers give cost estimates to “stories” and a budget of how much they can accomplish•Can use abstract accounting mechanism•Later compare to actual cost, to improve estimates over time–Customer prioritizes stories to fit within budgetExtreme Programming Practices3. Metaphor–Come up with metaphor that describes how the whole project will fit together–The picture in a jigsaw puzzle–Provides framework for discussing project in team–Tools and materials often provide good metaphors4. Small Releases–Time between releases drastically reduced•A few weeks/months–Multiple iterations–Can have intermediate iterations between bigger “releases”Extreme Programming Practices5. Testing–Test-first programming–Unit testing frequently by developers–Acceptance tests defined by customers6. Simple Design–Principles discussed in earlier lectures–Design should be quick, not elaborate–Pick the simplest thing that could possibly work–Resist adding stuff not ready yetExtreme Programming Practices7. Refactoring–Code gets worse with