Agile software development

1. Agile software development

2. The tale of thedragon hunter … Once upon a time, therewas a youngchinesewhodecidedto devote hiswholelifetolearntheancient art of dragonhunting… … And he didit, untilthemomentwhen he wassurethat he kneweverythingthatcouldbelearntaboutthetechniquestohuntdragons… … butthen he realizedthattherewere no dragons in theworldthatcouldbehunted… so… … he devotedtherest of hislifetoteachhowtohuntdragons.

3. Introduction • In the late 90s, two important new lines in software engineering: • Desing patterns development • Agile software development methods ¿What is Agile?

4. Introduction • In theearly 90s, a studydeveloped at IBM byCockburn: • Successfuldevelopmentteamsswearedthattheydidn’tapply formal methodsneither CASE tools, and thattheyestimulatedinformationflow and tests. • Theteamsthathadproblems in theirprojectsdidn’tudnestandthereason, cause thefollowedstrictlythe formal methods. • Theexperiencewasrepeatedallalongthedecade, allaroundtheworld and witheverykind of tool. • Conclussion: Lessemphasis in anexhaustivedocumentation and more in runableversions of theprojectthat can betested. Thefirst are promisses, thelatter, facts.

5. Software developmentmethodologies • Thetraditionalengieeringinspiredmethodologiesfor software developmenttheyimpose a disciplinedprocesstoreachtheirobjective: makethework predictible, efficient and planned. …but… • Theydidn’t stand out as successful. Ontheotherhand, theyrevealed as buraucratic and document-oriented

6. Agile methods • They emerge as a reaction to the tradictional software development methods. • They are based on the adaptability, instead of predictability. • More people-oriented than process-oriented. • To be able to undestand the foundations of the agile methods, we must look through the nature of the software development activity.

7. Take a look totheorigin:Design and construction in engineering. • Thedesignspecifythepartsand thewaytheyinteract. • Thedesign in thebasis of theconstruction plan • The plan defines tasks and inter-tasksdependencies, allowingto define theagenda and constructionbudget. • Thedesignprocessrequireshighqualifiedskills, whileconstructiontaksrequireslessqualified and, consequently, cheaperskills. • A gooddesignstablishes a straigth and plannedwaytobuildtheapplication.

8. And whataboutthe UML? Theorically: • Ifwe are ableto capture alltheimportantdecissionsaboutdesign in UML diagrams… we are supposedtobeabletodirectlydevelope a solid, robust and well-plannedcontruction plan. • Thecodingtasksshouldbejustanalmostmechanictranslationprocessfromdesigntotheprogramminglanguage. But in the real world… • UML design are nevergoodenougthtotranfertheprogammerwhatto do. • They can look goodonthepaper, but show theirproblems once they are programmed.

9. Whataboutthe UML? • The models developed by civil engineers are based on a wide experience and the key factors can be checked mathematically. …while… • The UML designs are only verificable by pair-reviewing. They are usefull but many of their deficiencies are discovered only during coding and testing phases.

10. And whathappenswiththerequirements? • Themostrecurringproblem in a software projectistheoneoriginatedfromtheever presente changes of therequirements. • Theclassicwaytofaceit: • Assumeit as a sympton of a poorrequirementengineering. • Sign a contractwithyourcustomerbeforestartingthedevelopmentprocess. • Forbidanychange once theprojectstarted. • Problem: • Usually, thecustomerisn’taware of thecostthat software development (and consequienly, thechanges in theplanning) involves.

11. And whathappenswiththerequirements? • Theestimation of thecostsderivedfromthe new requirementsishardtocalculatebecause: • Software developmentisessentially a designactivity • Thecosts are stronglyrelatedwiththepeople. • Software isintagible, thevalue of a feature in thesystemisdifficulttoevaluate. • Technologychangescontinuosly, and thevalue of thefeaturesalsochangeswiththetechnology (i.e.developing a web interface isharderthandeveloping a richclient interface)

12. And whathappenswiththerequirements? • And even more… • Ourcustomersexpectthatthe software mustbeeasytobeadapted, so… • It’sveryhardtoget a stable set of requirementsfromthem: But, Can’twedecicethat at theend? It’sonly a button! • Theyexpectitwillbepossibletomodifyit, bothwhenit’sdevelopedbythirdparties and whenit’scustomized at “home”. • So… ifwecannotget a stable set of requirementes, How can wepredict a plan todevelopit?

