Vanliga frågor om krav

Eftersom kravrollen tyvärr tagits bort är själva arbetet istället utdelat på alla i teamet. Oftast får produktägaren detta i sitt knä, men hen är redan väldigt upptagen med att prioritera mellan alla krav och kommunicera/förhandla med alla intressenter. Så ett tips är att teammedlemmar turas om att driva detta arbete tillsammans med PO.

Det är viktigt att även vid agilt arbete frysa kraven vid vissa tillfällen – så ni har ett fast mål att utveckla och testa emot. Det finns flera tillfällen i samband med backlog refinement att detaljera så pass mycket för att kunna estimera och ha ett första utkast. Ett förslag är att inkludera vad ni menar med frysta krav i er DoR (Definition of Ready) så att vid sprintstart hela teamet kan committa till ett överenskommet krav. OM ni vid sprint review/demo kommer på ändringar blir det ett nytt krav att utveckla emot under nästa sprint.

Azure DevOps är som du skriver ett bra ärendehanteringssystem främst för utveckling och för att koppla ärenden till exempelvis kodincheckningar och testfall. Dock blir det lätt grötigt att ha kravdokumentationen där, utan det är bättre att ha i ett tillhörande verktygsstöd – som Microsoft-produkterna Sharepoint eller Teams – och länka till detta från ärendena. Det är viktigt att separera krav som redan finns implementerade i produktion, krav som är under utveckling och framtida behov. I takt med nya releaser måste detta kontinuerligt uppdateras. Det finns också en massa andra verktygstöd som vi testat i denna rapport.

Alla som är med i utvecklingen! Dvs kravanalytiker, arkitekt, programmerare, testare, acceptanstestare, (om ni jobbar agilt) produktägaren. Kraven ska ju tillgodose behovet och implementeras i en lösning som alla är överens om. Beroende på lösningens komplexitet eller brådskan att utveckla något kommer kraven att behöva justeras så det fungerar i alla led. Kravhanteringen är också en kontinuerlig process som någon behöver leda och alla behöver kunna följa dokumentationen. För flera tips runt kravdokumentation se denna checklista.

Ja, detta är en väldigt vanlig situation. Oftast börjar den agila resan i ett team eller på hela IT-avdelningen men verksamheten inkluderas inte och fortsätter därför på samma sätt. Detta är en fråga som måste lösas på ledningsgruppsnivå, tex genom att bestämma att hela organisationen inklusive alla avdelningar (ekonomi, personal, etc förutom huvudverksamhet) genomför en agila transformation till exempelvis SAFE. Detta kommer dock ta en lång stund att bestämma om och genomföra så tills vidare får man mest leva med att det haltar.

Det är viktigt att tala om missmatchen utan att värdera den så alla är medvetna om problematiken. Om ni jobbar agilt i er vanliga produktutveckling, men sedan bestämmer sig arbetsplatsen för att genomföra ett större projekt på ett mera vattenfalls-sätt (kan vara ett komplext lagkrav eller kan vara en stor extern leverantör), då är det bäst att mest gilla läget och försöka göra det bästa av situationen. Att försöka få en stor extern leverantör att anpassa sig efter er arbetsplats eller få myndighetskrav att ändras är ganska lönlöst. Istället för att ägna massa energi åt att metoden inte passar in i sprintar eller era releasedatum, så fokusera på vad ni vill uppnå, vilken lösning som bäst tillgodoser behovet istället för exakt hur processen ser ut.

Jo, du måste frysa för att kunna utveckla och testa emot. En lagom frys-tid är en sprint. Ett förslag är att inkludera vad ni menar med frysta krav i er DoR (Definition of Ready) så att vid sprintstart hela teamet kan committa till ett överenskommet krav. OM ni vid sprint review/demo kommer på ändringar blir det ett nytt krav att utveckla emot under nästa sprint.

Den här frågan är en utmaning att ge ett tydligt svar på eftersom det kräver att man gör ett antagande utifrån vilka förutsättningar som ni har!

Det som vi har lärt oss när det kommer till upphandling av IT-tjänster är att man behöver säkerställa att alla förstår vilka förutsättningar man har från början. Här skiljer det sig enormt från vilken typ av bolag man är och vad det är man ska köpa in. Samt hur den här tjänsten ska levereras till er? Kommer ni att köpa en IT-tjänst som ni ska vara med och bygga eller är det en färdig SaaS-lösning som ni ska integrera i ert befintliga systemlandskap.

