Als ICT-professional heb je het liefst dat de klant exact weet wat hij wil, dat jij exact weet hoe je dat moet maken en dat niets verandert totdat het klaar is. In de praktijk blijkt meestal dat een klant ontdekt wat hij wil, dat je ontdekt hoe je dat moet maken en dat wanneer het klaar is bijna alles veranderd is.

Bij softwareontwikkeling van een groot project of product kan een flexibele aanpak aanzienlijk in kosten en doorlooptijd schelen, met een eindresultaat van hogere kwaliteit. Dit geldt zeker voor een web-based omgeving waar nieuwe ontwikkelingen en technieken elkaar snel opvolgen.

Agile softwareontwikkeling kan deze flexibiliteit bieden. In dit artikel probeer ik de verschillen tussen Agile en traditionele softwareontwikkelmethoden aan te geven en introduceer ik de ontwikkelmethode Scrum.

De watervalmethode

Veel websites en webapplicaties worden met de traditionele watervalmethode uitgevoerd. Deze methode vindt zijn oorsprong in de constructiebouw en deelt de ontwikkeling in fasen op. De meest voorkomende fasen zijn:

1. Analysefase (met definitiestudies en analyserapporten als eindproduct)
2. Ontwerpfase (met functionele en technische ontwerpen als eindproduct)
3. Bouwfase (met broncode als eindproduct)
4. Testfase (met werkende broncode als eindproduct)
5. Integratiefase (eindgebruikers gaan ermee aan de slag)
6. Beheer en onderhoud fase (het systeem wordt draaiend gehouden)

Eén van de uitgangspunten van de watervalmethode is dat fouten vroeg worden ontdekt en relatief voordelig te herstellen zijn. Er wordt veel gedocumenteerd zodat het eindresultaat voor de klant en leverancier duidelijk is. De volgende fase(n) zijn relatief eenvoudig in te schatten (mits het project niet te groot is) waardoor opdrachten gemakkelijk ‘fixed price’ kunnen worden aangenomen.

De watervalmethode vereist echter wel dat alle betrokken partijen goed begrijpen wat er in de verschillende fasen gedocumenteerd wordt. Vooral bij webapplicaties is veel documentatie dermate uitvoerig, technisch of complex dat deze door de klant vaak niet helemaal begrepen wordt. Het gebruik van prototypes en schetsen verhelpt dit maar gedeeltelijk; omdat de eerste ‘echte’ opleveringen pas laat in het traject zijn, ontvang je pas laat ‘echte’ feedback. Het gevolg is dat feedbackloop (de tijd tussen start en het krijgen van feedback) behoorlijk lang is.

Projecten die via de watervalmethode worden aangepakt hebben ook vaak te kampen met veranderende interne en externe omstandigheden, vooral bij projecten met een lange doorlooptijd. Hierdoor kunnen requirements of zelfs doelstellingen gedurende het project veranderen.

Als gevolg is er na oplevering vaak een versie 1.1 nodig, waarin feedback van de klant en de aanpassingen naar aanleiding van nieuwe ontwikkelingen worden verwerkt.

Agile softwareontwikkeling

‘Agile’ vertaalt zich naar ‘lenig’ of ‘behendig’. Agile methodes zijn een reactie op processen die er in theorie goed uitzien maar in de praktijk vaak hun beloftes niet waarmaken. De uitgangspunten van Agile ontwikkeling zijn in 2001 in het Agile Manifest vastgelegd.

De filosofie achter Agile is samengevat in de volgende tabel:

Belangrijk	Belangrijker
processen en tools	individuen en interactie
gedetailleerde documentatie	werkende software
contractonderhandeling	samenwerken met de klant
strikt het plan volgen	reageren op verandering

(bron: Agile Manifesto for Agile Software Development)

Bekende Agile ontwikkelmethoden zijn Scrum (dat ik verder in dit artikel introduceer), eXtreme Programming (XP) en Dynamic Systems Development Method (DSDM).

Iteratief werken

Eén van de meest kenmerkende verschillen tussen de watervalmethode en de Agile methode is de wijze waarop de onderdelen van de website of webapplicatie worden opgeleverd.

Bij traditionele ontwikkeling werk je aan alle onderdelen tegelijkertijd. Bij Agile ontwikkeling wordt er steeds aan één onderdeel gewerkt. Dit wordt gedaan gedurende korte iteraties of timeboxes, vaak van slechts enkele weken. Aan het einde van de iteratie wordt er iets bruikbaars vrijgegeven en ontvangt de leverancier feedback van de klant en/of eindgebruikers.

Feedback wordt dus veel eerder ontvangen dan bij de watervalmethode. Op basis van de feedback en veranderende omstandigheden wordt er bepaald aan welke onderdelen er in de volgende iteratie wordt gewerkt. Wijzigingen in doelstellingen zijn in deze aanpak geen probleem, zelfs laat in het proces.

