Lecture 29: Agile Design and Extreme ProgrammingKenneth M. AndersonSoftware Methods and ToolsCSCI 4448/6448 - Spring Semester, 20051April 25, 2005 © University of Colorado, Boulder, 20052Credit where Credit is DueThe material for this lecture is based on content from “Agile Software Development: Principles, Patterns, and Practices” by Robert C. MartinAs such, some of this material is copyright © Prentice Hall, 2003April 25, 2005 © University of Colorado, Boulder, 20053Goals for this lecture(Very) Briefly introduce the concepts of Agile Design and Extreme ProgrammingAlso briefly discuss some of the other Agile methods Agile Design is a design frameworkExtreme Programming is one way to “implement” agile designApril 25, 2005 © University of Colorado, Boulder, 20054Agile Development (I)Agile development is a response to the problems of traditional “heavyweight” software development processestoo many artifactstoo much documentationinflexible planslate, over budget, and buggy softwareApril 25, 2005 © University of Colorado, Boulder, 20055Agile Development (II)A manifesto (from the Agile Alliance)“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to valueindividuals 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 moreApril 25, 2005 © University of Colorado, Boulder, 20056Agile Development (III)From this statement of values, agile development has identified twelve principles that distinguish agile practices from traditional software life cyclesLets look at five of themDeliver Early and Often to Satisfy CustomerWelcome Changing RequirementsFace to Face Communication is BestMeasure Progress against Working SoftwareSimplicity is EssentialApril 25, 2005 © University of Colorado, Boulder, 20057Deliver Early and Often to Satisfy CustomerMIT Sloan Management Review published an analysis of software development practices in 2001Strong correlation between quality of software system and the early delivery of a partially functioning systemthe less functional the initial delivery the higher the quality of the final delivery!Strong correlation between final quality of software system and frequent deliveries of increasing functionalitythe more frequent the deliveries, the higher the final quality!Customers may choose to put initial/intermediate systems into production use; or they may simply review functionality and provide feedbackApril 25, 2005 © University of Colorado, Boulder, 20058Welcome Changing RequirementsWelcome change, even late in the project!Statement of AttitudeDevelopers in agile projects are not afraid of change; changes are good since it means our understanding of the target domain has increasedPlus, agile development practices (such as refactoring) produce systems that are flexible and thus easy to changeApril 25, 2005 © University of Colorado, Boulder, 20059Face to Face Communication is BestIn an agile project, people talk to each other!The primary mode of communication is conversationthere is no attempt to capture all project information in writingartifacts are still created but only if there is an immediate and significant need that they satisfythey may be discarded, after the need has passedApril 25, 2005 © University of Colorado, Boulder, 200510Measure Progress against Working SoftwareAgile projects measure progress by the amount of software that is currently meeting customer needsThey are 30% done when 30% of required functionality is working AND deployedProgress is not measured in terms of phases or creating documentsApril 25, 2005 © University of Colorado, Boulder, 200511Simplicity is EssentialThis refers to the art of maximizing the amount of work NOT doneAgile projects always take the simplest path consistent with their current goalsThey do not try to anticipate tomorrow’s problems; they only solve today’s problemsHigh-quality work today should provide a simple and flexible system that will be easy to change tomorrow if the need arisesApril 25, 2005 © University of Colorado, Boulder, 200512Extreme ProgrammingExtreme Programming (XP) takes commonsense software engineering principles and practices to extreme levelsFor instance“Testing is good?”then“We will test every day” and “We will write test cases before we code”As Kent Beck says extreme programming takes certain practices and “sets them at 11 (on a scale of 1 to 10)”April 25, 2005 © University of Colorado, Boulder, 200513XP Practices The best way to describe XP is by looking at some of its practicesThere are fourteen standard practices, we’ll look at six important onesCustomer Team MemberUser StoriesPair ProgrammingTest-Driven DevelopmentCollective OwnershipContinuous IntegrationApril 25, 2005 © University of Colorado, Boulder, 200514Customer Team MemberThe “customer” is made a member of the development teamA customer representative should be “in the same room” or at most 100 feet away from the developers“Release early; Release Often” delivers a working system to the customer; in between, the customer representative provides continuous feedback to the developersApril 25, 2005 © University of Colorado, Boulder, 200515User Stories (I)We need to have requirementsXP requirements come in the form of “user stories” or scenariosWe need just enough detail to estimate how long it might take to develop software to support this storyavoid too much detail, since the requirement will most likely change; start at a high level, deliver working functionality and iterate based on explicit feedbackApril 25, 2005 © University of Colorado, Boulder, 200516User Stories (II)User stories are not documented in detailwe work out the scenario with the customer “face-to-face”; we give this scenario a namethe name is written on an index carddevelopers then write an estimate on the card based on the detail they got during their conversation with the customerThe index card becomes a “token” which is then used to drive the implementation of a requirement based on its priority and estimated costApril 25, 2005 © University of Colorado, Boulder, 200517Pair ProgrammingAll production code is written by pairs of programmers working together at the same workstationOne member drives the keyboard
View Full Document
Unlocking...