Agile-softwareontwikkeling

Uit Wikipedia, de vrije encyclopedie
(Doorverwezen vanaf Agile-software-ontwikkeling)
Ga naar: navigatie, zoeken

Agile-softwareontwikkeling is een manier van softwareontwikkeling. Het Engelse woord agile betekent: behendig, lenig.

Inleiding[bewerken]

Hoewel de praktijken die onder de noemer agile vallen al gangbaar zijn sinds software ontwikkeld wordt, valt de geboorte van agile als term en concept, terug te brengen tot het Agile Manifesto.

Agile Manifesto[bewerken]

Het Agile Manifesto (Manifesto for Agile Software Development) is opgesteld tijdens een informele bijeenkomst van zeventien softwareontwikkelaars.[1] De bijeenkomst vond plaats van 11 tot en met 13 februari 2001 in "The Lodge" in "Snowbird", een ski-oord in de Amerikaanse staat Utah. In het Agile Manifesto staat het volgende (in het Engels):

Wij ontdekten manieren om beter software te ontwikkelen, door dit zelf te doen en door anderen te helpen om dit te doen. Hierdoor zijn we de volgende zaken gaan waarderen:

  1. Personen en interacties boven processen en tools.
  2. Software die werkt boven lijvige documentatie.
  3. Samenwerking met de klant boven onderhandeling over het contract.
  4. Omgaan met verandering boven het volgen van een plan.

Je moet dit zo lezen dat we zeker ook de zaken waarderen die rechts staan, maar dat we de zaken die links staan belangrijker vinden.

Uit het handvest volgen twaalf principes:

  1. Klanttevredenheid, door snelle, continue levering van bruikbare software.
  2. Zelfs late veranderingen in de requirements zijn welkom.
  3. Werkende software wordt regelmatig geleverd (weken in plaats van maanden).
  4. De ontwikkelaars werken nauw en dagelijks samen met de mensen die de business kennen.
  5. Projecten steunen op gemotiveerde en betrouwbare personen.
  6. Een gesprek in levende lijve is de beste manier van communicatie, wat betekent dat men zich bij voorkeur op dezelfde plek bevindt.
  7. Werkende software is de eerste maatstaf van vooruitgang.
  8. De ontwikkeling kan te allen tijde worden voortgezet.
  9. Er is voortdurende aandacht voor technische uitmuntendheid en goed ontwerp.
  10. Eenvoud is belangrijk: hoe meer er niet gedaan wordt, hoe beter.
  11. De teams organiseren zichzelf.
  12. Men past zich aan aan de omstandigheden.

Het handvest en de principes waren een kristallisatie van ideeën die midden de jaren negentig waren ontstaan, als reactie op methoden die men traditioneel klasseert als waterval-ontwikkelmodellen. 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 Agile stromingen. Vanuit de scrum hoek waren dat: Mike Beedle, Ken Schwaber en Jeff Sutherland. Vanuit de XP-hoek waren dat Kent Beck, Ward Cunningham, Martin Fowler en Ron Jeffries. Vanuit de DSDM-hoek vertegenwoordigde Arie van Bennekom. Crystal was vertegenwoordigd door Alistair Cockburn en verder waren er nog acht consultants.

Na de publicatie van het handvest, richtten enkele ondertekenaars de "Agile Alliance" op, om de principes verder om te zetten in methoden. In 2005 verzamelden "Alistair Cockburn" and "Jim Highsmith" een andere groep mensen — namelijk management experts — en schreven een addendum: de "PM Declaration of Interdependence".

Agile-methoden[bewerken]

Enkele agile-ontwikkelmethoden zijn:

Gesteld kan worden dat agile en iteratieve ontwikkelmethoden terugkeren naar de ontwikkelpraktijk in de vroege historie van softwareontwikkeling.[3] Oorspronkelijk werden agile-methoden "lightweight methods" (lichtgewichtmethoden) genoemd, omdat ze zo weinig regels hadden.

Agile-methoden hebben veel gemeenschappelijk met de rapid application development- of RAD-technieken 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 agile methoden 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[bewerken]

Iteraties[bewerken]

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[bewerken]

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 zeker 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[bewerken]

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. Doel is om te leren en steeds beter te worden. Dit aspect, de continue verbetering, (Kaizen) is overgenomen uit de Lean-productiemethoden.