De te bouwen functionaliteit wordt meestal kort beschreven in een requirement of user story. Dit kan ook uitvoeriger, bijvoorbeeld in een use case of scenario. De functionaliteit wordt voorzien van een (ruwe) inschatting en een prioriteit. Het prioriteren wordt gedaan door een uniek business value getal toe te kennen, waarbij een hoger getal een hogere prioriteit aangeeft. Omdat omstandigheden en doelstellingen voortdurend veranderen wordt de onderlinge prioriteit continu bijgesteld. Bij de start van elke iteratie wordt er uit de functionaliteit — die op dat moment de hoogste prioriteit heeft — gekozen. Tijdens de iteratie werk je alleen aan die onderdelen.

Agile technieken voor teams

Bij veel Agile softwareontwikkelmethodes wordt er gewerkt met een ‘team van gelijken’. In essentie zijn alle teamleden “softwareontwikkelaars” met bepaalde specialismen, zoals design, programmeren, databases of testen. De teamleden in het multidisciplinaire team worden zelf ook multidisciplinair. Daarnaast worden de volgende technieken vaak toegepast:

Pair programming

Bij pair programming werk je met twee teamleden aan hetzelfde onderdeel. Eén teamlid zit achter het toetsenbord en muis en het andere teamlid zoekt informatie op en denkt mee. Zoals in de rallysport heb je dus een ‘driver’ en ‘navigator’. Je wisselt elkaar regelmatig af. Deze wijze van werken blijkt vaak productiever dan wanneer beide teamleden achter hun eigen scherm zitten en levert betere kwaliteit op. Pair programming is een techniek die zijn oorsprong vindt in eXtreme Programming (XP) en wordt ook in veel andere ontwikkelmethodes toegepast. Het is overigens niet alleen zinvol bij het programmeren en kan net zo effectief bij ontwerpen, schrijven van test cases, et cetera worden ingezet.

Collective code ownership

In Agile methodes wordt er vaak met ‘collective code ownership’ gewerkt; iedereen mag in alle code werken, ongeacht de aard (CSS, JavaScript, server-side code) of onderwerp. Op deze manier krijg je meer uniformiteit en onderlinge kwaliteitscontrole. Ook kun je als team makkelijker schommelingen in de teamsamenstelling opvangen.

Snelle communicatie

Agile teams zijn klein en zitten zoveel mogelijk bij elkaar zodat alle teamleden elkaar kunnen zien en spreken. Op die manier kun je snel en efficiënt communiceren. Wanneer het team op verschillende plaatsen werkt, kunnen technieken als VOIP, Video Conference en desktop sharing worden gebruikt om zoveel mogelijk het zelfde effect te krijgen.

Scrum

Op dit moment is Scrum één van de populairste Agile ontwikkelmethoden. Het is een raamwerk voor iteratieve, incrementele productontwikkeling en maakt gebruik van een multidisciplinair, zelfsturend team. Scrum is gebaseerd op ‘best practices’, ‘lean principles’ en empirisch procesmanagement. Het woord Scrum is geen afkorting, maar afkomstig uit rugby jargon; in een scrum staan alle teamleden schouder aan schouder en vormen ze één blok.

Het proces in vogelvlucht

Binnen Scrum wordt er gewerkt vanuit backlogs. Het Product Backlog is als het ware een to-do lijst voor het gehele project en bestaat uit user stories en bugs.

Er wordt gewerkt in sprints: timeboxen van 2 - 4 weken. Aan het begin van elke sprint wordt er een Sprint Backlog samengesteld vanuit de Product Backlog Items met de hoogste prioriteit. Dit Sprint Backlog bevat taken die nodig zijn om de functionaliteit die is beschreven in de Product Backlog Items te voltooien. Aan het einde van de sprint wordt er meer marktwaarde aan de software toegevoegd door middel van verbeteringen, nieuwe functies en/of bugfixes.

Rollen in Scrum

Scrum kent slechts 3 actieve rollen:

• Product Owner

  Deze persoon representeert de stem van de gebruikers/klant. Hij/zij beheert en prioriteert het Product Backlog. De Product Owner kan een klant zijn, maar ook iemand vanuit de interne organisatie.

• Team

  Het team bestaat uit 3 - 8 personen, is multidisciplinair, autonoom en zelfsturend. Er zijn geen vaste rollen, maar er is wel sprake van expertise bij teamleden.

• Scrum Master

  Deze persoon is een combinatie van coach, probleemoplosser en facilitator. Hij/zij bewaakt het proces en beschermt het team tegen binnenlopende salesmanagers, support calls en andere vormen van ‘ruis’. De Scrum Master is nadrukkelijk geen projectleider.

Overige ‘rollen’ zoals stakeholders, klanten en managers bestaan uiteraard ook, maar hebben geen actieve rol binnen Scrum.

Sprint Planning Meeting

Elke sprint start met de Sprint Planning Meeting. Deze meeting duurt doorgaans 2 - 4 uur. De Product Backlog Items die bovenaan het Product Backlog staan op worden door het team opgedeeld in taken (of Sprint Backlog Items) en voorzien van een inschatting in Story Points. 1 Story Point staat voor 8 uur werk, maar zegt niets over doorlooptijd.

