Toelichting

Referentiemodellen in het domein Process – Agile-methoden. In 2001 kwamen vertegenwoordigers van de belangrijke agile-methoden bij elkaar en stelden het Agile Manifesto op. In het manifest wordt agile als een waardepropositie gepositioneerd (Unhelkar, 2013). De aanleiding voor het opstellen van dit Manifesto was om te komen tot betere methoden om software te ontwikkelen. Het Manifesto is een openbaar document (http://agilemanifesto.org/) en bestaat uit twaalf principes. De kern is dat software iteratief en incrementeel moet worden ontwikkeld, waarbij zelforganisatie, adaptiviteit, informeel handelen, durf en betrouwbaarheid belangrijke elementen zijn (Unhelkar, 2013).

Figuur 1 Agile Manifesto (Bron: agilemanifesto.org)

Er bestaan diverse methoden die onderdeel zijn van de zogeheten agile-familie, Scrum en DSDM Atern zijn daarvan de bekendste. In dit boek hebben we Scrum en DSDM Atern geanalyseerd. In de onderstaande toelichting geven we echter ook een aantal andere agile-methoden weer. Daarmee geven we een breder inzicht in het werkveld van agile-methoden.

Scrum gaat volgens de bedenkers uit van de ‘empirical process control theory’, ook wel empirisme genoemd. Uitgangspunt is dat kennis voortkomt uit ervaring en dat besluiten worden genomen op basis van de aanwezige kennis (Störig, 2008). Scrum werkt iteratief, incrementeel en probeert in de aanpak de voorspelbaarheid te vergroten en risico’s te verkleinen. Scrum rust op drie pijlers: transparantie, inspectie en adaptatie (Schwaber & Sutherland, 2013). Scrum beschrijft vier belangrijke bijeenkomsten voor: de Sprint Planning, de dagelijkse Scrum, de Sprint Review en de Sprint Retrospective. Het team is zelfsturend, cross-functioneel en bestaat doorgaans uit een kerngroep met een producteigenaar, het ontwikkelteam en een Scrum Master. Scrum inspireert: we kennen bijvoorbeeld ook de recente ontwikkeling van Public Scum waarbij in korte tijd met kleine teams beleidsstukken worden gemaakt die doorgaans een langere doorlooptijd kennen.

Figuur 2 Scrum Sprint Cycle

DSDM (Dynamic Systems Development Method) is een incrementele en iteratieve methode waarbij voortdurend input van gebruikers wordt gevraagd en waarbij prototyping een belangrijke rol speelt (Hildering & Peters, 2008). De basis van DSDM werd in 1994 gelegd door het DSDM Consortium naar aanleiding van de roep vanuit de markt om een gestandaardiseerde RAD-methode (Rapid Application Development). De eerste versie werd in februari 1995 gepubliceerd, een tweede versie volgde in december 1995. De methode is daarna aangevuld om naast applicatieontwikkeling ook toegepast te kunnen worden in veranderprocessen van de business. De laatste versie van DSDM is versie 4.2 uit 2003. Daarna is de nieuwe versie gepubliceerd onder de naam DSDM Atern. Bij deze versie horen gecertificeerde trainingen, een handboek en diverse hulpmiddelen en instructies. DSDM Atern gaat uit van acht ondersteunende principes op het gebied van het proces van het project, de life cycle van een project, de projectmedewerkers, hun rollen en verantwoordelijkheden, de producten die ze maken en vanuit de DSDM Atern-aanpak opleveren en de technieken en practices die ze daarvoor nodig hebben.

De door DSDM Atern onderschreven acht principes zijn:
1. Focus on the business need.
2. Deliver on time.
3. Collaborate.
4. Never compromise quality.
5. Build incrementally from firm foundations.
6. Develop iteratively.
7. Communicate continuously and clearly.
8. Demonstrate control.

Andere bekende agile-methoden zijn:
• Extreme programming (XP), waarbij individuen de vrijheid krijgen om zich te richten op het bouwen van wat voor de opdrachtgever belangrijk is. Het bouwen gebeurt in korte en incrementele stappen op basis van een set van afspraken met betrekking tot planning, management (hoe te managen), ontwerp, coderen en testen (Beck, 1999). Een XP-traject kent de volgende fasen (Abrahamsson et al., 2002):

1. Exploratiefase.
2. Planningsfase.
3. Iteraties tot en met de release.
4. Productiefase met iteraties bij ingebruikname.
5. Onderhoudsfase, waarin de release stabiel wordt, terwijl andere releases ontwikkeld worden.
6. Doodsfase: De release kent geen aanvullende wensen meer en de documentatie wordt op orde gebracht.

• Feature-Driven development (FDD) is door Jeff De Luca ontwikkeld. De toelichting op deze methodie is te vinden op: (http://www.nebulon.com/articles/fdd/ originalprocesses.html) en in een publicatie van Palmer & Felsing (2002). De methode bestaat uit vijf stappen. Per stap zijn de input, de activiteiten en de output beschreven (De Luca, 1998):
1. Modelleren van het objectmodel, ondermeer door gebruik te maken van Use Cases.
2. Opstellen van een overzicht met de eisen en wensen: de features.
3. Plan by feature: een afgebakende set wensen en eisen wordt toegekend aan een groep ontwikkelaars.
4. Design by feature: een ontwerp maken voor de geselecteerde wensen en eisen.
5. Build by feature: het ontwerp bouwen nadat de inspectie op het ontwerp is uitgevoerd.

• Adaptive software development (ASD) is in dezelfde periode beschreven als XP. Jim Highsmith (Highsmith 1997, 2000) heeft diverse artikelen en boeken geschreven die de methode toelichten. In de aanpak wordt gerefereerd aan de complexiteitstheorie. De aanpak staat voor om niet te starten met een plan-design-build cyclus, maar met een speculate-collaborate-learn-cyclus. In de specialisatiefase initieert men het project en plant men de vervolgstappen. In de collaborate-fase worden onderdelen van het project parallel ontworpen en gerealiseerd. In de leerfase wordt een review uitgevoerd en vindt de release en eindoplevering plaats. Leren is belangrijk, de drie fasen worden verbonden door een feedbackloop voor leerervaringen. De methode is vooral toepasbaar in projecten waarin extreem hoge ontwikkelsnelheid, veel verandering en onzekerheid een rol spelen.

• Test-driven development (TDD) is beschreven door Kent Beck (Beck 2003). De aanpak gaat uit van het eerst beschrijven van testcases, om pas daarna het ontwerp en de software te maken. De stappen zijn als volgt:
1. Test maken.
2. Test uitvoeren.
3. Code schrijven.
4. Test uitvoeren.
5. Code herschrijven, indien nodig.
6. Test uitvoeren. Als de test slaagt, volgt een volgende cyclus van iteraties voor nieuwe functionaliteit.

Twee belangrijke uitgangspunten zijn dat nieuwe code alleen geschreven wordt als de test niet gehaald wordt, en dat duplicaten van code altijd geëlimineerd moeten worden. Zie ook de toelichting op http://www.agiledata.org.

• Crystal Clear is een methode die geschikt is voor alle projecten. De methode omvat een set van meerdere methoden waarbij het kernpunt is dat het opleveren van producten met een hoge frequentie plaatsvindt. Uitgangspunten van de methode zijn ook: korte communicatielijnen, reflectie en verbetering. De methode dateert uit 1992, en kreeg zijn naam in 1997 (http://alistair.cockburn.us/ Crystal+methodologies). Alistair Cockburn, de founding father van de methode maakt onderscheid tussen twee dimensies: omvang (size) en de kritieke waarde van de oplossing (criticality) (Cockburn, 2004). Hij vergelijkt dat met mineralen: een groot project komt bijvoorbeeld overeen met donkere kleuren. Systemen die meer schade (damage) kunnen veroorzaken, bijvoorbeeld de software van een kernreactor, vragen om een strakkere methode en meer validatie en verificatieregels. Agile-projecten maken gebruik van de eerste drie van de zeven kenmerken waaraan projecten en teams moeten voldoen:
1. Frequent Delivery Property.
2. Reflective Improvement.
3. Osmotic Communication.
4. Personal Safety.
5. Focus.
6. Easy Access to Expert Users.
7. Technical Environment with Automated Tests, Configuration Management & Frequent Integration.

RUP (Rational Unified Process) wordt niet beschouwd als een agile-methode. Bij RUP wordt er meer gewerkt met visualisaties en processchema’s vooraf, is sprake van documentatie vooraf en tijdens het proces, en zijn de bouwers formeel verantwoordelijk de realisatie. Dat is bij agile-methoden niet het geval, daarbij is men veel meer gericht op het delen van code en gedeelde verantwoordelijkheid. Wel is het mogelijk om RUP op een agile-manier uit te voeren, maar dit vraagt dan om een andere aanpak (Unhelkar, 2013).

Weging

Scrum – gebruik

Figuur 3 Scrum gebruik

Scrum -inhoud

Figuur 4 Scrum inhoud

Reflectie

Scrum en DSDM Atern als basis voor evalueren, kan dat wel? Dat is de eerste vraag die we moeten beantwoorden. Scrum en DSDM Atern zijn vooral gericht op het ontwikkelen van software via een incrementeel proces. De bouwblokken van een agile-aanpak kunnen echter als kleine projecten worden gezien, waarmee toegewerkt wordt naar een groter eindproduct dat aan de eigenaar/opdrachtgever wordt opgeleverd. Inmiddels zijn er diverse initiatieven om ook projectmanagementmethoden als DSDM Atern – gebruik

Figuur 5 DSDM Atern gebruik

Figuur 6 DSDM Atern inhoud

PRINCE2 te laten aansluiten bij agile-werkmethoden en andersom. In evaluaties zal de beoordeling van dergelijke (deel)projecten kunnen plaatsvinden door het evalueren van projectonderdelen. De ‘kapstok’ die de beschrijvingen van Scrum en DSDM Atern leveren kunnen daarbij als basis dienen.

Scrum en vooral DSDM Atern scoren beide hoog op de aspecten van gebruik. Scrum kent een duidelijke eigenaar die het beheert en exploiteert. De gebruiker moet bij Scrum de voorgeschreven aanpak volgen en de organisatie zal daarop moeten worden ingericht. Dat verklaart de lagere score bij beheer & exploitatie vanuit het perspectief van de gebruiker. Ook de representatie scoort wat lager bij Scrum. Er is geen representatiemodel beschikbaar en de manier waarop andere methoden kunnen worden ingebed in Scrum is niet duidelijk. Dat leverde ook tijdens de analyse een wisselend beeld op bij de beoordelende experts.

DSDM Atern scoort zeer hoog op de gebruiksaspecten. Denkwijze scoort wat lager, omdat minder helder is vanuit welke inhoudelijke principes het model is opgebouwd. Wat betreft representatie, de uitleg van de werkwijze, de bruikbaarheid in combinatie met andere instrumenten en wat betreft beheer is DSDM Atern goed beschreven, met duidelijke hulpmiddelen en rolbeschrijvingen.

Scrum is op inhoud met name sterk in de manier van communiceren binnen het team en met de omgeving. De op te leveren producten worden zeer duidelijk afgebakend en de betrokkenheid van stakeholders is groot. De kracht van de incrementele aanpak is ook hier duidelijk. Daarnaast is de relatie met de andere (deel)projecten en (deel) producten helder en is zeer duidelijk hoe het traject gestructureerd wordt. Scrum kijkt naar de op te leveren producten en heeft in de methode minder aandacht voor verandermanagement en de ontwikkelingen binnen de organisatie.

DSDM Atern is op inhoud voor de diverse aspecten duidelijk beschreven. Alle elementen die in een projectmanagementaanpak kunnen voorkomen, scoren in de beschrijving van DSDM Atern. Daarmee laat DSDM Atern zien dat het zich niet alleen richt op het eindproduct en de incrementele werkwijze, maar ook op het proces om tot dat eindproduct te komen. Daarnaast kent deze methode een duidelijke beschrijving van de wijze van control en toetsing, waardoor de scores op de verschillende aspecten hoger liggen dan bij Scrum – uitgaande van het basisdocument. DSDM Atern heeft een lange geschiedenis waardoor de beschrijving verrijkt is met ervaringen uit de eerdere ontwikkeling van DSDM.

Scrum en DSDM Atern als basis gebruiken voor het evalueren van een project is zeker een mogelijkheid. In tegenstelling tot bijvoorbeeld projectmanagementmethoden, kennen de beschrijvingen van Scrum en DSDM Atern uitgebreide toelichtingen op diverse te evalueren projecten. Scrum en DSDM Atern zijn dus vooral goed in te zetten als basis voor een evaluatie van een agile-project, of om een project tegen het licht te houden dat niet volgens Scrum of DSDM Atern is ingericht, maar wel incrementele aanpakken heeft gebruikt in een of meer projectfasen. Projecten die met Scrum en DSDM Atern werken hebben een plek binnen de organisatie, leveren toegevoegde waarde aan een groter geheel, of vormen zelf onderdeel van een groter geheel. Deze laatste onderwerpen komen niet vanuit Scrum of DSDM Atern aan de orde. Om het goed in te zetten voor een evaluatie, zullen Scrum en DSDM Atern dan ook aangevuld moeten worden met aandachtspunten uit andere methoden, omdat anders de breedte van de evaluatie te beperkt is.

Wouter Bronsgeest

The post Agile Methoden appeared first on EN | Van Haren Publishing.