1. No category

1(4)
Framgångsrik agil kravhantering
Johan Berg
Bertil Danared
I många organisationer är intresset stort för att ta till
sig alltmer av agila systemutvecklingsmetoder. Men att
okritiskt ersätta tidigare arbetssätt med nya är oftast
inte rätt väg. Framgångsfaktorn för att få en kvalitativ
funktionsleverans, oavsett systemutvecklingsmodell,
är en gedigen och balanserad kravspecifikation (som
kombinerar det bästa med det agila och det redan
inarbetade sättet att arbeta) tillsammans med en väl
definierad beställarfunktion.
Förhållningssätten i de agila metoderna medför emellertid
att kunderna lätt förespeglas att det interna arbetet i form
av tydligt dokumenterade processer och kravställning inte
är av samma vikt som tidigare eller i jämförelse med de
arbetssätt som återfinns i de mer traditionella metoderna.
Det beror i sin tur på att kunderna okritiskt tolkar in de
värderingar som återfinns inom de agila metoderna.
Introduktion
I vårt tidigare white paper, ”Fem steg till en modern ITorganisation”, menar vi att IT-organisationerna i större
utsträckning måste tillgodogöra sig dessa mer lättrörliga
metoder och etablera en sund leveransmodell för att kunna
åstadkomma det som sätts upp på dagordningen. Ett
införande måste dock ske kritiskt, där befintliga, fungerande
och grundläggande arbetssätt, metoder och värderingar
prövas mot de nya. I ett optimalt läge anpassas det redan
etablerade och kompletteras med det nya.
Agilt är fortfarande ett modeord och används flitigt i
säljleden hos många IT-leverantörer. De talar om
färdigheter inom framförallt systemutvecklingsmetodiker
som SCRUM och XP, men också om kunskap och
erfarenheter i LEAN, Kanban och DevOps.
SCRUM och XP är de två mest utbredda agila metoderna.
Flera andra varianter har utvecklats ur dessa men alla utgår
ifrån de agila värderingarna eller det agila manifestet. Det
som gemensamt präglar dem är det iterativa och interaktiva
arbetssättet i korta cykler med fokus att snabbt leverera och
anpassa efter kundens behov. Metoderna har, för att
åstadkomma högsta möjliga produktivitet, skalat bort
mycket av de byråkratiska och tröga momenten som
återfinns i den mer traditionella metodiken.
Det agila manifestet (vilket är ett symboliskt manifest med
gemensamt formulerade idéer från representanter för de
större utvecklingsmetodikerna, framtaget 2001):




