Een schatting maken van een prototype
Hoe u een prototype moet beoordelen: het is een opleverbaar product 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 luidt: „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 doel is om snel genoeg antwoord te krijgen op een vraag (voelt deze interactie goed aan, is deze aanpak schaalbaar, zal deze API het volhouden?), zodat u van koers kunt veranderen voordat u zich er definitief aan committeert. Teams die prototypes op dezelfde manier inschatten als functies, komen uit op een cijfer dat de verkeerde vorm van werk financiert.
De andere manier waarop het mis kan gaan 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: “Welke vraag proberen we 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 het waard zijn om te stellen voordat u gaat stemmen
- Op welke vraag geeft het prototype een antwoord, en hoe weten wij dat wij een antwoord hebben?
- Alleen intern, of in het bijzijn van klanten?
- Is dit standaard een wegwerpproduct, 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 werkelijke risico: reserveer middelen voor het prototype als onderdeel van de oplossing en beschouw de productieversie als een apart project, zodat het weggooien niet automatisch de overhand krijgt.
Stel een prototype op voor het antwoord, niet voor 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 steeds verder in het verhaal doordringt, en de andere praktijkvoorbeelden van schattingen.