Granskning!
Ett ord jag har en viss hatkärlek till.
Nu under hösten läste jag en kurs i kravhantering på universitetet. I universitetsvärlden gillade man granskning. Som projektledare gillar jag också granskningar.
Vi sätter ner foten och säger att nu är det här jobbet klart.
Vi kvalitetssäkrar det vi gjort och går vidare. Kod, dokument, krav eller länkning spelar ingen roll. Teoretiskt så är allt så bra!
Men jag vet också att granskning är svårt.
Jag har arbetat som ledare i en organisation som släppte ut en mjukvara med ett mycket allvarligt fel på marknaden.
Efteranalys visade att alla granskningar var gjorda och att vi processmässigt gjort ett gediget jobb.
Problemet var att ingen som granskade dokumentationen eller koden hade tillräckligt god kunskap för att kunna hitta felet, eller ens se att de saknade förmågan till det.
Det handlade inte om att granskarna var okunniga, tvärtom hade man valt mycket relevanta granskare utifrån den grupp som kunde vara aktuella.
Istället handlade det vårt tillkortakommande till stor del om synen på den kunskapsuppbyggnad som följer med implementationen av mycket komplex funktionalitet i mjukvara.
Vi litade för mycket på en person under lång tid och trodde andra skulle kunna kvalitetssäkra det arbetet personen gjort under åratal i efterhand. Genom granskning!?
Granskning kan också bli väldigt tråkigt vilket gör att kvalitén i aktiviteten sjunker.
Artefakter där granskning är en viktig del i kvalitetssäkringen bör utformas så att granskning underlättas.
Granskning och scrum
Kan flera människor i ett tvärfunktionellt team granska en stor mängd artefakter, kanske i delar som bara är några timmar långa åt gången, och finns det några fördelar i att bedriva granskning så?
Jag skulle säga ja på båda på båda frågorna.
Men några saker måste vara på plats och är de det så bidrar det dessutom till att höja kvalitén i den granskning som ska göras.
- Det måste vara tydligt vad som ska granskas för respektive artefakt och hur kommentarerna ska hanteras.
- Artefakterna måste vara granskningsbara och strukturerade så att granskning av delar, eller vissa aspekter, är möjligt.
- Det måste finnas en granskningsledare och någon form av verktygsstöd som säkrar helheten.
Att sprida granskningen vid en scrum-tavla kan dessutom tvinga fram vissa effekter som i sig höjer kunskapsnivån på teamet och bidrar till att höja kvalitén i det som görs indirekt.
En tydlighet i vilken granskning som ska göras och vad den ska mynna ut i kombination med en gemensam insats att planera upp granskningen, exempelvis vid en scrum-tavla bidrar till det.
I praktiken kunde det se ut ungefär så här i Excelarken vi använde.
I praktiken hade vi 1000-tals ting att granska och vi granskade varje artefakt utifrån ett ganska stort antal aspekter. Det här var i sig inget nytt, åtminstone var inte kravet att granska det.
Det som var nytt var att vi gjorde det med hela projektets bemanning – ungefär 50 personer – och att alla kunde, alternativt var tvungna, att hjälpa till.
Att det gick berodde bland annat på att vi delat upp och förtydligat vad som skulle granskas med avseende på vad väldigt detaljerat.
Och vi gjorde det på ett enkelt tydligt vis genom att använda ett schema enligt bilden ovan.
De artefakter som var svårgranskade, främst en grupp dokument, arbetades till viss del om för att passa vårt schema istället för tvärtom.
Förmodligen fanns det inledningsvis en person som granskat koden bäst.
Eller som kunde kravverktyget bäst och därför borde granska länkningen som gjorts.
För att inte tala om hur det såg ut avseende varningarna i byggresultaten. Det ville ingen kunna något om. Men att visualisera och dela upp tog oss framåt.
Det var inte så svårt för systemkillen att granska alla filer med varningar när allt kom omkring.
Det blev en eller två punkter som behövdes tas upp i större grupp. UI-gruppen gjorde ett mycket bra jobb i granskningen av testfall och länkningen av dem.
Ibland kunde vi gjort saker i en ordning som varit klokare, men eftersom vi alla hjälptes åt och blev allt klokare så gick eventuella omtag snabbt.
Vi höll på i månader. Först gnölade något över att vissa dokument inte granskades i sin helhet.
Att allt snuttifierades.
Någon ansåg att ingen hade överblick på om systemet faktiskt fungerade som tänkt och enligt ställda krav – något vi genom allt arbete som gjorts tidigare samt systemtester, robusthetstester och vad alla tester nu kunde tänkas heta var rätt säkra på när vi startade slutgranskningarna- och någon ansåg att deras kompetens kunde användas bättre.
Men det tog inte många veckor innan alla var positiva.
Ingen satt med svartepetter. Kunskapsspridningen i granskningen gjorde att kvalitén snarare höjdes än sänktes.
Kanske viktigaste för arbetsmoralen var att det vi hittade, som behövdes undersökas, snabbt gick att hantera. Ingen nyckelperson satt fast i granskning två veckor.
Sällan hade någon en arbetsuppgift längre än ett par timmar.