Werkende software[bewerken]

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.

Gebruik[bewerken]

Agile-methoden worden snel populair en steeds meer gebruikt, ook in grote projecten. Bekende projecten en bedrijven waar het is toegepast zijn:

Vergelijking met andere methoden[bewerken]

Aanpassend versus voorschrijvend[bewerken]

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.[5] 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'[bewerken]

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[bewerken]

De watervalmethode wordt nog volop toegepast.[6] 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 mee 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.[7]

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"[bewerken]

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 zou kunnen worden.

Geschiktheid van agile-methoden[bewerken]

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):[8]

  • De cultuur van de organisatie moet openstaan voor discussie en onderhandeling
  • Organisaties moeten mensen (fulltime) vrijmaken om besluiten te nemen over wat de organisatie wil en om te testen of het opgeleverde ook daaraan voldoet.
  • Mensen moeten vertrouwd worden
  • Organisaties moeten de beslissingen accepteren die hun afgevaardigden / producteigenaars / product-managers nemen
  • Organisaties moeten een omgeving hebben waarin snelle communicatie tussen teamleden mogelijk is.
  • Mensen moeten kunnen samenwerken.

De DSDM-methode is voorzien van een ‘geschiktheidsfilter’. Ook de Crystal-familie van methoden voorziet in criteria waarmee een methode geselecteerd kan worden voor een zeker project. De selectie wordt daarbij gebaseerd op projectomvang, -belang en –prioriteit. Andere agile-methoden voorzien echter niet in zulke expliciete instrumenten om hun geschiktheid te bepalen.

Van sommige methoden, zoals DSDM en Feature Driven Development (FDD), wordt beweerd dat ze geschikt zijn voor elk ontwikkelingsproject, onafhankelijk van omgevingsfactoren (Abrahamsonn et al., 2003),[9] althans op het gebied van software.

Grote projecten[bewerken]

Grote projecten zijn altijd moeilijk vanwege de benodigde hoeveelheid communicatie, maar dat is juist een sterk punt van de agile methoden. Agile-ontwikkeling is uitgebreid gedocumenteerd om goed te werken in kleine (<10 ontwikkelaars) co-located teams.

Voor grootschalige ontwikkelingen (meer dan 20 ontwikkelaars) zijn er voorstellen gedaan[10]. Ook wordt er met agile gewerkt in non-co-located teams die over de hele wereld verspreid kunnen zijn. Er zijn voorstellen gedaan in Bridging the Distance[11] en in Using an Agile Software Process with Offshore Development[12]

Schaalgrootte of geografische spreiding op zich zijn kennelijk geen onoverkomelijke barrières voor succes.

Bestaansgrond[bewerken]

Agile-bestaansgrond:

  • Als nog onduidelijk is wat men precies wil.
  • Als snel eerste resultaten gewenst zijn.
  • Als de eisen steeds wijzigen
  • Continue beschikbaarheid van klant / gebruikers noodzakelijk om te bepalen wat men wil en de opgeleverde resultaten te testen.
  • Kan goed overweg met veranderingen, ook laat in het project.
  • Er wordt geclaimd dat Agile een factor 2 a 10 maal zo snel / goed is als een traditioneel traject.

Bestaansgrond van traditionele voorschrijvende methoden:

  • Als men niet wil veranderen / ontwikkelaars wil omscholen.
  • Als men vooral junior ontwikkelaars heeft
  • Vaststaande projecteisen / scherpe specificaties (als vooraf goed duidelijk is wat men wil).
  • Als de omgeving slechts langzaam verandert / zoals de (semi) overheid (Belastingdienst, UWV, ziekenhuizen, GBA, etc.)
  • Cultuur die orde vereist, geen veranderingen in requirements tussen de afronding van de analysefase en de implementatie.

Agile-methoden en maatwerkmethode[bewerken]

Verschillende termen worden gebruikt om methodeaanpassing (‘method adaptation’) aan te duiden, zoals ‘method tailoring’, ‘method fragment adaptation’ en ‘situational method engineering’. Maatwerkmethode (‘method tailoring’) wordt gedefinieerd als:

een proces of vaardigheid waarbij menselijke factoren de behandelwijze voor de ontwikkeling van een systeem voor een specifieke project situatie bepalen door afgestemde veranderingen in, en dynamische wisselwerkingen tussen contexten, intenties, en fragmenten van methoden.[13]

