Agile-softwareontwikkeling is een manier van softwareontwikkeling, waarbij software stap voor stap wordt ontwikkeld en verbeterd in kortdurende, overzichtelijke iteratieperiodes, waarbij na elke iteratie een werkend stuk software wordt opgeleverd. De beoogde voordelen van deze manier van werken zijn onder andere dat eventuele foutjes vroeg ontdekt worden, en er makkelijker op veranderingen kan worden ingespeeld. Het Engelse woord agile betekent dan ook behendig, wendbaar of lenig.
Geschiedenis Hoewel de praktijken die onder de noemer agile vallen al gangbaar zijn sinds software ontwikkeld wordt, valt de start van agile als term en concept terug te brengen tot het Agile Manifesto in 2001.Agile Manifesto. Gearchiveerd op 16 december 2021.
Iteratieve en incrementele softwareontwikkelingsmethoden werden toegepast vanaf 1957, terwijl evolutionair projectbeheer"Evolutionair Projectmanagement (Originele pagina, extern archief)". Gilb. Gearchiveerd uit het origineel op 27 maart 2016. Retrieved 09 March 2023."Evolutionary Project Management (New page)". Gilb. Ontvangen op 9 maart 2023. en adaptieve softwareontwikkelingEdmonds, E. A. (1974). "A Process for the Development of Software for Nontechnical Users as an Adaptive System". General Systems. 19: 215–18. opkwamen in het begin van de jaren 1970.Gilb, Tom (1 April 1981). "Evolutionary development". ACM SIGSOFT Software Engineering Notes. 6 (2): 17. doi:10.1145/1010865.1010868. S2CID 33902347.
Agile Manifesto Het Agile Manifesto (voluit het Manifesto for Agile Software Development, Engels voor "Handvest voor Agile-softwareontwikkeling") werd opgesteld tijdens een informele bijeenkomst van zeventien softwareontwikkelaars. Deze bijeenkomst vond plaats van 11 tot en met 13 februari 2001 in "The Lodge" in Snowbird (Utah).
De zeventien softwareontwikkelaars waren: Kent Beck (Extreme Programming), Ward Cunningham (Extreme Programming), Dave Thomas (PragProg, Ruby), Jeff Sutherland (Scrum), Ken Schwaber (Scrum), Jim Highsmith (Adaptive Software Development), Alistair Cockburn (Crystal), Robert C. Martin (SOLID), Mike Beedle (Scrum), Arie van Bennekum, Martin Fowler (OOAD en UML), James Grenning, Andrew Hunt (PragProg, Ruby), Ron Jeffries (Extreme Programming), Jon Kern, Brian Marick (Ruby, TDD), en Steve Mellor (OOA). Samen schreven en publiceerden zij het manifest.
Het handvest en de principes vormden een uitwerking van ideeën die halfweg de jaren negentig waren ontstaan, als reactie op methoden die men traditioneel klasseert als ontwikkelmodellen volgens de watervalmethode. Die modellen werden ervaren als bureaucratisch, traag en bekrompen en zouden de creativiteit en effectiviteit van ontwikkelaars belemmeren. De zeventien mensen die het Agile Manifesto samen hebben opgesteld vertegenwoordigden de diverse Agilestromingen. Na de publicatie van het handvest, richtten enkele ondertekenaars de "Agile Alliance" op, om de principes verder om te zetten in methoden.
Agile-methoden Enkele agile-ontwikkelmethoden en -frameworks zijn: Kanban Scrum (1986) Dynamic systems development method (DSDM) (1995) Extreme programming (XP) (1996) Crystal Clear and Other Crystal Methodologies (1996) Agile modeling Adaptive Software Development (ASD) Feature Driven Development (FDD) Lean-softwareontwikkeling (Lean software development) Agile Unified Process (AUP) Scaled Agile Framework (SAFe) Continuous integration Evolutionary Project Management (EVO)Evolutionary Project Management (EVO) Large Scale Scrum (LeSS).
Gesteld kan worden dat agile en iteratieve ontwikkelmethoden terugkeren naar de ontwikkelpraktijk in de vroege historie van softwareontwikkeling. (Permission note)
Oorspronkelijk werden agile-methoden "lightweight methods" (lichtgewichtmethoden) genoemd, omdat ze zo weinig regels hadden.
Agile-methoden hebben veel gemeenschappelijk met de rapid application development-technieken (RAD) uit de jaren tachtig volgens James Martin et al. Daarna zijn de volgende methoden ontwikkeld die later Agile genoemd werden.
Met extreme programming (afgekort als "XP") zijn agilemethoden populair geworden, hoewel het misschien niet de eerste agile-methode is. Extreme programming was het antwoord van Kent Beck in 1996 op de worsteling van het Chrysler Comprehensive Compensation-(C3)-project. De methode werd verfijnd door Ron Jeffries, via openbare discussie in Portland Pattern Repository van Ward Cunningham en verder werk van Beck, waaronder een boek in 1999. Er lijken elementen van extreme programming voor te komen die gebaseerd zijn op Scrum en "Episodes pattern language" van Ward Cunningham.
Kenmerken Iteraties De meeste agile-methoden proberen risico's te verminderen door software te ontwikkelen in korte overzichtelijke perioden (timeboxes), die 'iteraties' genoemd worden. Elke iteratie is als het ware een miniatuurproject op zichzelf, en omvat alle noodzakelijke taken: planning, analyse, ontwerp, testen en documentatie. Het is de bedoeling om na iedere iteratie iets bruikbaars op te leveren. Aan het eind van de iteratie wordt het product getoond, getest en het product en proces beoordeeld. Hierdoor wordt het risico beperkt en weet men snel of men op de goede weg zit. Doordat men het product ziet wordt het allemaal concreter en komen er nieuwe ideeën. Aansluitend wordt er dan naar de projectprioriteiten gekeken en bepaald wat er de volgende iteratie (release) gedaan wordt.
Communicatie Bij agile-methoden ligt de nadruk op directe communicatie, bij voorkeur als persoonlijk contact, in plaats van geschreven verslaglegging. In agile-projecten wordt erg weinig geschreven documentatie geproduceerd, vergeleken met andere methoden. De meeste agile-teams zijn gehuisvest op één locatie, een zogenaamde "bullpen". Zo mogelijk zijn alle mensen die nodig zijn voor het project in zo'n team ondergebracht. Maar ten minste zijn dit de ontwikkelaars en diegenen die het product definiëren. Dat kunnen productmanagers zijn, business-analisten of zelfs klanten. In Scrum heeft het team ook geen projectmanagers, maar scrummasters die hiërarchisch niet boven het team staan, maar deze ondersteunen. Dat bevordert de open communicatie tussen de gelijkwaardige teamleden. Bij XP is er ook sprake van pair programming, waarbij twee ontwikkelaars direct samenwerken. Dit is een erg directe manier van communicatie.
Voortgang Bij agile-methoden wordt de voortgang afgemeten aan de hand van werkende producten, features of prototypes. Aan het eind van elke iteratie of sprint wordt zowel het opgeleverde product beoordeeld als het ontwikkelproces. Het doel hiervan is om te leren en steeds beter te worden. Dit aspect, de continue verbetering, (Kaizen) is overgenomen uit de Lean-productiemethoden.
Werkende software Er wordt de nadruk gelegd op werkende software. In elke iteratie moet er iets werkends worden opgeleverd. Iets dat ook direct geïntegreerd wordt in de bestaande software, waardoor duidelijk wordt of dit ook allemaal goed gaat. In veel agile-projecten wordt nu gewerkt met continuous delivery, waarbij software na het controleren door een automatische test-suite onmiddellijk live gaat, en dat meermaals per dag. De combinatie van de testen en de korte tijdsframe tussen twee aanpassingen, maakt dat de mogelijke problemen zodanig klein zijn dat ze zeer snel kunnen opgelost worden, waardoor de algemene kwaliteit hoger ligt dan bij projecten waar slechts om de drie maand of langer software live gezet wordt.
Gebruik Agile-methoden worden snel populair en steeds meer gebruikt, ook in grote projecten. Bekende projecten en bedrijven waar het is toegepast zijn: IBM Nokia (bedrijf) AdWords van GoogleLessons learned from Scrum implementation at Google. Gearchiveerd op 17 maart 2021. BT Group. Bol.comAgile werken bij bol.com
Vergelijking met andere methoden Aanpassend versus voorschrijvend Agile-methoden worden soms misleidend gekarakteriseerd als de tegenpool van 'geplande' en 'gedisciplineerde' methoden. Een nauwkeuriger omschrijving kan gemaakt worden door onderscheid te maken tussen 'aanpassende' en 'voorschrijvende' methoden. Appendix A, p. 165-194 Agile-methoden staan dan aan het aanpassende uiteinde van dit spectrum.
'Aanpassende' (agile)methoden zijn er op gericht om zich snel aan te passen aan de veranderende werkelijkheid. Een 'aanpassend' team past zich dus snel aan maar heeft er moeite mee om exact te beschrijven wat er in de toekomst gaat gebeuren en wat het daarmee gaat doen.
Daartegenover staan 'voorschrijvende' methoden. Deze zijn er op gericht om de toekomst tot in detail te plannen. Een team dat met zo'n methode werkt kan precies aangeven welke resultaten en taken gepland staan voor de gehele duur van de ontwikkeling, maar heeft het moeilijk om om te gaan met verandering.
Tegenover 'iteratieve ontwikkeling' De meeste agile-methoden delen de nadruk van "iteratieve ontwikkeling", op het tot stand brengen van vrij te geven producten in korte perioden. Agile-methoden onderscheiden zich daarvan omdat de tijdsspanne nog korter is (weken in plaats van maanden) en vanwege de nadruk op intensieve samenwerking. Daarbij komt dat agile-methoden hun "timebox" letterlijk nemen; er wordt niet overgewerkt en aan het eind van de timebox wordt alleen opgeleverd wat ook echt klaar is (done).
Tegenover de watervalmethode De watervalmethode wordt nog volop toegepast.
Het is het meest voorschrijvende van alle modellen met uitgebreide voorschriften voor processtappen, in een strikt geplande volgorde. Voortgang wordt ermee gemeten aan de hand van allerlei documenten op basis waarvan management voortgangsbeslissingen neemt.
Het onbuigzame karakter van het watervalmodel, met de opdeling van projecten in afzonderlijke fasen en voortijdige commitments maken dat er moeilijk gereageerd kan worden op veranderingen. Het is daarom feitelijk onbruikbaar als projectdoelstellingen en producteisen vooraf nog niet gedetailleerd zijn of mogelijk onderhevig aan verandering gedurende het project.
Daartegenover leveren agile-methoden elke zoveel weken uitontwikkelde en geteste onderdelen, al zijn dit telkens kleine delen van het geheel. De nadruk ligt er op om zo snel mogelijk de kleinst mogelijke functionele onderdelen te leveren, en die voortdurend te verbeteren en uit te breiden. Sommige agile-teams passen de watervalmethode toe op een kleine schaal tijdens elke iteratie. Andere, vooral XP-teams laten de waterval geheel los en werken simultaan aan uiteenlopende taken.
Tegenover "cowboy coding" Bij cowboy coding is geen sprake van een uitgesproken methode. Teamleden doen wat hen goed dunkt. Agile-teams wekken soms de indruk aan cowboy-coding te doen. Geregelde herziening van plannen en nadruk op persoonlijk contact in plaats van gedocumenteerde communicatie kan ongestructureerd overkomen. Maar agile-teams coördineren hun activiteiten voortdurend en volgen wel degelijk gedefinieerde en gedisciplineerde processen.
Zoals met alle methoden hangt het succes ervan af van de vaardigheden van de gebruiker. Op vaststaande en systematische vereisten kunnen beoefenaars makkelijker afgerekend worden. Het vervallen van zulke vereisten kan leiden tot activiteiten die met cowboy-coding aangeduid zouden kunnen worden.
Geschiktheid van agile-methoden Of agile-methoden algemeen geschikt zijn is afhankelijk van het gekozen gezichtspunt. Agile-methoden zijn geschikter naarmate eisen nog vaag en veranderlijk zijn. Vanuit organisatorisch gezichtspunt kan de geschiktheid worden afgemeten aan drie dimensies: cultuur, mensen en communicatie. In dit verband is een aantal succesfactoren aangegeven (Cohen et al., 2004):Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. In Advances in Computers (p. 1-66). New York: Elsevier Science.
De cultuur van de organisatie moet openstaan voor discussie en onderhandeling.