Als groot nadeel van de cyclische werkwijze wordt wel genoemd dat teams gelijk aan de slag gaan. Er wordt dan te weinig nagedacht over wat er nu precies gewenst is. Verwachtingen van eventuele klanten of opdrachtgevers worden niet goed gemanaged. Afspraken over gewenste resultaten worden onvoldoende gemaakt. Dit is de andere kant van de cyclische werkwijze in tegenstelling tot de watervalaanpak waarbij in het begin alles wordt vastgelegd.
Om dit dilemma te omzeilen wordt binnen DANS voor softwareontwikkeling met het beste van twee methoden gewerkt. De projecten starten met de watervalmethode, zodat er goed nagedacht wordt over eisen, wensen en ontwerp. Na de ontwerpfase wordt overgegaan op cyclisch werken, waarbij flexibel omgegaan kan worden met eisen, wensen en ontwerpen. Voor het cyclische deel van de DANS-methode wordt gebruik gemaakt van eXtreem Programming (XP) (Chromatic, 2003, [ii], [iii]). Binnen de cycli vindt nadere definiëring, nader ontwerp, realisatie en testen plaats. Als de software vervolgens voldoende is ontwikkeld start de nazorgfase. Hieronder wordt deze werkwijze stap voor stap verder beschreven.
Initiatiefase
De initiatiefase begint bij een idee voor een project. Er is nog geen budget beschikbaar voor het project. Doel van deze fase is het schrijven van een projectplan op basis waarvan financiering intern of extern aangevraagd kan worden.
Activiteiten initiatiefase:
- Uitwerken idee
- Onderzoeken draagvlak
- Contacten leggen met eventuele partners
- Financieringsmogelijkheden onderzoeken
- Eerste globale inschatting van de GOKIT factoren voor het project
- Concrete inschatting GOKIT factoren voor de definitiefase
- Begrenzen van het project
- Schrijven projectplan
- Aanvragen financiering of contractafspraken maken met een eventuele klant
Resultaat initiatiefase:
- Goedgekeurd en gefinancierd projectplan
- (Eventueel) contract met klant
Uitvoering/Beslissingen:
- (Beoogd) projectleider
- Opdrachtgever
- (Eventueel) klant
Hulpmiddelen:
Als het mogelijk is om de financiering in trances te krijgen is dit te verkiezen boven financiering in één keer na de initiatiefase. Bij gefaseerde financiering wordt in de initiatiefase een financieringsverzoek gedaan voor een relatief klein bedrag in de initiatiefase voor het uitvoeren van de definitiefase en ontwerpfase. Op basis van de uitkomst van deze fases wordt aan het einde van de ontwerpfase een tweede financieringsverzoek gedaan voor de rest van het project.
Definitiefase
Nadat een projectplan is goedgekeurd, komt het project in de tweede fase, de definitiefase. In deze fase worden de eisen en wensen die aan een projectresultaat gesteld worden zo goed en compleet mogelijk bepaald. Het gaat er om de verwachtingen van de betrokken partijen over wat het projectresultaat moet zijn boven tafel te krijgen. Hierbij kan de lijst als geheugensteun dienen:
- Randvoorwaarden
- Functionele eisen
- Operationele eisen
- Ontwerpbeperkingen
Het is heel belangrijk dat alle betrokkenen in een project kunnen meedenken in de definitiefase. Vooral ook de eindgebruikers die het projectresultaat gaan gebruiken.
Activiteiten definitiefase:
- Eisen en wensenlijst opstellen samen met opdrachtgever, (eventuele) klant, eindgebruikers, experts, projectteam
- Eisen en wensen afwegen
- Haalbaarheid eisen en wensen toetsen
- Rapportage aan opdrachtgever en/of klant van eisen en wensen
- Rapportage van de GOKIT factoren tot nu toe (gerealiseerd)
- Nieuwe prognose van de globale GOKIT factoren voor de rest van het project
- Prognose van de concrete GOKIT factoren voor de ontwerpfase
Resultaat definitiefase:
- Goedgekeurde (voorlopige) eisen en wensenlijst
- Goedgekeurde GOKIT rapportage en prognoses
Uitvoering:
- (Beoogd) projectleider
- Opdrachtgever
- (Eventueel) klant
- Eindgebruikers
- Experts
- (Toekomstige) programmeurs en ontwerpers
- Systeembeheerder (in verband met eisen en wensen in de nazorgfase)
Beslissingen/goedkeuring:
- Projectleider
- Opdrachtgever
- (Eventueel) klant
Hulpmiddelen:
Bij de watervalmethode geldt dat er in principe na de definitiefase geen andere of aanvullende eisen meer gesteld mogen worden aan het project. De eisen en wensenlijst vormt als het ware de basis voor het contract tussen het projectteam en de opdrachtgever of klant. De eisen en wensenlijst is datgene waar het projectresultaat uiteindelijk aan moet voldoen.
Omdat we gezien hebben dat dit bij softwareprojecten tot problemen leidt, wordt deze strikte manier van werken hier niet gevolgd. De definitiefase wordt hier gebruikt om een onderzoek naar de eisen en wensen te laten plaatsvinden zodat het project zo goed mogelijk richting krijgt. Ook wordt er beschreven wat er allemaal niet gemaakt wordt. Dit om de verwachtingen tussen klant en makers helder te krijgen. Mocht door het voortschrijdende inzicht in de cyclische fases blijken dat bepaalde eisen en wensen anders ingevuld moeten worden, dan is dat bij deze werkwijze mogelijk (uiteraard in overleg en goed gedocumenteerd)
Ontwerpfase
Met de eisen- en wensenlijst uit de definitiefase kan het projectteam keuzes maken over hoe de software eruit moet komen te zien. De ontwerpfase van ICT projecten heeft een ontwerpdocument als resultaat. In het ontwerpdocument wordt het concept nader uitgewerkt en in grote lijnen wordt er een technisch ontwerp uitgewerkt. Doel is om te onderzoeken hoe de software er zowel technisch als functioneel uit zou kunnen zien (een voorbeeld van een functioneel ontwerpdocument is te vinden op [iv]).
In dit kader is het handig om in de ontwerpfase te werken met dummy’s die voorgelegd worden aan de opdrachtgevers en/of klanten en eindgebruikers.
Een dummy is een snel in elkaar gezet, niet werkende of slechts deels werkend stuk software dat vooral dient om het ontwerp te evalueren. Dummy’s hebben het voordeel boven schema’s op papier dat ze eruitzien als het beoogde eindproduct.
Bij de watervalmethode is het na de goedkeuring van de ontwerpdocumenten door de klant in principe niet meer mogelijk op ontwerpbeslissingen terug te komen. Bij de DANS-werkwijze kan dat wel. De ontwerpdocumenten dienen als eerste uitgangspunt voor de bouwers, maar mocht door voortschrijdend inzicht blijken dat er wijzigingen nodig zijn, dan kunnen die doorgevoerd worden.
Als in de cyclische fasen besloten wordt het ontwerp aan te passen, dan moet die wijziging niet alleen geprogrammeerd worden, maar ook bijgewerkt worden in een zogenaamd projectlog.
Als naar mening van het projectteam het ontwerp voldoende is uitgewerkt, start de cyclische fase.
Activiteiten ontwerpfase:
- Ontwerpdocumenten opstellen
- Mock-ups (dummies) maken en evalueren met klant
- Rapportage gekozen ontwerp
- Rapportage van de GOKIT factoren tot nu toe (gerealiseerd)
- Nieuwe prognose van de globale GOKIT factoren voor de rest van het project
- Prognose van de concrete GOKIT factoren voor de cyclische fase
Resultaat ontwerpfase:
- Goedgekeurd ontwerpdocument
- Goedgekeurde GOKIT rapportage en prognoses
Uitvoering:
- Projectleider
- Designers
- Programmeurs
- (Eventueel) eindgebruikers voor evaluatie ontwerpen
Beslissingen/Goedkeuring:
- Projectleider
- Opdrachtgever
- (Eventueel) klant
Cyclische fase
De werkwijze in de cyclische fase is ontleend aan XP. In deze fase wordt een aantal cycli na elkaar uitgevoerd. Een cyclus duurt maximaal een tot twee weken. In elke cyclus vinden de volgende activiteiten plaats:
- Plannen
- Onderzoeken van functionaliteiten
- Ontwerpen van functionaliteiten
- Realiseren van functionaliteiten
- Testen van functionaliteiten
- Opleveren van functionaliteiten
Plannen
Aan het einde van de ontwerpfase is een inschatting gemaakt van het aantal cycli dat nodig is voor het bereiken van het projectdoel. Dit gebeurt op basis van het functionele en technische ontwerp. Een cyclus duurt nooit lang, ergens tussen de twee en vier weken. In een cyclus komen altijd de activiteitenplannen, onderzoeken, ontwerpen, realiseren, testen en opleveren voor. Per cyclus wordt dus maar gewerkt aan enkele functionaliteiten, soms maar aanéén.
De spelregels voor het plannen zijn als volgt. De gewenste functionaliteiten worden door de projectleider samen met de klant op zogenaamde storycards opgeschreven. Begonnen wordt met de functionaliteiten die bepaald zijn in de definitie- en ontwerpfase op storycards te schrijven. Op basis van die storycards maken de programmeurs een takenlijst, een lijst van dingen die zij moeten doen om die functionaliteit te realiseren. Die taken mogen in de regel niet langer duren dan een paar uur. Als een taak langer duurt, moet hij gesplitst worden in verschillende subtaken of moet de storycard gesplitst worden in meerdere storycards. Als een storycard te veel werk is om in één cyclus plaats te vinden, moet hij worden teruggegeven aan de klant. De klant moet de wensen dan opsplitsen en verdelen over meer storycards.
Per taak geeft de programmeur aan hoeveel tijd hij ervoor nodig denkt te hebben. Zo ontstaat een ureninschatting per storycard. Op basis van de ureninschattingen van de storycards kan de klant nu samen met de projectleider aangeven welke van de functionaliteiten ze als eerste gerealiseerd willen zien in de eerstvolgende cyclus.
Hoelang duurt het om een website te maken en deze te vullen met 50 pagina’s tekst en een aantal foto’s? Een snel antwoord van de ontwerper dat het ‘ongeveer twee weken duurt’ is veel te grof. Het zou best wel eens veel langer kunnen duren. Wordt deze taak uitgesplitst dan blijkt dat er een CSS gemaakt moet worden, overleggen met de opdrachtgever over het ontwerp, het ontwerp programmeren in xhtml, de teksten inkorten voor het internet, de pagina’s vullen met de teksten, de foto’s geschikt maken voor het internet, de foto’s plaatsen, controle door de klant en de laatste foutjes eruit halen.
Door het werk uit te splitsen in kleinere delen, blijkt het veel meer werk dan aanvankelijk gedacht. Ook realiseert de opdrachtgever zich dat hij ook een aantal dingen moet doen. Als nu per taak ingeschat wordt hoeveel uur werk het is, zal het een veel betere totaalschatting opleveren (en zal blijken dat het niet in twee weken kan).
Als de programmeurs aan de slag gaan, houden ze hun uren bij die ze nodig hebben voor het uitvoeren van een taak. Vaak blijkt dat ze meer uren nodig hebben dan ze aanvankelijk zelf geschat hadden. Doordat ze een terugkoppeling krijgen op hun eigen inschattingen, leren de programmeurs steeds betere schattingen te maken.
Uit de praktijk blijkt dat naarmate een project een tijdje loopt er een redelijk constante factor verschil is tussen de schattingen van de programmeurs en de werkelijk benodigde aantallen uren. Deze factor wordt de ‘dragfactor’ genoemd. De dragfactor kan na een paar cycli bepaald worden op basis van het gemiddelde verschil tussen de geschatte en benodigde uren. De dragfactor wordt gebruikt in planningen van toekomstige cycli en in rapportages. Met name het aantal uitstaande storycards met takenlijsten maal de dragfactor is een redelijk betrouwbare indicatie van de hoeveelheid tijd die nog nodig is voor het realiseren van de rest van het project.
Het aantal uren voor het project is beperkt, dus dat betekent dat er keuzes gemaakt moeten worden. Doordat er een redelijk inzicht is in het aantal benodigde uren voor het realiseren van een storycard, kan een goede afweging gemaakt worden tussen de verschillende storycards. Sommige storycards zullen simpeler uitgevoerd moeten worden, andere storycards komen als geheel te vervallen. Belangrijk uitgangspunt bij het bepalen van de volgorde is dat risicovolle storycards als eerste behandeld moeten worden. Dit om zo snel mogelijk de belangrijkste risico’s uit te schakelen. Daarnaast gelden de MoSCoW-regels of een simpeler prioriteitstelling van 1 tot 5.
Plannen functionaliteiten in de cycli
Figuur 12: Plannen van de functionaliteiten in de cycli
Onderzoeken en ontwerpen functionaliteiten
Door het maken van de takenlijsten voor de planning vindt het eerste onderzoek van de functionaliteit plaats. Door het vooraf bedenken welke deeltaken nodig zijn bij het realiseren van een functionaliteit, krijgt de programmeur meer inzicht in de functionaliteit zelf. Voor het verder onderzoeken en ontwerpen van de gewenste functionaliteit is de betrokkenheid (aanwezigheid) van de klant essentieel. Hij moet aangeven wat hij precies wil. De klant zal in het begin van het project veel contact hebben met de programmeurs. Later in het project kan dat afnemen, al moet ervoor gewaakt worden dat programmeurs niet gaan denken voor de klant en dan verkeerde aannames doen.
Realiseren van de functionaliteiten
Nadat de klant en de makers een ontwerp voor de gewenste functionaliteit zijn overeengekomen, wordt deze gebouwd. Programmeurs werken daarbij altijd in paren (‘pairprogramming’ in XP termen). Dit lijkt wellicht improductief, maar pairprogramming biedt vele voordelen:
- Kennis van twee programmeurs wordt gecombineerd
- Minder tijd nodig voor overdracht van kennis of code binnen een project
- Minder fouten tijdens het programmeren
- Sneller knelpunten oplossen
Er is nog een ander voordeel: het grootste probleem is beginnen met programmeren. Eenmaal begonnen dan loopt het verder wel. Door paarsgewijs te programmeren, worden de programmeurs eerder door elkaar aangespoord te starten met werken.
Joel Spolsky was programmeur bij Microsoft en realiseerde zich dat hij maar zo’n drie uur per dag effectief werkte [v]. Vaak nog minder. Het lijkt erop dat meer collega’s dat hadden. De rest ging op aan koffiedrinken, e-mails lezen, internetten, praten met collega’s en de prachtige kantoortuin bekijken. Door te werken met een ander word je gemotiveerd en is de start makkelijker.
Overigens vraagt pairprogramming veel van de concentratie van programmeurs en niet alle programmeurs vinden het prettig. Bovendien werken niet alle combinaties van programmeurs prettig samen. Om deze nadelen te verzachten kan een team bijvoorbeeld besluiten om niet meer dan een halve dag per dag pairprogramming toe te passen voor een discussie over pairprogramming).
Testen en opleveren
Essentieel is dat elke cyclus tot een release van een nieuw deel van de software leidt en dat elk deel dat opgeleverd wordt, getest is. Testen bestaat uit een unit test (test door de programmeurs) en een acceptatietest (test door de klant). Ook hierbij is de inzet van de klant dus nodig.
Achterliggend idee van het testen in elke cyclus is de theorie dat het exponentieel duurder wordt om fouten te herstellen naarmate het langer heeft geduurd voor ze gevonden zijn. Uitgangspunt bij het opleveren van software in elke cyclus is dat de klant zo snel mogelijk waar voor zijn geld krijgt en dat er snel feedback mogelijk is van de gebruikers naar de programmeurs. De klant ziet duidelijk de voortgang van het project. Dit is vooral psychologisch van belang en kan de verhouding met de klant aanzienlijk verbeteren.
Op een punt verschilt de werkwijze van DANS essentieel met de werkwijze van XP. XP schrijft voor dat er niet vooraf een ontwerp gemaakt mag worden voordat met programmeren wordt begonnen. Dit om maximale flexibiliteit te bereiken en niet al dingen vast te zetten, die later niet handig blijken te zijn. Naar mening van de auteur en adviseurs van dit handboek is het echter wel nuttig om te beginnen met het maken van een ontwerp in de definitiefase en ontwerpfase. De functionaliteiten die in die fases worden bepaald, mogen bij de DANS werkwijze wel worden aangepast in de cyclische fase in tegenstelling tot de werkwijze van de watervalmethode.
Activiteiten cyclische fase:
- Doorlopen van een aantal cyclussen waarin onderzocht, ontworpen, gerealiseerd, getest en opgeleverd wordt
- Opstellen van storycards
- Keuzes maken uit de storycards
- Plannen van de cycli
- Voortgang bewaken (GOKIT)
- (Aan het einde) prognose van de concrete GOKIT-factoren voor de nazorgfase
Uitvoering/beslissingen
- Projectleider
- Opdrachtgever of klant
- (Eventueel) eindgebruikers voor testen en ontwerpen
- Programmeurs en ontwerpers
Hulpmiddelen:
- Nazorgfase
Nadat voldoende resultaat is bereikt in de cyclische fase, start de nazorgfase. In deze fase moet het projectresultaat geborgd worden. Het hangt van het soort project en de afspraken met de opdrachtgever of klant af wat die borging inhoudt. Bij een onderzoeksproject volstaat wellicht een eindrapport, bij de ontwikkeling van een nieuw product zal meer nazorg nodig zijn.
De meeste problemen in de nazorgfase ontstaan omdat er bij het begin van het project geen duidelijke afspraken zijn gemaakt tussen klant of opdrachtgever en projectteam.
Denk bijvoorbeeld aan de volgende punten:
- Hoe lang moet de nazorg duren?
- Waar bestaat de nazorg uit?
- Hoe snel moeten fouten hersteld worden?
- Zit er garantie op het projectresultaat?
- Wie is er verantwoordelijk voor bugs die gevonden worden ná het project?
- Moet er documentatie bij het projectresultaat worden geleverd?
- Is er training en/of opleiding nodig voor gebruikers?
- Wie is er verantwoordelijk voor updates?
- Wie wordt de eigenaar van de code, wie mag de code wijzigen?
- Wie betaalt de bovenstaande punten?
Het is belangrijk te beseffen dat een projectorganisatie gericht is op tijdelijke activiteiten en derhalve niet ingericht is om (lang) ondersteuning te bieden op de software die het zelf heeft ontwikkeld. Voor de langere termijn moet een andere vorm voor ondersteuning gevonden worden. Er zijn speciale (commerciële) organisaties voor het beheren van software. Deze organisaties bieden helpdeskondersteuning, trainingen, serverbeheer, applicatiebeheer en dergelijke. Voor kleine non-profit initiatieven zullen deze organisaties veelal (te) duur blijken.
Een ander traject dat bewandeld kan worden om de continuïteit van de software te waarborgen, is de software open source maken. Hier wordt een organisatie voor ingericht zodat een groep van ontwikkelaars en gebruikers in staat is om de software te onderhouden en te ondersteunen.
Activiteiten nazorgfase:
- Rapportage van de GOKIT-factoren van het project
- Opstellen en indienen eindverantwoording
- Ontbinden team
- Overdracht naar beheersorganisatie
Resultaat nazorgfase:
- Projectverantwoording
- Overdrachtsdocumenten
Uitvoering:
- Projectleider
- Teamleden
- Systeembeheerder
Beslissingen/Goedkeuring:
- Projectleider
- Opdrachtgever
- (Eventueel) klant
