thijs van bruxvoort

geldvriend, koffienerd en faalhaas

21 Jun 2019

Planning in de waterval

Hoe lang denk je nodig te hebben? Wanneer is het klaar? Ligt er al een planning die we kunnen gebruiken?

Hoeveel tijd kost dit?

Hier word ik soms wel eens moe van. Zeg maar altijd. Misschien omdat ik niet kán plannen, hoor. Vooral omdat ik het niet wíl. Ik heb het nog nooit meegemaakt dat een planning, naar volle specificaties en tevredenheid en binnen aangegeven tijdspad en effort, gehaald is. Nooit. Dus plannen is stom. Schatten is handig.

Hoe je dingen voor elkaar krijgt is door helder te hebben wat je doel is en accepteren dat je daarvan nooit 100% zeker bent. Pas als je bij de eindstreep bent, weet je hoe je erover nadenkt. Dus dan zorg je ervoor dat je gedurende het ‘proces’ in staat bent in te spelen op verandering. Niet krampachtig vasthouden aan wat je vooraf bedacht hebt.

Niet dat je niet moet plannen hoor. Maar je moet niet alles willen plannen. Plan vooral je eerste actie, iets behapbaars. Maak het een concrete actie en denk alvast na over de richting van vervolgactie(s), of parallele acties. Voor elk plan moet je in mijn optiek twee dingen weten:

  1. Wat wil je bereiken?
  2. Wat is de eerstvolgende concrete actie die hiervoor nodig is?

Exact dit is waarom ik zo fervent aanhanger van Getting Things Done ben. Je hoeft niet meer te doen dan dit. Alleen zorgen dat je up to date bent en regelmatig je projecten en acties evalueert, zodat je elke weer aandacht richt op wat je wel weet wat je moet doen. Dit probeer ik ook op mijn werk toe te passen, vaak nog tevergeefs. Want ik moet schattingen maken van hoeveel werk iets is, wanneer we het volgens kunnen opleveren, wanneer het geïmplementeerd kan worden en wanneer gebruikers er dan ook eens echt mee aan de slag kunnen.

Alleen zorgen dat je up to date bent en regelmatig je projecten en acties evalueert, zodat je elke weer aandacht richt op wat je wel weet wat je moet doen.

Dit is denk ik het moeilijkste en meest frustrerende van digitale producten maken en verbeteren. Gelijk ook een van de meest intrigerende aspecten en waarom ik met plezier dagelijks de geelblauwe faalbuis in ga en mijn fiets-met-blauwe-voorband op stap. Overigens heerlijk om actief de dag te starten, maar dat is een ander verhaal.

Watervallen is niet écht watervallen

In gesprek met een collega product owner noemde ik het alsof ze een watervalmethode wilden afdwingen, maar ‘het management’ wel wilden uitdragen naar de buitenwereld dat ‘wij Agile werken’. Dat vond ik onzin. Hij attendeerde mij op het feit dat we de watervalmethode eigenlijk niet is wat het is.

alsof ze een watervalmethode wilden afdwingen, maar ‘het management’ wel wilden uitdragen naar de buitenwereld dat ‘wij Agile werken’.

De watervalmethode is een sequentie van stappen die je doorloopt in de ontwikkeling van een (software) project of product, gewoon vierkantjes met een pijltje naar de opeenvolgende vierkantjes die er schuin onder staan. Dat de auteur van het artikel de watervalmethode beschreef, ook met het pijltje terug. Dat deze ‘methode’ onder zijn naam overgenomen is in het boek ‘Software Engineering Economics’ wat toen de heilige graal binnen software ontwikkeling werd. Een andere legende is dat iemand binnen het Amerikaanse ministerie van defensie het artikel las, het plaatje zag, dat overnam zonder te kijken naar de 5 verbeterpunten en Royce’s kritiek en dat heeft doorgevoerd als proces in de organisatie.

gewoon vierkantjes met een pijltje naar de opeenvolgende vierkantjes die er schuin onder staan.

Overgenomen uit het artikel van Royce (1970).

https://images.squarespace-cdn.com/content/v1/5d0e95d29294360001219669/1561581659268-OT0D810HX3HUUXXX55FO/ke17ZwdGBToddI8pDm48kOpVLoWmHnubY3_j0vO2vV97gQa3H78H3Y0txjaiv_0fDoOvxcdMmMKkDsyUqMSsMWxHk725yiiHCCLfrh8O1z5QPOohDIaIeljMHgDF5CVlOqpeNLcJ80NK65_fV7S1UUarTmxp1Nee-6e7b7QJcv3Oh8DqOsZn_cR2vIUXqxikG6v6ULRah83RgHXAWD5lbQ/royce-waterval-iteratief.png?format=1000w

Dat moet pijn doen, bekend worden voor iets wat je niet zo bedoeld hebt. Mensen lezen gewoon helemaal niet goed. Ik ging het artikel van dr. Winston Royce, gepubliceerd in 1970 doornemen. Heb ik gewoon al die tijd als een schaap alles overgenomen wat mij is verteld.

Van de watervalmethode is eigenlijk helemaal geen sprake. Royce zegt zelfs precies dat als je geen iteraties voor de stappen hebt, je requirements worden overschreden en je design aangepast moet worden, dat je 100% uit kan lopen op je planning. Nou, dat lijkt me zelfs nog wel een understatement. Maar het staat er echt:

Een quote uit het artikel van Royce (1970).

