11.0 Waterval versus cyclisch projectbeheer (deel 4) – Projectlevenscyclus en resultaten

Methoden van projectmanagement die cyclisch zijn #

Vanwege de hierboven besproken problemen hebben zich de afgelopen jaren verschillende alternatieve technieken voor projectmanagement ontwikkeld. Deze technieken zijn bijzonder geschikt voor initiatieven voor de ontwikkeling van informatietechnologie.

Cyclisch projectmanagement is een methode om de doelstelling van het project te bereiken via een reeks korte, opeenvolgende cycli. Elke cyclus is kort, idealiter minder dan een maand. Elke cyclus voltooit een deel van het project. Elke cyclus omvat analyse, ontwerp, implementatie en testen. Dit verschilt aanzienlijk van de watervalbenadering, waarbij elk van deze taken in zijn eigen afzonderlijke fase plaatsvindt. Bovendien specificeert de watervalbenadering een beperkt aantal verschillende momenten voor concept, ontwerp, implementatie en testen. In de cyclische benadering gebeurt dit vele malen achter elkaar.

Begrip Projectbeheersoftware Fiets #

Doorheen de cycli worden verschillende softwarecomponenten geïmplementeerd, die dus op zichzelf staan. Elke cyclus wordt na afloop geëvalueerd. Als er nieuwe of alternatieve behoeften voor het project ontstaan als gevolg van toenemend begrip, worden de activiteiten van toekomstige cycli aangepast om ze op te nemen.

Een cyclus begint met het opstellen of wijzigen van een planning. Daarna worden de outputbehoeften van de cyclus geëvalueerd. Een ontwerp wordt ontwikkeld, gecodeerd en gevalideerd. Daarna vindt evaluatie plaats en in bepaalde gevallen wordt het nieuwe programma geïmplementeerd. Vervolgens kan de volgende cyclus beginnen om de volgende onderdelen van het project te voltooien. (Voor een meer gedetailleerde bespreking van cyclische technieken en hun onderscheidingen, zie bijvoorbeeld Kroll, 2004; Chromatic, 2003; Stapleton, 2002.)

Dit zijn de belangrijkste voordelen van het gebruik van de cyclische methode:

  • Verbeterde productkwaliteit en implementatie van functionaliteit;
  • Verbeterde productkwaliteit en implementatie van functionaliteit;
  • Meer realistische tijd- en kostenramingen;
  • Minder druk op het projectteam;
  • Hogere kwaliteit.

De voorgaande hoofdstukken laten zien hoe moeilijk of onmogelijk het is om in de beginfase van een project de benodigde capaciteiten goed te definiëren. Cyclische technieken implementeren de vereiste functionaliteit in een reeks korte cycli. Elke cyclus onderzoekt, maar ontwerpt, implementeert en test ook een klein deel van de vereiste functionaliteit. De snelle opeenvolging van ontwerp, uitvoering en testen is van cruciaal belang voor kwaliteitsverbetering. Hierdoor zijn teams in staat om veranderingen door te voeren. Als een ontwerp in de praktijk niet werkt, wordt dat gedurende de hele cyclus duidelijk, waardoor aanpassingen mogelijk zijn. Bovendien stelt dit soort bewerkingen consumenten in staat om wijzigingen aan te vragen.

Kwaliteit behouden #

Een andere reden waarom cyclisch projectmanagement de kwaliteit verbetert, is dat elke cyclus een intensieve samenwerking vereist tussen opdrachtgever, ontwerpers en programmeurs. Een multidisciplinair team ontwikkelt en voert samen oplossingen uit. De opdrachtgever is vooral in het begin bezig, bij het ontwikkelen van eisen; vervolgens maken ontwerpers een ontwerp en als laatste bouwen programmeurs de software. De projectleider fungeert als schakel tussen alle verschillende partijen en is er verantwoordelijk voor dat de verstrekte informatie bij de juiste ontvanger terechtkomt. In werkelijkheid komen veel programmeurs en ontwerpers nooit de klant tegen, die pas tijdens het softwareontwikkelingsproces weer opduikt.

Cyclische technieken van projectmanagement zijn vooral geschikt voor projecten waarbij het einddoel niet vooraf duidelijk kan worden gedefinieerd, zoals artistieke of onderzoeksinitiatieven. Door in cycli te werken met een divers team met eindgebruikers, kan het team het ware doel van het project bepalen en de beste manier om het te bereiken. Elke cyclus biedt een kans voor reflectie en correctie.

