Rijmt iteratief ontwikkelen met project management

Iteratieve ontwikkeling is voor veel software developers al sterk ingeburgerd. De methode gaat er van uit dat je vroeg in de levenscyclus van een project begint met implementeren, testen, enzovoort, om de projectrisico’s zo vroeg mogelijk op te vangen. Toch zijn er nog veel andere betrokkenen die er moeite mee hebben om op deze manier te denken en steeds teruggrijpen naar de klassieke analyse-design-implementatie- test cyclus (de ‘watervalaanpak’).

De watervalmethode is geïnspireerd door meer klassieke engineeringpraktijken zoals de aanleg van bruggen en wegen of de constructie van gebouwen. Dat soort projecten wordt gekenmerkt door weinig veranderende behoeften en technieken die in de meeste gevallen zeer goed gekend zijn. We kunnen de parallel doortrekken naar IT-projecten: als de behoeften erg goed gekend zijn, de kans op wijzigingen zeer klein is en men bovendien al uitgebreide ervaring heeft met de te gebruiken technologieën, dan is er niks mis met een zuivere sequentiële aanpak zoals waterval.

Helaas voldoen de meeste hedendaagse projecten niet aan die criteria. De steeds terugkomende redenen van projectmislukkingen, volgens Frank Winters in ‘The top ten reasons projects fail’ zijn: – het onvoldoende begrijpen van de behoeften
– het wijzigen van de behoeften
– het onderschatten van het te verrichten werk
– slechte communicatie
– het ontbreken van afstemming met de stake holders van het project
het ontbreken van voldoende planning en controle Iteratieve ontwikkelingsmethodes zijn algemeen aanvaard als een betere methode om met dit soort problemen om te gaan.

ITERATIEVE ONTWIKKELINGSMETHODES
Deze methodes (de meest bekende is RUP) werken in meerdere iteraties naar het eindproduct toe. In elke iteratie wordt al een deel van het product afgewerkt om zo een ‘big bang’ implementatie op het einde uit de weg te gaan.

Vooral de risico’s van het project bepalen de inhoud van de iteraties: het is uiteraard de bedoeling om eerst de belangrijkste risico’s aan te pakken en later de minder belangrijke. De praktijk toont aan dat het is aangewezen om al tijdens de eerste iteraties de meer technische architectuurrisico’s te behandelen en pas later de businessrisico’s. Die laatste zijn immers een constant gegeven in de looptijd van een project.

Bovendien heeft men er als projectteam zelf weinig controle over (bv. veranderende prioriteiten, onbeschikbaarheid van business expertise, enzovoort). De technische risico’s daarentegen kunnen degressief quasi weggewerkt worden en leggen tegelijk ook de beperkingen vast die men bij de verdere implementatie in acht dient te nemen. De businesswaarde van een bepaald scenario kan een alternatieve benadering zijn voor het bepalen van de inhoud van een iteratie.

TE VERZOENEN MET KLASSIEKE PROJECT MANAGEMENT PRINCIPES?
We merken in de praktijk dat veel ontwikkelaars volledig gewonnen zijn voor deze methode. Toch zullen heel wat andere betrokkenen, zoals projectmanagers, QA managers, personen die contracten opstellen, enzovoort, nog altijd teruggrijpen naar het klassieke watervalmodel. Het spreekt voor zich dat dit laatste model simpeler te plannen en te beschrijven is. Projectplannen en in sommige gevallen contracten zijn ook meestal zo opgesteld dat een project wordt opgesplitst in fases, mijlpalen en bijhorende opleveringen. Die opleveringen vereisen een formele goedkeuring voordat men verdergaat met de volgende fase. De hamvraag is dan ook of we iteratieve ontwikkelingsmethodes kunnen verzoenen met die hardnekkige reflex.

Om daarop te antwoorden maken we gebruik van enkele basisdomeinen van het projectmanagement zoals beschreven in de PMBOK (Project Management Body of Knowledge). De PMBOK is de meest bekende publicatie van het Project Management Institute (PMI, cfr. www.pmi.org).

