Hoe moet een stageverslag voor XP-projekten eruit zien?

by Karel Thönissen

XP-projekten hebben in tegenstelling tot traditionele projekten geen vastomschreven doel. De veronderstelling is, dat een dergelijk doel helemaal niet bestaat, althans niet gekend kan worden door de grote onzekerheden die software-ontwikkeling kenmerken. In plaats van een groot massief projekt dat zonder tussentijdse sturing mikt op het veronderstelde doel, kiest XP voor een wendbare ('agile') aanpak. Meer dan een doel heeft een XP-projekt een koers. Er is geen planning die aangeeft wanneer het doel bereikt zou moeten zijn. Er wordt snel begonnen aan het projekt in de juiste richting. Het is niet zeker of het doel bereikt zal worden, maar er wordt stevig doorgestapt in de juiste richting. De vele tussentijds releases, de unit tests, de briefings, het pair-programmeren zijn er allemaal op gericht om zo veel mogelijk terugkoppeling te krijgen en wel zo vroeg mogelijk. Deze vroege ervaringen worden gebruikt om zo nodig van dag tot dag de koers aan te passen. En als de koers van dag tot dag op het doel gericht blijft en als er stevig wordt doorgestapt, moet het raar lopen wil het projekt niet het doel bereiken.

Vanuit de opleiding worden gewoonlijk eisen gesteld aan de verslagen van studenten. Het is begrijpelijk dat de opleidingen deze eisen willen handhaven, omdat zij op hun beurt beoordeeld moeten worden door assessoren/visitatiekommissies. Die moeten kunnen vaststellen of het beoordelingsproces aan de regels voldoet. Helaas zijn de eisen aan een verslag gericht op traditionele ontwikkeltrajekten. Gewoonlijk wordt van studenten verwacht dat een verslag de volgende onderdelen bevat:

• situatiebeschrijving van bedrijf, zijn produkten, zijn goede en zwakke punten (ist-situatie)
• doelbeschrijving: een beschrijving van dat wat bereikt moet worden in de opdracht (soll-situatie). Hieronder vallen ook een beschrijving van het eisenpakket, specifikaties, funktionele ontwerpen, technische ontwerpen, etc.
• plan van aanpak en planning: hierin wordt bij aanvang van het projekt beschreven op welke wijze het gat tussen de huidige en de gewenste situatie gedicht zal worden
• resultaatbeschrijving en evaluatie: hierin wordt aan het einde van de opdracht beschreven wat bereikt is en wordt een evaluatie gemaakt

Dit formaat is moeilijk toe te passen in een XP-projekt. Het eerste probleem is dat er geen grand design is met dito planning. Het maken van een doelbeschrijving moet daarom beperkt blijven tot een zeer globale stukje over de wens van de klant. De details worden gaandeweg in het projekt ingevuld. Het opstellen van een plan van aanpak is daarom ze goed als onmogelijk en elke poging daartoe is een bewuste leugen (in traditionele ontwikkeltrajekten is het meestal ook wel bezijden de waarheid, maar dat blijkt pas achteraf: ten tijde van het projekt gelooft men er in ieder geval nog in). Het maken van een resultaatbeschrijving mag op zich geen probleem vormen. Na afloop van een projekt kan een student een dergelijke dokument maken om te voldoen aan de opleiding. Evaluatie na afloop past niet in XP. Niet dat XP niet evalueert, integendeel, maar niet pas aan het einde van het projekt. XP verruilt planningen en specifikaties voor vroegtijdige evaluatie en terugkoppeling. Omdat dit punt niet genoeg onderstreept kan worden nogmaals een lijstje met XP-praktijken en konstateer dat deze sterk gericht zijn op het verkrijgen van veel vroege feedback:

• unit testing
• daily/nightly builds
• daily briefings
• pair programming
• release often
• customer on the team
• refactoring (snel naar werkend systeem, daarna opschonen)

XP wint aan momentum in de software-wereld. Daarom zullen studenten in toenemende mate te maken krijgen met XP-opdrachten waarvan de praktijken niet aansluiten bij de eisen van de opleidingen aan de verslagen. Het maken van een beginschets en eindschets blijft overeind, maar het probleem zit in de doelomschrijving/opdrachtomschrijving en het plan van aanpak. Het is daarom onvermijdelijk de verslageisen aangepast of op zijn minst geherïnterpreteerd moeten worden. Ik denk dat dat mogelijk is.

Een XP-projekt heeft weliswaar geen groot doel, maar aan het begin van de dag wordt de koers uitgezet en worden de dagtaken bepaald. Met andere woorden een XP-opdracht is niet een grote opdracht van bijvoorbeeld 100 dagen, maar het zijn 100 kleine opdrachten van een dag. Nu gaat het te ver om 100 kleine verslagen te maken, maar een redelijke tussenweg is zeker mogelijk, bijvoorbeeld door 20 weekverslagen te maken. Hierin moet de nadruk niet liggen op het plan van aanpak, maar op de koers (de dagtaak/ weektaak) en vooral de koerswijzigingen. Het verslag moet een aaneenschakeling zijn van beschrijvingen van de taken, de problemen, de analyses, de koerskorrekties en de daaruit volgende taken voor de volgende periode. Met andere woorden in plaats van een verslag dat aangeeft dat de student kapabel is om een upfront ontwerp te maken, te schatten en in te plannen, moet het verslag aantonen dat de student problemen kan herkennen, valkuilen kan vermijden onderweg en flexibel genoeg is om de koers te korrigeren.

Interessant element dat aan het einde van een projekt kan worden opgenomen in het verslag is een analyse of de problemen die onderweg zijn tegengekomen redelijkerwijze voorzien hadden kunnen worden bij gebruik van de traditionele aanpak. Zeer interessant, al zal het een kwestie van beoordeling blijven.