Del I – Tillämpa agila metoder för att samla in krav

Inledning

Processen med att samla in kraven för IT-produkter är en riktig mardröm för projektledare och stör den normala driftsättningen av produkten. Denna process äger rum i början av hela produktutvecklingsprojektet, när idén om vad som ska skapas liknar det mytomspunna Loch Ness-monstret: ingen har sett det, men alla känner sig tvungna att säga något om det. De fulla effekterna av det som görs i detta tidiga skede kommer att synas först när produkten faktiskt tas i bruk. Processen för att definiera kraven har dock en stark inverkan på alla steg i programvaruutvecklingsprocessen, dvs. även på analysfasen, arkitekturdesignfasen, kodningen och testningen. Det är viktigt att betona att nyckelrollen i denna process spelas av personer som är verkliga experter inom sina områden. Men de vet inte nödvändigtvis något om programvaruutveckling och även om de vet hur man definierar sina egna krav har de en begränsad förståelse för tillgänglig teknik, systemarkitekturer eller andra aspekter som har en enorm inverkan på slutresultatet.

Problem som uppstod under insamlingen av krav

Problem med två språk.

Det språk som används av affärsintressenter för att beskriva sina krav är ofta naturligt, överflödigt, tvetydigt och oprecist. Författaren kan vara övertygad om att formuleringen av kraven är helt tydlig, men de andra mottagarna eller till och med den grupp av intressenter som författaren representerar kanske inte är det. För att inte tala om utvecklarna som måste översätta sådana krav till kod.

Leverantör Krav Perspektivfråga

En annan aspekt av kravdefinitionen är det perspektiv ur vilket den görs. När intressenterna beskriver kraven använder de sitt eget perspektiv, eftersom andra perspektiv kan vara okända för dem, inte helt förstådda eller avsiktligt utelämnade av någon anledning.

Problem med dolda antaganden

Kraven skapas inte bara utifrån intressentens perspektiv utan också med vissa dolda antaganden. Sådana dolda antaganden är strikt kopplade till uppfattningen av hela affärsverkligheten och av de affärsprocesser som produkten är tänkt att stödja. Dessa antaganden kan vara nära korrelerade med beställarnas affärsperspektiv, deras tro på de lösningar som för närvarande tillämpas och som enligt utvärderarens uppfattning fungerar eller bör fungera på ett förutsägbart sätt, och endast korrelerade med författarens subjektiva åsikt eller bedömning, inte nödvändigtvis med verkligheten. Det som är viktigt att betona här är de viktigaste egenskaperna hos dessa dolda övertygelser och antaganden: de är icke-verbala och helt omedvetna. De är så uppenbara att de inte är värda någon diskussion. Någon kanske säger: ”Jag är mycket förvånad över att någon inte vet det”. Eftersom sådana dolda antaganden inte verbaliseras kommer kraven sannolikt att vara tvetydiga eller till och med missförstådda av andra.

Dessutom bör kognitiva fel som generaliseringar, förenklingar och förvrängningar av den upplevda verkligheten också beaktas. Felen uppstår i samband med uppfattningen av verkligheten, inklusive affärsverkligheten, och återspeglas i beskrivningarna av denna verklighet. En felaktig verklighetsuppfattning återspeglas således i kraven. Kraven måste därför verifieras och korrigeras på ett kontrollerat sätt.

Abstraktion av IT-systemfråga