Voor watervalprojecten wordt vooraf een doel gedefinieerd. Reflectie op het oorspronkelijke doel is minder waarschijnlijk. Het aanvankelijk gevormde doel wordt nooit (volledig) gerealiseerd, en noch het oorspronkelijk bedachte, noch het gerealiseerde doel zal waarschijnlijk precies zijn wat de bedoeling was.

Ten slotte bieden cyclische projectmanagementmethoden superieure resultaten, aangezien de klant acceptatietests uitvoert. Bovendien wordt de kwaliteit verbeterd door van meet af aan tests als criterium op te nemen voor goed presterende functionaliteit. Daarom moeten programmeurs ‘mislukte tests’ (of unit-tests) maken voordat ze hun code schrijven. Alleen code die de mislukte test doorstaat, wordt als acceptabel beschouwd.

Consistent testen #

Testgericht werken vereist dat programmeurs vóór het schrijven aantonen dat nieuwe code vrij is van bugs. Ze doen dit door een test (falende test) te maken die mogelijke fouten identificeert voordat ze beginnen te coderen. Overweeg het geval waarin software moet worden ontwikkeld om de juiste hoeveelheid wisselgeld te bepalen die van een snoepautomaat moet worden ontvangen. Om te beginnen moet de aanwezigheid van een functie die verandering kan veroorzaken, worden geverifieerd. Deze functie kan worden aangeduid als ‘wisselgeld geven’. Er zou een eenvoudige test kunnen worden uitgevoerd en dan zou blijken dat de functie ‘wisselgeld geven’ nog niet bestaat. De test zal slagen als de programmeur de functie creëert, maar deze nog geen inhoud geeft.

De volgende stap is om te bepalen of de machine het juiste bedrag teruggeeft wanneer een artikel wordt gekocht. Steek zestig cent in de automaat en koop een item van vijftig cent. De test zal mislukken omdat de functie leeg blijft. Daarna schrijft de programmeur de code. Hij specificeert in de functie ‘wisselgeld geven’ dat de hoeveelheid terug te geven wisselgeld gelijk is aan het geldbedrag dat in de automaat is gestopt, minus de kosten van het geselecteerde snoepje. De test zou nu met succes moeten slagen. Deze procedure moet voor elk onderdeel van het programma worden herhaald.

Niet alleen de code moet technisch getest worden; de functies moeten ook worden getest (dwz acceptatietests). Alvorens te beginnen met coderen, stelt de klant de criteria vast waaronder de te ontwikkelen mogelijkheden kunnen worden goedgekeurd (bijvoorbeeld hoe snel een computer moet reageren op een bepaalde gebruikersactie). Voor die tijd bleek het definiëren van de criteria waaronder de aanvullende capaciteit kan worden goedgekeurd, zeer complex en tijdrovend. Desalniettemin is de actieve betrokkenheid van consumenten bij het testen van cruciaal belang voor het succes van het project.

Tijd- en geldschattingen #

Het begrijpen van de te implementeren functies is niet vooraf bepaald aan het begin van een cyclisch project. De beschikbare tijd wordt gegeven. Er worden afspraken gemaakt over de richting van het project en gedurende het proces wordt vastgesteld wat echt nodig, nuttig en haalbaar is in termen van het te creëren programma. Omdat de in te voeren functies geen gestelde doelen zijn, minimaliseren cyclische projecten het gevaar dat de benodigde uren, en dus geld, uit de hand lopen. Om dit scenario te vermijden, wordt de beschikbare tijd als uitgangspunt genomen en wordt gedurende het hele proces vastgesteld wat redelijk is om in die tijd te anticiperen.

Bovendien zijn cyclische projectmanagementtechnieken aanzienlijk beter verteerbaar voor het projectteam. Het team doet wat het kan binnen de gestelde tijd, maar wordt niet onder druk gezet om onredelijke deadlines te halen of binnen een ontoereikend budget te opereren.

Daarnaast vereenvoudigen cyclische technieken de administratie van buitenlandse aanbieders. Met de watervalaanpak kan een project afhankelijk worden van één enkele leverancier totdat het project is voltooid, ongeacht de prestaties van de leverancier. Het is in theorie haalbaar om per cyclus of zelfs per onderdeel cyclisch te leveren nieuwe afspraken te maken en desgewenst van leverancier te wisselen.