Agile Development And Extreme Programming
Agile Development andExtreme ProgrammingCSCI 5828: Foundations ofSoftware EngineeringLecture 24Kenneth M. Anderson
Credit where Credit is Due The material for this lecture is based oncontent from “Agile Software Development:Principles, Patterns, and Practices” by RobertC. MartinAs such, some of this material is copyright Prentice Hall, 2003April 12, 2007 University of Colorado, 20072
Goals for this lecture (Very) Briefly introduce the concepts of AgileDesign and Extreme ProgrammingAgile Design is a design frameworkExtreme Programming is one way to“implement” agile design Other agile life cycles include SCRUM, Crystal,feature-driven development, and adaptivesoftware developmentSee http://www.agilealliance.org/ for pointersApril 12, 2007 University of Colorado, 20073
Outline Background on Agile MethodsExtreme ProgrammingAgile Perspective on Software DesignApril 12, 2007 University of Colorado, 20074
Agile Development (I) Agile development is a response to theproblems of traditional “heavyweight”software development processes too many artifactstoo much documentationinflexible planslate, over budget, and buggy softwareApril 12, 2007 University of Colorado, 20075
Agile Development (II) A manifesto (from the Agile Alliance) “We are uncovering better ways of developingsoftware by doing it and helping others 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 theright, we value the items on the left moreApril 12, 2007 University of Colorado, 20076
Agile Development (III) From this statement of values, agile developmenthas identified twelve principles that distinguish agilepractices from traditional software life cyclesLets look at five of them Deliver Early and Often to Satisfy CustomerWelcome Changing RequirementsFace to Face Communication is BestMeasure Progress against Working SoftwareSimplicity is EssentialApril 12, 2007 University of Colorado, 20077
Deliver Early and Often to Satisfy Customer MIT Sloan Management Review published ananalysis of software development practices in 2001 Strong correlation between quality of software system andthe early delivery of a partially functioning system the less functional the initial delivery the higher the qualityof the final delivery!Strong correlation between final quality of software systemand frequent deliveries of increasing functionality the more frequent the deliveries, the higher the final quality!Customers may choose to put initial/intermediatesystems into production use; or they may simplyreview functionality and provide feedbackApril 12, 2007 University of Colorado, 20078
Welcome Changing Requirements Welcome change, even late in the project!Statement of Attitude Developers in agile projects are not afraid ofchange; changes are good since it means ourunderstanding of the target domain has increasedPlus, agile development practices (such asrefactoring) produce systems that are flexible andthus easy to changeApril 12, 2007 University of Colorado, 20079
Face to Face Communication is Best In an agile project, people talk to each other! The primary mode of communication isconversation there is no attempt to capture all project information inwritingartifacts are still created but only if there is animmediate and significant need that they satisfy April 12, 2007they may be discarded, after the need has passed University of Colorado, 200710
Measure Progress against Working Software Agile projects measure progress by theamount of software that is currently meetingcustomer needs They are 30% done when 30% of requiredfunctionality is working AND deployedProgress is not measured in terms of phasesor creating documentsApril 12, 2007 University of Colorado, 200711
Simplicity is Essential This refers to the art of maximizing theamount of work NOT done Agile projects always take the simplest pathconsistent with their current goalsThey do not try to anticipate tomorrow’s problems;they only solve today’s problemsHigh-quality work today should provide a simpleand flexible system that will be easy to changetomorrow if the need arisesApril 12, 2007 University of Colorado, 200712
The Other Seven The other seven principles are Deliver working software frequentlyStakeholders and developers work together dailyBuild projects around motivated individualsAgile processes promote sustainable developmentContinuous attention to technical excellence and gooddesign enhances agilityAgile team members work on all aspects of the projectAt regular intervals, the team reflects on how to becomemore effectiveApril 12, 2007 University of Colorado, 200713
Outline Background on Agile MethodsExtreme ProgrammingAgile Perspective on Software DesignApril 12, 2007 University of Colorado, 200714
Extreme Programming Extreme Programming (XP) takes commonsensesoftware engineering principles and practices toextreme levels For instance “Testing is good?” then “We will test every day” and “We will write test cases beforewe code”As Kent Beck says extreme programming takescertain practices and “sets them at 11 (on a scale of1 to 10)”April 12, 2007 University of Colorado, 200715
XP Practices The best way to describe XP is by looking atsome of its practices There are fourteen standard practicesCustomer Team MemberUser StoriesShort CyclesAcceptance TestsPair ProgrammingTest-Driven DevelopmentCollective OwnershipApril 12, 2007 University of Colorado, 2007Continuous IntegrationSustainable PaceOpen WorkspaceThe Planning GameSimple DesignRefactoringMetaphor16
Customer Team Member The “customer” is made a member of thedevelopment team The customer is the person or group who definesand prioritizes featuresA customer representative should be “in the sameroom” or at most 100 feet away from thedevelopers“Release early; Release Often” delivers a workingsystem to the client organization; in between, thecustomer representative provides continuousfeedback to the developersApril 12, 2007 University of Colorado, 200717
User Stories (I) We need to have requirementsXP requirements come in the form of “userstories” or scenarios We need just enough detail to estimate how longit might take to support this story April 12, 2007avoid too much detail, since the requirement will mostlikely change; start at a high level, deliver workingfunctionality and iterate based on explicit feedback University of Colorado, 200718
User Stories (II) User stories are not documented in detail we work out the scenario with the customer “face-to-face”;we give this scenario a namethe name is written on an index card developers then write an estimate on the card based on thedetail they got during their conversation with the customerThe index card becomes a “token” which is thenused to drive the implementation of a requirementbased on its priority and estimated costApril 12, 2007 University of Colorado, 200719
Short Cycles (I) An XP project delivers working softwareevery two weeks that addresses some of theneeds of the customer At the end of each iteration, the system isdemonstrated to the customer in order to getfeedbackApril 12, 2007 University of Colorado, 200720
Short Cycles (II) Iteration Plan The collection of user stores that will be implementedduring this iterationdetermined by a “budget” of pointsthe budget is determined by the progress made on theprevious iterationRelease Plan A plan that maps out the next six iterations or so (3months)A release is a version of the system that can be put intoproduction useApril 12, 2007 University of Colorado, 200721
Acceptance Tests Details of a user story are captured in the form ofacceptance tests specified by the customer The tests are written before a user story is implementedThey are written in a scripting language or testingframework that allows them to be run automatically andrepeatedlyOnce a test passes, it is never allowed to fail again (at leastfor very long)These tests are run several times a day each time thesystem is builtApril 12, 2007 University of Colorado, 200722
Pair Programming All production code is written by pairs of programmers workingtogether at the same workstation One member drives the keyboard and writes code and testcases; the second watches the code, looking for errors andpossible improvementsThe roles will switch between the two frequentlyPair membership changes once per day; so that eachprogrammer works in two pairs each day this facilitates distribution of knowledge about the state of the codethroughout the entire teamStudies indicate that pair programming does not impactefficiency of the team, yet it significantly reduces the defect rate! [Laurie Williams, 2000] [Alistair Cockburn, 2001] [J. Nosek, 1998]April 12, 2007 University of Colorado, 200723
Test-Driven Development All production code is written in order to make failingtest cases pass First, we write a test case that fails since the requiredfunctionality has not yet been implementedThen, we write the code that makes that test case passIteration between writing tests and writing code is veryshort; on the order of minutesAs a result, a very complete set of test cases iswritten for the system; not developed after the factApril 12, 2007 University of Colorado, 200724
Collective Ownership A pair has the right to check out ANY module andimprove it Developers are never individually responsible for aparticular module or technologyContrast this with Fred Brook’s conceptual integrityand the need for a small set of “minds” controlling asystem’s design Apparent contradiction is resolved when you note that XPis designed for use by small programming teams; I haven’tseen work that tries to scale XP to situations that require100s or 1000s of developersApril 12, 2007 University of Colorado, 200725
Continuous Integration Developers check in code and integrate itinto the larger system several times a daySimple Rule: first one to check-in “wins”;everyone else mergesEntire system is built every day; if the finalresult of a system is a CD, a CD is burnedevery day; if the final result is a web site, theydeploy the web site on a test server, etc. This avoids the problem of cutting integrationtesting to “save time and money”April 12, 2007 University of Colorado, 200726
Sustainable Pace A software project is not a sprint; it’s amarathon A team that leaps off the starting line and races as fast as itcan will burn out long before the finish lineThe team must instead “run” at a sustainable paceAn XP rule is that a team is not allowed towork overtime This is also stated as “40 hour work week”April 12, 2007 University of Colorado, 200727
Open Workspace The team works together in an open room Each pair of programmers are within earshot of each other;information is communicated among the team quickly There are tables with workstationsThere are whiteboards on the walls for the team members to usefor status charts, task tracking, UML diagrams, etc.“War room” environments can double productivity 6144705.htmJoel on Software disagrees lApril 12, 2007 University of Colorado, 200728
The Planning Game Customer decides how important a feature isDevelopers decide how much that feature costsAt the beginning of each release and/or iteration,developers give customers a budget based onproductivity of previous iterationCustomers choose user stories whose costs total upto but do not exceed the budget The claim is that it won’t take long for customer anddevelopers to get used to the systemand then the pace can be used to estimate cost andscheduleApril 12, 2007 University of Colorado, 200729
Simple Design An XP team makes their designs as simpleand expressive as they can be They narrow focus to current set of stories andbuild the simplest system that can handle thosestoriesMantras Consider the Simplest Thing That Could PossiblyWorkYou Aren’t Going to Need ItOnce and Only Once (aka Don’t Repeat Yourself)April 12, 2007 University of Colorado, 200730
Refactoring XP teams fight “code rot” by employingrefactoring techniques constantly They have the confidence to do this because theyalso use test-driven designBy “constantly” we mean every few hours versus“at the end of the project”, “at the end of therelease”, or “at the end of the iteration”April 12, 2007 University of Colorado, 200731
Metaphor (I) The big picture that ties the whole system together Vocabulary that crystallizes the design in a team member’sheadApril 12, 2007 University of Colorado, 200732
Metaphor (II) Example A system that transmits text to a screen at 60chars per second; programs write to buffer, whenbuffer full, programs are suspended, when bufferempty, programs are activated April 12, 2007Metaphor: Dump Trucks Hauling GarbageScreen “Garbage Dump”, Buffer “Dump Truck”,Programs “Garbage Producer” University of Colorado, 200733
Metaphor (III) Example network traffic analyzer, every 30 minutes, system polleddozends of network adapters and acquired monitoringdata; Each adaptor provides block of data composed ofseveral variables Metaphor: A toaster toasting bread Data Block “Slices” Variables “Crumbs” Network analyzer “The Toaster” Slices are raw data “cooked” by the toasterApril 12, 2007 University of Colorado, 200734
Benefits of XP Customer FocusEmphasis on teamwork and communicationProgrammer estimates before implementationEmphasis on responsibility for qualityContinuous measurementIncremental developmentSimple designFrequent redesign via refactoringFrequent testingContinuous reviews via pair programmingApril 12, 2007 University of Colorado, 200735
Criticisms of XP Code centered vs. Design centered Lack of design documentation Hurts when developing large systemsLimits XP to small systemsProducing readable code is hardCode not good as serving as documentation (listings can run to1000s of pages)Lack of structured inspection process (can miss defects)Limited to narrow segment of software application domainsMethods are only briefly describedDifficult to obtain management supportLack of transition support (how do you switch from waterfall or otherprocess?)April 12, 2007 University of Colorado, 200736
Outline Background on Agile MethodsExtreme ProgrammingAgile Perspective on Software DesignApril 12, 2007 University of Colorado, 200737
Agile Methods: Perspective on Design Agile methods have an approach to softwaredesign that includes identifying aspects of bad designavoiding those aspects via a set of principlesApril 12, 2007 University of Colorado, 200738
Bad Design Rigidity: The design is hard to changeFragility: The design is easy to breakImmobility: The design is hard to reuseViscosity: It is hard to do the right thingNeedless Complexity: OverdesignNeedless Repetition: Copy and PasteOpacity: Disorganized ExpressionApril 12, 2007 University of Colorado, 200739
Good Design Principles The Single Responsibility PrincipleThe Open-Closed PrincipleThe Liskov Substitution PrincipleThe Dependency Inversion PrincipleThe Interface Segregation PrincipleApril 12, 2007 University of Colorado, 200740
Single Responsibility Principle A class should have only one reason to change If a class has more than one responsibility, theresponsibilities can become coupled changes to one can impact the otherIf a class has a single responsibility, you can limit theimpact of change with respect to that responsibility to thisone classExample Class Rectangle with draw() and area() methods draw() is only used by GUI apps, separate theseresponsibilities into different classesApril 12, 2007 University of Colorado, 200741
Open-Closed Principle Discussed previously in Lecture 20A class should be open to extension butclosed to modification Allows clients to code to class without fear of laterchangesApril 12, 2007 University of Colorado, 200742
Liskov Substitution Principle Also discussed in lecture 20Subclasses need to respect the behaviorsdefined by their superclasses if they do, they can be used in any method thatwas expecting the superclassIf a superclass method defines pre and postconditions a subclass can only weaken the superclass precondition, and can only strenghen the superclasspost-conditionApril 12, 2007 University of Colorado, 200743
Example (I)class Rectangle {private int width;private int height;public void setHeight(int h) { height h }public void setWidth(int w) { width w }} postcondition of setHeight?postcondition of setWidth?April 12, 2007 University of Colorado, 200744
Example (II)class Square extends Rectangle {public void setHeight(int h) {super.setHeight(h)super.setWidth(h)}public void setWidth(int w) {super.setWidth(w)super.setHeight(w)}}Does this maintain the postconditions of thesuperclass?April 12, 2007 University of Colorado, 200745
Example (III) Let’s checkpublic void checkArea(Rectangle r) {r.setWidth(5);r.setHeight(4);assert (r.area() 20);// fails when Square is passed} Whoops!April 12, 2007 University of Colorado, 200746
Example (IV) In order to achieve the Liskov substitutabilityprinciple, Square’s methods needed to have equalor stronger postconditions than its superclass For setWidth: Rectangle: width w && height old.height Square: width w && height wThe postcondition for Square is weaker than thepostcondition for Rectangle because it does not attempt toenforce the clause (height old.height)April 12, 2007 University of Colorado, 200747
Dependency-Inversion Principle High-level modules should not depend onlow-level modules; Both should depend onabstractions In response to structured analysis anddesign, in which stepwise refinement leads tothe opposite situation high-level modules depend on lower-levelmodules to get their work doneApril 12, 2007 University of Colorado, 200748
Why “inversion”? DIP attempts to “invert” the dependenciesthat result from a structured analysis anddesign approach High-Level modules tend to contain importantpolicy decisions and business rules related to anapplication; they contain the “identity” of anapplication April 12, 2007If they depend on low-level modules, changes in thosemodules can force the high-level modules to change!High-level modules should not depend on low-levelmodules in any way University of Colorado, 200749
Solution (I) In a layered system, a “higher” layer definesan interface that lower layers implementTypical Layered SystemApril 12, 2007 University of Colorado, 200750
Solution (II)Layered Systemwith DIP appliedApril 12, 2007 University of Colorado, 200751
Inversion of Ownership Its not just an inversion of dependency, DIPalso inverts ownership Typically a service interface is “owned” ordeclared by the server, here the client isspecifying what they want from the serverApril 12, 2007 University of Colorado, 200752
Depend on Abstraction A simple heuristic based on DIP No variable should reference a concrete classNo class should derive from a concrete classNo method should override an implementedmethod of any of its base classesNote: this is just a heuristic, not somethingthat can be universally applied but its use can lead to lower coupling within asystemApril 12, 2007 University of Colorado, 200753
Interface Segregation Principle Clients should not be forced to depend on methodsthat they do not use Concerns classes with “fat” interfaces what we’ve been calling a non-cohesive moduleA class with a “fat” interface has groups of methodsthat each service different clients This coupling is bad however, s
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
The most popular agile methodologies include: extreme programming (XP), Scrum, Crystal, Dynamic Sys-tems Development (DSDM), Lean Development, and Feature Driven Development (FDD). All Agile methods share a common vision and core values of the Agile Manifesto. Agile Methods: Some well-known agile software development methods include: Agile .
1. The need for an agile way of working 6 2. The need for an agile way of working 9 3. Agile Core Values - Agile Project Management Vs. 10 Agile Event Management 4. Agile principles 12 _Agile Principles of Agile Project Management 13 _Agile Principles of VOK DAMS Agile Event Management 14 5. Agile Methods 16 _Scrum in Short 16 _Kanban in Short 18
Agile Estimating and Planning by Mike Cohn Agile Game Development with Scrum by Clinton Keith Agile Product Ownership by Roman Pichler Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and .
1.1 Purpose of the Agile Extension to the BABOK Guide1 1.2 What is Agile Business Analysis?2 1.3 Structure6 Chapter 2:The Agile Mindset 2.1 What is an Agile Mindset?7 2.2 The Agile Mindset, Methodologies, and Frameworks8 2.3 Applying the Agile Mindset9 2.4 Agile Extension and the Agile Ma
Agile World View "Agility" has manydimensions other than IT It ranges from leadership to technological agility Today's focus is on organizational & enterprise agility Agile Leaders Agile Organization Change Agile Acquisition & Contracting Agile Strategic Planning Agile Capability Analysis Agile Program Management Agile Tech.
AGILE TESTING For agile testers, test engineers, test managers, developers, technical leads. Ensure the production of effective and valuable software. Agile Fundamentals Agile Programming Agile Software Design Agile Fundamentals Agile Testing Agile Test Automation ICP CERTIFIED PROFESSIONAL ICP CERTIFIED PROFESSIONAL ICP-PRG CERTIFIED .
2. Quality Assurance AND Methods of Agile 3. Metrics of quality AND Agile quality assurance 4. Agile AND Quality 5. Agile Quality AND Software Development 6. Agile quality AND Agile methods The search keywords for agile particulars have been merged by using the Boolean ''OR" operator, which
1. Agile methods are undisciplined and not measurable. 2. Agile methods have no project management. 3. Agile methods apply only to software development. 4. Agile methods have no documentation. 5. Agile methods have no requirements. 6. Agile methods only work with small colocated teams.-7. Agile methods do not include planning. 8.
