Revision av agila utvecklingsprocesser

Den 9 maj höll jag och Magnus Juvas, VD på Solidify, en presentation på Transcendent Groups GRC-dag kring hur IT-utvecklingen förändrats under de senaste decennierna mot mer agila utvecklingsmetoder och vilken påverkan det får på vårt sätt att granska systemutvecklingsprocessen. Nedan följer en summering av vår presentation.

Agila utvecklingsmetoder

De allra flesta verksamheter har idag infört agila utvecklingsmetoder i någon utsträckning. Detta bedömer vi som positivt då de agila utvecklingsmetoderna har förutsättningar att åstadkomma en mycket högre grad av intern kontroll än traditionella vattenfallsmetoder. De agila metoderna har en högre ändringsfrekvens vilket medför lägre risk per produktionssättning och minskar diskrepansen mellan vad som beställts och vad som levereras. Det finns även ofta en ökad transparens inom utvecklingsteamet vilket minskar risken för både olovliga och felaktiga förändringar. Tvärfunktionella team med helhetsansvar inom olika produktområden ger också bättre möjlighet till löpande prioriteringar och säkerställande av verksamhetsnytta.

Det uppstår dock svårigheter när man försöker anamma traditionella kontroll- och granskningsmetoder på de nya agila arbetssätten. Gamla vattenfallsmetoder med tydliga faser och kontrollpunkter för utveckling, testning och produktionssättning går inte att applicera på exempelvis ett utvecklingsteam där dessa faser går in i varandra i korta iterationer med dagliga eller veckovisa produktionssättningar. I en revision behöver vi därför utvärdera hur alternativa kontroller har byggts in i utvecklingsmetodiken.

Nya kontrollmål för revisionen

Vi kan konstatera att flera klassiska kontrollmål kvarstår men andra har minskat i vikt eller är inte längre aktuella vid agil utveckling. Nedan redogör jag för de, enligt min åsikt, mest väsentliga skillnaderna:

1. Struktur, ansvar och mandat för inhämtande av ändringsbehov och prioritering av systemutvecklingsaktiviteter blir ett viktigt kontrollmoment i agil utveckling och behöver få större fokus i revisionen. Produktägarrollen som ofta tar prioriteringsbesluten får en central funktion och rollen behöver vara tydligt definierad och förankrad.
2. Formella styrdokument för utvecklingsprocessen får mindre fokus inom agil utveckling. Det betyder dock inte att man får göra hur man vill! Det behöver finnas övergripande kriterier och överenskomna arbetssätt i de enskilda teamen. Begreppet ”Definition of done” används ofta för att definiera vad som ska vara utfört innan något flyttas till produktionsmiljö. Exempel på kriterier kan vara att genomföra och dokumentera en riskanalys, obligatorisk kodgranskning av någon annan i teamet, spårbarhet från genomförda tester och formellt godkännande inför produktionssättning.
3. Till följd av de korta utvecklingscyklerna kräver agil utveckling en hög grad av automatiska kvalitetskontroller/tester för att effektivt hantera riskerna. För att utvärdera den interna kontrollen behöver det verifieras att automatiserade tester hanterar majoriteten av riskerna. Begreppet ”code coverage” används ofta för att definiera hur stor del av källkoden som täcks in i de automatiserade testerna. De automatiserade testverktygen har generellt bra spårbarhet men de behöver ofta kompletteras med manuella tester och där bör det också finnas spårbarhet.
4. De automatiserade testerna bör även omfatta IT-säkerhetsrisker och att det finns testverktyg som letar efter kända sårbarheter i koden. Vid vissa förändringar och speciellt för webexponerade applikationer kan det även vara nödvändigt med ett separat penetrationstest inför produktionssättning som fokuserar på att den nya koden är säker och inte medför några sårbarheter, men också att ny kod inte påverkar annan programkod i negativ bemärkelse.
5. Formella godkännanden inför produktionssättning är viktigt även i agil utveckling men då produktionssättningar ibland görs på daglig basis fungerar det inte att ha månadsvisa CAB-möten (Change Advisory Board) eller motsvarande för godkännande enligt klassisk metodik. Det kan istället vara tillräckligt att godkännande sker av produktägare (eller annan utsedd) via knapptryckning i mobilen. Viktigt här är att konsekvensanalysen av förändringen gjorts redan i designfasen.

Utmaningar

Det tar vanligtvis många år att inför agila utvecklingsprocesser som fungerar effektivt genom hela verksamheten. Ofta börjar IT-avdelningen att jobba agilt och därefter brukar detta anammas av övriga verksamhetsprocesser. Detta innebär att kringliggande processer såsom projektstyrning, systemförvaltning, budgetering och resurstilldelning inte alltid fungerar i god samverkan med den agila IT-utvecklingen. Vid revision av utvecklingsprocessen är det därför viktigt att utvärdera hur samverkan mellan dessa processer fungerar.

Inom samma organisation kan det också finnas skiftande mognadsnivåer vad gäller agil utveckling. Olika system kan därmed inom samma verksamhet behöva granskas på olika sätt som en följd av användandet av olika utvecklingsmetodiker och varierande mognadsgrader.

Med tanke på ovan utmaningar vill jag avslutningsvis poängtera vikten av att den som utför granskningar av utvecklingsprocessen lägger ner tillräckligt med tid i planeringsarbetet för att sätta sig in i de arbetssätt som tillämpas och de kringliggande processer som påverkar detta arbete.

Författare: Magnus Thyllman