Agile software ontwikkeling

5.2.1 Inleiding

De roep om een meer iteratieve benadering van software ontwikkeling werd dus groter en agile soft-ware ontwikkeling ontstond zodoende in het midden van de jaren negentig als reactie op de traditio-nele ontwikkelmethoden.

Een iteratieve benadering gaat ervan uit dat je eerst een voorlopige versie maakt. Daar vraag je ver-volgens feedback op om daarna de software aan te passen aan de eisen. Deze benadering heeft

Design Software architecture

Implementation Software

Verification

Maintenance Requirements Product requirements document

5.2.2 Het Agile Manifesto

In februari 2001 heeft een groep van 17 prominente leden uit de software industrie de term 'Agile methods' geïntroduceerd en 'The Agile Manifesto' opgesteld. Deze mensen waren bijeengekomen om met elkaar te zoeken naar een betere manier om software te ontwikkelen. Later vormden ze de 'Agile Alliance' (http://www.agilemanifesto.org).

De principes die ze formuleerden waren gebaseerd op wat wel en niet werkt in de praktijk en hun ervaringen met het slagen en falen van softwareprojecten. De deelnemers van deze 'denktank' had-den allemaal al zo hun eigen filosofie en benadering van software development, maar tijhad-dens de bij-eenkomst in februari 2001 vonden ze een gemeenschappelijk kader.

Het Agile Manifesto

Met het Agile Manifesto dook het woord 'agility' voor het eerst formeel op in het kader van product-ontwikkeling. De term 'agile' op zichzelf betekent dat iets flexibel is en mee kan buigen. De term 'agile methods' houdt in het vermogen om succesvol te overleven in een omgeving van continue verandering (Anderson, 2004).

Agility in de software ontwikkeling is de alertheid: "…to rapidly or inherently create change, proactively or reactively embrace change, learn from change while contribu-ting to perceived customer value (economy, quality and simplicity) through its collective components and relationships with its environment."

(Bron: Persson e.a., 2012, p.3)

Het Agile Manifesto bracht een golf van nieuwe software methodieken, tools en handelswijzen met zich mee. Vier bewegingen zijn waar te nemen (Dingsøyr e.a., 2012).

Ten eerste de beweging naar meer gezamenlijk ontwikkelen, waarbij mensen meer ruimte krijgen en niet meer beperkt worden door bedrijfsprocessen. Medewerkers zijn immers de meest waardevolle bron voor een project.

Ten tweede de beweging naar een 'lean mentality’. Dat doen wat nodig is en niet meer. Deze bewe-ging verwees met name naar het niet langer creëren van 'overbodige' documentatie en 'goldplatting' (overbodige toeters en bellen). Met name over dit punt van documentatie zijn veel misverstanden ontstaan. In tegenstelling tot wat men vaak denkt wordt er niet mee bedoeld 'geen documentatie'. Er wordt mee bedoeld ‘alleen documentatie die absoluut nodig is en niks meer’. Volgens Cockburn is het verschil tussen agile en ‘document-driven methods’ niet uitgebreide documentatie versus geen documentatie maar geschreven documenten versus met elkaar praten om elkaar te begrijpen (Cockburn, 2007).

De derde beweging is de beweging om klanten actief te betrekken bij het ontwikkelproces.

De vierde en laatste beweging is de acceptatie dat onzekerheid een onlosmakelijk onderdeel is van software ontwikkeling en dat de neiging om afwijkingen te controleren en beheersen zinloos is. Het onderzoek van Nerur en Balijepally (2007) wijst erop dat de beweging om overmatige controlezucht/ beheersing los te laten, bij de tijdsgeest hoorde. Zij vonden soortgelijke bewegingen in het denken in andere ontwerpwerelden, zoals bijvoorbeeld de architectuur.

5.2.3 De principes van de Agile Alliance

In het Agile Manifesto (2001) zijn de uitgangspunten van de Agile ontwikkelmethodieken vastgelegd. De uitgangspunten zijn:

Het individu en hun onderlinge interactie boven processen en hulpmiddelen. Werkende software boven allesomvattende documentatie.

Samenwerking met de klant boven contract onderhandelingen. Inspelen op veranderingen boven het volgen van een plan.

Waarbij de kanttekening is dat de aspecten aan de rechterkant wel worden gewaardeerd, maar dat de aspecten aan de linkerkant méér worden gewaardeerd. In het Manifesto worden deze uitgangs-punten nader gespecificeerd met behulp van een twaalftal principes (Agile Alliance, 2001).

Principes

Klanttevredenheid Door snelle en continue oplevering van werkende software. Wijzigingen Verwelkom veranderende behoeften.

Iteratief Lever regelmatig werkende software op.

Samenwerking Ontwikkelaars en stakeholders werken op dagelijkse basis nauw met elkaar samen tijdens het gehele project.

Motivatie Projecten worden ingericht rondom gemotiveerde personen.

Directe communicatie De meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten.

Voortgang Wordt primair gemeten aan de hand van de opgeleverde, werkende software. Duurzame ontwikkeling Agile processen bevorderen constante ontwikkeling.

Uitdaging Voortdurende aandacht voor technische kwaliteit en voor een goed ontwerp versterken ‘agility’.

Eenvoud Zorg voor een eenvoudig ontwerp; de kunst om overbodig werk zo veel mogelijk achterwege te laten.

Zelfsturende teams De beste architectuur, eisen en ontwerpen komen voort uit zelfsturende teams. Regelmatige evaluatie Op vaste tijden onderzoekt het team hoe het effectiever kan worden en past

Agile ontwikkelmethoden volgen deze specifieke principes als een soort 'guideline' voor het leveren van hoge kwaliteit software. En hoewel de principes en aanpak van agile development niet nieuw waren, werden ze wel voor het eerst samengepakt in één raamwerk (Williams en Cockburn, 2003). Er zijn verschillende methoden die onder de parapluterm Agile development vallen, zoals onder andere scrum, XP (eXtreme Programming), FDD (Feature Driven Development) en Crystal. De wijze waarop de principes en uitgangspunten worden toegepast verschilt per methode. Strode geeft een overkoepelende begripsomschrijving van de agile ontwikkelmethoden.

“An agile method is a software development methodology designed for the mana-gement and support of iterative and incremental development of business systems in environments where change is constant. Agile methods use software development techniques that enhance teamwork in small empowered teams and support active customer involvement. An agile method is designed to produce working software early using communication, feedback, learning and frequent meetings in preference to than modelling and documentation. Agile methods adapt existing software development techniques to achieve these goals.”

(Bron: Strode, 2006, p.262)

Agile development is de laatste jaren populair geworden en de agile methoden worden door veel organisaties toegepast in hun software ontwikkelprojecten (Misra, Kumar en Kumar, 2009). Een uit-gebreide beschrijving en vergelijking van de verschillende agile methoden voert te ver voor dit schrij-ven maar de geïnteresseerde lezer verwijs ik graag naar de vergelijkende analyse van Abrahamsson, Warsta, Siponen, Ronkainen (New directions on agile methods: A comparative analysis in Pro-ceedings of the 25th International Conference on Software Engineering, ICSE’03, pagina 244-254, Washington DC, USA) (2003).

5.2.4 Het wetenschappelijk perspectief

Agile development is ontstaan uit persoonlijke ervaringen en collectieve wijsheid van prominente leden uit de software gemeenschap. De meeste agile praktijken bleken een intuïtieve aantrekkings-kracht te hebben. Vanuit de wetenschappelijke wereld volgde al snel aandacht voor deze methoden en een stroom van publicaties en onderzoeken kwam op gang.

In hun artikel 'A decade of agile methodologies; Towards explaining agile software development' geven Dingsøyr en anderen (2012) een overzicht van de wetenschappelijke publicaties die er in de tien jaar na het Agile Manifesto zijn opgedoken. Volgens deze onderzoekers ging in aanvang veel aandacht uit naar het vergelijken van de verschillende agile methoden, maar uiteindelijk richtte onderzoek zich ook op het adopteren en implementeren van agile methoden. Als gevolg van ontwik-kelingen in de software industrie verschoof de aandacht vervolgens ook naar agile methoden in ge-distribueerde omgevingen en op dit moment is de aandacht verschoven naar thema's rondom het managen van een agile project.

Introducties in agile development en overzichten van agile development methoden zijn goed be-schreven in publicaties van Abrahamsson e.a. (2002), Cohen e.a. (2004), Dyba en Dingsøyr (2008). In het artikel van Dingsøyr e.a. (2012) wordt ook een overzicht gegeven van de populaire theoretische perspectieven waarmee tot dan is gekeken naar agile methoden. Niet verrassend staat bovenaan 'knowledge management'. Software ontwikkelen is immers een kenniscreërende activiteit. Ook het perspectief van persoonlijkheidstheorieën en het perspectief van organisatieleren hebben binnen de context van agile aandacht gekregen. Dingsøyr e.a. (2012) concluderen dat er nog veel onderzoek nodig is. Een gedegen theoretische onderbouwing over de effectiviteit van agile methoden en praktij-ken en het begrijpen ervan ontbreekt tot op heden.

5.2.5 Kanttekeningen bij agile

Miller beschouwt agile software development niet als een nieuw fenomeen. Hij ziet het als een evo-lutie van ‘best practices’ zoals deze de afgelopen decennia zijn ontstaan. Hij waarschuwt ervoor om de methode te zien als een garantie voor succes.

“Geen van de methoden is een garantie op succes.” (Bron: Miller, 2001)

Volgens Highsmith en Cockburn (Highsmith, 2001) is het belangrijkste verschil met andere methoden de nadruk die agile legt op het mensenwerk met de mens als succesfactor. In de wens om agile me-thoden breder toepasbaar te maken en ook in andere contexten te gebruiken is er veel wildgroei te zien. Kruchten (2010) gaat in zijn artikel 'Contextualizing Agile Software Development' in op het be-lang van de context waarbinnen agile methoden worden gebruikt. Hij spreekt van een 'Agile sweet spot', daarmee doelende op een ideale context of de ideale voorwaarden voor agile methoden. Het gaat dan om een co-located team van minder dan 15 personen, gericht op het ontwikkelen van een vrij jong systeem waar geringe risico's aan zitten, in een omgeving met veel verandering, waar de architectuur gedefinieerd en stabiel is en met een eenvoudige beheersstructuur. Hij waarschuwt voor het gebruik van deze methoden in contexten die erg ver af staan van deze 'Agile sweet spot'.