Een schatting maken van een prototype
Hoe u een prototype moet beoordelen: het is een eindproduct dat bedoeld is om van te leren, niet om te gebruiken. Hoe u kunt voorkomen dat het wegwerpbare prototype uitgroeit tot de productiecode waar niemand rekening mee had gehouden.
Het verhaal waarvan het eindresultaat is: „we weten nu wat we moeten bouwen”, en niet: „we hebben het gebouwd”.
Een prototype is bedoeld om van te leren, niet om daadwerkelijk te gebruiken. Het gaat erom een vraag te beantwoorden — voelt deze interactie goed aan, is deze aanpak schaalbaar, zal deze API standhouden — en wel zo snel dat u van koers kunt veranderen voordat u zich er definitief aan vastlegt. Teams die prototypes op dezelfde manier inschatten als functies, komen uit op een getal dat de verkeerde vorm van werk financiert.
De andere vorm van mislukking is precies het tegenovergestelde: een prototype te klein inschatten, iets opleveren dat „net voldoende werkt”, en dat vervolgens in productie nemen omdat de planning al verder is gevorderd. Het prototype dat uiteindelijk het product wordt, is de duurste code in de codebase, omdat er geen rekening is gehouden met de onderdelen die ontbreken.
Wat er in de kamer wordt gezegd
Ingenieur: “Ik kan er binnen een paar dagen wel iets in elkaar zetten.”
Inleiding: “Wat is de vraag die wij proberen te beantwoorden?”
PM: “Is dit bedoeld voor klanten, of alleen voor intern gebruik?”
Inleiding: “Als het antwoord ja is, gooien we het dan weg en beginnen we opnieuw?”
Ingenieur: „Wij gooien het nooit weg.“
Vragen die u zich het beste kunt stellen voordat u gaat stemmen
- Op welke vraag geeft het prototype een antwoord, en hoe weten we dat we een antwoord hebben?
- Alleen intern, of in het bijzijn van klanten?
- Standaard weggooien — en staat het team daar volledig achter?
- Wat is de tijdslimiet, en wat gebeurt er aan het einde daarvan?
- Als het werkt, hoe verloopt dan het traject van prototype naar productiecode?
De uitspraak van de ingenieur „we gooien het nooit weg“ vormt het echte risico: reserveer budget voor het prototype als oplossing, en beschouw de productieversie als een apart project, zodat het weggooien niet automatisch de overhand krijgt.
Stel een prototype op basis van het antwoord op, niet op basis van het eindproduct — en plan de herontwikkeling voordat de planning dit voor u regelt.
Net als bij het inschatten van een piek in het onderzoek is het eindresultaat kennis; behandel deze op dezelfde manier. Zie veelvoorkomende fouten bij Planning Poker over het feit dat onderzoek in het verhaal binnensluipt, en de andere praktijkvoorbeelden van schattingen.