Agile-software-ontwikkeling

Uit Wikipedia, de vrije encyclopedie

Ga naar: navigatie, zoeken

Agile-software-ontwikkeling is een conceptueel raamwerk voor het uitvoeren van software-ontwikkelingsprojecten als alternatief voor traditionele starre praktijken. Het Engelse woord agile betekent: behendig, lenig.

Inhoud

[bewerken] Inleiding

Er zijn een aantal agile-ontwikkelingsmethoden, zoals aangegeven op The Agile Alliance. 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 zich zelf, en omvat alle noodzakelijke taken: planning, analyse, ontwerp, testen en documentatie. Een iteratie levert niet altijd genoeg op om het eindproduct vrij te geven. Desondanks is het de bedoeling van een agile-project om na iedere iteratie iets bruikbaars voor de markt op te leveren. Voor software gaat dat vaak op vooral als deze web-gebaseerd is. Maar, ongeacht het resultaat wordt na iedere iteratie door het ontwikkelteam herafgewogen wat de project-prioriteiten zijn.

Bij agile-methoden ligt de nadruk op directe communicatie, bij voorkeur als persoonlijk contact, in plaats van geschreven verslaglegging. 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 product-managers zijn, business-analisten of zelfs klanten.

Bij agile-methoden wordt de voortgang afgemeten aan de hand van werkende producten of prototypes. In agile-projecten wordt erg weinig geschreven documentatie geproduceerd, vergeleken met andere methoden. Dit heeft geleid tot kritiek als zouden agile-methoden ongedisciplineerd zijn.

[bewerken] Geschiedenis

De moderne definitie van agile-ontwikkeling ontstond in de mid jaren-1990 als onderdeel van een reactie op "zwaargewicht"-methoden die getypeerd worden door zwaar gereguleerd, detail-gestuurd, gebruik van waterval-ontwikkelmodellen. Deze modellen werden als bureaucratisch, traag en bekrompen ervaren en belemmeren de creativiteit en effectiviteit van ontwikkelaars.

Gesteld kan worden dat agile en iteratieve ontwikkelmethoden terugkeren naar de ontwikkelpraktijk in de vroege historie van software-ontwikkeling.[1] Oorspronkelijk werden agile-methoden "lightweight methods" (lichtgewichtmethoden) genoemd. Maar enkele prominenten gaven er de naam "agile methods" aan op een bijeenkomst in 2001 in Snowbird, Utah. Enkelen van hen stichtten daarop de Agile Alliance.

Vroege agile-methoden—van voor 2000—zijn Scrum (1986), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, en DSDM (1995).

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.

[bewerken] Principes achter agile-methoden — Het Agile Manifest

Agile-methoden zijn dus een familie van ontwikkelprocessen. In 2001, kwamen 17 prominenten [2] op het terrein van agile-ontwikkelen bijeen om manieren te bespreken om software lichtvoetiger, sneller, en meer mens-gericht te ontwikkelen. Zij stelden het Agile Manifesto op, in brede kring gezien als de kanonieke definitie van agile-ontwikkeling, en van bijkomende agile-principes.

Enkele van de principes van het Agile Manifesto[3] zijn:

  • Klanttevredenheid door snelle, levering van bruikbare software op een continue basis
  • Regelmatig aanbod van nieuwe werkende software (eerder per week dan per maand)
  • Voortgang wordt afgemeten aan de hand van werkende software
  • Wijziging van doelstellingen zijn welkom, zelfs laat in het proces
  • Nauwe samenwerking op een dagelijkse basis tussen ontwikkelaars en hun belanghebbenden
  • Direct persoonlijk contact als beste vorm van communicatie
  • Projecten worden opgezet rondom gemotiveerde individuen, en die moeten dan vertrouwd worden
  • Voortdurende aandacht aan technische hoogstandjes en goed ontwerp
  • Eenvoud
  • Zelf-organiserende teams
  • Voortdurende aanpassing aan veranderende omstandigheden

