Från pyramider till Scrum, del 2

Första delen finns här

Hittils har vi tacklat problemen inom mjukvaruutveckling genom att försöka skapa struktur och ordning och reda. Vi har använt JSP (Jacson Structured Programming), ROP, RUP och UML.

Vi hamnade, och kanske fortfarande är, i ett läge med många olika roller med olika hattar som ska vara kunniga inom området och ta hand om de olika delarna som dokumentation, analys, prioritering och spårbarhet.

Med introduktionen av det agila synsättet så verkar det som att man tror att det bara behövs en enda hatt, en roll som kan allt. Men kan man verkligen vara så duktig på allt?

Om teamet har de kravkompetenser som krävs, kan de då samtidigt vara vassa programmerare? Många hävdar att produktägaren ska vara den som står för kravkomptensen, vilket vore lämpligt enligt det enkla Scrum-ramverket. Men många gånger är produktägarrollen en karriärroll i organisationen. Kravkomptensen står inte i fokus eller fattas kanske helt och hållet. Enligt vårt sätt att se det hela, är kravkompetens viktigare än verksamhetskunskap i produktägarrollen!

När produktägaren saknar kravkompetens motsvarande exempelvis en IREB®-certifiering, förlitar sig verksamheten och produktägaren på att teamet ska ta hand om allt som omfattas inom den traditionella kravingenjörsrollen. Problemet är att de i verkligheten oftast är fullt upptagna med att vara vassa på sina respektive fokusområden. Det är således oerhört lätt att kravarbetet som borde gjorts faller mellan stolar och inte adresseras över huvud taget. Det resulterar också i frustration för dem som ska testa systemet eftersom de inte får något att testa mot, ingen helhetsbild och nedbrutna delar med definierade testbara krav.

 

Därför är det viktigt att se till att kravkompetensen är levande och tar plats och startar tidigt i projektet, eller ännu bättre, redan innan själva projektet drar igång, i en tidigarelagd ”kravsprint”. Då kommer det att finnas någon som ansvarar för helhetsbilden, verksamhetsnyttan och kommunikationen samt avstämningen med de identifierade mottagarna av vad som kommer att byggas och levereras.

 

Efersom det nästan alltid finns mer än en (1) intressent för ett system (enligt Tom Gilb, ca 38 olika intressenter i genomsnitt!) och mängden intressenter dessutom förändras under projektets gång, så är det viktigt att ha kravkompetens att kunna analysera och återspegla ändringarna av målbilden både till utvecklingsteamet och till verksamheten.

 

De olika intressenternas bilder behöver beskrivas och alla kvalitetskriterier behöver kvantifieras.

 

Helhetsbilden behöver analyseras, dubletter och motstridigheter behöver bearbetas.

 

Efter analys och ett kvalitativt kravarbete blir helheten och målbilden tydlig.

Denna bild är möjlig att designa till en god arkitektur!

Detta arbete handlar om ”Requirements Engineering”, De flesta kan göra det men det krävs träning och erfarenhet för att bli bra på det. Precis som skillnaden mellan att spela fotboll på korpnivå och i högsta serien.

Så nästa gång du ska bemanna ett agilt projekt, se till att kravkompetensen finns med och är stark och aktiv. Det är extremt ovanligt med supermänniskor som kan axla produktägarens superroll som expert på väldigt mycket och samtidigt ha en helhetssyn.

Det borde således finnas en utpekad roll som verkar som produktägarens högra hand, Scrummästarens vänstra hand och som alltid tillgänglig för teamet. Den rollen är kravingenjören - the Requirements Engineer.

Om författaren
Torbjörn Andersson är expert inom kravhantering och kvalitetsäkring av IT-projekt. Han arbetar vanligtvis som konsult, mentor och utbildare.