13. Predictability • There are somecontextswherepredictabilityispossible: • Itrequires time, hugeteams and stablerequirements. • But… • Most of software developmentprojectsdoesn’tbelongtothiscategory. • Wemustnotpretendtoapply a methodologybased in predictibilitywhenitcannotbereached. • Predictibilityisalwaysdesirable, butnotalwayspossible! • So… What do we do then? Unpredictabilitydoesn’t mean uncontrolable chaos, buttheneed of a developmentmethodology adaptable tothechanges of therequirements.

14. Controllingunpredictableprocesses Iterativedevelopments: • First, Where are wenow? • Frequentproduction of productversionsthatcover a little set of therequirements… • Integrated and tested as theywere final deployments • Theyrevealthefaults and weaknessthatmanyclassicaldocuments and tests use tohide. • Thelongtermplans are very flexible, and eachiteration plan verystable. • Iterationsmustbe short (from 1 weekto 1 month) totakeadvantage of thefeedback. • Thebest extra conditionwouldbe a flexible and full adaptable relationshipwiththecustomer.

15. Thepeoplefromthepoint of view of Agile methods • They are thekey in any software developmentprocess. • Programmers are responsiblepeople, so theydon’tneedtobecontinouslysupervised. • Theprocessesmustbeadapted and agreed, neverimposed. • Theleadership of theprojectissharedbetweendevelopers and account managers. • Theworkingtasksthatdevelopers and thepeoplethatknowsthebuisnessmustbethe rule, nottheexception.

16. The auto-adaptable process in the agile methods. • Regular revisions of the process: • Where did we hitted? • What did we learn? • What can we improve? • What was our headache? • With the answers new ideas are generated for the next iteration of the process. • Every now and then we must do retrospective revisions that can derive to changes in the organizational model of the development team.

17. Commonfeatures of the agile methods • Increasing development model (small versions developed in short iterations) • Cooperativity • Straigth and easy to learn • Adaptable • Speed and simplicity directed.

18. The Agile Manifesto • Meeting in Salt Lake City of 17 promoters of the agile methods. • March 2001 • TheAgile Manifesto …, The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment

19. The Agile Manifesto 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 interactionsoverprocesses and tools Working softwareovercomprehensive documentation Customer collaborationovercontract negotiation Responding to changeover following a plan That is, while there is value in the items on the right, we value the items on the left more. 

20. Principles behind the Agile Manifesto We follow these principles: • Our highest priority is to satisfy the customerthrough early and continuous deliveryof 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 to the shorter timescale. • Business people and developers must work together daily throughout the project. • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

21. Principles behind the Agile Manifesto • 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. • Continuous attention to technical excellenceand 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.

22. Cost of change Cost of change Requirements Analysis Design Implementation Tests Production

23. Whichmethods are Agile? • XP: Extreme Programming (Kent Beck) • http://www.xprogramming.com • Extreme Programming Explained: Embrace Change, KentBeck, Addison Wesley, 1999 • Crystal Family (Alistair Cockburn) • http://members.aol.com/humansandt/crystal/clear • http://members.aol.com/acockburn • CockBurn, Alistair. Surviving Object-Oriented Projects. Addison Wesley, 1998 • Open Source • http://www.tuxedo.org/~esr/writing/cathedral-bazaar • SCRUM • http://www.controlchaos.com • http://jeffsutherland.com/scrum • Feature Driven Develoment (Peter Coad) • Peter Coad y Otros, Java Modeling in Color with UML. Prentice Hall, 1999 • Agile Alliance • http://www.agilealliance.org

24. XP (Extreme Programming) • XP by far most common agile method • XP phases • Exploration - customers write story cards. Project team becomes familiar with tools, technology and practices • Planning - set priority of stories and contents first release • Iterations to Release - iterations before releases • Productionizing - extra testing and checking before release to customer • Maintenance and Death - new iterations and no more more customer stories

25. XP (Extreme Programming) • XP roles and responsibilities Programmer - writes tests and then code Customer - writes stories and functional tests Tester - helps customer write tests and runs them Tracker - gives feedback on estimates and process on iterations Coach - person responsible for whole process Consultant - supplies specific technical knowledge needed Manager - makes decisions

26. XP (Extreme Programming) • XP Practices • Planning game - programmers estimate effort of implementing customer stories and customer decides about scope and timing of releases • Short releases - new release every 2-3 months • Simple design - emphasis on simplest design • Testing - development test driven. Unit tests before code • Refactoring - restructuring and changes to simplify • Pair Programming - 2 people at 1 computer

27. XP (Extreme Programming) • XP Practices (cont) • Collective ownership - anyone can change any part of the code at any time. • Continuous integration - new builds as soon as code ready • 40 hour week - maximum 40-hour week. No overtime • On-site customer - customer present and available full-time for team • Coding standards - rules exist and are followed • Open workspace - large room small cubicles • Just rules - team has own rules but can be changed any at time