Er wordt bepaald hoeveel Story Points het team tijdens de sprint kan verwerken. Op basis hiervan bepaalt het team welke Product Backlog Items in de sprint worden opgenomen en committeert het team zich hier echt aan. Waar bij veel andere ontwikkelmethoden dit soort beslissingen door iemand als een projectleider genomen, ligt de verantwoordelijkheid bij Scrum hiervoor bij het Team.

Ondanks dat hij niet beslist, kan de Product Owner wel invloed uitoefenen; door de onderlinge prioriteit of scope van de Product Backlog Items te veranderen kan hij ervoor zorgen dat het team zich tijdens de komende sprint tóch aan de door hem gewenste onderdelen committeert.

Kwaliteit is geen variabele om tot een lagere inschatting te komen, tenzij het om het verminderen van externe kwaliteit gaat, zoals een eenvoudigere gebruikersinterface. Op de interne kwaliteit (die onder andere de onderhoudbaarheid van het systeem bepaalt) wordt niet bezuinigd, omdat dit op korte en lange termijn hogere kosten met zich meebrengt.

Dagelijkse Scrum meeting

Tijdens de sprint zijn er korte dagelijkse meetings van het team waarin het Team en de Scrum Master aanwezig zijn en elk lid van het team de volgende 3 vragen beantwoordt:

1. Wat heb je gedaan sinds de laatste meeting?
2. Wat ga je doen tussen nu en de volgende meeting?
3. Is er iets dat je weerhoudt om te doen wat je van plan bent?

Via de eerste twee vragen blijven de aanwezigen op de hoogte van de voortgang. Via de derde vraag worden problemen die de voortgang bedreigen (in Scrum: impediments) gesignaleerd en opgelost.

Tijdens de dagelijkse Scrum meeting kunnen alle geïnteresseerden aanwezig zijn, echter alleen de Scrum Master en het Team mogen spreken. De meeting duurt maximaal 15 minuten en wordt meestal staand gehouden. Dat is minder comfortabel dan zittend. Dit alles houdt het geheel bondig en to the point.

De voortgang wordt op een taskboard bijgehouden. Hierop zijn 3 kolommen aangegeven: niet gereed, in uitvoer en gereed. Elk Sprint Backlog Item staat in één van de kolommen, met de naam van de uitvoerende persoon en aantal uur resterend werk erbij. De totale voortgang van de sprint wordt bijgehouden in een Sprint Burn-down grafiek.

De burn-down grafiek geeft per dag aan hoeveel ingepland werk er over blijft. Hierin is al na enkele dagen te zien of je als team ‘on track’ bent, tijd over houdt of tijd tekort zult komen.

Sprint Demo en Retrospective

Aan het einde van de Sprint toont het Team aan de Product Owner, Stakeholders en andere geïnteresseerden het resultaat tijdens de Sprint Demo. Hierbij geldt de regel dat alleen Product Backlog Items mogen worden getoond die 100% af zijn.

Aansluitend op de demo vindt er een evaluatie plaats tijdens de Sprint Retrospective Meeting. Tijdens deze meeting (waarbij het Team en Scrum Master aanwezig zijn) geeft elk teamlid aan wat goed ging, wat beter kon en wat ze anders willen doen in de volgende sprint.

Wanneer Agile?

De keuze voor een ontwikkelmethode voor een website of webapplicatie hangt af van veel factoren. Over het algemeen kun je stellen dat bij projecten met complexe technologie, of waar (veel) wijzigingen in requirements te verwachten zijn, Agile een goede keuze kan zijn. Bij eenvoudige projecten met stabiele requirements kan de watervalmethode prima werken.

Eén van de vereisten voor het hanteren van een ontwikkelmethode is acceptatie door alle betrokken partijen, niet in de laatste plaats door de klant. Een Agile softwareontwikkelmethode vraagt vaak om meer betrokkenheid en proactiviteit van een klant dan de watervalmethode.

Omdat toekomstige veranderingen onbekend zijn, weet je bij een Agile aanpak niet van tevoren welke functionaliteit wel en niet ontwikkeld zal (of moet) worden. Om deze reden is Agile vaak geen logische keuze wanneer een klant beslist op basis van een Fixed Price traject wil werken.

Conclusie

Agile softwareontwikkeling kan een serieus alternatief zijn voor traditionele manieren van software ontwikkelen. Je kunt binnen minder tijd meer klanttevredenheid bereiken, door een website of webapplicatie op te leveren die beter aansluit bij wat de klant uiteindelijk wil. Scrum is een breed inzetbare en effectieve vorm van Agile softwareontwikkeling, maar vereist wel vertrouwen vanuit de klant richting de leverancier.

Meer lezen over Scrum en Agile?

Wil je meer informatie over deze onderwerpen? Kijk dan eens op:

• http://www.agilealliance.org/
• http://www.controlchaos.com/
• http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

• Home
• Artikelen
• Colofon