Met de publicatie van dit manifest werd de agile-ontwikkelen-beweging in gang gezet.

In 2005 verzamelden Alistair Cockburn and Jim Highsmith een andere groep mensen — namelijk management experts — en schreven een addendum: de PM Declaration of Interdependence.

[bewerken] Vergelijking met andere methoden

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 'adaptieve' en 'voorschrijvende' methoden.[4] Agile-methoden staan dan aan het "adaptieve" uiteinde van dit spectrum.

'Adaptieve' methoden zijn er op gericht om zich snel aan te passen aan de veranderende werkelijkheid. Een 'adaptief' 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 zulke teams hebben grote moeite om van richting te veranderen.

Agile-methoden hebben veel gemeenschappelijk met de "Rapid application development (RAD)"-technieken uit de jaren-1980 volgens James Martin et al.

[bewerken] Tegenover 'iteratieve ontwikkeling'

De meeste agile-methoden delen de nadruk van iteratieve ontwikkeling op 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.

[bewerken] Tegenover de watervalmethode

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

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.

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

[bewerken] Geschiktheid van agile-methoden

Hoewel agile-methoden in hun praktijken verschillen, delen zij een aantal gemeenschappelijke karakteristieken, waaronder iteratieve ontwikkeling en een focus op interactie, communicatie, en een beperkt gebruik van procedures en hulpmiddelen die een groot beslag doen op hulpbronnen.

Of agile-methoden ook algemeen geschikt zijn is afhankelijk van het gekozen gezichtspunt. Vanuit het product-perspectief zijn agile-methoden geschikter naarmate eisen nog vaag en veranderlijk zijn; zij zijn minder geschikt voor systemen die aan kritische eisen moeten voldoen zoals betrouwbaarheid en veiligheid, hoewel ook daar geen volledige consensus over bestaat. Vanuit organisatorisch gezichtpunt kan de geschiktheid worden afgemeten aan drie dimensies: cultuur, mensen en communicatie. In dit verband is een aantal succesfactoren aangegeven (Cohen et al., 2004)[7]:

  • De cultuur van de organisatie moet openstaan voor discussie en onderhandeling
  • Mensen moeten vertrouwd worden
  • Minder maar competentere mensen
  • Organisaties moeten de beslissingen accepteren die ontwikkelaars nemen
  • Organisaties moeten een omgeving hebben waarin snelle communicatie tussen team-leden mogelijk is

De belangrijkste factor is mogelijk project-omvang. Persoonlijke communicatie binnen een project-team wordt moeilijker naarmate de omvang toeneemt. Daarom zijn agile-methoden geschikter voor kleine projecten van hooguit 20 tot 40 mensen.

Een ander probleem is dat aannames bij aanvang of een bovenmatig snel verzamelen van eisen van tevoren een afwijking van de optimale oplossing kan veroorzaken, vooral als de afnemer zijn wensen niet goed heeft verwoord. Evenzo is het, gegeven de menselijke natuur, goed mogelijk dat een “dominante” ontwikkelaar een zwaar persoonlijk stempel drukt op het ontwerp dat niet overeen hoeft te komen met het gewenste projectresultaat. Historisch gezien kunnen ontwikkelaars hun oplossingen aan klanten opdringen, deze ervan overtuigen dat die de beste is en er uiteindelijk achter komen dat de oplossing niet werkt. In theorie zou het snelle iteratieve karakter dit moeten beperken, maar daar wordt bij aangenomen dat er sprake is van negatieve terugkoppeling. Als daar geen sprake van is kan de afwijking snel toenemen.

Dit bezwaar kan worden opgeheven door de eisen in een afzonderlijke fase op te stellen (veel voorkomend in agile-systemen) en het zo te isoleren van de invloed die ontwikkelaars er op kunnen uitoefenen, of door de klant voortdurend bij de ontwikkeling te betrekken en elke tussenstap te laten testen. Probleem hierbij is dat klanten er niet zo veel tijd in willen investeren. Het bemoeilijkt ook de QA (Quality Assurance) omdat er geen duidelijke (SMART) testdoelstellingen zijn die niet van vrijgave tot vrijgave veranderen.

