Krav på ordning!

Som ett exempel på detta har vi ett inlägg i tidningen Computer Sweden av Anita Roll och Tony Gorschek, där de ställer krav på att vi nu måste fokusera än mer på krav- och testprocessen (12 januari 2010).

Enligt artikelförfattarna ställs krav i projekt ”innan projektet startas och test involveras senare”.  De menar dessutom att lösningen på dålig kvalitet och ordning i processerna är mer ordning och större fokus i krav- och testprocesserna. De går också vidare och pratar om hur dyrt det är att ändra i kravbilden och hitta fel sent i projektet.

Det är mänskligt, men ibland ack så fel, att vilja laga det system som inte fungerar genom att förbättra systemet och kräva mer ordning inom befintliga ramar. Problemet är bara att systemet i sig kan vara problemet och ramarna kan vara satta på helt fel plats. Så är det om vi tar på oss agila glasögon. Med sådana glasögon ser vi istället att systemet i sig till stora delar är sjukt och att vi behöver andra lösningar.

I en kunskapsarbetares vardag är krav inget som kan definieras på förhand. Mål och medel för att komma fram är alltför ofta luddiga, otydliga och svåra att greppa. Istället för att definiera kraven på förhand nöjer vi oss med ”good enough” på en kort men effektiv tid.

Vi kan till exempel i form av en ”user story writing workshop” under en dag eller två klämma ur beställarna en tillräckligt stor kravbild för att påbörja ett projekt i storleken 10 000 timmar. Vi kan i motsvarande grad skapa definitioner av de viktigaste testerna ungefär lika fort i samband med att vi definierar kraven.

Därefter sätter vi gång och skapar affärsnytta med en gång, och krav och test är inget vi gör vare sig före eller efter det att vi levererar affärsnytta, utan:

• varje dag jobbar vi med kraven
• varje dag designar vi lösningen
• varje dag testar vi lösningen
• varje dag testar och kvalitetssäkrar vi
• varje dag validerar och acceptanstestar vi
• varje dag dokumenterar vi
• varje dag gör vi helt enkelt ALLA typer av arbetsuppgifter

…så att vi på ett sådant sätt är klara med en del av den totala affärsnyttan en gång i månaden. I en kunskapsarbetares vardag behöver vi också lösningar och arbetssätt som säkerställer att det är enkelt och automatiskt för oss att göra ändringar och hitta fel i krav och struktur.

Naturligtvis är vi duktiga på att prata om vad vi tänker göra istället för att ändra i det vi redan gjort, men vi ser också till att det är lätt och billigt att ändra i krav och struktur när vi emellanåt inser att vi tänkt fel och behöver ändra riktning. Vi är inte rädda för förändringar utan vi välkomnar löpande förändringar och detaljeringar av kravbilden. Som stöd finns väl beprövade tekniker som evolutionär prototyping, re-factoring och automatisering. Rädda pojkar får inte kyssa vackra flickor! (och tvärtom).

Poängen är att krav och test, liksom allt annat arbete, inte är något vi gör i serie utan parallellt. Därmed faller diskussioner med kunder, beställare, chefer och ledning om hur mycket kalendertid vi skall lägga på krav och test. Det behövs inte så mycket kalendertid!

Däremot behöver vi ganska mycket resurser och medarbetare som fokuserar på test och krav, och dessa resurser arbetar parallellt med allt annat arbete. I ett moget agilt perspektiv fokuserar därför diskussionen runt den just nu skapade affärsnyttan, och vilka resurser som behövs för att uppnå den, och inte hur länge vi skall testa eller analysera.

Exempel på resurser som behövs är en kravledare (product owner) som arbetar i nuet och sitter i knät på teamet som levererar nyttan. Ett annat exempel på resurs är en kompetent testare och kvalitetssäkrare som säkerställer att vi testar på rätt sätt och automatiserar testning runt produktens vitalaste delar. Dessutom kan vi nämna att testning inte är något som bara testare gör, utan alla vi i projektteamet är testare och ansvarar för hög kvalitet i vårt eget arbete.

Sammanfattningsvis kan vi säga att ja – krav och test är områden som alltför ofta lider. Lösningen är dock inte att fokusera mer tid på krav och test i ett system som bygger på att krav och test är något som händer efter varandra med lite ”konstruerande” mitt emellan. Lösningen är inte ett system som antar att det går att definierar kraven rätt från början och att det sedan bara är att ”verifiera” mot kraven. Tyvärr fungerar inte ett sådant system för flertalet av de utmaningar som en kunskapsarbetare möter. Fungerar det för dig?

Lösningen är istället att byta till ett system som är mer förankrat i verkligheten. En verklighet där det är meningslöst att tro på att kartan och kravbilden går att få helt rätt från början, en verklighet där vi förstår att vi måste ge oss ut i terrängen och parera och göra kartan samtidigt som vi rör oss framåt. En verklighet där vi investerar i vår förmåga att parera och ändra strukturen, istället för den fasta strukturen i sig.

Kartor, krav och planer är viktiga, men de går inte alltid att göra i detalj i förväg utan vi får nöja oss med grova skattningar. Detaljerna tar vi effektivast hand om när vi går. Om inte du heller tycker att det fungerar att definiera allt i detalj från början utan vill ut i terrängen fortare och ändå hamna rätt till slut – använd agile!

För den här spaningen ber jag att få ge ett tips-tack till mina kollegor Anders Nygren och Mats Janemalm.

Per-Magnus Skoogh har många års erfarenhet av att använda och införa agila processer och arbetssätt. Han var bland de allra första i Sverige med att börja använda formellt definierade agila arbetssätt, när han för knappt 15 år sedan började arbeta med DSDM/atern. Sedan dess har Per-Magnus använt olika agila tekniker från Scrum till XP i projekt i Sverige, Tyskland och England. Idag hjälper han och hans kollegor olika kunder med att ta till sig agila tekniker av olika sorter med en fokus på ökad verksamhetsnytta.