Bijna alle agile-methoden komen in potentie in aanmerking voor maatwerk. Zelfs de DSDM-methode wordt voor dit doel gebruikt en is succesvol op maat gemaakt in een CMM-context.[9] Als kenmerk waarmee onderscheid gemaakt kan worden tussen agile-methoden en traditionele ontwikkelmethoden, waarbij de laatste inflexibel en voorschrijvend zijn, wordt situationele aanpassing beschouwd. Praktisch gevolg hiervan is dat de agile-methoden projectteams in staat stelt om praktijken aan te passen aan de individuele projectbehoeften. Praktijken zijn concrete activiteiten en producten die deel uitmaken van een methodisch raamwerk. Op een extremer niveau kan de filosofie achter de methode, bestaande uit een aantal ‘’’principes’’’ worden aangepast (Aydin, 2004).[14]

XP[bewerken]

In het geval van XP is de noodzaak voor methodeaanpassing expliciet gemaakt. Een van de basisaannames van XP is dat er geen proces bestaat dat op elk project van toepassing is, maar dat praktijken aan de individuele projectbehoeften moeten worden aangepast. Er zijn ook geen ervaringsrapportages waarin XP-praktijken zijn opgenomen. Daar staat tegenover dat er meermalen verslag van gedeeltelijke toepassing van XP-praktijken is gedaan.[15]

Er kan onderscheid gemaakt worden tussen statische en dynamische methodeaanpassing.[16] De basisaanname achter statische methodeaanpassing is dat de projectcontext gegeven is bij aanvang en gelijk blijft gedurende het project. Met als gevolg een statische definitie van de projectcontext. Met zo'n definitie kan een keuze gemaakt worden uit fragmenten van gestructureerde methoden. Daartegenover wordt bij dynamische methodeaanpassing aangenomen dat ook de projectcontext in ontwikkeling is. Dit betekent dat het project in hoge mate onvoorspelbaar is en aan verandering onderhevig. Vooraf kan dus niet bepaald worden welke fragmenten van methoden toepasbaar zullen zijn. Projectmanagers zullen er dus, gedurende de uitvoering van projecten, toe moeten overgaan om methodefragmenten zelf aan hun behoefte aan te passen of zelfs nieuwe uit te vinden. (Aydin et al, 2005).[16]

Agile-methoden en projectmanagement[bewerken]

Agile-methoden verschillen in hoge mate in hoeverre zij met project-management overlappen. Sommige methoden worden aangevuld met richtlijnen voor project-management.[17]

Agility meten[bewerken]

Hoewel agility (behendigheid) wordt gezien als een middel om een doel te bereiken zijn er meerdere voorstellen gedaan om het te kwantificeren. Agility Index Measurements (AIM) meet projecten af met een aantal agility-factoren. De bijna-naamgenoot Agility Measurement Index, zet ontwikkelingen af tegen vijf dimensies van een project (duur, risico, nieuwheid, inspanning, interactie). Andere technieken zijn gebaseerd op meetbare doelen. In een onderzoek waarin gebruik maakt van fuzzy wiskunde[18] wordt voorgesteld om projectsnelheid te gebruiken als een maat voor agility.

Conferenties[bewerken]

Agile-ontwikkelen is het onderwerp van meerdere conferenties. Sommige daarvan hebben een wetenschappelijke achtergrond met peer-reviewed artikelen en gevalsstudies. In gevalsstudies wordt ervaringen gedeeld die in de praktijk met agile ontwikkelen is opgedaan.

Enkele conferenties waarin ervaringen gepubliceerd werden

  • XP (2000, 2001, 2002, 2003, 2004, 2005, 2006)
  • XP Universe (2001)
  • XP/Agile Universe (2002, 2003, 2004)
  • XP Days Benelux (2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012) [19]

Opleidingen en certificering[bewerken]

Met het groeiende gebruik is er ook een markt ontstaan voor het geven van agile/scrum-opleidingen die dan ook met een certificering afgesloten kunnen worden. Dit kan bij verschillende instanties.[20],[21]

Kritiek[bewerken]

