Mike Cohn over Scrum en Interaction Design

 Hoewel het nog te vroeg is om iets zinnigs te zeggen over de door ons onlangs ingeslagen weg om interaction design en scrummen te combineren, blijven we natuurlijk lezen over de mogelijk betere methodes. Zodoende kwam ik een hoofdstuk in Mike Cohn’s boek ‘User Stories Applied’ (2004, ISBN: 0321205685, hoofdstuk 16) tegen. In plaats van interaction design mee te nemen in de sprint (onze eerste opzet), of een sprint voor te laten lopen (waar we dus onlangs aan zijn begonnen) stelt hij iets anders voor: doe het interaction design voor dat je met het daadwerkelijke scrummen (lees: programmeren) begint, een idee eigenlijk afkomstig van Constantine and Lockwood (2002). Gesuggereerd wordt, alvorens aan het sprinten te beginnen, de volgende stappen te doorlopen:

1. Modelleer de gebruikersrollen (zoals gebruikelijk)
2. Selecteer de belangrijkste user stories (interaction design specifiek(?))
3. Prioriteer deze met hoge, midden, en lage prioriteit (interaction design specifiek(?))
4. Verfijn de user stories met hoge en middelbelangrijke prioriteit (interaction design specifiek?)
5. Groepeer de user stories naar verwacht gebruik (wat zou een gebruiker normaliter tegelijk willen doen)
6. Maak prototypes op papier (prototyping)
7. Test, overleg met gebruikers (en ga des noods terug naar 6)
8. Begin met programmeren

Toen ik deze lijst tegen kwam was ik enigszins verbaast dat het afweek van het normale Scrum proces. Nergens wordt benadrukt wie de prioriteiten stelt, en of deze wel of niet de geschatte kosten mee neemt. Het lijkt erop alsof gesuggereerd wordt pas na stap 8 te beginnen met serieus Scrummen: eigenlijk wordt er dus een klein watervalletje geïntroduceerd, ook al wordt er op gehamerd dit nog zo kort te houden. Met Scrum proberen we toch eigenlijk watervallen, dat wil zeggen mijlpalen die het project een (semi-)definitieve sturing geven, te vermijden, juist omdat de toekomst zich niet laat voorspellen.

Natuurlijk is ook paper prototyping (de methode die aanbevolen wordt in het hoofdstuk) er op gericht door doormiddel van ‘tastbare’ interfaces de ideeën vroeg te testen en beter te communiceren. Toch zie ik zelf meer in de filosofie van Getting Real, waarbij echte software wordt ontwikkeld die getest en gefinetuned kan worden… bij interfaces op papier moet toch nog teveel uitgelegd worden, of aan de fantasie overgelaten te worden.

Het is echter onverstandig om advies van een authoriteit zomaar naast je neer te leggen… en er waren dan ook wel een paar belangrijke elementen tussen de regels (en enige vrije interpretatie ;) ) op te pikken in het hoofdstuk:

• Interactie is belangrijk, en de klant en gebruiker wil ook graag weten waar het naar toe gaat. Beperk je tijdens de brainstorm niet enkel tot woorden. Gebruik het beste medium om je uit te drukken, dus schets waar nodig (eigenlijk ook al een vorm van prototyping… maar ook in paper prototyping is nog een groot onderscheidt te maken van low-fidelity tot high-fidelity).

-  Zorg dat je niet interface afhankelijk programmeert: maak de interface makkelijk aanpasbaar, ook wanneer de logica grotendeels geschreven is. Mike Cohn citeerd een advies van Ward Cunningham: probeer gewoon twee interfaces te onderhouden. Programmeren voor twee interfaces zorgt ervoor dat je applicatie logica en presentatie duidelijk gescheiden houdt, wat er vervolgens voor zorgt dat je ook achteraf de interface gemakkelijk kunt aanpassen (om zo b.v. de consistentie tussen elementen te bewaken). Maar dat doe je natuurlijk uit jezelf al, niet?                      

Deze post verscheen eerder op The Bean Blog