Slutligen kommer IT-systemens inneboende egenskaper in i bilden. System är abstrakta. Det innebär att de inte har någon tydlig fysisk representation, i motsats till mekaniska strukturer eller byggnader. De kan inte enkelt ritas eller visualiseras. Det finns inte heller någon etablerad och allmänt accepterad eller allmänt använd metod för att beskriva dem. Det finns inga tydliga måttenheter. Det görs vissa försök att standardisera de beskrivningsmetoder som rekommenderas av standardiseringsorganisationer eller som utvecklats av de mest erkända privata företagen i IT-miljön. Några av exemplen på grafiska notationssystem är BPMN/BMPL, BPEL eller allmänna systemmodelleringsspråk som UML. Dessa system och språk är dock främst kända och förstådda av analytikerna. Resten av deltagarna i IT-produktutvecklingsprocessen kan inte alltid förstå på ett korrekt och felfritt sätt vad ett visst schema visar. Notationer betyder något annat än vad en teknisk ritning för ingenjörsarbete gör. Notationerna försöker bara göra samma sak för design av IT-produkter som den tekniska ritningen för ingenjörs- eller byggnadsdesign gör. Notationer är bara ett metaforiskt sätt att presentera den abstrakta verkligheten och de processer som implementeras i IT-systemet. Grafiska notationer är till stor hjälp i kravdefinitionsfasen (som man säger – en bild säger mer än 1024 ord), men samtidigt har de grafiska representationerna av abstrakta begrepp sina begränsningar och måste förstås och kontrolleras. För att skapa en bra uppsättning krav räcker det inte att bara använda den grafiska notationen av den. Dessutom kan man, eller till och med bör, använda sig av bästa praxis enligt ISO/IEC/IEEE 29148:2011 ”Systems and software engineering – Requirements engineering” eller ISO/IEC 25000 ”System and Software Quality Requirements and Evaluation”. Det är värt att komma ihåg att de endast är god praxis och rekommendationer som bör antas varje gång för ett specifikt projekt i din organisation. De utgör dock en kunskapsbas för analytiker eller chefer på efterfrågesidan som kan hjälpa till att skapa en specifik process för programvaruutveckling för en viss programvara i en organisation.

Hantering av processen för att definiera krav på ett agilt sätt

Processen för att definiera krav bör kunna hantera de företeelser som hindrar att en lista med bra krav upprättas. Oavsett vilken metod för IT-projektledning som tillämpas och oavsett om det är en vattenfallsmetod, en inkrementell utveckling eller en agil metod, bör kravutvecklingsprocessen vara iterativ och interaktiv och baseras på Demings schema (Plan-Do-Check-Act) och agila metoder för mjukvaruutveckling. Det bör betonas att det inte handlar om agil hantering av en hel IT-projektleverans, utan snarare om att använda vissa agila metodkomponenter för att skapa en bra uppsättning krav.

Här är de viktigaste delarna i processen för att skapa krav:

• Engagemang från ett tidigt skede i arbetet med krav, inte bara från de intressenter som lämnar in krav, utan även från medlemmarna i implementeringsteamet;

• Cyklisk analys och utveckling av inlämnade krav – utförs i cykler med fast längd där analysen av de allmänna kraven görs successivt;

• Förbättring och urval av kraven och skapande av en lista med krav som är redo för implementering.

Den allmänna idén bakom detta tillvägagångssätt kan sammanfattas i denna fängslande mening: Ta kontroll över kraven innan kraven tar kontroll över dig.

För att ta kontroll över denna komplexa, iterativa process kan du dra nytta av den agila projektmetoden och anpassa den agila projektledningsmodellen (APM-modellen) till hanteringen av hela IT-programvaruutvecklingen, och endast tillämpa den på kravhanteringsprocessen.

För vårt ändamål kan vi kalla den anpassade APM-modellen för kravhantering för IIRM-modellen (Interactive and Iterative Requirements Management Model). Den körs i cykler med fast längd, som varar från en vecka till några veckor, och består av följande steg: Vision, Planering av krav, Utveckling av krav. Vad som bör göras under varje steg beskrivs nedan.

Vision

Innan vi börjar fokusera på visionen är det viktigt att identifiera rätt grupp av intressenter och att kartlägga deras roller i RACI-matrisen (Responsible-Accountable-Consulted-Informed). Ansvarsfördelningen gör det möjligt för implementeringsteamet att kontrollera intressenternas ansvarsområden och i slutändan leverera de bästa resultaten, enligt intressenternas förväntningar.

När visionen skapas bör intressenterna (och i synnerhet produktägaren) fokusera på att etablera den första allmänna ramen som gör det möjligt för alla att förstå kärnan och de viktigaste funktionerna i projektet. I det här skedet kan kravens identifieringsnivå vara allmän, men de viktigaste funktionella elementen i den slutliga lösningen bör redan vara identifierade.

Den allmänna ramen för en vision omfattar:

• Affärsmål, dvs. vilka affärsprocesser produkten ska stödja, vad produkten ska underlätta eller tillhandahålla inom ramen för dessa processer;