28. Scrum • Phases • Pregame • Planning - define system. Product Backlog • Architecture - high level design of system • Development • Iterative cycles (sprints) - new or enhanced functionality • Postgame • Requirements satisfied - no new items or issues

29. Scrum • Roles and Responsibilities Scrum Master - project following rules and practices Product owner -officially responsible for project Scrum Team - project team. Free to organize as they see fit to achieve goals of each sprint Customer - participates in Backlog items Management - Makes final decisions

30. Scrum • Practices • Product Backlog -Current prioritized list of work to be done • Effort Estimation - iterative on Backlog items • Sprint - 30 day iteration • Sprint Planning Meeting - decide goals for next spring and how team will implement • Sprint Backlog -Product Backlog items for sprint • Daily Scrum meeting – every now and then, what doing, what will do, and any problems • Sprint Review Meeting -present results of sprint

31. Crystal Light Methods(AlistairCockburn) • In theearly 90s, a studydeveloped at IBM byCockburn: • Successfuldevelopmentteamsswearedthattheydidn’tapply formal methodsneither CASE tools, and thattheyestimulatedinformationflow and tests. • Theteamsthathadproblems in theirprojectsdidn’tudnestandthereason, cause thefollowedstrictlythe formal methods. • Theexperiencewasrepeatedallalongthedecade, allaroundtheworld and witheverykind of tool. • Conclussion: Lessemphasis in anexhaustivedocumentation and more in runableversions of theprojectthat can betested. Thefirst are promisses, thelatter, facts.

32. Crystal Light Methods(Alistair Cockburn) • A secondconclussion: Eachdifferentprojectneedsitsowndifferentmethod • As thenumber of peoplegrows, theprojectrequest more coordination. • Whenthedamageriskisincreased, theprojectislesstoleranttochanges in therequirements. • The time a productmustremain in productionsdepends. Sometimesthis time mustbeshorter and somefaults are assumed, butsometimesotherfeaturesturn more important (auditing, legal protection, reliability, etc).

33. Crystal Light Methods(Alistair Cockburn) • So… • We must apply different development policies when building software with different teams. • Colour codification of Crystal: • Depending the size of the team:

34. Open Source • A lot of theprocessesappliedbythe open-sourcecommunity are applicabletocommonprojects. • Thesourcecodeissharedwitheverydeveloper of theteam, butonlythemaintenance manager can changeit. • Thedebuggingis a pararelprocess. • Stillpendingtheformalization of thisprocesses as agile methods. • Resources: • Eric Raimond. TheCathedral and theBazaar, http://www.tuxedo.org/~esr/writings/cathedral-bazaar • Karl Franz Fogel’s. Open SourceDevelopmentwith CVS. Coriolis Open Press, 1999

35. FeatureDrivenDeveloment(Peter Coad) • Short iterations (2 weeks) of usefullfunctionality. • Fice processes: • Develop a complete model. • Build a list of features • Createthe plan besed of thefeatureswewanttocover. • Designbased of thefeatures. • Cosntructionbasedonthefeatures. • Design and construction in everyiteration. • Organization: Bossprogrammer and propietaries of theclasses. • Resources: • Peter Coad y Otros, Java Modeling in Color with UML. Prentice Hall, 1999

36. Agile Software Development Recursos de información: • James Highsmith. Adaptive Software Development. Dorset House, Jan 2000 • http://www.agilealliance.org • JimHighsmith. http://www.adaptivesd.com • IEEE Software, Vol. 17, No. 4. Jul/Aug 2000.http://www.computer.org/software/so2000/s4toc.htm • Martin Fowler. Putyourprocesson a Diet. http://www.sdmagazine.com/articles/2000/0012/0012a/0012a.htm • Larry Constantine. MethodologicalAgility. http://www.sdmagazine.com/articles/2001/0106/0106f/0106f.htm

37. Whenshouldweapplythesemethodologies? • Small applications are easiertodevelopewhenthere’s no method. • Agile methodsfitwhen: • Teamwithlessthan 50 people. • Whenthere are no stablerequirements. • Whenthedevelopers are good, responsible and verymotivated. • Thecustomergetsinvolved in thedevelopmentprocess. • Predectivemethodologiesfitbetterwith,… • Biggetteams. • Thescope of theprojectisstablishedbycontract.

38. References • www.martinfowler.com • www.extremmeprogramming.org

39. Thanks! Dr. Daniel Fernández Lanvin