Värderar individer och interaktion framför processer
och verktyg.
Värderar samarbete med kunden framför att förhandla
om kontrakt.
Värderar att reagera på förändringar framför att följa en
uppgjord plan.
Värderar fungerande mjukvara framför omfattande
dokumentation.
Beställande IT-funktioner tilltalas av att de agila metoderna,
åtminstone i teorin, erbjuder möjligheter till snabbare och
mer pricksäkra leveranser både tids- och kvalitetsmässigt,
större flexibilitet och ett mer adaptivt beteende.
Införande av agil metodik
Som kund måste man vara väl medveten om vilket ansvar
man har, vilka förutsättningar och vilken kunskap som krävs
som beställare vid tillämpning av en mer agil metodik. Det
är avgörande faktorer om man skall lyckas få en effekt av
ett leverantörssamarbete i en mer agil eller lättrörlig miljö.
Tittar man på det agila manifestet så syftar det till en annan
typ av arbets- eller samarbetsform. De agila metoderna har
en betydligt högre grad av interaktion, iteration, kontinuitet,
kort cykeltid och förmåga till snabb anpassning jämfört med
de traditionella. Dessa är mer diskreta i sin karaktär, dvs
arbete och leverans sker mer sekventiellt, vid få och
förutbestämda tidpunkter, över en längre cykel och med ett
mer konstant innehåll.
Enligt vår erfarenhet är en framgångsfaktor att inte okritiskt
införa en agil metodik utan att ta hänsyn till tidigare
arbetssätt, kulturell mognad, kompetens med mera. Vårt
budskap är att komplettera befintligt som fungerar väl,
snarare än att ersätta, med nya eller förändrade arbetssätt
och metodiker.
2(4)
Beställarfunktionen
En av de viktigaste rollerna i en agil miljö är den som i den agila begreppsfloran kallas
produktägare. Han/hon förväntas inneha en god kunskap och förståelse om hur verksamheten
bedrivs, vilka krav som ställs och hur IT-systemen skall byggas upp och/eller fungera, för att
på bästa sätt bidra till verksamhetens förmåga. Produktägaren har det yttersta ansvaret för
beslut i frågor som rör prioritering av krav från verksamheten, förväntat innehåll i olika
leveranser samt storleken på budgetutrymmet.
Beställarrollen i de agila metoderna representeras således av produktägaren. Men i de flesta
fall sitter kunden med en traditionell besluts- och attesttrappa och rollen som beställare
innebär ett ansvar att formellt godkänna och fatta beslut om leveranser. Beställaren innehar
oftast en chefsposition i linjen och har vanligtvis ett budget- och personalansvar. För att trygga
framdriften i olika initiativ och projekt tillsätts projektledare och projektresurser från
linjeverksamheten men de har i princip inget mandat att fatta beslut i frågor som rör
verksamhet, budget eller tidplan.
En viktig framgångsfaktor är således att etablera en väl definierad beställarfunktion. Den skall
inrymma motsvarande roller och ansvar som återfinns hos produktägaren i den agila världen.
Det är därför av största vikt att lägga tid på att arbeta med att definiera rollerna i en
beställarfunktion utifrån detta.
Kravspecifikationen
Oavsett vilken metodik eller kombination av metodiker som används har kravspecifikationens
kvalitet en avgörande betydelse för hur bra en lösning blir i slutänden. Naturligtvis beror
kvaliteten på en rad andra faktorer som t ex leverantörens förmåga att omsätta krav till en
lösning inkluderande förmågan hos involverade nyckelpersoner att ur alla aspekter få till en
bra lösning (men det går vi djupare in på i annat sammanhang). Men sett till kunden så är
utformningen av en god kravspecifikation en faktor som i hög grad kan påverkas och styras
eftersom det är en inre faktor (leverantören betraktas som en yttre faktor i det här fallet).
Arbetet med kravspecifikation, masterdata och informationsmodell (de två sista belyses inte
här) är grundläggande i all systemutveckling oberoende av form eller metodik. Att verka fram
en bra kravspecifikation är ett hantverk i sig och är betingat med ett flertal utmaningar. Den
största eller vanligast förekommande är på vilken nivå krav skall specificeras. På en
övergripande nivå är det oftast ganska lätt att definiera vad lösningen skall bestå av och det
går ganska fort att vaska fram krav. Dessvärre lämnar ett sådant förfarande många
frågetecken som måste rätas ut efter hand och det är otydligt vilka krav och förväntningar
lösningen skall uppfylla. Risken är uppenbar att resultatet blir något annat än vad kunden tänkt
sig. Med en altför detaljerad nivå så tappar man lätt bort helheten, man riskerar till slut att gå
vilse i all detaljrikedom och sammanhanget blir svårt att se. Man riskerar också att frångå sin
beställarroll och börja göra systemleverantörens arbetsuppgifter, med främst tidsmässiga
konsekvenser som följd.
Balanserad kravspecifikation
En balanserad kravspecifikation innebär att man först och främst sätter kraven i ett
sammanhang. I sammanhanget skall det framgå:

Processtillhörighet, dvs vilken process eller del av process kravet eller kraven avser.

Krav på funktion/funktioner i ett system en viss typ av användare vill komma åt, men också
vilket värde de ger, så kallad ”user story”.

