We zitten op dit moment te worstelen met een groots project. Niets is dan lastiger dan het duidelijk krijgen wat er nu precies gebeuren moet. De Scrum methode helpt hierbij, maar dan nog blijft het lastig om de wensen van een klant die grote documenten aanlevert de bevatten en om te zetten in daden die concreet gedaan moeten worden. Ik dacht ik grijp eens terug op wat Mike Cohn hierover schrijft in 'User Stories Applied' (2004, ISBN:
0321205685).
Over requirements schrijft Mike Cohn dat de belangrijkste tekortkomingen zijn:
- Het schrijven van een requirements document word een doel op zich
- Geschreven taal laat veel ruimte voor interpretatie over
Ik zou hier graag een derde tekortkoming aan toe willen voegen: Requirement documenten laten zich te gemakkelijk schrijven. Te gemakkelijk worden requirement documenten overladen met wensen waardoor er door de 'requirement bomen' het gewenste bos niet meer gezien kan worden.
Dus wat is het alternatieve pad? Er is niets tegen het kort en krachtig opschrijven, in tegendeel, een goed geprioriteerde backlog met daarin de noodzakelijke test criteria kan helpen gedachten te ordenen. Maar daarna is het belangrijk om snel concreet te worden (Get Real). Begin gewoon zo snel mogelijk met realiseren van de belangrijkste functionaliteit. Houd het in de applicatie in het begin vooral simpel. Vervolgens kan er vanuit wat er dan staat een betere oplossing gekneed worden.