Idag blev jag ombedd att dela med mig av råd och erfarenheter rörande lättrörlig kravhantering i praktiken - vilka verktyg ska man använda, hur hanterar man nedbrytning, spårning mellan krav och specifikationer, osv.
Frågan har kommit upp många gånger förut, och det lustiga är att den mest effektiva lösningen jag varit med och skapat var också den allra första.
När jag som projektledare en gång började experimentera med XP och Scrum var jag tämligen skeptisk mot de kravhanteringsverktyg jag upplevt dittills, och var måttligt sugen på att brottas med de jag hade tillgång till eller lära mig något nytt. Och då har jag inte ens pratat om hur svårt det var att få mitt än mer skeptiska utvecklingsteam att dokumentera i det verktyget. (Som givetvis var så dyrt att vi inte kunde ha licenser till alla, vilket skapade ett alltför bra dåligt exempel på köteori i praktiken)
Någon i teamet föreslog att vi skulle skapa en Wiki för kraven istället. Jag lät mig lätt övertalas, och förundrades över hur denna konkurrent till det hårt reglerade intranätet snabbt växte till en överblick över projektläget.
Den första sidan innehöll en kort beskrivning av projektet. Den fylldes snart på med en produktbacklog, som helt enkelt utgjordes av en lista med alla högnivåkrav. Listan kunde enkelt exporteras till Excel för de traditionella (slöseri-)rapporterna o dyl.
Efter ett tag började saker på produktbackloggen förvandlas till länkar, i takt med att teamet började planera upp nästa sprint. Varje länkat krav pekade på en sida som innehöll kravnedbrytning och mål för kravet. I takt med att kraven började bli implementationsfärdiga växte teknisk dokumentation som skildrade lösningsförslaget in, och tekniska specifikationer länkades in.
Det riktigt intressanta hände när teamet började blogga om arbetet med varje krav på respektive undersida. Resonemang kring valda lösningar, och hur de skulle testas (och resultatet av tester och eventuella korrigeringar) vävdes in i bloggen av deltagarna, och växte snart till en sökbar kunskapsdatabas om de olika funktionerna i systemet. Delar av ledningen började intressera sig för detta nya "projektintranät", och när CTO glatt deklarerade på ett fredagsfika att han såg fram emot att läsa om nya utmaningar och lösningar på wikin eldade det förstås på motivationen än mer hos alla inblandade!
Själv var jag förundrad. Visserligen hade både personalchef och några andra intressenter uttryckt oro för att detta inte skulle fungera utan en redaktör - men själva naturen av egenmoderering verkade fungera utmärkt utan uppmaning - sidor som blev pratiga, svåröverskådliga eller helt enkelt för stora sammanfattades eller bröts ned till mer fokuserade avsnitt. Och till och med Anders, en av de mer erfarna och skickliga utvecklarna i teamet, som var notorisk för att ogilla dokumentation i alla former, satt nu ofta och skrev koncisa och förträffliga sidor om designval och lösningsförslag - inte utan en viss lakonisk ton.
Genom det kollektiva ägandet följde också ett kollektivt ansvarskännande. Då flera projektexterna parter gärna följde wikin var deltagarna måna om att hålla den läsbar och nyttig, och det fanns aldrig någon redaktör som var flaskhals, eller för få licenser som ställer till kö och glömda uppdateringar.
Efter några spännande kursändringar i verksamheten fanns en reell möjlighet att projektet skulle utsättas för en granskning av FDA. Eftersom de ställer mycket hårda krav på mjukvaruutveckling (dock mer i form av process än kvalitet, men ändå) anlitade vi en specialist från USA som skulle gå igenom våra arbetssätt och dokument inför en eventuell granskning. Det blev förstås viss oro och tandagnisslan från ledningen som förfasade sig över att vi hade så lite dokumentation utskriven i pärmar. Nå, för-granskningen genomfördes, och experten granskade vår wiki med nyfiket intresse - och godkände den, eftersom den enligt honom uppfyllde samtliga krav inför en fullständig granskning:
- Wikin säkerhetskopierades automatiskt och regelbundet
- Inloggning krävdes för att göra ändringar, vilket ger spårbarhet på ändringarna
- Den versionshanterades automatiskt, vilket ledde till att information inte kunde gå förlorad genom misstag.
Detta var många år sedan, och wikitekniken var betydligt mer exotisk då. Idag finns många att välja på, och exempelvis kan man få backlogtabeller som enkelt kan prioriteras om genom att dra och flytta elementen direkt i listan, och man kan ofta utbyta data enkelt mellan exempelvis Office och wiki. Det finns wikis som är specialgjorda för att ha en hög andel grafiskt innehåll för publikation, och wikis man enkelt kan ladda ned till ett USB-minne och flytta med sig på det sättet.
...
Efter denna framgång har jag använt wiki med lyckat resultat i många sammanhang. Ibland finns det en it-avdelning eller informationsansvarig (eller metodchef) som av någon anledning försöker bromsa det hela, och då har vi skapat en server lokalt i vår projektmiljö och satt upp den där. I två fall har t.o.m. den blygsamma projektwikin med tiden kommit att ersätta det tröga och svåradministrerade intranätet!
Ibland kan en wiki bli vildvuxen eller yvig, och det är ofta ett tecken på att ansvarskännandet för wikin gått ned - antingen börjar informationen bli gammal och sällan använd, eller så är helt enkelt inte tillräckligt många intresserade av den. Då kan det vara läge att arkivera den och börja om!
Comments