Agile-ontwikkelen wordt soms bekritiseerd als 'cowboy coding'. XP baarde met zijn controversiële leerstellingen zoals "pair programming" en "continuous design" aanvankelijk veel ophef en lokte kritiek uit als van McBreen[22] en Boehm en Turner en in Extreme Programming Refactored van Matt Stephens.[23] Veel van de kritiek werd door agile-praktijkmensen als onbegrip afgedaan.[24]

Kritiek behelst:

  • gebrek aan structuur, discipline en documentatie;
  • omvat onvoldoende softwareontwerp;
  • werkt alleen met ervaren ontwikkelaars;
  • vereist te veel culturele verandering;
  • men weet vooraf niet wat men wil en krijgt. Dit kan daardoor leiden tot moeilijkere contractonderhandelingen bij fixed price-projecten. Deze zijn daarmee bijna onmogelijk, men kan eigenlijk alleen een vast uurtarief afspreken.

Literatuur[bewerken]

  • Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-254.
  • Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. (2005). On the Adaptation of An Agile Information Systems Development Method. Journal of Database Management Special issue on Agile Analysis, Design, and Implementation, 16(4), 20-24
  • Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. In Advances in Computers (p. 1-66). New York: Elsevier Science.
  • Fowler, Martin. Is Design Dead?. Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001.
  • Highsmith, J. Agile Software Development Ecosystems. Addison-Wesley Professional, 2002 (ISBN 0-201-76043-6)
  • de Jonge, M. (maart 2009). Agile (web)ontwikkeling - omarm de verandering. NAARVOREN, artikel #155.
  • Karlstrom, D., & Runeson P. (2005). Combining agile methods with stage-gate project management. IEEE Software, 22(3), 43-49
  • Larman, Craig, & Basili, Victor R. Iterative and Incremental Development:A Brief History IEEE Computer, juni 2003
  • Molendijk, K., Oud, S. (juni 2008). Selectie van softwareontwikkelmethoden: het gevecht om de aandacht van de projectmanager. Informatie, nr. 50(5), p. 48-52.
  • Riehle, Dirk. A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn From Each Other. Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001.
Bronnen, noten en/of referenties
  1. Agile Manifesto
  2. Evolutionary Project Management (EVO)
  3. Larman, Craig, Victor R. Basili (June 2003). Iterative and Incremental Development: A Brief History (pdf). Computer 36 (nr. 6): 47-56 . DOI:10.1109/MC.2003.1204375. Geraadpleegd op 2 december 2013. (Permission note)
  4. Lessons learned from Scrum implementation at Google
  5. Boehm, B.; Richard Turner, Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, Boston, MA. ISBN 0-321-18612-5, 2004 Appendix A, p. 165-194
  6. Laplante, P.A., C.J. Neill (februari 2004). "The Demise of the Waterfall Model Is Imminent" and Other Urban Myths. ACM Queue 1 (10) . Geraadpleegd op 13 mei 2006.
  7. Sommerville, Ian, Software engineering, 8th edition, Addison Wesley, Harlow [1982], 2007, “4.1.1. The waterfall model”, p. 66f ISBN 0-321-31379-8.
  8. Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. In Advances in Computers (p. 1-66). New York: Elsevier Science.
  9. a b Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-254
  10. Supersize Me
  11. Bridging the Distance
  12. Using an Agile Software Process with Offshore Development
  13. Aydin, M.N., Harmsen, F., Slooten, K. v., & Stegwee, R. A. (2004). An Agile Information Systems Development Method in use. Turk J Elec Engin, 12(2), 127-138
  14. Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004). An Agile Information Systems Development Method in use. Turk J Elec Engin, 12(2), 127-138
  15. Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. VTT Publications 478
  16. a b Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. (2005). On the Adaptation of An Agile Information Systems Development Method. Journal of Database Management Special issue on Agile Analysis, Design, and Implementation, 16(4), 20-24
  17. Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-254.
  18. Kurian, Tisni (2006). "Agility Metrics: A Quantitative Fuzzy Based Approach for Measuring Agility of a Software Process" ISAM-Proceedings of International Conference on Agile Manufacturing'06(ICAM-2006), Norfolk, USA.
  19. XP Days Benelux
  20. Agile foundation certificering
  21. certificering bij exin
  22. McBreen, P., Questioning Extreme Programming, Addison-Wesley, Boston, MA. ISBN 0-201-84457-5, 2003
  23. Extreme Programming Refactored
  24. sdmagazine