Wat een badkamer hiermee te maken heeft?
Vorige zomer is onze badkamer flink onderhanden genomen. Muurtjes verplaatsen, vloerverwarming erin, nieuwe vloer en natuurlijk tegelen. Wij kozen voor de optie “Wij vakantie, u hard werken”. Terwijl wij met de camper in Frankrijk waren, kregen we een telefoontje van onze hardwerkende aannemer:
- “Ik zit nog eens goed naar die tegeltjes te kijken die je in de douche wil” (o jee, wat is er niet goed)
- “En ik wil graag even overleggen” (Nou, brand maar los. Ik ben benieuwd hoe veel meerwerk dit gaat kosten)
- “Omdat ze niet plat zijn gebakken en nogal klein zijn gaat het niet mogelijk zijn om deze kaarsrecht op de muur te zetten. Je zal af en toe wat zien verspringen en hierdoor zal de voeg ook niet perfect kaarsrecht zijn.” (phew dat valt mee!!)
Voor ons was dit geen issue. De aannemer zei dat klanten soms pas achteraf problemen zien, als alles al klaar is. Best logisch dus dat hij even een belletje gaf op basis van wat hij al eerder had meegemaakt.
In de IT-wereld is het niet ongewoon dat een klant plots met een probleem komt waarbij we bijna onze ogen rollen en denken: "Kon je daar niet eerder aan denken?". Maar dan herinner ik me dat mijn klant niet elke dag met softwareontwikkeling bezig is. Soms moet ik echt even de stap zetten om dingen uit te leggen of opties voor te leggen.
Net zoals bij mijn aannemer. Hij kon er makkelijk vanuit gaan dat ik, de klant die de tegels uitkoos, wel zou begrijpen hoe ze aan de muur zouden komen. Maar hij besloot toch nog een check te doen. Die kleine moeite van 10 minuten zorgde voor een tevreden klant en voorkwam mogelijk gedoe. Want stel je voor dat ik die tegels niet eens een beetje scheef wilde hebben? Ze waren nog niet geplaatst, dus er was nog tijd om eventueel andere tegels te kiezen. Misschien niet de makkelijkste route, maar zeker goedkoper dan later alles eraf te bikken en nieuwe tegels te plaatsen.
Shift-left benadering & badkamerrenovatie
Dit is een voorbeeld van de “shift-left” benadering bij badkamerrenovatie.. Hoe eerder je potentiële problemen signaleert, hoe makkelijker en goedkoper het is om ze op te lossen. Stel je voor dat de aannemer ons niet had gebeld en we pas na de vakantie het werk zouden beoordelen. Dan hadden we ruwweg drie scenario’s:
- Geen probleem, ik vind de tegels prachtig en die paar scheve tegeltjes had ik zelf ook al verwacht.
- Ik zie bij thuiskomst scheve tegels en de aannemer legt uit waarom dit zo is. Ik bedenk me dat hij eigenlijk wel gelijk heeft, dat het m’n eigen schuld is en ik accepteer hoe het er nu uit ziet.
- Ik vind de scheve tegels onacceptabel en wil nieuwe. Er komt discussie over wie z’n schuld dat is. Kan de aannemer niet tegelen? Hoort dit bij de tegels die ik heb gekozen? Is dit nu een bug of een feature? Aannemer heeft 3 dagen extra werk om de tegels eraf te halen en andere te plakken. De rechtzaak over wie betaalt loopt nog…
Optie 3 is waar we allemaal bang voor zijn. Bug fixen is duur en ook al kosten in software ontwikkeling de meeste bugs niet drie dagen, je zal versteld staan hoeveel tijd ze opslokken. Plus, hoe vaak deadlines verschoven moeten worden omdat problemen pas laat in het proces aan het licht komen.
Shift-Left benadering in de praktijk
Hoe werkt dit in de praktijk? Er zijn diverse voorbeelden van shift-left in de praktijk. Als software tester ben ik nogal slecht van vertrouwen. Dat wil zeggen dat als ik requirements zie, ik er niet van uit ga dat die requirements 100% kloppen. Zelfs als een klant of business analist er uitgebreid over heeft nagedacht. Het dubbelchecken van requirements kan problemen later in het proces voorkomen.
Wat ook vaak voorkomt is dat we intuïtief wachten met testen tot de gehele flow klaar is. We denken dan dat we goed omgaan met de beschikbare tijd, omdat we aan het eind zoveel mogelijk checks in een zo kort mogelijke tijd kunnen uitvoeren. Het nadeel hiervan is dat we in een laat stadium problemen tegenkomen en daardoor deadlines in gevaar komen. Daarom is het soms nodig om tegen onze intuïtie in te gaan.
Vasthouden aan principes zoals 'Test vroeg en test vaak' kan ons hierbij helpen.
Agile testing & shift-left
Vroeger, toen we nog in watervalprojecten werkten, hadden ze ook al de shift-left benadering ontdekt, maar ze noemden het nog niet zo. Voor iedere fase was ook een check moment ingebouwd.
.jpg)