• Mål för produktkvalitet, dvs. projektets omfattning, tillgänglighet och lyhördhet, antalet kunder som betjänas, antalet anställda som arbetar samtidigt, antalet samtidiga operationer;

• Designbegränsningar definieras i termer av tid och resurser som krävs för att genomföra projektet. Vi talar i första hand om finansiella resurser. Naturligtvis kan man också peka på icke-finansiella resurser så länge de är nödvändiga för att genomföra projektet och bör identifieras i detta skede, till exempel specifik kunskap eller teknik eller licens.

Planering av krav

I det här skedet får intressenterna möjlighet att rapportera sina krav.

Det är viktigt att understryka att kravlistan inte behöver vara komplett, kraven behöver inte vara detaljerade utan kan med fördel vara allmänt hållna i detta skede. Det är önskvärt att de krav som rapporteras är kopplade till de affärsprocesser som nämns i Visionen.

Det är lämpligt att kravet definieras i ett enkelt interaktionsdiagram med schemat aktion-reaktion-effekt. En åtgärd i en rolldefinierad process i systemet – en reaktion från systemet. Låt oss ge ett enkelt exempel för att förtydliga:

• roll i processen: en säljare

• min handling inom min systemroll: Jag lägger till en ny kund i systemet
• Systemets svar (valfritt): Systemet bekräftar för mig att en klient har lagts till i systemet.

I det här skedet definierar vi inte vad kunden menar här, vilka egenskaper den har eller vad ”add”-åtgärden innebär i det här sammanhanget. Detta kommer att göras i samband med kravutvecklingen.

Kravplanen skapar en uppsättning produktbackloggar som kommer att förfinas och definieras ytterligare i nästa steg i vår IIRM-modell.

Utveckling av krav

Utvecklingen av krav börjar med analysen av dem. I kravanalysen är alla visualiseringsmetoder som härrör från UML eller BPMN/BPML eller BPEL-notationer till hjälp. Grafiska krav för processer, dataflöden, maskintillstånd, arkitektur, kommer inte bara att definiera kraven bättre – de kommer också att göra det möjligt för dem att förstå deras struktur, att upptäcka deras verkliga komplexitet och att förstå de underliggande antagandena bakom de rigorösa krav som de har förberett. Det viktigaste i det här skedet är inte så mycket precisionen i definitionen av kraven, utan snarare att de förstås fullt ut av rapportörerna, analytikerna och representanterna för implementeringsteamet. Direkt kommunikation, interaktiva sessioner, nära samarbete mellan multidisciplinära team, engagerade intressenter och implementeringsteamet (eller dess representanter) är avgörande för ett bra resultat i detta och kommande steg.

Ju mer vattenfallsmetoden tillämpas på hela IT-projektet, desto mer exakt bör kraven beskrivas. Om vårt arbetssätt är mer agilt är det bara första steget, och detaljnivån anpassas till det aktuella arbetssättet.

Resultatet av vårt analytiska arbete kommer att leda till att vi omformulerar, delar upp, slår samman, grupperar eller till och med eliminerar de inkommande kraven. Ett av resultaten kommer också att vara att fastställa hur viktiga kraven är för hela produkten mot bakgrund av visionen och tidpunkten för implementeringen av kraven baserat på den inledande bedömningen.

Om kravet uppfyller vissa parametrar kan det bedömas enligt ett visst kriterium och så småningom flyttas till driftsättningsfasen eller till nästa steg, om vår metodik är mer agil. Nu har vi två möjliga vägar.

Uppdatering …

Om kravet inte uppfyller bedömningskriterierna bör det uppdateras i den utsträckning som det kan förbättras under en given cykel och kvarstå i processen för vidareutveckling under nästa processcykel. I detta skede kan vissa riktlinjer skapas för uppdatering av visionen eller projektramen.

… eller vidarebefordran av kravet till driftsättningsfasen

Kravet går in i driftsättningsfasen om det är korrekt definierat under IIRM-modellcykeln. Kriterierna för korrekt definition av krav kan beskrivas med ett minnesord: ”INVEST”, som föreslagits av Bill Wake och som ursprungligen endast användes för agila projekt. Kriterierna kan också tillämpas med vissa ändringar i andra typer av projekt.