Om de geschiktheid van afzonderlijke agile-methoden te bepalen is een diepergaande analyse noodzakelijk. De DSDM-methode is daarom bijvoorbeeld 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).[8], althans op gebied van software.

Een vergelijking van agile-methoden zal onthullen dat ze elk hun eigen fase van een software-ontwikkel-life-cycle ondersteunen. Deze individuele karakteristieken van agile-methoden kunnen natuurlijk goed gebruikt worden ten behoeve van hun selectie voor een specifiek project.

Agile-ontwikkeling is uitgebreid gedocumenteerd (zie Agile-ontwikkelen in de praktijk, hieronder, zowel als Beck, pg. 157, en Boehm en Turner pg. 55-57) om goed te werken in kleine (<10 ontwikkelaars) co-located teams.

De vraag is nog niet beantwoord of agile-ontwikkeling geschikt is voor de volgende scenario’s:

  • Grootschalige ontwikkelingen (>20 ontwikkelaars); er zijn echter voorstellen gedaan[9]
  • Distributed development (non-co-located teams die over de hele wereld verspreid kunnen zijn). Er zijn voorstellen gedaan in Bridging the Distance[10]en in Using an Agile Software Process with Offshore Development[11]
  • Projecten van strategisch- en levensbelang
  • Hiërarchische organisaties

Wetenswaardig is dat verschillende grootschalige successen zijn opgetekend bij organisaties als BT Group die over honderden ontwikkelaars beschikten gesitueerd in het VK, Ierland en India, die gezamenlijk in projecten werkten volgens agile-methodologieën. Hoewel ongetwijfeld vraagtekens geplaatst kunnen worden over de geschiktheid van agile methoden voor bepaalde project-typen, zijn schaalgrootte of geografische spreiding op zich kennelijk geen onoverkomelijke barrières voor succes.

Barry Boehm en Richard Turner opperen om risico analyse toe te passen om te kiezen tussen adaptieve ("agile") en voorschrijvende methoden. Volgens hen hebben beide uiteinden van het continuüm hun eigen bestaansgrond.

Agile-bestaansgrond:

  • Grote oplossingsruimte
  • Senior ontwikkelaars
  • Zeer veranderlijke project-eisen
  • Klein aantal ontwikkelaars
  • Cultuur die in chaos gedijt

Bestaansgrond van voorschrijvende methoden:

  • Scherpe specificaties
  • Junior ontwikkelaars
  • Vaststaande project-eisen
  • Groot aantal ontwikkelaars
  • Cultuur die orde vereist

[bewerken] Agile-methoden en maatwerk-methode

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 actoren 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. [12]

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. [8] Als kenmerk waarmee onderscheid gemaakt kan worden tussen agile-methoden en traditionele ontwikkelmethoden, waarbij de laatste inflexibel en voorschrijvend zijn, wordt situationele aanpassing beschouwd. Practisch 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).[13]

In het geval van XP is de noodzaak voor methode-aanpassing 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 project-behoeften 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.[14]

Er kan onderscheid gemaakt worden tussen statische en dynamische methode-aanpassing.[15] De basisaanname achter statische methode-aanpassing is dat de project-context gegeven is bij aanvang en gelijk blijft gedurende het project. Met als gevolg een statische definitie van het project-context. Met zo'n definitie kan een keuze gemaakt worden uit fragmenten van gestructureerde methoden. Daartegenover wordt bij dynamische methode-aanpassing aangenomen dat ook de project-context in ontwikkeling zijn. 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 methode-fragmenten zelf aan hun behoefte aan te passen of zelfs nieuwe uitvinden. (Aydin et al, 2005).[15]

[bewerken] Agile-methoden en project-management

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

[bewerken] Agile-methoden

Enkele welbekende agile-ontwikkelmethoden:

Andere benaderingen:

Voorbeelden van agile-principes buiten ontwikkelingsactiviteiten:

