Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

De politieke wurggreep voor het testteam

Wanneer er bij softwareontwikkeling gebruik wordt gemaakt van de traditionele watervalmethode dan kan dit een probleem vormen voor het testteam doordat zij in een politieke wurggreep terecht komen. Ik wil hier graag dieper ingaan op de nadelen waar het testteam tegen aanloopt bij traditionele watervalprojecten, maar ga ik ook in op oplossingen en hoe hiermee om te gaan.

De watervalmethode is een methode voor softwareontwikkeling, waarin de ontwikkeling regelmatig en vloeiend (als een waterval) naar beneden loopt. De watervalmethode bestaat uit een aantal fasen die elkaar logisch opvolgen, namelijk: definitiestudie/analyse, basisontwerp, technisch ontwerp/detailontwerp, bouw/implementatie, testen en  integratie. Dit is een traditionele manier van software-ontwikkeling die al jaren wordt toegepast. Het grote voordeel van deze manier van ontwikkelen is dat het duidelijk, bekend en snel te begrijpen is. Wensen en eisen zijn vooraf gedefinieerd en de realisatie daarvan kan in de tijd worden uitgezet en dus goed gepland worden. De methode behelst dat een volgende fase pas gestart kan worden als de vorige is afgerond.

In de praktijk wordt er echter vaak een dakpansgewijze constructie gevolgd, waarbij  de volgende fase  al wordt opgestart voordat de vorige volledig is afgerond. Dit omwille van besparing op doorlooptijd en budget (leegloop, onnodig wachten op elkaar), waardoor deze aanpak in de praktijk vaak leidt tot veel rework en forse overschrijding van tijd en/of kosten per fase.

Politieke wurggreep

Als testteam loop je in deze traditionele projecten het risico in een politieke wurggreep terecht te komen. Als team zit je aan het einde van de rit. Eén van de grote nadelen hiervan, zeker als de einddatum (implementatiedatum) en de kosten van het project gefixeerd zijn, is dat eerder opgelopen vertragingen in het project gecompenseerd moeten worden in de fase van testen. In de praktijk betekent dit dat vertraging binnen een watervalproject ook altijd als een waterval bij de laatste in de lijn, het testteam, als probleem terecht komt. Wanneer de fase van testen ingekort moet worden vanwege vertragingen in de voorgaande fases, dan betekent dit dat er minder tijd besteed kan worden aan het testen van het softwaresysteem. Hierdoor is er te weinig tijd om alle risico’s in kaart te brengen, het systeem grondig te testen en alle fouten en eventuele problemen op te sporen. Dit gaat ten koste van de kwaliteit van het systeem en kan zeer nadelige gevolgen hebben.

De mogelijkheden binnen een watervalproject om in de testfase met dit probleem om te gaan zijn:

- De einddatum van het project uitstellen:
Voordelen: het volledige systeem kan grondig getest worden, het risico op fouten in productie neemt af.
Nadelen: het project duurt langer, de kosten worden hoger, het uitnutten van de baten start later.

- Het aantal testanalisten verhogen om in de kortere tijd dezelfde hoeveelheid testwerk te verzetten:
Voordelen: het volledige systeem kan grondig getest worden, de einddatum van het project wordt gehaald.
Nadelen: de kosten worden hoger, nieuwe testanalisten zijn beperkt inzetbaar vanwege een inwerkperiode.

- De scope van het project verkleinen:
Voordelen: een deel van het systeem kan grondig getest worden, budget en tijd worden niet overschreden.
Nadelen: niet het volledige systeem komt in productie.

- Minder grondig testen:
Voordelen: het volledige systeem wordt getest, budget en tijd worden niet overschreden.
Nadelen: groter risico op fouten in het systeem in de productiefase, risico op hogere herstelkosten, risico op imagoschade.

Welke keuze er in deze fase ook door het testteam gemaakt wordt, de klant- en projectbelangen staan lijnrecht tegenover elkaar, waarmee het team zich per definitie in een politieke wurggreep bevindt. Als het testteam in het belang van de klant de risico's zo goed mogelijk in kaart brengt, betekent dit dat het extra geld en/of tijd nodig heeft (optie 1 en 2). Brengt het testteam de risico's in het belang van het project zo goed mogelijk in kaart, dan kiest het voor minder of minder grondig testen om op tijd en binnen budget klaar te zijn (optie 3 en 4).