Het is geenszins de bedoeling om een theoretische één op één mapping te maken tussen PMBOK en bijvoorbeeld RUP. We geven daarentegen wel aan welke in de praktijk de specifi eke aandachtspunten blijken te zijn en op welke manier men er mee om kan gaan.

SCOPE MANAGEMENT
Met het beheren van de project scope komen we direct tot de kern van de zaak. In een watervalaanpak wil men alle behoeften (requirements) volledig in kaart brengen na de eerste fase van het project. Slechts bij hoge uitzondering kan ervan afgeweken worden (b.v. via change requests). In een iteratieve ontwikkeling wordt die ambitie opgeborgen en weten we dat na de eerste fase de scope nog maar in grote lijnen zal zijn beschreven.

In het verdere verloop van het verhaal is het vrij waarschijnlijk dat er nog wijzigingen zullen gebeuren. Dat valt te verklaren door de eerder vermelde kortere feedback loop met de gebruikers die grotendeels gebaseerd is op werkende software. Daardoor kan men erg snel bijsturen. Op het einde van de rit zal de gebruiker zeker een product hebben dat goed is afgestemd op zijn noden. Maar hoe manage je dat? Een goede methode daarvoor is het focussen op de productscope, met andere woorden, de scope van het eindproduct. Die wordt uitgedrukt in een aantal features en eventueel subfeatures.

Naarmate het iteratieve project vordert, moet de granulariteit van de features verkleinen, tot op het ogenblik dat het niet meer de moeite loont om nog verder te verfijnen. In RUP zal men bijvoorbeeld vóór het project de features in grote lijnen hebben vastgelegd (niveau ‘lastenboek’), na de Inceptiefase in vrij gedetailleerde vorm en na de Elaboratie in zeer gedetailleerde vorm.

Nogal watervalachtig, zal u zeggen? Inderdaad, maar het verschil is dat de features aan de hand van iteraties tot stand zijn gekomen en dat het ook vrij waarschijnlijk is dat ze in de volgende fases en iteraties nog gaan wijzigen (niet meer verfijnen, maar eerder weglaten en toevoegen van features). Daar kan meteen een kost aan gekoppeld worden, uitgedrukt in mandagen of euro’s. Dit is dus ook de sleutel naar het eventueel contractueel beheer van het project.

Een goed scope management zal ook voorzien in de nodige traceability van de features, enerzijds naar de behoeften en beperkingen van het project, anderzijds naar de analysedocumenten, programmatiecode en testcases.

Het beheer van de features en de traceability ervan kan gebeuren met professionele tools zoals Requisite Pro, maar met een uitgebreide spreadsheet komt men ook al een heel eind.

HUMAN RESOURCE MANAGEMENT
Hiervoor zoomen we specifiek in op het aspect project staffing. Verschillende rollen zoals analisten, testers en managers worden typisch in iteratieve ontwikkelingsmethodes voor quasi de volledige levenscyclus van het project ingezet. Dat verhoogt het verantwoordelijkheidsgevoel en de betrokkenheid van alle projectleden.

Het is onmogelijk om hiervoor een standaardregel te geven. Elk project is anders: een grote e-business site bouwen is anders dan een integratieproject en is anders dan een maintenance opdracht op een bestaande applicatie. Er bestaat daarover heel veel literatuur zodat men zeker niet het wiel opnieuw moet uitvinden. Staffing is dus een complexere aangelegenheid dan in de watervalmethode. Het organiseren van beschikbaarheden over langere perioden, eventueel in een internationale context, is niet altijd vanzelfsprekend.

TIME MANAGEMENT
In iteratieve ontwikkelingsmethodes wordt er altijd op twee niveaus gepland: op lange termijn enkel met de belangrijkste mijlpalen en op korte termijn in detail. De praktijk wijst uit dat het volledig in detail op voorhand inplannen van een IT-project een frustrerende bezigheid is, omdat men meestal al kort na de start achter de feiten aanholt.