[bewerken] Agility meten

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[17] wordt voorgesteld om project-snelheid te gebruiken als een maat voor agility.

De praktische toepasbaarheid van deze maten is nog te bezien.

[bewerken] Kritiek

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[18] en Boehm en Turner en in Extreme Programming Refactored van Matt Stephens.[19]. Veel van de kritiek werd door agile-praktijkmensen als onbegrip afgedaan.[20]

Kritiek behelst:

  • gebrek aan structuur en noodzakelijke documentatie
  • werkt alleen met ervaren ontwikkelaars
  • omvat onvoldoende softwareontwerp
  • vereist te veel culturele verandering
  • kan leiden tot moeilijker contract-onderhandelingen

[bewerken] Agile-ontwikkelen in de praktijk

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 sinds 2006 waarin ervaringen gepubliceerd werden

  • XP (2000, 2001, 2002, 2003, 2004, 2005, 2006)
  • XP Universe (2001)
  • XP/Agile Universe (2002, 2003, 2004)

[bewerken] Zie ook

Referenties:
  1. ↑ Gerald M. WeinbergLarman, Craig, Victor R. Basili (June 2003). Iterative and Incremental Development: A Brief History (pdf). Computer 36 (No. 6): pp 47-56. DOI:10.1109/MC.2003.1204375. Geraadpleegd op 2007-02-22. (Permission note)
  2. ↑ Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
  3. ↑ Agile Manifesto principles
  4. ↑ Boehm, B., R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley, Boston, MA. ISBN 0-321-18612-5, 2004 Appendix A, pages 165-194
  5. ↑ Laplante, P.A., C.J. Neill (February 2004). "The Demise of the Waterfall Model Is Imminent" and Other Urban Myths. ACM Queue 1 (10). Geraadpleegd op 2006-05-13.
  6. ↑ Sommerville, Ian, “4.1.1. The waterfall model”, Software engineering, 8th edition, Addison Wesley, Harlow [1982], 2007, p. pp 66f
  7. ↑ Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. In Advances in Computers (pp. 1-66). New York: Elsevier Science.
  8. ↑ 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
  9. ↑ Supersize Me
  10. ↑ Bridging the Distance
  11. ↑ Using an Agile Software Process with Offshore Development
  12. ↑ 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
  13. ↑ 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
  14. ↑ Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. VTT Publications 478
  15. ↑ 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
  16. ↑ Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-254.
  17. ↑ 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.
  18. ↑ McBreen, P., Questioning Extreme Programming. Addison-Wesley, Boston, MA. ISBN 0-201-84457-5, 2003
  19. ↑ Extreme Programming Refactored
  20. ↑ sdmagazine

[bewerken] Verder lezen

  • Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-254.
  • Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. VTT Publications 478.
  • 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
  • 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 (pp. 1-66). New York: Elsevier Science.
  • Karlstrom, D., & Runeson P. (2005). Combining agile methods with stage-gate project management. IEEE Software, 22(3), 43-49
  • Highsmith, J. Agile Software Development Ecosystems. Addison-Wesley Professional, 2002 (ISBN 0-201-76043-6)
  • Molendijk, K., Oud, S. (November 2007). Projectmanagement is risicomanagement. Automatisering Gids, issue 47, pp.18-19
  • Molendijk, K., Oud, S. (June 2008). Selectie van softwareontwikkelmethoden: het gevecht om de aandacht van de projectmanager. Informatie, issue 50(5), pp. 48-52.
  • de Jonge, M. (maart 2009). Agile (web)ontwikkeling - omarm de verandering. NAARVOREN, artikel #155.

[bewerken] Externe links

[bewerken] Officiële websites van organisaties etc.

[bewerken] Artikelen, papers, essays

[bewerken] Handleidingen

[bewerken] Diversen

[bewerken] Boek promotie

[bewerken] Vluchtige content: blogs, nieuws, journals, forums

Ontvangen van "http://nl.wikipedia.org/wiki/Agile-software-ontwikkeling"
Persoonlijke instellingen