Agile Development and Extreme Programming CSCI 5828 Foundations of Software Engineering Lecture 5 Supplement Kenneth M Anderson Credit where Credit is Due The material for this lecture is based on content from Agile Software Development Principles Patterns and Practices by Robert C Martin As such some of this material is copyright Prentice Hall 2003 January 29 2007 University of Colorado 2007 2 Goals for this lecture Very Briefly introduce the concepts of Agile Design and Extreme Programming Agile Design is a design framework Extreme Programming is one way to implement agile design Other agile life cycles include SCRUM Crystal feature driven development and adaptive software development See http www agilealliance org for pointers January 29 2007 University of Colorado 2007 3 Outline Background on Agile Methods Extreme Programming January 29 2007 University of Colorado 2007 4 Agile Development I Agile development is a response to the problems of traditional heavyweight software development processes too many artifacts too much documentation inflexible plans late over budget and buggy software January 29 2007 University of Colorado 2007 5 Agile 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 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 January 29 2007 University of Colorado 2007 6 Agile Development III From this statement of values agile development has identified twelve principles that distinguish agile practices from traditional software life cycles Lets look at five of them Deliver Early and Often to Satisfy Customer Welcome Changing Requirements Face to Face Communication is Best Measure Progress against Working Software Simplicity is Essential January 29 2007 University of Colorado 2007 7 Deliver Early and Often to Satisfy Customer MIT Sloan Management Review published an analysis of software development practices in 2001 Strong correlation between quality of software system and the early delivery of a partially functioning system the 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 functionality the 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 feedback January 29 2007 University of Colorado 2007 8 Welcome Changing Requirements Welcome change even late in the project Statement of Attitude Developers in agile projects are not afraid of change changes are good since it means our understanding of the target domain has increased Plus agile development practices such as refactoring produce systems that are flexible and thus easy to change January 29 2007 University of Colorado 2007 9 Face to Face Communication is Best In an agile project people talk to each other The primary mode of communication is conversation there is no attempt to capture all project information in writing artifacts are still created but only if there is an immediate and significant need that they satisfy January 29 2007 they may be discarded after the need has passed University of Colorado 2007 10 Measure Progress against Working Software Agile projects measure progress by the amount of software that is currently meeting customer needs They are 30 done when 30 of required functionality is working AND deployed Progress is not measured in terms of phases or creating documents January 29 2007 University of Colorado 2007 11 Simplicity is Essential This refers to the art of maximizing the amount of work NOT done Agile projects always take the simplest path consistent with their current goals They do not try to anticipate tomorrow s problems they only solve today s problems High quality work today should provide a simple and flexible system that will be easy to change tomorrow if the need arises January 29 2007 University of Colorado 2007 12 The Other Seven The other seven principles are Deliver working software frequently Stakeholders and developers work together daily Build projects around motivated individuals Agile processes promote sustainable development Continuous attention to technical excellence and good design enhances agility Agile team members work on all aspects of the project At regular intervals the team reflects on how to become more effective January 29 2007 University of Colorado 2007 13 Outline Background on Agile Methods Extreme Programming January 29 2007 University of Colorado 2007 14 Extreme Programming Extreme Programming XP takes commonsense software engineering principles and practices to extreme levels For 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 January 29 2007 University of Colorado 2007 15 XP Practices The best way to describe XP is by looking at some of its practices There are fourteen standard practices Customer Team Member User Stories Short Cycles Acceptance Tests Pair Programming Test Driven Development Collective Ownership January 29 2007 University of Colorado 2007 Continuous Integration Sustainable Pace Open Workspace The Planning Game Simple Design Refactoring Metaphor 16 Customer Team Member The customer is made a member of the development team The customer is the person or group who defines and prioritizes features A 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 client organization in between the customer representative provides continuous feedback to the developers January 29 2007 University of Colorado 2007 17 User Stories I We need to have requirements XP requirements come in the form of user stories or scenarios We need just enough detail to estimate how long it might take to support this story January 29 2007 avoid too much detail since the requirement will most likely change start at a high level deliver working functionality and iterate based on explicit feedback
View Full Document
Unlocking...