Dat gezegd zijnde, moet men er toch over waken dat men van bij projectaanvang enkele major milestones definieert om te vermijden dat men in het oneindige gaat itereren. Dat is trouwens een valkuil waar regelmatig wordt ingetrapt: men start en men gaat verder met veilige, nietszeggende iteraties. Schouderklopjes alom, maar de moeilijkheden worden vooruit geschoven.

Duidelij
k in tegenspraak dus met de stelling dat de inhoud van iteraties gestuurd moet worden uit de risico’s, integratieproblemen en business waarde!

Rational Unified Process (RUP) past het principe van de major milestones goed toe. Men heeft vier fases (Inceptie, Elaboratie, Constructie en Transitie) die uiteindelijk aanleiding geven tot één ‘software generatie’. Binnen elke fase kunnen er meerdere iteraties gepland worden.

COMMUNICATION MANAGEMENT
De PMBOK verstaat onder communication management vooral informatieverspreiding (binnen en buiten het projectteam) en projectrapportering naar de belanghebbenden (stakeholders).

Vooral bij dat laatste wringt het schoentje: we moeten er voor zorgen dat al deze stakeholders ‘mee’ zijn met de manier van werken, met de inhoud van de iteraties, het ‘waarom’ van de iteraties, waarom men al testers nodig heeft in het begin van het project, enzovoort. Als men daarover bezorgd is, loont het de moeite om te investeren in een uitgebreide ‘awareness sessie’ voor deze personen!

RISK MANAGEMENT
Veel projecten, onafhankelijk van de manier waarop ze worden uitgevoerd, gaan stiefmoederlijk om met risicobeheer. Dat is in alle gevallen onvergeeflijk, maar zeker in een iteratief ontwikkelingstraject is dat onaanvaardbaar, want de inhoud en opeenvolging van de iteraties worden gestuurd vanuit de risico’s.

Een projectrisico beschrijven is het expliciet maken van een mogelijke gebeurtenis die verstorend kan werken op het verloop van het project. Alle risico’s krijgen een score voor waarschijnlijkheid en impact, zodat ze gerangschikt kunnen worden naar belangrijkheid.

Projectrisico’s kunnen bijgehouden worden in een eenvoudige spreadsheet en moeten op regelmatige basis geëvalueerd worden door alle betrokkenen bij het project.

INTEGRATION MANAGEMENT
Tot slot zoomen we even in op integration management en meer bepaald op het release- en versiebeheer. Voor elke iteratie moet er beslist worden of het gaat om een release in productie of in test. Dat moet heel omzichtig afgewogen worden. Is het überhaupt mogelijk om naar productie te gaan met slechts gedeeltelijke functionaliteit aanwezig? Zijn de bijkomende kosten naar migratie, maintenance, fallback enzovoort wel voorzien?

Meestal wordt er gekozen om enkel in de testomgeving op te leveren. Het gevaar is dan dat die oplevering niet au serieux wordt genomen. Hier is een belangrijke rol voor de projectmanager weggelegd: het waken over de echte waarde van de oplevering aan de hand van bijvoorbeeld gedocumenteerde en op voorhand overeengekomen testresultaten. Men mag zeker niet trappen in de val van meerdere nietszeggende nepreleases waarbij men alle moeilijkheden voor zich uit blijft schuiven.

Ook het versiebeheer wordt complexer zodra men tussentijdse werkende opleveringen heeft. Hoe houd je meerdere versies, in meerdere omgevingen, coherent, rekening houdend met wijzigingen van andere iteraties en van andere projecten? Ook hier vereist de iteratieve aanpak een hele investering en ondersteuning.

Het toepassen van iteratieve ontwikkelingsmethoden vermindert de kans op gehele of gedeeltelijke projectmislukkingen. We hebben aangetoond dat alle elementen uit de klassieke projectmanagement disciplines kunnen worden toegepast op deze methoden, zij het met enkele specifieke aandachtspunten. Elke organisatie die op een ernstige manier met projecten bezig is, zou deze aanpak op zijn minst moeten overwegen.

Patrick Okerman is managing consultant bij Inno.com?