Alla dessa grundläggande saker ger er förutsättningar för hur ni har möjlighet att jobba med kraven. Det som är lika för alla typer av IT-tjänster att man behöver förstå det övergripande behovet. Där du säkerställer att alla är med på varför ni ska göra en upphandling och vad för värde det kommer att medföra.

För att få full spårbarhet rekommenderas att använda antingen JIRA/Confluence eller Azure DevOps/Sharepoint. I dokumentationssystemet Confluence eller Sharepoint (eller annat system) kan behov och affärskrav dokumenteras och sedan kopplas till ärenden för systemutveckling. Ärenden syns i JIRA eller Azure DevOps och de kan koppla till kodhantering och testfall. Bägge dessa system kan hantera olika typer av testfall. Glöm inte att uppdatera all dokumentation i samband med release (vad som är nytt i produktion).

Vi har testat ett antal verktygsstöd (se hänvisning ovan) och det finns många att välja bland. Det viktigaste är att ni internt kommer överens om era viktigaste krav på verktygsstödet och sedan ser ni vilket som passar er bäst. Om ni börjar klicka runt i olika verktyg är det risk att ni kommer tappa bort er bland all funktionalitet och kanske köper ett system som ökar er komplexitet istället för hjälper er vara agila. Kraven har som du säger en livscykel så det är viktigt att ni kopplar detta till era processer. Ett förslag är att tillsammans i teamet rita livscykeln som en process där varje steg förtydligas med vad och var ni dokumenterar och sedan har detta lättillgängligt för alla. I samband med olika kravdiskussioner så turas ni om att vara sekreterare och uppdaterar direkt på rätt plats. Det är bra om systemet har spåra ändring funktionalitet och notifieringar så alla kan följa kravets utveckling. För flera tips runt kravdokumentation, kolla checklistan vi tipsar om ovan.

Ja rollbeskrivningen ser ofta olika ut om man delar upp kravarbetet på detta sätt. I vissa, mindre,  organisationer har man en roll ”kravanalytiker” som utför all kravhantering. I större organisationer delas ofta kravhanteringen upp på flera roller eftersom det är mer jobb och annan hantering och annan process.

Typiska benämningar på roller som hanterar krav är Verksamhetsutvecklare, Verksamhetsarkitekt, Business Architect, Business Analyst, Produktägare, Product Owner, Kravanalytiker, Requirement Analyst, Systemanalytiker, System Analyst. Vad gäller nivå (Top-Down; Mål, Effekter, Verksamhetskrav, Lösningskrav, Features) eller (Epic, User Stories, Features) – så skiljer sig dessa inte vad gäller detaljeringsgrad. Alla beskrivningar oavsett nivå behöver vara klara, precisa och otvetydiga.  Det handlar snarare om vilken typ av kravtyper man jobbar med och i vilken kontext.

Kravtyper kan då delas in i vilken nivå och roll som jobbar med respektive.

PO - Mål, effekter
Verksamhetsarkitekt/ Business architect - Verksamhetskrav, Epic, processer och information
Kravanalytiker/ Business analyst/ Requirement analyst - User stories, Lösningskrav, Features
Systemanalytiker - Features, data

Detta handlar om spårbarhet. I små initiativ kan det räcka med att använda en matris exempelvis excel. Ofta länkar man entitetens id (kravid/ testid) med varandra. SÅ när du klickar på den ena så får du upp ID och beskrivingar av alla relaterade entiteter. Men ibland ökar kravmassan och det blir ohållbart när mer och mer tid går åt till att försöka uppnå spårbarhet framåt eller bakåt. Dvs spåra framåt exempelvis från behov till krav eller bakåt från test till krav. Benämningarna framåt och bakåt beror på att man utgår från att processen börjar behov och man sedan jobbar sig framåt i tiden tills man är framme vid test. I större initiativ eller efter en tid in i projektet inser man behovet av ett kravverktyg. Verktygen har ett sätt att skapa spårbarhet både framåt och bakåt. Några populära är Jira, ALM (HP), ReqTest.

Jag vet inte riktigt vad du menar med krav-review och det är sant att kraven utvecklas kontinuerligt. Det är viktigt att även vid agilt arbete frysa kraven vid vissa tillfällen – så ni har ett fast mål att utveckla och testa emot. Ett förslag är att inkludera vad ni menar med överesnkommen krav-review i er DoR (Definition of Ready) så att vid sprintstart hela teamet kan committa till ett överenskommet krav. OM ni vid sprint review/demo kommer på ändringar blir det ett nytt krav att utveckla emot under nästa sprint.

