Ontwikkelingsmethoden als ‘rapid application development’ managen is niet eenvoudig. Immers de vele vooraf gedefinieerde mijlpalen van een traditioneel lineair proces ontbreken. Het gevaar van uitloop ligt op de loer, sterker nog; is acuut. ‘Timeboxing’ kan zo’n proces beheersen; strikte mijlpalen in de tijd worden onveranderbaar vastgesteld. Tijdsdruk kàn de timebox echter veranderen in een tijdbom. Een speciale ‘gelaagde’ variant biedt een goede oplossing, maakt een consultant van Getronics duidelijk.
Met timeboxing weten projectteams (deel)systemen exact op de vooraf gestelde data op te leveren. Toch leidt deze techniek in de praktijk niet altijd tot goede resultaten. Ondanks vooraf gemaakte afspraken is er vaak sprake van ontevredenheid over het opgeleverde product bij eindgebruikers en management. Als dan ook nog de invoering niet mogelijk blijkt te zijn door het ontbreken van bepaalde functionaliteit werkt de timebox als een tijdbom; het stopt abrupt en wat er overblijft is chaos.
Moderne systeemontwikkelingsmethoden onderscheiden zich met name van de lineaire methoden door hun iteratieve karakter. Bij iteratief ontwikkelen bestaat de mogelijkheid bepaalde beslissingen te heroverwegen. Dit is prettig voor de eindgebruikers die betrokken zijn bij de systeemontwikkeling. Enerzijds doordat het een bepaalde vrijheid creëert; de gebruiker wordt namelijk niet direct vastgepind op zijn ideeën en uitspraken. Anderzijds worden wijzigingen, naar aanleiding van voortschrijdende inzichten, zonder vervelende en tijdrovende wijzigingsprocedures doorgevoerd.
Spanningsveld
Toch kent het iteratieve karakter ook het gevaar van oneindig lang doorgaan. Iteratieslagen hebben als eigenschap nooit te willen stoppen. Er blijft altijd nog wel een behoefte om bepaalde zaken te heroverwegen. Gebruikers komen voortdurend terug op reeds genomen beslissingen. Niet alleen een nachtmerrie voor een projectteam maar uiteindelijk ook voor de opdrachtgever. Projecten lopen uit, budgetten worden overschreden.
Timeboxing of Time Box Management wordt dan veelal gezien als de techniek om dergelijke problemen te voorkomen. Bij timeboxing worden strikte mijlpalen in de tijd onveranderbaar vastgesteld. Hierdoor kan de oplevering per definitie niet uitlopen. Timeboxing vindt zijn oorsprong in de journalistiek waar bijvoorbeeld het Journaal exact om 20.00 uur aanvangt. Nieuws dat net te laat arriveert, kan pas in een volgende uitzending worden meegenomen.
In de systeemontwikkeling vertaalt dit zich naar kosten en kwaliteit (functionaliteit). Als voor de oplevering van een applicatie de tijd onveranderbaar is vastgesteld, zijn alleen de kosten en de kwaliteit (functionaliteit) te variëren. Aangezien de budgetten ook veelal zijn vastgesteld vindt de oplevering inderdaad plaats op de vooraf gestelde datum, maar is de functionaliteit of kwaliteit van de applicatie pas bekend op die datum. Functionaliteiten waar men nog niet aan toegekomen is, schuiven door naar een volgende oplevering.
Gebruikers die bepaalde functionaliteiten of kwaliteiten van een applicatie verwachten bij een eerste oplevering kunnen dus teleurstellingen tegenkomen. Gebruikers trachtten dit op creatieve wijze te voorkomen. Zo is een geval bekend van een 150-pagina’s tellende fax met gewenste wijzigingen die op de sluitingsdag van de laatste timebox bij het projectteam binnenkwam. Het fax-apparaat draaide van 4 uur ’s middags tot 9 uur ’s avonds en was daarmee, volgens de gebruikers, nog net op tijd.
Om de impasse te doorbreken biedt gelaagde timeboxing een oplossing. Deze vorm van timeboxing zorgt voor evenwichtigheid in het spanningsveld tussen opdrachtgever, gebruikers en projectleider.
Gelaagde timeboxing
In een traditioneel lineair ontwikkelingsproces zorgen vooraf gedefinieerde mijlpalen voor tussentijdse ‘go’- of ‘no go’-momenten. In rad-projecten (rapid application development) zijn deze momenten niet aanwezig. Daarom is de techniek (gelaagde) timeboxing vooral in rad-projecten succesvol. Dergelijke projecten beginnen veelal met een fase waarin het applicatiegebied op functionele, technische en organisatorische aspecten wordt afgebakend. Indien het applicatiegebied te omvangrijk is, wordt deze opgedeeld in deelapplicaties, ook wel incrementen genoemd.
Deze fase is in de literatuur bekend onder diverse benamingen. James Martin spreekt in dit geval over ‘joint requirement planning‘. In dit artikel wordt voor deze fase de term ‘applicatie-afbakening’ gehanteerd. Nadat het applicatiegebied duidelijk is afgebakend en de eisen die daaraan gesteld worden bekend zijn, start het ontwerp. Met intensieve workshop-sessies geven gebruikers, manager en projectleden per increment invulling aan de applicatie. James Martin noemt deze ontwerpfase een ‘joint application design‘ (jad).
Parallel aan het ontwerp vindt de bouw plaats van het increment. Nadat het increment gebouwd is, wordt deze op iteratieve wijze gereviewd en verbeterd. Gelaagde timeboxing zorgt ervoor dat dit voor alle betrokken partijen op een aanvaardbare wijze gebeurt.
Iteratiestrategie
De meest toegepaste iteratiestrategie is ‘incrementeel ontwikkelen’, waarbij onderdelen van de applicatie-ontwikkeling (ontwerp en bouw) heroverwogen worden. Deze heroverwegingen moeten echter wel binnen het afgebakende gebied van het increment blijven. Met andere woorden, de applicatie-afbakening als voorfase van de jad-workshop maakt geen onderdeel uit van de iteratieslagen. Gewenste aanpassingen buiten de afbakening leiden tot wijzigingsvoorstellen met consequenties voor kosten en doorlooptijd.
Timeboxing wordt toegepast op elke iteratieslag. Er vinden drie slagen plaats op elk increment. Dit gebeurt in de vorm van een workshop waarin het increment in zijn geheel wordt gedemonstreerd. De drie iteratieslagen verschillen inhoudelijk.
Logische drie lagen
Gelaagde timeboxing is gebaseerd op de meest geaccepteerde logische drie-lagenarchitectuur, bestaande uit de presentatielaag, bedrijfslogica- of functielaag en datalaag. Het increment is ontwikkeld binnen de vastgestelde applicatie-afbakening. Verbeteringen worden middels review-sessies besproken en doorgevoerd.
Drie maal (iteraties) wordt het increment (of incrementen) beoordeeld. Bij iedere iteratie nemen de aanpassingsmogelijkheden voor de gebruiker af. Deze aanpassingsmogelijkheden hebben betrekking op de logische drie-lagenarchitectuur. Vandaar de term ‘gelaagde timeboxing’.
Tijdens de review-sessie(s) wordt het gehele increment gedemonstreerd en beoordeeld. Binnen de grenzen van de applicatie-afbakening mag de gebruiker alles aanpassen. Ook wanneer dit niet geheel strookt met hetgeen in de jad-workshop is besproken.
Tijdens de review-sessies wordt weliswaar het gehele systeem beoordeeld, maar de nadruk moet liggen op de goedkeuring van de datalaag. Wijzigingen met gevolgen voor de andere lagen zijn ook toegestaan, maar hiervoor krijgen de workshop-leden nog voldoende mogelijkheden.
Belangrijk bij de review-sessie(s) is de aanwezigheid van een datamodelleerder en database-expert. Deze persoon moet na de review-sessie(s) over alle benodigde gegevens beschikken voor het inrichten van de datalaag (zowel het logische als fysieke datamodel).
Bouwen op drijfzand
Voor de start van de refine-sessies wordt de datalaag van het increment bevroren. Dit houdt in dat tijdens deze fase wijzigingen met consequenties voor de datalaag (entiteiten, attributen, relaties plus de interfaces naar de datalaag) niet meer zijn toegestaan. Anders blijft het bouwen op drijfzand.
Indien de gebruikers toch van mening zijn dat de applicatie niet in productie kan zonder een aanpassing op de datalaag, dan treedt de wijzigingsprocedure in werking. Dat betekent dat er een wijzigingsvoorstel wordt opgemaakt met daarop de consequenties voor de kosten of de doorlooptijd van het project. Het management moet dan beslissen of de wijziging wordt doorgevoerd.
Belangrijk voor het procesverloop is dat tijdens deze sessies het besef bij de gebruikers gaat leven dat niet alle aanpassingen zonder consequenties zijn door te voeren. Veel gestelde vragen bij het bespreken van een gewenste aanpassing zijn dan ook : "Kan dat nu nog wel?" of "Mag ik dit nu nog roepen?".
De gebruiker kan niet altijd de consequenties van een aanpassing overzien. In de praktijk blijkt dat de gevolgen van een aanpassing op de logische architectuurlagen aantoonbaar kunnen worden gemaakt en begrijpelijk uit te leggen zijn.
Tijdens de refine-sessies wordt weliswaar het gehele systeem beoordeeld, maar de nadruk moet liggen op de goedkeuring van de functielaag.
Ook tijdens de tuning-sessie(s) wordt het gehele increment getoond en beoordeeld. Heroverwegingen zijn alleen nog toegestaan voor de presentatielaag. Voor de gebruikers zijn de mogelijkheden beperkt, maar het geeft de ontwikkelaars tijd om de aanpassingen uit de refine-sessies door te voeren. Voor de start van de tuning-sessies worden de datalaag en de functielaag van het increment bevroren. Dat betekent dat er gedurende deze sessie slechts ‘cosmetische’ wijzigingen doorgevoerd kunnen worden op de presentatielaag.
Gemeentelijk Havenbedrijf Rotterdam
Gelaagde timeboxing wordt toegepast in recente projecten, waarbij gekozen is voor een iteratief ontwikkelingsproces. Met name bij de ontwikkeling van decision support systems, executive information systems en administratieve systemen is deze techniek in diverse branches steeds met succes toegepast.
Een praktijkvoorbeeld is de iteratieve ontwikkeling van een management-informatiesysteem voor het Gemeentelijk Havenbedrijf Rotterdam: een applicatie die gegevens extraheert en valideert uit operationele systemen van twee afdelingen en ze omvormt tot managementinformatie. Aan de hand van deze applicatie kan het management de gecombineerde gegevens op diverse aggregatieniveaus benaderen. Na de applicatie-afbakening begon het iteratieve ontwikkelproces met de project-initiatie. Een ‘kick-off’ werd gehouden, workshopsessies werden in de agenda’s geplaatst en de ontwikkelomgeving werd geïnstalleerd.
Vervolgens startte het ontwerp van de applicatie. Parallel daaraan werd de initiële applicatie gebouwd. Met behulp van intensieve workshopsessies gaven de toekomstige gebruikers van beide afdelingen en de gegevensbeheerder invulling aan de initiële applicatie. De resultaten uit de voorfase, de applicatie-afbakening, vormden de basis voor het ontwerp, alsmede de bewaking. Ook de ontwikkelaars van de applicatie waren aanwezig bij de workshop-sessies. Aan de hand van de specificaties uit de sessies waren zij in staat een eerste versie van de applicatie te bouwen. De applicatie-ontwikkeling (ontwerp en de initiële bouw) nam een doorlooptijd van slechts zes weken in beslag.
3 : 2 : 1
Na de initiële bouw begonnen de iteratieslagen in combinatie met gelaagde timeboxing; de reviewfase, gevolgd door de refine- en tuningfase. De sessies in deze fasen vonden wekelijks plaats; drie keer review, twee keer refine en één keer tuning. De ontwikkelaars konden gedurende de rest van de week de applicatie aanpassen op basis van de resultaten uit de fasen.
Tijdens de reviewfase kwamen veel aanpassingswensen naar voren. Zolang de wijzigingen binnen het afgebakende gebied bleven, werden ze ook doorgevoerd. De snelle ontwikkeling en terugkoppeling van wijzigingen nodigden de enthousiaste gebruikers uit kritisch te zijn. Hierdoor ontstonden ook wensen die buiten het afgebakende gebied vielen. Het management-informatiesysteem moest informatie leveren die niet afkomstig was uit één van de geselecteerde operationele systeem. Deze wijzigingsvoorstellen werden beschreven en geparkeerd voor ná de oplevering. Het was niet nodig en wenselijk het applicatiegebied met consequenties voor kosten en tijd uit te breiden.
Tijdens de tuningfase bleek het Gemeentelijk Havenbedrijf Rotterdam nog wensen te hebben om de applicatie aan te passen met gevolgen voor de datalaag. De gebruikers gaven aan dit zo belangrijk te vinden dat de applicatie, naar hun mening, zonder deze wijziging niet in productie kon worden genomen. De gebruikers beschreven het probleem, het ontwikkelteam gaf de consequenties aan en de projectleider nam daarop direct contact op met de opdrachtgever om de knoop door te hakken.
Wanneer deze omvangrijke wijziging in dit stadium zou worden doorgevoerd, zou de oplevering van het management-informatiesysteem met minstens twee weken worden vertraagd. De opdrachtgever besloot daarop de wijziging na oplevering door te voeren. De tuningfase leverde niet veel wijzigingen op voor de presentatielaag en kon derhalve snel worden afgerond. De regels voor gelaagde timeboxing hebben gewerkt. Wildgroei en andere narigheid bleven uit, het creatieve element bleef.
Conform planning
Tijdens de bouw werd direct getest. Na de laatste aanpassing vond een integrale systeemtest plaats. Ondanks het gezamenlijke ontwerp en de drie iteratieslagen (review, refine- en tuningfasen) met gebruikers bestond toch de behoefte aan een formele eindcontrole. Voor de invoering is daarom een korte acceptatietest uitgevoerd door de gebruikers en gegevensbeheerder. Kort, omdat de gebruikers de applicatie reeds kenden en de laatste aanpassingen minimaal waren (tuningfase).
Het management-informatiesysteem werd conform de planning opgeleverd door de intensieve inspanning van alle partijen. Het project werd afgesloten met een eindpresentatie en demonstratie aan diverse betrokkenen binnen het Gemeentelijk Havenbedrijf Rotterdam. Bij het samenstellen van de presentatie werd ondersteuning verleend, maar de uiteindelijke uitvoering verzorgden de toekomstige gebruikers zelf volledig. Deze bereidheid zegt wel iets over het behaalde resultaat.
De duur en het aantal sessies per iteratieslag worden vooraf bepaald en veranderen niet (timeboxing). Zij verschillen wel van elkaar. Dit komt door enerzijds de toenemende bekendheid met het increment en anderzijds de afnemende aanpassingsbevoegdheden van de gebruikers. De tijdsverdeling van de drie type iteratieslagen (review, refine en tuning) verhoudt zich over het algemeen als: 3 : 2 : 1.
Norbert van Hengstum, consultant bij Getronics Software
Gelaagde timeboxing