Weg met overbodige voorraden

Lean is een ontwikkeling die stamt uit de industriële wereld, maar die ook heel goed op software development kan worden toegepast. Lean richt zich vooral op snelheid, klantfocus en het elimineren van allerlei vormen van verspilling. Eén van de zeven vormen van verspilling die Lean onderscheidt is voorraadvorming. Het hebben van onnodig grote voorraden leidt tot hogere kosten en overbodig werk. Ook bij het ontwikkelen en testen van software is er sprake van onnodige voorraadvorming.

Neem het ontwerpproces. Een nog veel voorkomende werkwijze is dat gedurende een bepaalde tijd het ontwerpteam diverse documenten produceert. Na grondige review (waarbij uiteraard ontwikkelaars en testers betrokken zijn) wordt een stapel (is voorraad) vrijgegeven voor bouwers en testers die er vervolgens mee aan de slag gaan. De ontwerpers gaan verder met de volgende stapel of een volgend project.

Er zijn programmeurs die honderden regels sourcecode schrijven zonder die tussendoor ook maar één keer uit te voeren. Fouten vinden en herstellen in zo'n grote voorraad sourcecode is erg lastig. Een voorraadje van maximaal enkele tientallen regels blijkt veel handelbaarder.

We spreken in de testwereld vaak van de testspecificatiefase. Vaak is dit een periode van dagen/weken waarin testers testgevallen bedenken en deze opschrijven in een bepaald standaardformaat, zodat ze tegen de tijd dat de testgevallen worden uitgevoerd ook nog te begrijpen zijn.

Ik zie volwassen testafdelingen die een groot deel van hun tijd besteden aan het maken en up to date houden van omvangrijke, gedetailleerde testsets. Heel gestructureerd, maar is zo'n voorraad van testgevallen altijd wel wenselijk?

In de testuitvoeringsfase worden uiteraard fouten gevonden. Deze worden opgeslagen in een bevindingendatabase en afgedrukt op lijsten. Daarna worden er overleggen gehouden, waar de lijst met bevindingen wordt doorgenomen, toegewezen en bewaakt. Als een bevinding na een tijdje is opgelost, moet er gehertest worden. Als het goed is weet de hertester nog wat er precies aan de hand was… Vaak zijn programmeurs in die fase al weer bezig met het toevoegen van nieuwe functionaliteit, terwijl er nog een flinke voorraad openstaande bevindingen is.

Risico’s voorkomen

Te grote voorraden, of het nu ontwerpen, sourcecode, testgevallen of bevindingen zijn, brengen risico's met zich mee. Zo ontstaat onnodig tijdverlies doordat men steeds opnieuw moet uitzoeken ‘hoe het ook al weer zat', maar ook structurele fouten of gewijzigd inzicht kunnen leiden tot veel verlies; de hele voorraad moet worden aangepast (fout geproduceerd) of is zelfs overbodig geworden (zinloos geproduceerd)

Deze risico's kunnen we gemakkelijk inperken (en daarmee veel kosten beparen) door op andere wijze met elkaar samen te werken. Ontwerpers, houd een ontwerp niet te lang bij je. Deel het vroegtijdig met ontwikkelaars en testers, ook als je het idee hebt dat het nog niet helemaal 'af' is. Ontwikkelaars, werk in kleine stapjes. Run je code vaker dan je lief is. Continuous integration/continuous testing is hiervoor een heel goed principe. Geef prioriteit aan het oplossen van fouten in plaats van het inbouwen van nieuwe functionaliteit. Testers, ga niet in een aparte zaal zitten maar zoek ontwerpers en ontwikkelaars op. Focus je minder op administratie van testgevallen en bevindingen, maar voorzie alle project stakeholders snel en continu van nuttige informatie over de kwaliteit van het product dat gemaakt wordt. Kies bewust vaker voor minder formele testtechnieken; niet alle testgevallen hoeven voor het nageslacht bewaard te blijven.

Is dit niet gewoon Agile? De wijze van werken bij Agile-ontwikkelmethoden leidt inderdaad in veel gevallen tot minder grote voorraden. Toch is dit artikel niet direct een pleidooi om vanaf nu alles Agile te doen. Ook als je werkt volgens een traditionele ontwikkelmethode kun je door ‘Lean' om te gaan met voorraden al flinke besparingen bereiken.