Ja, det är skillnad beroende på systemets livscykel. Vid nyutveckling har man alla chanser att verkligen göra helt rätt, att jobba agilt på riktigt. Detta gäller framförallt om det är ett system som fyller en ny funktion, men även om det är ett system som ska ersätta ett befintligt system. I det senare fallet (system ska ersätta) kan man jobba agilt tills MVP är på plats men under migreringsfasen blir det mera styrt, och sedan kan ni fortsätta agilt igen.

Om ni jobbar med vidareutveckling av ett system som funnits länge så är det ofta en blandning av agilt, ad-hoc, vattenfall. Om det är ett system som mest underhålls rekommenderar jag att inte ändra för mycket i arbetssättet, men om det är ett system ni lägger mycket tid på utveckling så är det värt att ta ett större omtag runt ert arbetssätt. Ni kan börja med det ni utvecklar framåt är agilt och hanteras och dokumenteras enligt era nya regler för DoR och DoD.

Om ni jobbar med ett system som ska avvecklas och ska ersättas av ett nytt kan det vara bra att ha en genomlysning av hela systemets krav som ni kan ha som grund för det nya systemet. Många underförstådda krav glöms lätt bort annars.

Det finns inget som heter ett agilt krav. Det handlar mer om hur man hanterar krav. Några riktlinjer som du kan tänka på om du skall formulera krav.

Inte för mycket och inte för lite – beroende på sammanhang. Utan lagom.
Inte för sent eller för tidigt – beroende på sammanhang. Utan Just In Time.

Samt kravet skall vara:
- Oberoende från andra krav så du kan implementera det i godtycklig ordning
- Kommunicerat och förhandlat med intressenterna. 
- Värdeskapande, dvs ngn behöver det och är villig att prioritera och betala för det.
- Estimerat, så vi vet hur lång tid det tar att implementera och vad det kostar.
- Sized. Skall vara rätt omfattning i förhållande till situationen. Inte för litet inte för stort.
- Det skall vara testbart.

Under förutsättning att man jobbar på rätt sätt så slipper du detta problem. Men många hamnar här och vissa pga att man hanterar inte krav korrekt. Då hanterar man symtom istället för orsaker.

Orsaken i detta fall är att kravhantering inte skett korrekt. I detta fall är inte analys/ syntes av krav gjort korrekt, kanske inte heller estimering och sizing om dessa var korrekt utförda så skulle varje krav vara i stort sett kunna implementerats oberoende av varandra oberoende av team. Dvs du skalar upp/ner krav och team-storlek och team-velocity så dessa mappar till varandra. Men om du ändå sitter i detta så handlar det om vanlig projekt-planering ”look-ahead-planning” med koordination. Många använder SAFE eller Scrum of Scrum etc för att lösa dessa symptom.

Kravställning är processen att formulera krav. Kravhantering är hela processen - Fånga/ upptäcka/ analysera/ formulera/ dokumentera.

För att analysera As-Is. Förutsatt att nyckelperson finns tillgänglig eller går att få tag i. Kontakta dessa och utför kravfångst, analys etc. Om inte så finns det säkert utvecklare/ arkitekter som kan hjälpa till att beskriva lösningen. Om inte så kan ni använda något reverse engineering tool för att skapa er en bild av lösningen, om ni har codat i java testa Recaf.

Best practise finns inte utan det är situationsberoende. Men du skulle kunna använda dig av förmågekartor, dvs gruppering av förmågor utifrån vissa egenskaper vanligen utifrån ett affärsvärde, dvs gruppera saker i en och samma grupp som behövs för att åstadkomma en verksamhets-output. Dvs fokus på vad och inte på hur! 

Förmågor är den mest generella abstraktionsnivån för att beskriva vad som behövs/ används för att utföra organisationens verksamhet. Dvs den beskriver inte processen, systemet, informationen, datat eller featuren i detalj.  I många fall används begreppet ”Epic”.

Best practise finns inte utan det är situationsbereonde. Men om frågan avser exempelvis användare och deras åtkomstbehörigheter så är det vanligt att använda en matrix precis som du skriver, med förklaringar i kolumnhuvudet, ytterligare kolumner är vanliga exempelvis Id, system/komponentnamn, giltighetsperiod, timestamp etc

Exempel: