DANMARKS NATIONALBANK LEVER AGIL UDVIKLING STADIG I DET VILDE VESTEN Sikkerhed og Revision 2013 Martin Falk-Hansen & Svend M
Er sikkerhed og revision et problem i agil udvikling? Og i givet fald hvorfor? Samtale med sidemanden i 5 min 5 min opsamling.
Risikoreduktion 1 af 3 I kraft af at et agilt team laver konstante leverancer, med 2-4 ugers mellemrum, som derefter kan testes og kommenteres af slutbrugerne mindskes risikoen for at teamet efter måneders arbejde leverer et produkt der ikke kan benyttes eller ikke virker efter hensigten. Da agil udvikling tillader løbende prioriteringer, så længe det ikke påvirker den igangværende iteration, vil en dygtig produktejer sikre at de mest værdifulde eller mest risikofyldte produkter (potentielle showstoppere) bliver udviklet i starten af projektet.
Risikoreduktion 2 af 3 Anvendes Test Driven Development skriver udviklerne software test før man begynder udviklingen af produktet. Med anvendelse af moderne integrations metoder sikrer man at en udvikler aldrig utilsigtet gemmer kode der ikke virker som tilsigtet.
Risikoreduktion 3 af 3 (Gentages i Transparens) Der måles løbende på teamets performance, derved kan teamet (eller ledelsen) håndtere eventuelle fald i produktionen; typisk skyldes det udskiftning af teammedlemmer, dårligt arbejdsmiljø eller andre forstyrrende elementer. Man bør også være opmærksom på eventuelle stigninger i produktionen om disse skyldes en god forbedring af teamets performance, eller at teamet arbejder på så højt et niveau at der er risici for stress. Et godt agilt team har en jævn til let stigende performance, så man kan forudsige og planlægge det arbejde teamet kan udføre således at teamet og organisationen ved hvor meget de kan levere.
Øget kontrol over et projekt En dygtig produktejer kan mindske risikoen ved konstant at prioritere de produkter der skal udvikles giver mest mulig værdi for organisationen samt sikre at der ikke udvikles overflødige eller urentable. En Produktejer kan til enhver tid stoppe et projekt, for eksempel hvis det udviklede produkt viser sig at være af en sådan beskaffenhed at det er klar til produktion. Eller det viser sig at projektet ikke giver den tilsigtede RIO.
Gennemsigtighed 1 af 2 Den LEAN kultur som Agil udvikling stammer fra, har en term der hedder Gemba (staven også Genba ) eller at gå Gemba. Det betyder at man går derhen hvor den faktiske produktion sker. Dette er en integreret del af den Agile proces, hvor alle kan møde op til de daglige møder det er dog kun udviklerne der må tale. I revisions sammenhæng kan revisorne deltage på et helt sprint, se på de produkter/ stories der er bliver produceret og hvordan bliver viden delt på de daglige møder. Bliver der både talt om hvad man laver og hvilke problemer man har, eller er det bare et udstillingsvindue for de mest frembrusende bliver der ageret som et team eller som individer?
Gennemsigtighed 2 af 2 (Gentages i Risikoreduktion) Der måles løbende på teamets performance, derved kan ledelsen eller teamet tage hånd om eventuelle fald i produktionen, som for eksempel kunne skyldes udskiftning af teammedlemmer, arbejdsmiljø eller forstyrrende elementer. Man bør også være opmærksom på stigning i produktionen skyldes en god forbedring af teamets performance, eller at teamet arbejder på så højt et niveau at der er risici for stress. Et godt agilt team har en jævn til let stigende performance, så man kan forudsige og planlægge det arbejde teamet kan udføre. Alle teams anvender de samme simple visuelle oversigter (burn down, Scrum boards).
Proces forbedringer indbygget 1 af 2 Ledelsen/teamet kan aktivt arbejde med et teams velocity (performance). I kraft af at burndown chartet som giver udtryk for et teams performance er tilgængeligt for alle, vil en faldende velocity naturligt give anledning til spørgsmål, enten fra ledelsen eller indenfor teamet selv. Et godt agilt team vil typisk tage et fald eller stigning i velocity op til retrospektiverne og diskutere årsagerne til dette. Change management er en naturlig del af en agil proces og derfor billigt. Interessenter kan derfor normalt anmode om ændringer til de efterfølgende iterationer.
Proces forbedringer indbygget 2 af 2 Ved mindre ydre omstændigheder kræver det, er der intet overhead for teamet at der sker ændringer i de produkter der skal udvikles. Da teamet er vant til at release et nyt produkt, og arbejder med TDD vi en omkostning ved ændringer i et allerede færdigt produkt ofte være forbundet med meget færre omkostninger en traditionelle vandfaldsprodukter.
Samarbejde med et agilt team 1 af 3 Definiton of done er et vigtigt aspekt i agil udvikling. Der skal være enighed i teamet og ledelsen hvilke krav der stilles til et færdigt produkt - inden for dokumentation, sikkerhed, review og test. Intet teammedlem må erklære et produkt eller story som færdig før de aftalte krav er opfyldt. Definiton of Done er ikke statisk men det kræver enighed i teamet og ledelsen hvis denne definition ændres. I revisionsøjemed er det interessant at have Definition of Done med i mente når et team medlem flytter et produkt/story som værende afsluttet.
Samarbejde med et agilt team 2 af 3 Hvis en revisionsproces kræver at teamet skal bruge ekstra tid til at tilfredsstille revisionen, skal det planlægges ind i en iteration på niveau med andre produkter/stories. Denne process skal foregå i samarbejde med produktejeren. Det kan være interessant for en revisor at få indblik i hvad der foregår på retrospektiver. Dog vil et retrospektiv normalt ikke give det fulde billede/udbytte hvis det bliver overvåget af revision eller ledelse. Nogle teams udvælger emner eller handlingspunkter fra retrospektiverne som der bliver skrevet referat ud fra. Disse kan sige meget om et teams tilstand. Info fra retrospektiverne bør behandles med største fortrolighed.
Samarbejde med et agilt team 3 af 3 (Delvist gentaget i Transparens og Risikoreduktion) Et Burndown Chart giver som udgangspunkt udtryk for et teams performance på tværs af iterationer. Derved kan ledelsen eller teamet tage hånd om eventuelle fald i produktionen, som for eksempel kunne skyldes udskiftning af teammedlemmer, arbejdsmiljø eller forstyrrende elementer. Man bør også være opmærksom på stigning i produktionen skyldes en god forbedring af teamets performance, eller at teamet arbejder på så højt et niveau at der er risici for stress. Et godt agilt team har en jævn til let stigende performance, så man kan forudsige og planlægge det arbejde teamet kan udføre. Det er vigtigt at man ikke sammenligner hvor mange storypoints der færdiggøres på tværs af forskellige teams, da definitionen af arbejdet i et storypoint typisk er forskelligt fra team til team.
Spørgsmål Hvordan sikrer du sikkerhed, revision og kontrol i en moderne udviklingsproces? Kunne man tænke sig en rolle der hedder en agil reviser?
Citater I BBS/Nets har Scrum over flere år vært den foretrukne metode i de fleste leveranseområder, samtidig har BBS vært ISO 9001 sertifisert siden 1995 og ISO 27001 sertifisert siden 2002 (den første tiden BS 7799). Vi har valgt en bred tilnærming for å beskytte våre kunders data mot urettmessig innsyn, tilgang og endringer. Bjørn Vargmo, fhv. Chef for Kvalitet, Revisjon og Sikkerhet i BBS/Nets I Topdanmarks IT afdeling bekender vi os nu til agil udvikling. Jeg oplever ikke sikkerhed, som en særlig udfordring ifm agil udvikling det er et aspekt i udviklingen, som man eksplicit skal forholde sig til. Thomas Krogsætter, Arkitektur- og applikationsansvarlig i Topdanmark
Læringspunkter Sikkerhed og kontrol afhænger af ledelsen ikke metoden Sikkerhed er en organisatorisk/ledelsesmæssig opgave det er ALDRIG den enkelte projektleders ene ansvar Revision af agile processer kræver indlevelse og deltagelse i processen
Links Security user stories: http://www.safecode.org/publications/ SAFECode_Agile_Dev_Security0712.pdf Agile risk management: http://www.mountaingoatsoftware.com/ blog/managing-risk-on-agile-projects-with-the-risk-burndownchart Agile ultra light: http://agilelion.com/agile-kanban-cafe/agile-2-0- embracing-lean-and-rise-ultra-light-methods Generelt om agile: http://www.agilenutshell.com/