INOM
EXAMENSARBETE DATATEKNIK, GRUNDNIVÅ, 15 HP
STOCKHOLM SVERIGE 2020,
Framställande av traditionell kravspecifikation inom agilt ramverk: är det möjligt?
Obtaining a traditional
requirements specification within agile frameworks - a feasible task?
ELLINOR SJÖSTRÖM NINA SEGELÖV
KTH
SKOLAN FÖR KEMI, BIOTEKNOLOGI OCH HÄLSA
Framställande av traditionell
kravspecifikation inom agilt ramverk:
är det möjligt?
Obtaining a traditional requirements specification within agile frameworks - a feasible task?
Ellinor Sjöström Nina Segelöv
Examensarbete inom Datateknik,
Grundnivå, 15 HP
Handledare på KTH: Anders Cajander Examinator: Ibrahim Orhan
TRITA-CBH-GRU-2020:051 KTH
Skolan för kemi, bioteknologi och hälsa 141 52, Huddinge, Sverige
Sammanfattning
Utveckling av produkter och tjänster har historiskt föregåtts av en tydlig
kravspecifikation över önskat innehåll, fastslagna kostnadsramar och tidsram för lansering. I modern tid har agila metoder successivt blivit standard inom
mjukvaruutveckling, metoder som inte kräver en explicit kravspecifikation.
Behovet av en traditionell kravspecifikation kan dock kvarstå eller ett alternativ till den, att bistå hantering av överordnad planering, varför en överbryggning mellan gammal och ny kravhantering kan behövas. En litteraturstudie gjordes av tre agila ramverk, innefattande en kartläggning av var krav förekommer i moderna
strukturer, och som skulle kunna motsvara en traditionell kravspecifikation.
Studien påvisade att övergripande krav tas fram innan ett projekt påbörjas för att sedan specificeras för enskilda användarscenarion, under utvecklingsprocessens gång. En aggregering av dessa skulle kunna motsvara en traditionell
kravspecifikation.
Skatteverket genomgår en organisatorisk omvandling till det agila ramverket Scaled Agile Framework (SAFe), varpå behov kring kravhantering och dess
dokumentation uppstått. Litteraturstudien tillsammans med modellering av deras nuvarande arbetssätt i mjukvaruverktygen Jira och Confluence, har jämförts med
“bästa praxis”. Jämförelsen visade att Skatteverket följer ramverkets struktur men att diskrepans förekommer med avseende på dokumentationsstruktur i verktygen, varpå förändringsförslag presenteras.
Nyckelord
Agila metoder, mjukvaruutveckling, kravspecifikation, SAFe, agila ramverk.
Abstract
Development of products and services has historically been preceded by a clear requirements specification of the desired features, a fixed margin of expenditure and a launch time frame. Nowadays, agile methods have gradually become
standard within software development and do not require an explicit requirements specification. However, the need for such a specification, or an alternative to it, may remain to assist in the management of overall planning and thereby function as a bridge between old and new requirements management. A literature study was conducted, reviewing three agile frameworks, including a mapping of where
product requirements exist in modern structures, which may correspond to a traditional requirements specification. The study demonstrated that overall
requirements are produced prior to the start of a project and later specified during the development process, to match individual user scenarios. By aggregating these, a requirements specification, corresponding to the traditional format, can be obtained.
The Swedish Tax Agency is undergoing an organizational transformation to the agile framework named Scaled Agile Framework (SAFe), whereupon a need for managing requirements and its documentation has arisen. The literature study, together with modeling of their current working methods in the software tools Jira and Confluence, has been compared with "best practice". The comparison showed that the agency follows the SAFe framework structure, but that discrepancy occur regarding the documentation structure used in the tools, whereupon amendments are presented.
Keywords
Agile methods, software development, requirements specification, SAFe, agile frameworks.
Förord
Den här rapporten är resultatet av vårt examensarbete inom
högskoleingenjörsprogrammet i datateknik, vid Kungliga Tekniska Högskolan.
Arbetet är utfört på uppdrag av Skatteverkets IT-avdelning, under vårterminen 2020 och motsvarar 15 högskolepoäng.
Vi vill tacka vår handledare Anders Cajander som fungerat som mentor och guide under den här resans gång. Du hjälpte oss att hålla rätt kurs och att hålla
motivationen uppe.
Vi vill också tacka Ylva Rudander, Marie Persson och Örjan Östervall på
Skatteverket för ert utmärkta bemötande, transparens och hjälpsamhet och för att ni givit oss en inblick i er IT-avdelnings arbetssätt.
Slutligen vill vi tacka Victor Sjöström och Elin Segelöv för ert stöd på hemmaplan.
Innehållsförteckning
Begreppslista ... 1
1 Inledning ... 4
1.1 Problemformulering ... 4
1.2 Målsättning ... 4
1.3 Avgränsningar ... 5
1.4 Författarnas bidrag till examensarbetet ... 5
2 Teori och bakgrund ... 6
2.1 Kravhantering enligt traditionella modeller ... 6
2.1.1 Vattenfallsmodellen ... 7
2.1.1.1 V-modellen ... 8
2.1.2 Certifiering av projektledare enligt traditionell modell ... 10
2.2 Agila utvecklingsmetoder ... 10
2.2.1 Det agila manifestet ... 10
2.2.2 Acceptanskriterier ... 11
2.2.3 Agil utvecklingsmetod inom myndigheter ... 11
2.3 Agila ramverk ... 13
2.3.1 Scaled Agile Framework, SAFe ... 13
2.3.1.1 Koncept ... 13
2.3.1.2 Arbetssätt och kravhantering ... 14
2.3.2 Disciplined Agile Delivery, DAD ... 18
2.3.2.1 Koncept ... 18
2.3.2.2 Arbetssätt och kravhantering ... 20
2.3.3 Large-Scale Scrum, LeSS ... 21
2.3.3.1 Koncept ... 21
2.3.3.2 Arbetssätt och kravhantering ... 23
2.3.3.2.1 Small LeSS ... 23
2.3.3.2.2 LeSS Huge ... 25
2.3.3.2.3 Definition of Done ... 25
3 Metoder och resultat ... 28
3.1 Överväganden och val av metod ... 28
3.1.1 Vald metod ... 28
3.1.2 Övervägda lösningsalternativ ... 28
3.2 Data från Skatteverket ... 29
3.2.1 Mjukvaruverktyg och versioner ... 29
3.2.2 Resultat från modellering av data från Skatteverket ... 30
3.2.2.1 Topografi och modellering ... 30
3.2.2.1.1 Confluence ... 31
3.2.2.1.2 Jira ... 34
3.3 Atlassians “bästa praxis” ... 37
3.3.1 Produktkravdokument ... 38
3.3.2 Skapa samförstånd mellan team ... 38
3.3.3 Resultat från modellering av Atlassians PRD-exempel ... 38
3.3.4 Fördelar och utmaningar med ett PRD ... 42
4 Analys och diskussion ... 44
4.1 Analys av resultat i förhållande till arbetets målsättningar ... 44
4.1.1 Undersökning av agila ramverk för att se var krav förekommer ... 44
4.1.2 Kunskap till Skatteverkets IT-avdelning ... 44
4.1.3 Sammanställning av agila krav till en traditionell kravspecifikation ... 45
4.2 Analys av resultat i förhållande till metod ... 46
4.2.1 Resultat i relation till vald metod ... 46
4.2.2 Resultat i relation till lösningsalternativ ... 47
4.3 Samhälleligt, ekonomiskt, miljömässigt och etiskt sammanhang ... 47
5 Slutsatser ... 50
5.1 Arbetets nytta och bidrag ... 50
5.2 Rekommendationer till uppdragsgivaren ... 50
5.3 Förslag till fortsatt arbete ... 52
Källförteckning ... 54
1
Begreppslista
Agila metoder: Samlingsnamn för strategier för mjukvaruutveckling, under vilken krav och lösningar utvecklas genom samarbete av självorganiserande och tvärfunktionella team och deras kund/slutanvändare. Produkter/tjänster tas fram iterativt under inkrementella faser med anpassningsbar planering, evolutionär utveckling, snabba leveranser samt snabbt och flexibelt svar på förändring.
Artefakt: Biprodukt som produceras under mjukvaruutveckling, t.ex. Story, logg eller användningsfall.
BDD: (eng. Behaviour Driven Development) En process för agil
mjukvaruutveckling som uppmuntrar till samarbete mellan utvecklare, testare och övriga intressenter där de tillsammans kommer överens om en produkts
beteenden.
BRUF: (eng. Big Requirements Up Front) Ett traditionellt förfarande där en detaljerad kravspecifikation tas fram tidigt i projektets livscykel.
Continuous Delivery: Kontinuerlig leverans. En process inom systemutveckling med målet att snabbt kunna leverera ny och/eller uppdaterad programvara.
DevOps: (eng. Development and Operations) En fras inom mjukvaruutveckling som används för att beskriva den agila relationen mellan utveckling och IT- verksamhet, med målet att förbättra relationen genom kommunikation och samarbete.
Etapp: En tidsbestämd arbetsfas inom agil mjukvaruutveckling under vilken en färdig, användbar produktversion skapas. En etapp pågår som mest i fyra veckor.
Go See: Tillbringa tid på platsen där arbete som ger kundvärde sker, för att se och förstå problem eller förbättringsmöjligheter. Informationen används vid beslut om lämpliga åtgärder utan att vara detaljstyrande. Arbetssättet står i motsats till indirekt information via rapportering och möten.
Inkrementell utveckling: En produkt byggs upp bit för bit över tid och släpps i en enda färdig version. Inom agil utveckling kombineras inkrementell och iterativ utveckling för att successivt släppa en färdig version av produkten, som förbättras över tid motsvarande nya versioner.
Iterativ utveckling: En produkts samtliga funktioner utvecklas parallellt, förbättras och förfinas successivt över tid och släpps i en enda färdig version när alla funktioner är fulländade. Inom agil utveckling kombineras iterativ och inkrementell utveckling för att successivt släppa en färdig version av produkten, som förbättras över tid motsvarande nya versioner.
Kravspecifikation/produktspecifikation: En lista med tydliga krav på
funktion som en beställare har på en produkt eller tjänst. Dessa sammanställs i ett dokument.
Lean: Ett arbetssätt vars syfte är att maximera kundvärde med så få resurser som möjligt. De centrala värderingarna är: eliminera slöseri, fokusera på lärande, skjut på åtagande, leverera snabbt, respektera människor och optimera helheten.
2
Lean-Agile: En kombination av antaganden, attityder, handlingar och övertygelser som har sitt ursprung i det agila manifestet och Lean.
Livscykel: En utvecklingsprocess för planering, konstruktion, testning och
driftsättning av ett IT-system. Vanligt förekommande faser är: kravanalys, design, utveckling och testning, implementation, dokumentation samt utvärdering.
Logg: En samling arbete som ska utföras men ännu ej är genomfört.
Produktchef: (eng. Product Manager) En arbetsroll som innebär ansvar för strategi, färdplan och funktionsdefinition för en produkt eller produktlinje.
Scrum: Ett ramverk som används inom agil projekthantering för utveckling och underhåll av komplexa produkter. Arbetssättet betonar daglig kommunikation och flexibel omprövning av planer som genomförs i korta, iterativa etapper av arbetet.
Scrum Master: En sammanhållande och coachande roll som stöttar och hjälper utvecklingsteamet att agera så autonomt och effektivt som möjligt.
Stop-and-Fix: Medlemmar från flera team går samman för att lösa uppkomna problem, innan de fortsätter med sina ordinarie arbetsuppgifter.
TDD: (eng. Test-driven development) En utvecklingsmetod med fokus på
automatiserad enhetstestning av varje programblock, följt av integrationstester och användartester. Testfallen skrivs före programkoden, som endast får checkas in när den godkänts av testerna.
Top-down-utveckling: Ett tillvägagångssätt för programutveckling där framsteg görs genom att definiera nödvändiga element i termer av mer grundläggande element. Tillvägagångssättet går från generell programdefinition till specifik implementation.
Vertical Slice: Ett tvärsnitt av de lager som bygger upp strukturen för t.ex.
mjukvara.
3
4
1 Inledning
Skatteverkets IT-avdelning är inne i en organisatorisk förändring, där det agila arbetssättet ska skalas upp för att omfatta hela utvecklingsverksamheten med syfte att effektivisera leveranserna av digitala lösningar. Förändringen medför behov av ett snabbare sätt att identifiera användarbehov och systemkrav.
1.1 Problemformulering
Utveckling av produkter eller tjänster har historiskt kunnat föregås av en tydlig kravspecifikation på vad leveransen kommer att innehålla, vad det kommer att kosta och när lanseringen beräknas ske. Under efterkrigstiden var
kravspecifikationen det avgörande underlaget för avtalsskrivning,
portföljhantering, utbildning av personal, utveckling av dokumentation och
planering av tjänst- eller produktlansering. Efter millennieskiftet har agila metoder successivt vunnit mark och är idag näst intill standard inom mjukvaruutveckling.
Dessa metoder kräver normalt inte en explicit kravspecifikation. Dock kan fortfarande behovet av en sådan förekomma, eller ett alternativ till den, för hantering av den överordnade planeringen av en tjänst eller produkt.
Skatteverket använder systemkrav för att beskriva ett IT-systems beteende och funktion och dessa tas vanligtvis fram i samråd mellan verksamhets- och
utvecklingsteam. Systemkraven dokumenteras i ett kravdokument som används för att skriftligen kommunicera verksamhetens behov till utvecklingsteamen vid
nyutveckling och förvaltning. Detta kan dock leda till kostsamma problem om kravställningen initialt var bristfällig eller missvisande.
1.2 Målsättning
Målsättningen för examensarbetet är en undersökning av populära agila ramverk för att se var krav, motsvarande en traditionell kravspecifikation, förekommer i de agila ramverken. Skatteverket har nyligen implementerat ramverket SAFe och målsättningen med arbetet är även att deras IT-avdelning ska få kunskap om hur en kravspecifikation kan tas fram i det nya ramverket.
Examensarbetet syftar till att besvara frågeställningen:
Kan krav vid agil mjukvaruutveckling identifieras och sammanställas till en motsvarande traditionell kravspecifikation? Om så är fallet, var hamnar då kraven i den agila strukturen?
5
1.3 Avgränsningar
Examensarbetet kommer beskriva vattenfallsmodellen, det agila manifestet och de agila ramverken SAFe, DAD och LeSS med fokus på hur dessa ramverk arbetar med kravhantering.
Examensarbetet kommer inte inkludera Skatteverkets förutsättningar eller det ramverk som användes innan övergången till det agila arbetssättet. Arbetet kommer inte gå igenom de lagkrav som myndigheter behöver förhålla sig till eller hur beslutsfattande inom dessa organisationer går till. Arbetet kommer heller inte att beröra hur kravanalys genomförs.
1.4 Författarnas bidrag till examensarbetet
Kapitel 3.2 utgör en modellering baserad på Skatteverkets aktuella
arbetsförfarande. Modelleringen är gjord av rapportens författare och baseras på information och bilder tillhandahållna av uppdragsgivaren.
Kapitel 3.3 utgör en modellering av “bästa praxis” för upprättande av ett kravdokument och bygger på rekommendationer från Atlassian Agile Coach.
Kapitel 5.2 utgör rekommendationer skrivna av rapportförfattarna och riktar sig till uppdragsgivaren. Rekommendationerna baseras på information från rapportens litteraturstudie i kombination med “bästa praxis” från kapitel 3.3 och är anpassade till Skatteverkets aktuella arbetsförfarande.
6
2 Teori och bakgrund
Kapitlet utgör rapportens litteraturstudie och inleds med en beskrivning av
vattenfallsmodellen och V-modellen, med fokus på kravhantering. Efterföljande del berör svårigheter som kan uppstå med de traditionella modellerna och följs av en introduktion till det agila manifestet. Därefter belyses de problem som kan uppstå när agila metoder appliceras inom myndigheter. Avslutningsvis kommer tre populära agila ramverk att beskrivas.
2.1 Kravhantering enligt traditionella modeller
Sedan 1950-talet har flera varianter av livscykeln för mjukvaruutveckling beskrivits, däribland vattenfallsmodellen [1].
En artikel från 1983 sammanfattar ett föredrag om mjukvaruutveckling som hölls år 1956 av Benington. I föredraget presenterar han slutsatser om att konstruktion av större programvara bör föregås av noggrann planering i flera faser. Han
beskriver Lincoln Laboratory:s förfarande, vilket utgjordes av nio olika faser, med utgångspunkt från en operationell plan. I den operationella fasen definieras en operationell plan som utgör systemets övergripande design. Planen förbereds av systemingenjörer i samråd med eventuella användare. I efterföljande faser, med planen som mall, förbereds en funktionsspecifikation som i sin tur lägger grunden för programspecifikationer vilka leder kodspecifikationer. Därefter kodas varje komponent och testas i flera nivåer. Sist görs en systemutvärdering som återknyter till den operationella planen (figur 2.1). Benington uttrycker att anledningen till att de lyckats relativt bra med processen, enligt hans mening, var på grund av att de strukturerade arbetet på ett ingenjörsmässigt sätt. Han uttrycker dock att det finns risker med att skriva specifikationer på ett Top-Down-manér eftersom det kan leda till att kännedom om viktiga detaljer kan missas. Han menar att en prototyp av systemet bör konstrueras innan projekt på stor skala startar. Med insikt i detaljer om mjukvaran kan bättre bedömning göras gällande förhållandet mellan kostnad, risk och prestanda [2].
7
Figur 2.1: Produktion av ett storskaligt system.
Det amerikanska försvarsdepartementet har anammat en Top-Down-modell för systemutveckling. En standard upprättades och krav samlades i en
kravspecifikation [3]. Deras standard från år 1985 var avsedd att användas som mall för att utarbeta specifikationer som var avsedda att användas vid design och upphandling av konfigurationsobjekt och tjänster som krävs för programspecifik tillämpning. Mjukvaruspecifikationen beskriver i detalj de krav för funktionalitet, gränssnitt, kvalitetsfaktorer samt speciella och kvalificerade krav som behövs för att designa, utveckla, testa, utvärdera och leverera den avsedda produkten [4].
2.1.1 Vattenfallsmodellen
En formell beskrivning av vattenfallsmodellen gjordes år 1970 av Royce, även om den inte nämndes vid det namnet [5]. Royces modell omnämns sex år senare som vattenfallsmodellen i en artikel om mjukvarukrav, av Bell och Thayer [6].
Royce beskriver behovet av fler faser än enbart analys och kodning när större programvara ska konstrueras. Den första modellen som visas i rapporten består av
8
sju faser i en nedåtgående trappformation likt ett vattenfall. Faserna är följande:
systemkrav, mjukvarukrav, analys, programdesign, kodning, testning och drift.
Han beskriver att faserna följer på varandra uppifrån och ner, men förespråkar att varje fas bör behandlas iterativt mellan föregående och efterföljande fas (figur 2.2).
Han betonar också problematiken som strukturen medför om det i testfasen upptäcks problem av en omfattning som leder till att stora förändringar behöver göras, t.ex. designen av systemet. Det kan i sin tur bryta mot kraven som tagits fram för mjukvaran, vilket kan bli mycket kostsamt och tidskrävande vid retroaktiva förändringar [5].
Figur 2.2: Vattenfallsmodellen på iterativ form.
2.1.1.1 V-modellen
V-modellen kan ses som en förlängning av vattenfallsmodellen [7], men istället för ett strikt linjärt flöde där krav, design och kod görs före testning av mjukvaran, tas systemdesign och testning fram parallellt. Modellen beskrivs av Rook i Software Engineering Journal, år 1986. Han utgår ifrån att varje modern metod på ett eller annat sätt innefattar faserna: projektinitialisering, kravspecifikation,
strukturdesign, detaljerad design, kodning och enhetstester, integrering och tillhörande tester, acceptanstester, underhåll, projektavslut samt utfasning av produkten. Det som genereras av en fas blir utgångspunkten för efterföljande fas.
En måttstock kan upprättas varsomhelst i processen och består av den information som definierar produkten vid det valda läget. Den kan användas för att kunna se
9
och kontrollera var projektet befinner sig i utvecklingsprocessen. När en fas
avslutas, utformas måttstocken för nästa fas med produktens aktuella tillstånd som utgångspunkt [8].
V-modellen kan illustreras i form av ett diagram som visar processens faser. I diagrammet presenteras processens faser av rektanglar och måttstockarna av ovaler. V-formationen illustrerar en symmetri mellan vänstersidans designdelar och högersidans konstruktionsdelar av produkten, genom successiva steg med integrering och testning. Varje designfas verifieras mot den föregående
måttstocken och varje integrationsfas verifieras mot motsvarande design eller måttstock på vänster sida av diagrammet (figur 2.3) [8].
Figur 2.3: V-diagram enligt Paul Rook som visar parallell framtagning av en produkts funktionalitet och tester.
Rook lyfter fram att moderna processers livscykler ger en bild av att varje fas är tydligt avgränsad och måste avslutas innan en ny kan inledas. Han menar att det dock i praktiken inte är realistiskt, framför allt vid mjukvaruutveckling på stor skala. I realiteten menar han att t.ex. efterforskning inför en kommande fas ofta behöver genomföras innan pågående fas kan avslutas. Han lyfter också
problematiken med att tydligt avgränsade faser gör att processen blir känslig för förändringar. En förändring sent i processen kan medföra att hela projektet behöver göras om [8].
10
Han skriver också att användarens angivna krav kan komma att ändras under processens gång och att mjukvaruutvecklingen kan behöva ske under iterativa former. Rook skriver att konceptet med att ha tydligt avgränsade faser som
representerar produktutvecklingens framsteg, snarare är något som en produktchef inför i syfte att hantera utvecklingens komplexitet och synliggöra hur projektet ligger till [8].
2.1.2 Certifiering av projektledare enligt traditionell modell
The Project Management Institute (PMI) har skrivit en guide som enligt författarna blivit en erkänd standard inom projektledning. Guiden beskriver
projektledningsprocesser, verktyg och tekniker som används för att driva ett projekt mot tillfredsställande resultat [9]. PMI tillhandahåller utvecklingsprogram och certifieringar inom projektledning, med guiden som utgångspunkt och är aktuellt än i dag [10, 11]. Guiden beskriver hur intressenters krav inom projekt definieras och dokumenteras tidigt i processen och används för att bestämma projektets kostnader, tidsbegränsning och kvalitetsplanering. Dokumentationen ska vara tillräckligt detaljerad för att kunna mätas när utvecklingen startat [9].
Förfarandet BRUF används här, vilket innebär att en detaljerad kravspecifikation tas fram tidigt i ett projekt.
2.2 Agila utvecklingsmetoder
Moe et al. skriver i ett konferensbidrag från 2006, att det är svårt att på förhand sätta en kravspecifikation inom mjukvaruutveckling. Skälen de anger är
svårigheten att förutse alla krav som kommer att ställas på ett system. Om viktiga krav saknas i specifikationen kan det leda till att mjukvaran inte resulterar i det som efterfrågades. Författarna skriver vidare att en låst och bristfällig
kravspecifikation kan begränsa mjukvaruutvecklares arbete och därmed riskera utveckling av en otillfredsställande produkt. De antyder att den risken minskar om kravspecifikationen är mer öppen [12].
2.2.1 Det agila manifestet
Det agila manifestet skrevs i början av 2001 av grundare från olika agila metoder. I historien kring manifestet tar författarna upp att fokus bör ligga på att göra det bästa för kunden och leverera delmål vid utlovade leveransdatum [13]. Det agila manifestet bygger på värderingar som prioriterar kundnöjdhet genom kontinuerlig leverans av värdefull programvara och där kunden har möjlighet att förändra sina krav, oavsett när de tillkommer under utvecklingsprocessen. Under projektet ska utvecklarna arbeta nära varandra, helst i samma lokaler och i ett arbetstempo som är konstant under hela utvecklingsprojektet. Utvecklingsteamet är självorganiserat och består av motiverade medarbetare som med rätt stöd och miljö har möjlighet
11
att genomföra projektet på ett tillfredsställande sätt. Författarna till manifestet skriver att de föredrar att utvecklingsteamet anpassar sig till förändringar framför att följa en fastställd plan samt att det görs genom ett tätt samarbete med kunden [14]. Det agila manifestet bygger på fyra värderingar [15]:
● Individer och interaktion är viktigare än processer och verktyg.
● Fungerande programvara är viktigare än omfattande dokumentation.
● Kundsamarbete är viktigare än kontraktsförhandlingar.
● Anpassning till förändring är viktigare än att följa en plan.
2.2.2 Acceptanskriterier
För att ett utvecklingsteam ska kunna leverera en lösning som möter de krav som ställts på produkten behövs en tydlig kommunikation mellan teamet och
beställaren. För att kunna fånga beställarens krav kan användarberättelser och acceptanskriterier användas, där acceptanskriterier är detaljerade villkor för en specifik användarberättelse som måste uppfyllas för att kunna klassificeras som färdig (eng. Done) [16, 17]. Koncist och tydligt skrivna acceptanskriterier
introducerar en gemensam överenskommelse av vad lösningen till produktens önskade funktionalitet ska uppfylla. Kriterierna ska vara skrivna innan utveckling startar, för att inte riskera att motsvara funktionalitet som redan hunnit utvecklas, istället för det som kunden vill ha [17, 18]. Ett acceptanskriterium kan antingen skrivas i form av ett förväntat händelseförlopp, en checklista eller ett eget definierat format [16, 18].
2.2.3 Agil utvecklingsmetod inom myndigheter
Av Riksrevisionens granskning från 2011 framgår att cirka 40% av alla IT-projekt hos IT-tunga myndigheter överskrider sin budget, i synnerhet gällande större och mer komplexa projekt. Överskriden budget kan orsakas av bristande planering, oklara mål eller krav alternativt brister i styrning och kontroll. Det kan leda till att leveranser inte lever upp till de krav som ställs på projektet samt att onödiga merkostnader tillkommer. Riksrevisionen menar att ledningen inom myndigheter generellt har svårt att ställa tydliga krav och mål för projekten, vilket leder till oklarheter rörande vad som ska utvecklas. Mjukvaruutveckling är viktig för dessa myndigheter och Riksrevisionens rekommendationer är att se till att det finns tillräcklig kompetens inom styrgruppen för att kunna göra adekvata
kravspecifikationer [19].
Jamieson et al. skriver i sitt konferensbidrag från 2005, att leverantörer av IT- system har begränsade möjligheter att bekräfta och fastställa de krav som ställs på
12
den produkt som ska utvecklas. Det kan leda till att det från kundens sida kan finnas dolda krav som inte uttryckts till leverantören men som är underförstådda för kunden. Sådana dolda krav på produkten kan dock framkomma tydligt i en iterativ utvecklingsprocess där kravbilden på produkten har möjlighet att förändras under processen. Författarna skriver även att krav som ställs på myndigheter kring offentliga upphandlingar försvårar möjligheten till förändringar i
kravspecifikationer. Orsaken är att det kräver nya offentliga upphandlingar vilket leder till förseningar i framtagningen av produkten och ökade kostnader eller nedläggning av projektet. Om man istället använder sig av en agil metodik kommer kunden i slutet av den sista iterationen att ha en produkt som åtminstone
tillgodoser några av de funktionella krav som ställs på produkten och som kan ge värde till organisationen. Jamieson et al. uttrycker att det under utvecklingen av komplexa IT-system oundvikligen kommer att ske förändringar i
kravspecifikationen och att ett agilt arbetssätt därmed lämpar sig bättre.
Författarna menar att kombinationen av en vattenfallsmodell för den offentliga upphandlingen med en agil utvecklingsmetod inte kommer att gynna varken kunden eller leverantören. Istället föreslår de att agila utvecklingsmetoder ska kombineras med en agil offentlig upphandling för att nå bäst resultat. Det ger kunden större kontroll över utvecklingsarbetet och möjligheten för flera leverantörer att utveckla olika komponenter [20].
Palmquist et al. illustrerar i sin artikel från 2013, hur en myndighet kan använda agila metoder för att specificera de dokument som ska användas i den offentliga upphandlingen av ett nytt IT-system. Författarna skriver att myndigheten börjar med att specificera deras vision med systemet som ska utvecklas och därefter sätter upp övergripande högnivåkrav i prioritetsordning. Därefter sätter leverantören tillsammans med myndigheten upp vilka mål som IT-systemet ska nå. I det skedet bör båda parter vara överens om att beskrivningen av systemets behov är
ofullständig och kommer att förändras över tid. Efter detta ska varje övergripande högnivå-krav förtydligas, vilket gör kraven lättare att förstå och kommunicera. Nya krav ska inte läggas till under pågående iteration men får läggas till i kravlistan över önskvärda funktionaliteter som ska implementeras [21].
Enligt Nuottila et al. i sin artikel från 2016, är det få myndigheter som implementerat en agil projektmetodik för mjukvaruutveckling inom sin organisation, men att intresset för att införa sådana metoder ökar. I studien framgår det att användning av agila metoder innebär en effektivare
mjukvaruutveckling vilket ledde till att den studerade organisationen fick mer utrymme att utveckla fler digitala tjänster. En svårighet med agilt arbete är balansgången mellan formellt uppställd dokumentation och informell
kommunikation, vilket enligt författarna beror på övergången från den traditionella vattenfallsmodellen till ett agilt arbetssätt. Det kan vara ett problem då offentlig
13
sektor traditionellt sett haft detaljerad dokumentation under hela
utvecklingsprocessen som ett framträdande krav och i många fall något som förväntas finnas [22].
2.3 Agila ramverk
De senaste årens mest populära agila metoder på större skala har varit flera och varierande. Några av de som återkommit är ramverken Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD) och Large-Scale Scrum (LeSS) [23-26].
2.3.1 Scaled Agile Framework, SAFe
SAFe grundades år 2011 av Leffingwell och Jemilo från Scaled Agile, Inc., och har släppts i fem versioner varav den senaste kom ut år 2020. Ramverket ska
underlätta formationen av ett Lean Enterprise och riktar sig till kommersiella företag, ideella föreningar samt statlig verksamhet, som vill omforma sin
organisation helt eller delvis. Idén handlar om att integrera principer, praxis och kompetenskrav inom Lean, agila metoder och DevOps, för att skapa agila
organisationer [27].
2.3.1.1 Koncept
Ramverket kan appliceras enligt olika standardiserade paketlösningar och sedan skräddarsys efter organisationens behov. En fullskalig version av SAFe bygger på implementationen av två systemtyper: ett hierarkisk operationellt system och ett nätverkssystem som fokuserar på organisationens kunder. Den senare av de två ämnar skapa konkurrenskraft, leverera kundnytta samt bygga upp en kvalitativ portfölj av produkter och lösningar. Nätverkets kärna bygger på sju kompetenskrav som täcker in både strategi och verkställning för att uppnå kundfokus [28]:
1. Ledarskap enligt Lean-Agile: Föregå med gott exempel genom empati, transparens, främja lärande av ny kunskap och att decentralisera beslutsfattande. Det innebär också att lägga en grund för ett växande
tankesätt istället för ett statiskt samt förmedla SAFe:s fyra kärnvärderingar:
linjering, inbyggd kvalitet, transparens och programutförande.
Organisatorisk förändring börjar i ledarskapet genom att förändra företagets kultur och arbetssätt.
2. Agil teknik och agila team: Samverkan mellan multifunktionella och
högpresterande team. Utveckling och framställning av produkter sker i Agile Release Trains (ART:s), som utgörs av flera agila team för att, i samråd med intressenter, utveckla och leverera en eller flera lösningar. ART:s arbetssätt ska ge en inbyggd kvalitet som syftar till att lägga grund för korta ledtider och därmed stärka organisationens konkurrenskraft.
14
3. Agil produktleverans: Tillvägagångssätt bestående av definition, konstruktion och utgivning av ett kontinuerligt flöde av produkter och tjänster till kunder och användare. Kompetenskravet består av tre
dimensioner: designtänkande och kundfokus, en fast utvecklingstakt och utgivning på begäran samt DevOps och Continuous Delivery.
4. Enterprise Solution Delivery: Beskriver hur Lean-Agile-principer och arbetssätt tillämpas för att specificera, utveckla, driftsätta, hantera och utveckla stora och sofistikerade applikationer, nätverk och system.
5. Lean portföljhantering: Berör det större perspektivet av vilka lösningar som bör skapas och varför. Det görs genom att se till att hela portföljen är
anpassad och finansierad, koordinera och stötta decentraliserat programutförande, samt övervaka utgifter, revision och efterlevnad.
6. Agil organisation: Underlättar snabbt gensvar på marknadens förändringar och görs genom: Lean affärsverksamhet såsom identifiering av
värdeströmmar för analys och förbättring av arbetsflödet, Lean-tankesätt hos personal och agila team samt agil strategi där företaget ständigt
sonderar marknaden efter förändringar samt omorganiserar agila team och ART:s för att bättre ta sig an nya möjligheter.
7. Continuous Learning Culture: Beskriver värderingar och tillämpningar som uppmuntrar individer såväl som hela organisationen, att kontinuerligt öka sin kunskap, kompetens, utförande och innovation.
Omvandlingen av en organisation till denna storskaliga agila apparat sker uppifrån och ner, med etablering av en kultur av förändringsbenägenhet som startar i
organisationens ledarskap. Omvandlingen sker i 12 steg som lägger en grund för agilt arbete på alla nivåer, och som sedan ska vidmakthållas och accelereras [28].
2.3.1.2 Arbetssätt och kravhantering
SAFe använder en kravmodell med syftet att få med fördelar från Lean och agil utveckling. Kravmodellen riktar sig till större organisationer eller mindre företag som bygger komplexa system. Modellen ämnar vara skalbar och demonstrera ett sätt att uttrycka systembeteenden genom bland annat Epics, Capabilities,
Features, Stories såväl som icke-funktionella krav (figur 2.4) [29].
15
Figur 2.4: Relation mellan en produktloggs artiklar, baserad på SAFe:s kravmodell. Loggen begränsas av icke-funktionella krav och dess artiklar definieras med bland annat acceptanskriterier.
Den traditionella kravspecifikationen ersätts inom SAFe till stor del med nya paradigm som baseras på utveckling enligt Lean-Agile. Detta illustreras i figur 2.4 och specificeras genom beskrivningar och acceptanskriterier av dess artefakter.
Modellen avser att hjälpa team att inte fokusera på en specifik lösning för tidigt samt undvika att välja ut specifika krav eller design i början av inlärningsprocessen.
Istället uppmanas de att lämna utrymme för en växande förståelse för avsikt [29].
En Epic utgör ett signifikant utvecklingsinitiativ och täcker in huvudsyftet i ett investeringsförslag som finns i organisationens portfölj. Den tillskrivs en hypotes, vilken testas experimentellt för att se om den anses den värd att investera i. Epics prioriteras och placeras i en portföljlogg, varifrån de portioneras ut på de ART:s som har kapacitet att ta emot dem. Därefter kan de agila teamen starta
utvecklingen, som inleds med att bryta ner en Epic i små, funktionella delar:
Business Features och Enabler Features. En Epic kan även uppstå lokalt inom ett ART och kan också brytas ner till Capabilities, vilket görs av Epic-ägaren i samråd med produktledning och systemarkitekter [30].
Capabilities understödjer definitionen och utvecklingen av Solutions, vilka utgör produkter, tjänster eller system som levereras till kund inom eller utanför
organisationen. Capabilities realiseras av flera ART:s och delas upp i flera Features
16
för att möjliggöra dess implementation inom en enskild Program Increment (PI).
Capabilities kan förutom att härstamma från en Epic också uppstå lokalt inom kontexten för en Solution [31].
En Feature liknar en Capability, men har lägre abstraktionsgrad och beskrivs med en fras och en Benefit Hypothesis. Hypotesen består av en föreslagen mätbar fördel för slutanvändare eller företag, samt acceptanskriterier (figur 2.5). En Feature läggs in och bearbetas i en programlogg, för att passa en enskild PI och därmed kunna leverera värde. Features innefattar ofta funktionalitet för flera
användarroller, varför formulering av dessa bör skilja sig från användarhistorier, som utgår från en roll [31].
Figur 2.5: Features med tillhörande Benefit Hypothesis.
Acceptanskriterier används för att avgöra om en implementation är korrekt och levererar värde (figur 2.6). Produktledningen ansvarar för vilka Features som accepteras och använder acceptanskriterier för att avgöra det. Acceptanskriterierna omvandlas ofta till acceptanstester. Features kan förutom att härstamma från en Capability eller Epic också uppstå lokalt inom ett ART [31].
Figur 2.6: Exempel på acceptanskriterier för en specifik Feature.
Features delas upp i Stories, vilka är de huvudsakliga artefakterna som används inom agil metodik, och kan även uppstå lokalt inom ett ART. De definierar
17
systembeteenden och är korta beskrivningar av avgränsade delar av önskad funktionalitet. En Story är skriven med användarens språkbruk och ur dennes perspektiv. Stories används av agila team under utvecklingen och varje Story ska kunna bli färdig under en enskild iteration. En Story ska möjliggöra
implementationen av en liten prototyp som motsvarar systemets beteende och stödjer inkrementell utveckling. Den innehåller minimal men tillräcklig
information för att både affärspersoner och tekniskt kunnig personal ska förstå principen. Detaljer inkluderas först när det är dags för implementation [32].
Acceptanskriterier och acceptanstester leder till att Stories kan bli mer specifika och förbättrar kvaliteten. Alla Stories samlas i en teamlogg och delas upp i två typer: Användarberättelser och Enabler Stories. Användarberättelser levererar funktionalitet direkt till slutanvändaren och Enabler Stories ger synlighet åt arbetsmoment som stöttar utforskande, arkitektur, infrastruktur och efterlevnad.
Användarberättelser beskriver funktionalitet och ersätter till stor del den traditionella kravspecifikationen. I vissa fall tjänar de också till att förklara och utveckla systembeteenden som registreras senare, för att t.ex. stödja framtida drift eller spårbarhet. Användarberättelser är värdebaserade eftersom de utgår från användarna och inte systemet. Formatet som rekommenderas är:
Som (användarroll), vill jag (aktivitet), för att (affärsvärde).
En användare kan förutom en person, representera en enhet eller ett system, t.ex.
en skrivare eller en server (figur 2.7) [32].
Figur 2.7: Exempel på en användarberättelse.
Enabler Stories, motsvarar sådant som kan behövas för att användarberättelser ska kunna implementeras. T.ex. kan arkitektur eller infrastruktur behöva utvecklas först, något som inte direkt kommer i kontakt med slutanvändaren och därför inte ingår i användarberättelser. Enabler Stories kan rent språkligt uttryckas i mer tekniska termer, till skillnad från användarberättelser (figur 2.8) [32].
18
Figur 2.8: Exempel på en Enabler Story.
För att utforma bra berättelser kan flera team samarbeta och använda
beteendedriven utveckling (BDD). Med hjälp av BDD definieras acceptanstester som tydligt beskriver varje berättelse och inkluderar flera perspektiv.
Produktägaren svarar för kundperspektivet, utvecklarna för teknisk
genomförbarhet och testarna för ett brett perspektiv med undantagsfall och
oväntade sätt som användaren kan interagera med systemet. På stor skala har varje berättelse förutom acceptanstester också enhetstester. Dessa underlättar för
automatiserad testning och testdriven utveckling (TDD) [32].
Icke-funktionella krav (Nonfunctional Requirements, NFR:s) förekommer också och definierar systemattribut såsom säkerhet, pålitlighet, prestanda,
förvaltningsbarhet, skalbarhet och användbarhet. NFR:s fungerar som restriktioner för systemdesignen och sträcker över flera loggar [33].
2.3.2 Disciplined Agile Delivery, DAD
DAD utvecklades av IBM [34] och är grunden inom Disciplined Agile vilket är ett kostnadsfritt och icke varumärkesskyddat ramverk inom agil metodik [35]. En undersökning av Ambler från 2010 visade att agila team i snitt lägger ner en månads arbete för projektinitialisering och ytterligare en månad för överlämning av en färdig produkt [36]. Ambler, som är en förespråkare av DAD, skriver att det i agila metoder saknas riktlinjer för hur förarbetet och efterarbetet i ett projekt bör gå till [34]. Det kan leda till att projektet består av en traditionell
projektinitaliseringsfas, en utvecklingsfas som följer Scrum för att sedan avslutas med en traditionell fas för driftsättning. Projekttypen kallas Water-Scrum-Fall och motsvarar en kombination av vattenfallsmodellen och Scrum[37], och riskerar enligt Ambler att öka leveranstiden, den totala projektkostnaden samt minskar sannolikheten att produkten uppfyller intressenternas förväntningar. Han menar att projekt som implementerar DAD minimerar risken att hamna i Water-Scrum- Fall [34].
2.3.2.1 Koncept
DAD utgår från Scrum men har stöd från andra metoder och ramverk som kan användas inom ett projekts livscykel. Förutom Scrum kan inslag från bland annat Agile Modeling, Extreme Programming, Unified Process, Kanban, Lean Software
19
Development, SAFe och LeSS användas. DAD gör det möjligt att använda dessa delar tillsammans och ger rekommendationer om när respektive metod kan användas [35].
Inom DAD finns olika alternativ för att skräddarsy en lösning som passar en enskild organisations specifika behov och förutsättningar. För att organisationen ska kunna fatta genomtänkta beslut kring implementationen av DAD, har
ramverket inkluderat både för- och nackdelar för de olika alternativen [35].
En av ramverkets nyckelaspekter kallas Enterprise Awareness och handlar om att organisationens befintliga system inte ska påverkas negativt av nyutvecklade lösningar och att utvecklingsteamen ska nyttja varandras funktionalitet och data.
Aspekten bidrar till ökad sannolikheten att nya tillgångar kan återanvändas av andra projekt, vilket sparar tid och ekonomiska resurser [34]. DAD har stöd för följande former av livscykler:
1. Agil: Baseras på Scrum och Extreme Programming där konstruktionsfasen består av tidsbegränsade etapper. En lista över arbetsuppgifter innehåller krav, icke-funktionell arbetsinformation och buggar. Livscykeln är
rekommenderad att användas om arbetet kan identifieras, prioriteras och tidsestimeras tidigt i projektet, vars slutmål primärt är att förbättra tidigare produkt eller implementera nya funktioner [38].
2. Lean: Använder sig av principer från Lean för att göra det möjligt för team att arbeta i eget tempo utan att behöva förhålla sig till fasta tidsramar.
Arbetsmetoden är lämplig att använda när arbetet är svårt att förutse och när det är möjligt att dela upp arbetsuppgifterna i små delar [39].
3. Continuous Delivery: Utvecklas från en av livscyklerna: agil eller Lean, med tillägget att arbetsmetoden även inkluderar användning av Continuous Delivery. Metoden lämpar sig för projekt där tidig leverans av delprodukter är viktigt för projektets intressenter [40, 41].
4. Den utforskande: Lämplig att använda när intressenter och utvecklingsteam är flexibla med projektets resultat. Metoden tillåter utvecklingsteamen att experimentera och utveckla projektidén baserat på de lärdomar som experimenten genererat [42].
5. Program: Passar större utvecklingsteam och organisationer som tillämpar agila metoder på stor skala. Projektet bör vara tydligt organiserat redan i uppstartsfasen [43].
20
DAD delar in ett projekts intressenter i två huvudgrupper: primära respektive stödjande roller. De primära rollerna används i alla typer av DAD-projekt oavsett skala, medan de stödjande rollerna endast används inom större projekt eller under en begränsad tidsperiod [35]. Ambler et al. skriver att det finns sex faktorer som kan vara till grund för att det agila arbetet behöver skalas upp: storleken på teamen, geografisk spridning av medarbetare, hur många organisationer som är delaktiga i ett projekt, lagar och förordningar, produktkomplexitet samt teknisk komplexitet [44]. För att kunna skala upp det agila arbetssättet föreslår Project Management Institute att det finns ett produktledningsteam. Teamet har till uppgift att utveckla visionen för organisationens portfölj, prioritera arbetet i organisationen, dela ut arbetsuppgifter till de olika utvecklingsteamen samt
hantera synkronisering av arbetet mellan dem. DAD använder fyra strategier för att organisera stora agila team: varje team ansvarar för en eller flera delsystem, varje team ansvarar för att implementera en Vertical Slice för ett visst funktionellt krav, varje team är uppdelat efter dess funktion samt utveckling av ett delsystem med hjälp av Open Source [45].
2.3.2.2 Arbetssätt och kravhantering
Inom DAD genomförs produktleverans i en cykel av tre faser: inledning, konstruktion och överlämning [46]. I ramverket beskrivs inledning som ett projekts initieringsfas där målet för fasen innefattar bland annat klargöring av problemet som ska lösas, identifiering av en tänkbar teknisk lösning samt att
övertyga berörda intressenter att projektet är värt att investera i [47, 48]. Ambler et al. skriver att en organisation under inledningsfasen, bör ta fram högnivåkrav för produkten och sedan specificera dessa först när det är nödvändigt, för att kunna fatta så genomtänkta beslut som möjligt [47].Fasen inkluderar också val av strategi för hur icke-funktionella krav ska fångas upp och hur länge den första fasen pågår beror bland annat på projektets komplexitet och intressenternas förståelse för projektets krav [47, 48]. Vid fasens avslut ska intressenternas frågor kring produktens funktionalitet, kostnad och leveransdatum vara besvarade [48].
Under konstruktionsfasen sker utvecklingsarbetet och de anser att projektet bör använda sig av korta utvecklingsetapper för att möjliggöra tidig feedback från kunden. De rekommenderar bland annat teamen att använda sig av
parprogrammering, låta intressenterna vara delaktiga i processen samt kontinuerlig interaktion och driftsättning [46, 49]. Under överlämningsfasen lanseras produkten på marknaden eller går in i produktion [46, 50]. Fasens mål är att lösningen håller marknadsstandard samt att intressenterna är redo för leverans [50].
21
Project Management Institute skriver att DAD är mer flexibelt och lättare att skala upp än andra agila metoder. Orsaken de anger är att ramverket är måldrivet och fokuserar på att adressera förändrade behov hos intressenterna, under
konstruktionen. Genom att använda ett måldiagram för att visualisera den initiala omfattningen av den produkt som ska utvecklas, är det möjligt att också fånga upp icke-funktionella krav [35]. Diagrammets ovala former representerar processmål och rektanglar motsvarar beslutspunkter, där varje punkt hänvisar till en lista med lösningsalternativ. Listan med tekniker kan vara i prioritetsordning [51].
2.3.3 Large-Scale Scrum, LeSS
LeSS grundades år 2005 av Larman och Vodde. En efterfrågan om hur agil utveckling kan genomföras på stor skala hade uppstått efter att Larman år 2002 skrivit en bok om agil och iterativ utveckling. Det ledde till ett samarbete mellan honom, Vodde och ett flertal klienter, för att arbeta fram hur uppskalning av agil utveckling skulle kunna göras. Idag har deras två ramverk Smaller LeSS och LeSS Huge, implementerats hos företag över hela världen [52].
2.3.3.1 Koncept
LeSS är Scrum applicerat på ett större antal team som arbetar tillsammans på samma produkt. Ramverket syftar till att på ett så enkelt sätt som möjligt, på stor skala applicera principer, syften och element från Scrum-metodiken. LeSS kan tillämpas på många typer av team som arbetar tillsammans mot det gemensamma målet att vid slutet av varje gemensam etapp, leverera en gemensam produkt.
Produkten som tas fram är en komplett och kundfokuserad lösning [52].
Inom LeSS betonas att det inte förekommer någon bästa praxis för
produktutveckling utan att en praxis endast är lämplig utifrån ett specifikt
sammanhang. Syftet med synsättet är att främja en kultur av lärande, engagemang och kontinuerlig förbättring, istället för rädsla att ifrågasätta något som anses perfekt [52].
LeSS tillhandahåller guider och experiment som företag kan använda för att lättare komma igång med ramverket. Den övergripande bilden av hur LeSS introduceras utgörs av principer, ramverk, guider och experiment [52]. Principerna definierar ramverket och utgår från antingen Small LeSS eller LeSS Huge [53]. Ramverkets nyckelelement definieras av en uppsättning regler, som kan användas som
utgångspunkt för att komma igång och ligga till grund för att stötta empirisk processkontroll och fokus på hela produkten. Guiderna utgörs av experiment samt en uppsättning tips på hur reglerna kan användas. Experimenten är
situationsbaserade där varje företag rekommenderas att endast använda de experiment som passar för den enskilda organisationen [52].
22 LeSS utgår från tio principer [52]:
1. Storskalig Scrum är Scrum: LeSS är inte en förbättrad variant av Scrum utan ett sätt att tillämpa Scrum:s principer, regler, grunddrag och syfte på en större skala.
2. Transparens: Uppnås genom korta arbetscykler, samarbete och gemensamma definitioner.
3. Mer med mindre: Färre arbetsroller för att främja tydlig ansvarsfördelning.
Få artefakter för att minska avstånd mellan team och kunder. Färre processer för att främja bättre inlärning och ägandeskap mellan team och processer.
4. Fokus på hela produkten: Kunden vill ha en sammanhängande produkt med värdefull funktionalitet. Det åstadkoms med en gemensam produktlogg, produktägare, etapper och levererbar produkt.
5. Kundfokus: Fokus på att förstå kundens problem och lösa dessa. Identifiera vad kunden anser värdefullt respektive onödigt. Minska kundens upplevelse av väntetid och etablera god återkoppling. Varje medarbetare är införstådd i hur dennes arbete på daglig basis relaterar till och gagnar kunden.
6. Kontinuerlig förbättring mot perfektion: Strävan efter att kontinuerligt skapa och leverera en produkt som saknar defekter, glädjer kunden samt förbättrar liv och miljö, till en nära obefintlig kostnad. En uppmaning om att genomföra förbättringsexperiment för att uppnå det.
7. Lean-tänkande: Skapa ett organisationssystem vars grund utgörs av de två pelarna: respekt för människor och tankesättet att kontinuerlig förbättring sker genom att utmana status quo. Utöver det tillkommer synsättet att chefer agerar lärare som tillämpar och lär ut Lean-tänkande, genomför förbättringar, främjar Stop-and-Fix och utövar Go See.
8. Systemtänkande: Se, förstå och optimera systemet som helhet och använda systemmodellering för att utforska systemdynamiken. Undvik fokus på effektivitet eller produktivitet hos individer eller enskilda team eftersom det kan leda till suboptimering.
9. Empirisk processkontroll: Inspektera och anpassa produkter, processer, beteenden, organisationsdesign och praxis för att kontinuerligt utvecklas.
Gör det på ett sätt som passar organisationen, istället för färdiga mallar eller
23 koncept.
10. Köteori: Förstå hur system som innefattar köer uppför sig i FoU-domänen och tillämpa dessa insikter på hantering av köernas storlek, avgränsning för pågående arbete, multitasking och variation.
2.3.3.2 Arbetssätt och kravhantering
Inom LeSS förespråkas decentralisering inom en organisation vilket innebär få arbetsroller för att minska komplexitet och förbättra överblicken av produkten.
Därför anser grundarna att det inte behövs någon portföljhantering för att försäkra sig om att teamen arbetar med produkter som ger högt värde [54]. Istället har produktägaren en central roll och befinner sig mellan beställaren och
utvecklingsteamen. Produktägarens roll innefattar att specificera beställarens behov och önskemål om produkten och baserat på det, utforma en produktlogg vars innehåll prioriteras och specificeras [55].
LeSS i sin ursprungliga form, också benämnd Small LeSS, lämpar sig bäst för organisationer med mellan två till åtta utvecklingsteam. Ett större antal kan
innebära problem såsom att produktägaren får svårt att överblicka hela produkten, balansera externt respektive internt fokus eller att produktloggen blir för stor för en enskild person att hantera. I sådana fall rekommenderas LeSS Huge. Båda
varianterna av ramverket har följande gemensamt [52]:
● En produktägare och en produktlogg.
● En gemensam etapp för alla team.
● En leveransklar produktdel vid etappens slut.
2.3.3.2.1 Small LeSS
Med produktloggen som utgångspunkt kan en initial etapplanering (etapplanering 1), inledas, vilken genomförs gemensamt av produktägaren och alla team eller teamrepresentanter under planeringen. Tillsammans väljer de ut de artiklar från produktloggen som varje team ska arbeta med under kommande etapp. Resterande etapplanering görs inom respektive team, eller vid behov av flera samverkande team under en andra etapplanering (etapplanering 2), där de utformar sin
etapplogg. Efter planeringarna genomför varje team löpande kodning, testning och integrering av sina respektive artiklar. Genom att integrera testning och
implementation istället för att utföra dessa i separata faser, blir varje del redo för driftsättning på kortare tid. Ett mål som eftersträvas är att ständigt förbättra
24
Definition of Done så att en leveransklar produkt levereras varje etapp, eller oftare om möjligt. Varje etapp avslutas med en etappgranskning som utgör en gemensam genomgång av resultaten där produktägare, användare och andra intressenter samt alla team deltar. Efter varje avslutad etapp hålls retrospektivmöten, först på
teamnivå och sedan på en övergripande nivå med produktägare, Scrum Masters, platschef och representanter från teamen. De går igenom frågor som rör samarbete mellan teamen eller systemövergripande problem, exempelvis koordinering. De delar också med sig av information och genomför förbättringsexperiment. Se figur 2.9 för en sammanfattande vy av en etapp [52].
Figur 2.9: Överblick av en etapp inom small LeSS. Produktägare (PO) och team väljer ut artiklar från produktloggen som ska utvecklas under etappen, som avslutas med en leveransklar produkt.
Koordinering på teamnivå görs genom dagliga stå-upp-möten och kan även inkludera deltagare från samarbetande team. Vid behov kan möten hållas där alla team eller representanter från dem är med, i syfte att titta på övergripande problem eller frågor. Problem såsom systembuggar löses direkt med Stop-and-Fix och
ansvaret för koordineringen av lösningsmetoden roterar mellan teamen varje etapp. Förädling av produktloggen görs av produktägaren genom prioritering av artiklar, samt av teamen genom klargörande av respektive artiklar i samråd med kunden och andra intressenter [52].
Om en artikel är stor och komplex kan ett team bryta ut en bit av det och börja arbeta med. Syftet är att genom praktiskt arbete förstå komplexiteten och dra lärdomar som kan användas i det fortsatta arbetet med den övergripande
uppgiften. Det här tillvägagångssättet syftar till att vara effektivare än att vänta på en potentiellt lång analytisk utredning av komplexiteten innan arbetet får påbörjas [52].
25
2.3.3.2.2 LeSS Huge
Med LeSS Huge kommer följande tillägg:
● Kravområde: Ett kundområde som hanteras av mellan fyra till åtta team.
Området är dynamiskt och kan både växa och krympa med antalet team och medarbetare från andra områden. Områdena fungerar som enskilt
implementerade Smaller LeSS-ramverk som arbetar parallellt i en
gemensam etapp (figur 2.10). I produktloggen tillkommer ett attribut som anger vilket kravområde en artikel tillhör.
● Produktägare för ett kundområde: Fokuserar på ett enskilt kundområde och dess produktlogg vilken är en vy av den gemensamma produktloggen, filtrerad efter område. Rollen innehas ofta av områdets produktchef, som utöver produktägare också har en stöttande funktion.
● Team för ett funktionsspecifikt kundområde: Arbetar inom ett kravområde med tillhörande produktägare. Att arbeta inom ett område liknas vid att arbeta i Small LeSS-ramverket [52].
Figur 2.10: En etapp, enligt LeSS Huge-ramverket. Produktägare (PO) och områdesproduktägarna (APO) väljer ut artiklar från produktloggen som ska utvecklas av teamen inom respektive område
under etappen. Etappen avslutas med en gemensam leveransklar produkt.
2.3.3.2.3 Definition of Done
För att få en samstämmighet kring när en arbetsuppgift är färdig och minska sannolikheten för ofärdigt arbete under produktutvecklingen, tillämpar LeSS Definition of Done (DoD). Definitionen formar den lista av kriterier som mjukvaran ska uppfylla för varje enskild artikel i produktloggen, enligt
överenskommelse mellan team och produktägare. För att artikeln ska definieras som färdig, bryter teamen ner den i arbetsuppgifter som samtliga behöver
färdigställas. DoD tas fram i ett första utkast i samband med en workshop för den
26
initiala förädlingen av produktloggen, innan första etappen. Listan tas fram genom följande två steg:
● Definiera de aktiviteter som behövs för att kunna leverera produkten till slutkund.
● Besluta om vilka aktiviteter som kan genomföras i respektive etapp.
Definitionen förfinas sedan allt eftersom, av respektive team. DoD gäller enhetligt för alla artiklar i produktloggen och ska inte förväxlas med acceptanskriterier, vilka är specifika krav som ställs på enskilda artiklar [56].
27
28
3 Metoder och resultat
Kapitlet inleds med att presentera arbetets valda metod och de alternativa
lösningar som övervägdes. Därefter följer resultat från modelleringar som gjorts av data från Skatteverket respektive Atlassians “bästa praxis”.
3.1 Överväganden och val av metod
Nedan presenteras arbetets valda metod tillsammans med argument varför metoden valdes. Därefter följer en diskussion om alternativa lösningar som övervägdes, med argument varför dessa alternativ valdes bort.
3.1.1 Vald metod
För att besvara rapportens frågeställning och skapa förutsättningar för att uppnå rapportens mål, gjordes en litteraturstudie i ämnet innefattande en kartläggning av krav inom agila strukturer, samt egen undersökning. Undersökningen inbegrep att ta reda på vilka stöd som finns för kravhantering enligt agila metoder, i moderna mjukvaruverktyg, genom att handgripligen modellera ett projekt i sådana verktyg.
Syftet var att förena befintliga verktyg med “bästa praxis” för kravhantering i agila ramverk, med litteraturstudien som utgångspunkt.
Metodvalet skapade förutsättningar för att dels kombinera praktiskt arbete i moderna mjukvaruverktyg med god praxis från litteraturstudien och dels forma modellen för att passa en bredare grupp såväl som Skatteverkets verktygsval.
Utförandet skulle dock behöva genomföras på en liten skala för att rymmas inom examensarbetets tidsram, något som skulle kunna medföra risken för svårighet att skala upp exemplet, samt svårigheter med att både få modellen att bli applicerbar på en större grupp samtidigt som det passar Skatteverkets omorganisation.
3.1.2 Övervägda lösningsalternativ
Alternativa metoder som övervägdes var att kombinera litteraturstudien med:
1. Intervjuer med representanter från företag eller organisationer som
genomfört en övergång från traditionellt till agilt arbetssätt, i syfte att se var kravspecifikationen representeras och dokumenteras i den nya strukturen.
2. Intervjuer med leverantörer av moderna verktyg som används för
dokumentation och hantering av agil mjukvaruutveckling, i syfte att få insikt i deras uppfattning om hur verktygen bör användas för att få en
överbryggning mellan krav enligt en traditionell respektive agil process.
29
Det första alternativet skulle medföra utmaningen att erhålla den typ av företagsinformation som behövs för att besvara rapportens frågeställning och målsättningar, samt att de val som gjorts riskerar att vara subjektiva för det
enskilda företaget. Resultatet skulle därmed bli svårare att applicera på en bredare grupp eller på det agila ramverk som Skatteverket använder, varför alternativet förkastades.
Det andra alternativet skulle kunna medföra en risk att lösningen som presenteras är subjektiv och inte följer en praxis som kan förankras i litteraturstudien, varför även denna förkastades.
3.2 Data från Skatteverket
Information om Skatteverkets organisatoriska omvandling och arbetssätt har erhållits genom e-post och telefonsamtal med representanter från två av deras ART:s. Informationen har innefattat olika exempel på deras användning av Jira och Confluence, och utgjort rapportens data som modellerats för att representera
Skatteverkets arbetssätt.
Skatteverkets organisatoriska omvandling till ramverket SAFe är fortfarande pågående och har gjorts stegvis, där ett ART implementerats inledningsvis och övriga ART:s följer successivt. SAFe förespråkar decentraliserat beslutsfattande kring vilka Features och komponenter som ska implementeras under ett
inkrement, genom självbestämmande team. Inom Skatteverkets IT-avdelning har därav olika ART:s, valt olika sätt för t.ex. hur de använder länkar mellan
Confluence och Jira, format på användarberättelser, eller förekomst av acceptanskriterier på Story-nivå och i så fall var de dokumenteras. Detta har medfört en viss intern diskrepans och därmed också ett behov av struktur kring kravhantering och vilken nivå av kravdokumentation som ska sparas för
eftervärlden.
Följande avsnitt redogör för hur Skatteverkets nuvarande dokumentation och stöd för utvecklingsprocessen görs med hjälp av mjukvaruverktyg.
3.2.1 Mjukvaruverktyg och versioner
Atlassian är en leverantör av mjukvaruverktyg för företag [57]. Verktyget Jira ger stöd och struktur åt processen under mjukvaruutveckling [58] och Confluence är ett verktyg för dokumentation, planering och kommunikation [59]. Eftersom Confluence och Jira är populära verktyg bland många företag som arbetar med mjukvaruutveckling [58, 59] samt att även Skatteverket använder dessa verktyg, valdes de för modellering i syfte att återskapa Skatteverkets arbetssätt. Bilder som visas i 3.2.2 är tagna på modelleringar som gjorts m.h.a. Atlassians molntjänster
30
för dessa verktyg, verksamma under april och maj 2020, och är baserade på Skatteverkets egna dokument och ärenden gjorda i Confluence version 7.2.1 och Jira version 8.3.4. Modellering i verktygsmiljöerna ses också i avsnitt 3.3 vid beskrivning av “bästa praxis” vid kravhantering.
För att ge stöd åt agil utveckling på stor skala har Atlassian utvecklat en plattform med specifik funktionalitet för flera stora ramverk, däribland SAFe 5.0, DAD och LeSS [60]. För SAFe, som Skatteverket använder, finns stöd för olika
konfigurationer såsom portföljhantering, Lean budgets och stöd för specifika
arbetsroller som medföljer ramverket [61]. På nivån för portföljhantering finns bl.a.
funktionalitet för att överblicka den mängd tid som spenderats på varje Epic, Feature och Story [62] och för produktledningen är det möjligt att få en komplett bild över det som utvecklas från Epic-nivå ner till underuppgiftsnivå för Stories [63].
3.2.2 Resultat från modellering av data från Skatteverket
Nedan presenteras resultaten från den modellering som gjordes av den data som erhölls från Skatteverket.
3.2.2.1 Topografi och modellering
Agila metoder, däribland SAFe, förespråkar att ett agilt ramverk eller agil metod justeras för att passa den enskilda organisationen. Nedan illustreras hur
Skatteverket bryter ner Epics till Stories (figur 3.1), där acceptanskriterier förekommer på Feature- samt Story-nivå. Epics hanteras av produktledningen (eng. Product Management, PM) och fungerar som en sammanhållande funktion för Features och Enablers. En Epic involverar oftast ett eller två team och tar ett eller två Program Increments (PI) att implementera. PM och produktägaren bryter ner Epics till Features eller Enablers stegvis tills de ryms inom ett PI och kan hanteras av ett enskilt team. Dessa bryts sedan ner till Stories som tar en iteration att implementera. Features, Enablers och Stories kan även uppstå lokalt vid behov.