INVEST är ett mnemoniskt begrepp som beskriver egenskaperna hos väldefinierade krav. De enskilda bokstäverna i akronymen bryts ut enligt följande:

I – Oberoende – kraven ska inte vara beroende av andra krav eller så ska dessa beroenden vara så begränsade som möjligt. Med beroende menas här att arbetet med ett visst krav måste påbörjas för att arbetet med ett annat krav ska kunna slutföras. Det är viktigt att minimera de inbördes beroendena, inte nödvändigtvis reducera dem till noll, utan snarare hålla sig till regeln att ju mindre desto bättre i det här fallet.

N – Negotiable – dvs. rätt beskrivningsnivå beroende på designmetodiken för hela produktproduktionen; en beskrivning som gör att du kan förstå vad en viss berättelse är. I agila metoder förstås att genomföra en funktion i samband med beskrivningsflexibilitet. Vi definierar det nödvändiga minimumet eftersom kravet kommer att fortsätta att leva i programutvecklingscykeln och en viss flexibilitet är nödvändig. Kravet måste beskrivas på ett sådant sätt att det kan modifieras i senare skeden. I projekt av mer vattenfallskaraktär innebär denna funktion att beskrivningen av kravet bör utformas tillräckligt exakt och att dess utseende bör vara välgrundat, vilket betyder ordentligt förankrat i visionen, i affärsprocesserna. Alla system och beskrivningar av de processer som kravet är kopplat till, och de som har framkommit under kravanalysfasen, ökar förhandlingsbarheten för ett sådant krav.

V – Värdefullt – Kravet ska ge ett värde för intressenterna, uttryckt i termer av det värde som intressenterna själva bedömer. Oftast är värdet den förväntade affärsnyttan i form av kassaflöden från kunder, ledningar som minskar genomförandet av affärsprocesser eller minskade driftskostnader.

E – Uppskattningsbart – kravet bör definieras så att implementeringsteamet kan utvärdera kostnaden för implementeringen av ett sådant krav. En sammanhängande bedömning av implementeringstiden, komplexiteten och antalet resurser som behövs för implementeringsteamet kan vara delar av uppskattningsmåtten.

S – Sizable – det handlar om att kraven ska vara rätt skalbara och lämpliga för implementeringsfasen. Kraven bör definieras i en liknande skala av implementeringstid eller implementeringsansträngning av driftsättningsteamet. I mer agila metoder kallas denna dimension ”liten”, vilket innebär att den ska passa in i en enhet för iterativ implementering, till exempel i en sprint. Medvetenhet om kravens omfattning gör det möjligt att definiera kraven på rätt sätt och underlättar de framtida aktiviteterna under driftsättningen av produkten, planeringsfasen för produktversionen eller resursallokeringen och testningen.

T – Testable – Den sista dimensionen av ett krav är dess testbarhet, vilket innebär att kravet har tydliga kriterier för att avgöra om det givna kravet faktiskt har implementerats.

Om kraven uppfyller INVEST-kriterierna kan vi anta att kraven har definierats korrekt i detta skede av processen. Detta innebär inte att arbetet med kraven är avslutat, särskilt inte när vi hanterar projektet med hjälp av agila metoder. Det innebär dock att kravet har förståtts, beskrivits korrekt, är tillräckligt stort och att det värde och den arbetsbelastning som krävs för implementeringen är känd.

Sammanfattning

Agila metoder är en nyckel för att samla in krav oavsett om hela projektet leds på traditionellt sätt, enligt kaskadmetoden eller enligt agila ramverk. När vi definierar krav går vi från någon form av kaos eller informationsentropi till en strukturerad ordning. För att göra det på rätt sätt och undvika många fällor är det nödvändigt att göra det på ett interaktivt sätt. Erfarenheter från agila ramverk är ovärderliga för att samla in kravprocessen.

Den agila metoden hjälper dock till att börja arbeta med kraven på rätt sätt, och en mycket viktig aspekt är att ha bra kriterier för att veta när arbetet ska avbrytas. INVEST-metoden är till stor hjälp för detta ändamål. Detta heuristiska stöd är det sista steget i processen med att definiera och samla in kravdefinitioner och leder oss till en lista med väldefinierade krav som ska säkerställas i vårt system.