Denna vecka har jag fått seriösa griller i huvudet. Företaget jag höll kurs för i tisdags arbetade hårt med prototyping för att undersöka vilka koncept som fungerade och inte fungerade. Tänk om hela produktbackloggen kunde ersättas med en levande prototyp?
Fram tills i tisdags betraktade jag prototyping endast som ett verktyg för teamet och produktägaren för att flytta en funktioner och features från ”Anarchy” or ”Complex” space ner mot ”Complicated” eller ”Simple” space.
Prototypen blir närmast ett verktyg för groomingen av produkt-backloggen. När produktägare och kund sett och klickat runt i prototypen kan EPIC User Stories brytas ner, detaljeras och prioriteras (eller förkastas). När detta arbete är gjort har prototypen spelat ut sin roll. Den fungerar alltså bara som ett ”hur”, ett verktyg att förstå vad man vill ha och vad som fungerar bäst, ett steg i utvecklingsprocessen på resan mot att leverera värdefull och användbar mjukvara.
Med lite tur kan man ibland återanvända lite kod från prototypen till den ”riktiga” produkten men oftast har den spelat ut sin roll och förkastas till skräpkorgen (eller arkivet).
.
Men nu snurrar (för mig) många nya tankar, åtminstone kring prototyping av gränssnitt och dialoger. POC:ar för att undanröja tekniska frågetecken eller risker lämnar jag därhän för tillfället.
.
För, tänk om…
- Vi inte alls förkastar våra olika prototyper utan prototypen föds i tidig analysfas och fortsätter sedan leva, förändras och växa genom hela projektet.
. - Prototypen är så enkel att bygga ut och laborera med att Produktägaren själv kan experimentera med att lägga till dialoger, skapa dummy-funktioner och koppla ihop systemet på olika sätt. (Kanske har produktägaren ett prototyp-team till sin hjälp eller så spenderar ordinarie team en viss tid av sin sprint för att skulptera prototypen som ett steg i det kontinuerliga analys- och designarbetet.)
. - Prototypen kan ”spelas upp” i olika skepnader. Man bygger inte en helt ny prototyp för att gestalta en annan variant av dialogen utan prototypen kan ställa in i vilket version vi vill experimentera med denna testkörning. Skepnader och flödesvarianter kan enkelt konfigureras on the fly.
. - Vissa delar av prototyp-produkten består av luddiga dialoger och grova funktioner medans andra är tydligare, mer detaljerade och närmare en implementerbar nivå.
. - Prototypen låter sig delas upp i funktioner och komponenter som teamet kan estimera.
. - Estimaten behöver inte lagras i en separat lista någon stans utan är en del av modellen och kopplas till ”prototyp-komponenter”.
. - Komponenterna kan innehålla dolda attachments som inte syns vid körning. Exempelvis word dokument, sökvägar in i wikin, osv.
. - Komponenterna kan innehålla annan meta-information som t.ex:
- Prioritet
- Att-Göra-lista med öppna frågor för produktägaren
- Vilket team som eventuellt ska bygga funktionen
- Vilken release/sprint funktionen eventuellt är planerad till
.
- Slutligen så går prototypens komponenter att skriva ut som en prioriterad lista. Denna lista kommer snarare likna ett träd med grenar som spretar iväg. Ibland lever flera varianter av samma funktion (User Story) fram tills dess att en av dem implementeras och andra förkastats.
Kommentar: När jag skriver ”komponent” ovan menar jag inte modul eller klass, jag syftar till en dialog eller en specifik funktion i användargränssnittet.
.
.
Om denna fantasi besannas har vi då helt och fullt lyckats ersätta produktbackloggen med en prototyp?
Men varför stanna där? Anta att plattformen och språket vi bygger prototypen med är samma som vi använder när vi bygger den ”riktiga” produkten och att implementera en komponent/funktion i prototypen enbart handlar om reda ut återstående detaljer, skriva koden bakom, testa av samt rensa bort döda versioner och aspekter?
Når vi hela vägen hit är vår release-branch helt enkelt en specifik konfigurering av prototypen. Känns definitivt som en utopi men kanske ett vision att arbeta mot?
Är du intresserad och vill anmäla dig så se till att göra det så snart du kan då antalet platser är begränsade till 40 stycken. Träffen sker precis som vanligt i Stockholm (vilket jag tycker är lite tråkigt men jag eftersom grundarna och drivkrafterna bakom gruppen finns i Stockholm så är detta kanske bara naturligt). Agendan ser ut som den brykar, först några blixttal följt av ett Open Space. Mycket lyckat och roligt upplägg tycker jag!
Jag har varit med om att flera team schemalagt sina demos spridda över en och samma dag för att man ska kunna delta på alla som intresserar en.
Pust. Är inte säker på att jag använder tekniken som tänkt men å andra sidan växer ibland arbetet till ett mindre berg, och då helgar ändamålet medlen. Pomodoro tekniken har iallafall gett mig ett verktyg med vilket jag kan jobba riktigt fokuserat, systematiskt och effektivt med.
Idag kommer det inte bli många knop gjorda. Förkylningen har slagit ned sina bopålar så det är bara att gilla läget.
Dras dit team med en person som fått rollen som produktägare och som envisas med att sätta ”Måste”-prioritering på allt? Eller hör du kanske själv till skaran beställare som blir frustrerad när teamet ber dig prioritera ”User Stories” och som inte förstår dig när du försöker förklara för dem att ”alla dom här funktionerna är oerhört viktiga”? 
Jag har prioriterat råden efter den ordning jag tycker man ska följa dem 😉 Vidare, när jag skriver ”Story” i texten nedan syftar jag till User Story/Feature/Funktion.
Teamet hinner bara bygga och leverera ett begränsat antal färdiga funktioner/features per sprint. Att designa, utveckla och testa av funktioner och features tar tid. Hur mycket du som produktägaren än vill så kan inte teamet leverera hela produktbackloggen på en sprint. Att sätta Måste-prio på allt hjälper vare sig teamet eller dig. Det skapar snarare enbart frustration.
För varje råd du följer ovan desto bättre förutsättningar och möjligheter får teamet att lyckas med sin leverans under pågående sprint. Det de bygger blir rätt, behöver inte göras om och håller hög kvalitet. Du ger dem också möjlighet att hålla samma (och förutsägbara) tempo, effektivitet och kvalitet varje sprint.
En natt i februari pågick det ett livlig twittrande om den fantastiske Chuck Norris, eller åtminstone om hur fantastisk han hade varit om han hade jobbat agilt.
Har upptäckt att det finns en hel del små fiffiga appar på min Android som kan vara bra att ha till hands för utvecklarna i det agila teamet och den gadget-glade Scrum Mastern. (Jag är säker på att samma appar eller motsvarande går att hitta till iPhone också.)
Det kommer att bli några spännande sprintar framöver för utvecklingsteamet och mig själv när vi ska försöka leva, leverera och överleva i gränslandet mellan Scrum och Vattenfall. Den uppenbara risken är såklart att eventuella förseningar och/eller problem skylls på den nya kompisen i gänget (Scrum) istället för de sanna grundorskarna (som t.ex. skulle kunna vara dåliga estimat, dåliga förustättningar eller yttre störningsmoment för att nämna några) och att den nyväckta glöden till Scrum i utvecklingsteamet släcks.
Jimmy Janlén "Den Scrummande Konsulten" 