En bild, så kallad ”wire frame” som återger var en funktion/funktioner placeras i förhållande
till andra.
© 2015 Sourcing Professionals Nordic AB
3(4)

Vilken ingående information som krävs för att en funktion/funktioner skall fungera.

Vilken utgående information som en funktion/funktioner resulterar i.

Andra värdeadderande krav såsom prestanda, svarstider etcetera.
Här följer ett exempel på hur krav kan formuleras på en balanserad nivå och satt i ett
sammanhang, se bild.
<Funktion> anges och kan motsvara ett eller flera processteg i en process eller delprocess.
1. Process eller delprocess i vilka krav på funktionalitet ställs, det vill säga där en framtida
lösning är tänkt att fungera.
2. Processteget bryts ned i olika användarfall/user stories som ligger till grund för
systemutveckling och test.
3. Här anges krav på vilka steg som skall kunna utföras. Krav ställs på layout och disposition.
4. Indata och/eller förutsättningar specificeras. Här anges vilken information (data) som
matas in. Inmatningssätt anges, det vill säga manuell alternativt automatisk populering
från föregående processteg eller system.
5. Utdata specificeras, det vill säga vilken information (data) som skall skapas eller
vidareförädlas och vara tillgängligt för efterföljande processteg eller system.
6. Behörighet och roller (verksamhetsroller) definieras.
7. Icke-funktionella krav specificeras, till exempel vilken UI-standard/ramverk (User
Interface) som skall gälla. Tillgänglighetskrav och prestandakrav etcetera anges.
© 2015 Sourcing Professionals Nordic AB
4(4)
Slutsats
En tydlig slutsats är att oavsett metodik eller kombination av metodik måste kunden alltid
genomföra ett gediget kravarbete. Där skall krav sättas in i ett sammanhang på en rimlig nivå.
Det kommer i sin tur att spara tid, efterlämna färre frågetecken, vara lättare att justera eller
ändra och resultera i en lösning som motsvarar det som efterfrågas.
På så vis kan den agila metodiken hos en leverantör möta ett mer vanligt och traditionellt
förfarande hos en kund. En balanserad kravspecifikation kombinerar det bästa i det agila med
det efterfrågade i det traditionella.
I den agila världen är produktägaren överst i näringskedjan men i kundens värld fattas
besluten ofta i andra strukturer. Avsaknad av produktägarroll eller motsvarande beslutsroll
hos kunden medför då en svårighet att få en bra utväxling vid tillämpningen av de agila
metoderna.
Lösningen finns dock nära till hands och kan överbrygga ett flertal av de problem och
utmaningar som kan uppstå när leverantörens erbjudande om ett mer agilt arbetssätt möter
kundens mer traditionella och diskreta arbetssätt eller förmåga.
Att säkerställa en balanserad kravspecifikation tillsammans med en väl definierad
beställarfunktion blir den grund som behövs för att generera en kvalitativ funktionsleverans,
oavsett systemutvecklingsmodell.
Om Sourcing Professionals Nordic
Kontakt
Sourcing Professionals Nordic tillhandahåller oberoende och professionell
rådgivning
inom
sourcing
och
outsourcing,
affärsoch
verksamhetsutveckling, transformation och supply chain management.
Det innebär att vi bistår våra kunder med hur de kan utveckla sin
verksamhet relaterat till sourcing (både in- och outsourcing), vad det
ställer för krav på ledning och styrning samt att vi bistår med att
upphandla rätt leverantör och teknologi för att utveckla våra kunders
konkurrenskraft.
Om du vill veta mer om Sourcing Professionals Nordic
är du välkommen.
info@spnord.se
www.spnord.se
Copyright © Sourcing Professionals Nordic 2015.
Copyright © Sourcing Professionals Nordic 2015. All rights reserved. The prior written permission of Sourcing Professionals Nordic
is required to reproduce all or any part of this document, in any form whether physical or electronic, for any purpose.
© 2015 Sourcing Professionals Nordic AB