En nu?

Als tester wil je een gedegen advies geven aan de klant omtrent de risico’s die deze loopt als de opgeleverde software in productie gaat én wil je een bijdrage leveren aan een succesvol project. Betekent dit dan dat de waterval methode per definitie leidt tot een politieke wurggreep voor de tester en dat er altijd een keuze gemaakt moet worden tussen het projectbelang of het klantbelang?

Het antwoord is nee. Als een waterval project niet te complex is en niet te lang duurt (dus kleinere projecten) en als er een goede projectleiding is, worden rework en overschrijding van budgetten beperkt en kan het testteam prima binnen de grenzen van het project het belang van de klant én het project dienen. Krijgen we echter te maken met grotere en complexere projecten, dan is de wurggreep nagenoeg een feit.

De laatste jaren zien we in dit soort projecten de Agile benadering steeds meer aan terrein winnen. Binnen deze benadering is het testen niet geïsoleerd aan het einde van het project, maar juist vol betrokken op elk tijdstip van het project. Geeft deze benadering dan een oplossing voor de politieke wurggreep van het testteam in de traditionele benadering?

In een Agile aanpak van projecten leveren klant, ontwerper, ontwikkelaar en testanalist in een multi-disciplinair team in korte sprints functionaliteiten van een systeem op. Elke sprint is als het ware een miniatuurproject op zichzelf en omvat alle noodzakelijke taken: planning, analyse, ontwerp, testen en documentatie. Anders dan bij een watervalproject zit je als testteam dus niet meer aan het eind van de lijn, maar ben je vanaf het begin van het project actief onderdeel van de verantwoordelijkheid om tot een goed werkend systeem te komen. De functionaliteiten met de meeste waarde worden binnen een Agile benadering als eerste opgeleverd en na iedere sprint worden de project-prioriteiten heroverwogen. Hierdoor is er na elke sprint een moment voor alle partijen om zowel op project- als klantbelang te sturen. Op deze manier komt het probleem van vertraging niet meer automatisch als een waterval bij het eind van het project, dus het testteam, terecht en is er van een politieke wurggreep voor het testteam geen sprake meer.

Toch zijn er ook kanttekeningen bij een Agile benadering van projecten. Voorwaarde voor het slagen van deze benadering is dat het als een soort ‘way of life’ door de hele organisatie gedragen moet worden, wat in te passen moet zijn binnen de bestaande cultuur van een organisatie.  Verder moet het gehele team vanaf het begin van het project altijd aanwezig zijn,  waarbij afwezigheid tot stagnatie en vertraging leidt en is het eindproduct niet vooraf exact te bepalen wat de langere  termijn planning lastig maakt. Ten slotte vereist het werken in een Agile omgeving specifieke eigenschappen en de nodige ervaring van de testconsultant: hij moet op de hoogte zijn van de politiek binnen en de cultuur van de organisatie, en hij moet over ruime business- en testkennis en de juiste softskills (zoals communicatieve vaardigheden en empathisch vermogen) beschikken.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4711308). © Jaarbeurs IT Media.
?

 

Reacties

In agile projecten ligt het risico meer bij de klant/gebruiker. De doorlooptijd en het budget liggen vast, maar de hoeveelheid functionaliteit is variabel. Als de klant bijvoorbeeld 1000 functiepunten wil in 6 maanden, en er zijn er maar 700 af, dan komt dat overeen met het de voor- en nadelen onder het kopje 'De scope van het project verkleinen'. Enige voordeel bij agile projecten is wel dat de meest belangrijke/gewenste functionaliteit gereed is.

Om dit soort problemen te voorkomen is het belangrijk om ieder project met realistische verwachtingen te starten. Veel organisaties baseren zich nog steeds alleen op expertbegrotingen, waarvan bekend is dat ze vaak veel (tot 30%) te optimistisch zijn. Een simpele reality check op een expertbegroting is daarom altijd een goed idee.