https://images.squarespace-cdn.com/content/v1/5d0e95d29294360001219669/1561581756241-AQH5N3K3ARNY72XQYXMW/ke17ZwdGBToddI8pDm48kABCLp3xrtPa0b3biKypV3AUqsxRUqqbr1mOJYKfIPR7LoDQ9mXPOjoJoqy81S2I8N_N4V1vUb5AoIIIbLZhVYy7Mythp_T-mtop-vrsUOmeInPi9iDjx9w8K4ZfjXt2dtgh-qyuT9Zn0qv7uHteuDskfwXxHQ7BxNqsZ2BeYoUOCjLISwBs8eEdxAxTptZAUg/royce-planning-overschrijden.png?format=1000w

HOE HET BETER KAN.

In het artikel geeft hij zelfs kritiek op deze methode en geeft hij inzicht in het voorkomen van fouten. Hij doet 5 aanbevelingen:

  1. Programma ontwerp
  2. Documenteren
  3. Doe het 2 keer
  4. Plan, controleer en evalueer testen
  5. Betrek de klant

Van deze 5 stappen zijn met name de laatste 3 keer verrassend Agile. Met betrekking tot de eerste twee heb ik ook mijn bedenkingen en ik heb het idee dat deze aanbevelingen uit hun verband zijn getrokken en gecombineerd met de beschrijving van het watervalmodel Royce zijn reputatie heeft bezorgd.

Eerst goed bedenken wat er nodig is en dit uitgebreid documenteren is de strekking van de eerste twee punten. Royce is overtuigd dat er ‘vrij veel’ documentatie nodig is, meer dan analisten en ontwikkelaars denken. Volgens hem is de documentatie de specificatie en ontwerp.Hij heeft wel een goed punt wat betreft het punt dat zonder goede documentatie de software eigenlijk alleen onderhanden kan worden door de maker ervan. Dat heb ik al ontelbare keren in levende lijve ondervonden. Maar uitgebreide documentatie is niet per definitie ook goede documentatie.

De andere punten sluiten goed aan bij Agile filosofie. Zoals het ‘doing it twice’ principe, dat wat je bij de klant neerzet niet de eerste versie van je product is. Dus een pilot model bouwen en deze testen. Snel bouwen en feedback ophalen met een klein stukje werkende software, zodat je snel kan bijsturen en fouten voorkomt, dus. Alleen dan iets anders verwoord.

Royce is ook tegenstander van op het laatst pas testen, maar doet geen aanbeveling om écht vroeg te testen. Daar tegenover zet hij dat het belangrijk is een goed testplan te beschrijven, te laten controleren door een specialist (test engineer) en niet de ontwikkelaar van het stuk. Dit zou je kunnen interpreteren als het ‘pair programming’ principe, waarbij je aan software werkt in paren ontwikkelaars. Hiermee krijg je een kennis verdeeld over het team en doe je direct een soort code review. Tevens een goede manier om nieuwe ontwikkelaars in het team snel mee te laten draaien.

Het niet betrekken van je klanten is vragen om problemen. Dat is wet nummer 1 in de Agile filosofie, maar Royce zei dit dus al in 1970. Dit is ook echt wel logisch, stel je voor dat je een huis gaat bouwen, je schrijft op wat je wilt en je laat de aannemer volledig zijn gang gaan en na 6 maanden zie je wel wat het geworden is

Geheid gezeik.

Maar op de volgende 3 momenten zou het zinvol kunnen zijn:

  1. Na je preliminary program design » je voorlopige functionele ontwerp
  2. Functionele en technische ontwerp
  3. Na testfase

Dit is best opvallend, want waarom zou je niet tijdens het testen, of sterker nog, de klant mee laten testen? En waarom niet na het opstellen van je requirements document? Dan kun je verifiëren dat wat je hebt geschreven te gaan maken, ook zo wordt geïnterpreteerd door de klant. Dit vind ik ontzettend belangrijk, want hoe vaak gaat het wel niet fout in de semantiek. Ik denk maar even aan de ‘ruzies’ die ik gehad heb met mijn vriendin over de afwas (toen we nog geen vaatwasser hadden, wow, dat lijkt eeuwen geleden): ik vind het pas nodig om af te wassen zodra ik (met moeite) een schone lepel of beker kon vinden die ik op dat moment nodig had. In tegenstelling tot mijn vriendin, die bij een klein stapeltje vaat al de kriebels kreeg. Zolang er geen overeenstemming is over wanneer ‘de afwas moet worden gedaan’ of ‘het huis vies is’, dan ontstaan irritaties. Semantische verschillen, wat betekent dit voor de leverancier en voor de klant, maken écht heel veel uit. Mij lijkt het daarom vanzelfsprekend om even te checken, voordat je begint met verder uitwerken en ontwikkelen, bij de klant of je het over dezelfde requirements hebt.

Voor testing geldt hetzelfde, het principe van weten is geen doen. Ik kan heel goed weten hoe ik een tennisracket moet zwaaien, de biomechanica bestudeerd hebben, maar zonder dat ik het daadwerkelijk heb gedaan, kan je niet zeggen of je er goed in bent of niet. Hoe gaat een klant accepteren dat software goed werkt, zonder zelf even aan de knoppen gezeten te hebben, of in elk geval, een live demo heeft meegemaakt met het product team?

Dit zijn wat mij betreft wel zaken die ik in elk geval anders zou doen dan Royce, maar zijn strekking, over het algeheel, is niet zoals mijn voorstelling van de Watervalmethode was. Sterker nog, ik vind het bijzonder vooruitstreven dat een bijna 50 jaar oud artikel nog zo overeind staat in een wereld waar de technologie al 500x de wereld rond is gegaan. Petje af.

Daarom stel ik ook voor dat we de watervalmethode eren, het heeft productontwikkeling juist heel veel gebracht. We hernoemen het naar de Waterrad methode, want er zit toch wel degelijk iets cyclisch in.

Ik hoop dat ik ooit een keer géén planning hoef af te geven. Want ik weet, met 95% zekerheid, dat het eindresultaat 100% niet is wat men vooraf denkt.

Toedels T.