Meet de functionele omvang in functiepunten en bepaal de impliciet begrote productiviteit in uren per functiepunt. Selecteer een aantal relevante projecten uit de ISBSG database, analyseer de spreiding in deze productiviteitscijfers en kijk in welk percentiel de expertbegroting valt. Ik heb vaak genoeg gezien dat expertbegrotingen tussen de 0% en 20% percentiel vallen, wat natuurlijk zeer onrealistisch is voor de meeste organisaties. De mediaan productiviteit is vaak al aan de optimistische kant voor veel Nederlandse bedrijven.

Een nog betere optie is om een 'Software Cost Engineering' begroting te maken, bijvoorbeeld met tools als QSM SLIM Estimate of Galorath SEER-SEM, maar er zijn maar weinig organisaties die het volwassenheidsniveau hebben om dit soort tools toe te passen. Voordeel van dit soort begrotingen is wel dat ook het aantal te verwachten defects wordt begroot, wat in het testproject kan worden gebruikt om in te schatten hoeveel defects er nog gevonden kunnen of moeten worden.

Citaat: "Anders dan bij een watervalproject zit je als testteam dus niet meer aan het eind van de lijn, maar ben je vanaf het begin van het project actief onderdeel van de verantwoordelijkheid om tot een goed werkend systeem te komen."

Ik ben het niet eens met deze stelling. Als testengineer kun je bij een watervalproject ook vanaf het begin actief onderdeel zijn. Mijn advies luidt: stel je pro-actief op als testengineer en draag zorg voor hoge kwaliteit van ieder op te leveren product.

De schrijver stelt (na het omschrijven van de vier mogelijkheden om met dreigende uitloop om te gaan): "... de klant- en projectbelangen staan lijnrecht tegenover elkaar, ...".
Ik ben het hier niet mee eens.

PRINCE2 onderscheidt in plaats van één klant twee rollen: die van opdrachtgever en die van gebruiker. Dit onderscheid is terecht omdat (1) budgetbeslissingen iets anders zijn dan alles wat te maken heeft met specifieke wensen, acceptatie en invoering, en (2) deze op een ander niveau spelen.

Verder zijn er geen projectbelangen. Er is een projectmanager. Hij moet drie heren dienen: de opdrachtgever (geld), de gebruiker (oplevermoment, scope en kwaliteit) en zijn eigen organisatie (PRINCE2: de supplier, voor mankracht en middelen). Maar dat is gewoonlijk niet constant touwtrekken maar een kwestie van plannen en afspraken maken.

De projectmanager zal altijd proberen, "zijn" project te laten slagen: op tijd, binnen budget, goed en compleet. Soms gaat dat niet lukken. Er zijn allerlei manieren om projectvoortgang te volgen; uitloop hoeft dus niet als een donderslag bij heldere hemel te ontstaan. De taak van de projectmanager is dan, zijn opdrachtgever tijdig op de hoogte te stellen en eventueel met een suggestie voor een oplossing te komen (PRINCE2: een exception plan).

In een situatie van verwachte uitloop van een project komen opdrachtgever en gebruiker met elkaar in conflict - zij zijn de partijen met tegengestelde belangen.

Natuurlijk ken ik de situatie dat de ontwikkelaars uitlopen terwijl de deadline blijft staan. Maar die uitloop groeit met één dag tegelijk. Tijd genoeg om dit te rapporteren en te kiezen hoe het testteam ermee om moet gaan. "Heren, zo liggen de kaarten, dit zijn de alternatieven, mijn voorkeur gaat uit naar (zie exception plan). Zegt u het maar."

Zo ontworstelt het testteam zich aan een politieke wurggreep en ligt de verantwoordelijkheid voor de beslissing weer waar hij hoort te liggen.

Een tikje academische discussie, die inmiddels toch wel geslecht zou moeten zijn, maar goed.

Niet elk project leent zich voor een Agile aanpak.
Maar een watervalproject waar niet reeds bij de start-up een requirementsmanager, een testmanager en een acceptatie-/implementatiemanager betrokken zijn is bij voorbaat een risico-project geworden. Voorbeelden te over.

Computable Expert
Ralph  Bauling

drs. Ralph Bauling MBA
testmanager, bartosz. Expert van Computable voor de topics Management, Development en Loopbaan.
Hele profiel

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×