Få fordelene ved agil udvikling i IT-porteføljen

Annette Klink DalgaardSenior Certified Project Manager, IBM Agile coach

Agil IT-portefølje forvaltning

• Agil udvikling er mere end blot en metode til projektudvikling og kan også bruges som arbejdsramme til vedligeholdelse af produktporteføljen.

• Med agile metoder arbejder man for minimering af risikoen og maksimering af produktiviteten ved at udvikle gennem en kort iterativ proces.

• Agile metoder har en dynamisk planlægningsproces, således at forekommer der uundgåelige ændringer under udviklingsprocessen, kan disse indarbejdes i produktet. Traditionelle, ikke-agile metoder, har en statisk planlægningsproces, der forhindrer forandring og som ofte skaber konflikter mellem den statiske plan og den dynamiske virkelighed.

EfterhEfterhååndennden somsom ststøørrerre

videnviden opnopnååss brugesbruges

iterationeriterationer tiltil at at sikresikre at at

projektetprojektet opnopnåårr detdet

udvidedeudvidede mmååll

Iterationer sikrer dynamisk planlægning

Planlagt vej

Aktuel vej

AktueltAktuelt mmååll

Start

Success zonePlanlagtPlanlagt mmååll

Øget v

iden

Med agile praktikker og teknikker...

• Er der fokus på kundens forretningsbehov og

udviklingen kan styres efter leverancer med det

største investeringsafkast.

• Giver mulighed for at bruge fundamental

funktionalitet af en applikation og sætte den i

produktion tidligere og få afkast af den tidligere

• scope kan ændres med minimal bureaukrati

• risici associerede med leverancer og tidsplaner

identificeres og mitigeres mere effektivt

Branchen anbefaler

2-4 ugers sprint

2 uger

Agil udvikling med SCRUM

potentially shippable product increment

Bemærk:

• Ordene sprint og iteration betyder det samme

• Scrum er efterhånden førende indenfor industrien

Scrum - standard

Scrum som det agile rammeværk

• SCRUM er ikke raketvidenskab

–Det er et simpelt rammeværk

–Blokkere viser sig tydeligt

–Ved at følge simple (IKKE nemme!!!)

regler og processer viser problemerne

sig ved at dukke op på ”overfladen”

Scrum er lommelygten som fremhæver problemerne –

Det løser dem ikke!

Agil portefølje forvaltning

i IBM GBS/AMS

• Annette Klink Dalgaard, IBM senior certificeret projektleder, Certificeret scrummaster, Agil coach

• Min praktiske erfaring kommer fra IBM Payments Systems (PS)

– Verdensomspændende system til clearing af kredit kort og elektroniske betalinger

– PS interfacer med en del bank-partnere: Chase, Citibank, American Express, First Data, Certegy, Wells Fargo, Deutsche Bank, Barclays, Diners såvel som Paypal.

• IBM Payment System har brugt agil udvikling siden 2006. Jeg startede som projektleder, blev senere program manager og i dag vedligeholdes også porteføljen problemfrit med agil udvikling

Payment systems realiserede fordele

med Agil udvikling• Agil udv. gør problemer/blokkere mere synlige

• Demonstrerer hurtigere resultater

– Tidlige målinger viste forbedringer i produktivitet på omkring 50%

• Fokus på opgaver som er mest vigtige for forretningen

– Kunden er omdrejningspunkt for alle beslutninger

vedrørende prioritet af krav

• Hurtigere udviklings cyklus

– Tilføje en ny connector (online og/eller batch)

• Siden IBM har startet med hvad de kalder ”co.sourcing” (agile

udvikling, genbrug, komponentbaseret udvikling etc...) vi har

reduceret tiden det tager at udvikle en connector til at tage mindre

end 25% af den oprindelige udviklingstid

Realiserede fordele...

• Bedre team motivation

– Globale ressourcer bliver længere i jobbet (tidligere max.

18 måneder, nu flere år)

– Bedre samarbejde mellem danske og globale ressourcer

– ”Penetration procent” i udviklingsteams er langt over 50%

• Hyppigere leverancer

– Projekter/releases havde tidligere en gennemsnitlig

længde på 12-18 måneder, nu er den 3-4 måneder

• Indbygget kvalitet

– Automatisk og hyppig test som sikrer udvikling og afvikling

af end user test cases samtidigt med koden

Alle kravKrav, udvalgt

til et sprint

Daglige scrum møder –

samme tid, samme sted

hver dag

2 uger

IT-portefølje i scrum rammeværk

Product Backlog

Krav, udvalgt til en release

potentially shippable product increment

Release Backlog

Grafisk gengivelse af release-modellen for PS

Start op

Koncept

Koncept

Koncept

Sprint 1, Sprint 2, Sprint 3... Accept Test Udrul

Sprint 1, Sprint 2, Sprint 3... Accept Test Udrul

Sprint 1, Sprint 2, Sprint 3... Accept Test Udrul

Release 1

Release 2

Release 3

Hvert sprint (2-4 uger) afsluttes med en Demo

Projektstart omfatter opgaver som f.eks.allokering af projekt team-medlemmer

Overordnetplanlægning ogarkitekturspor

Overgang til næste release

Identificerede fejl addresseres i sprint i den efterfølgende release

Tid

Forretningsprojekt 1

Forretningsprojekt 2

Forretningsprojekt 3

Vedligeholdelsesopgaver

Release backlog kræver valg

Ved projekter skal hvert eneste backlog item analyseres for:

•Kundens fordele af et backlog item•Hvad giver forretningen det størsteinvesteringsafkast?

•Hvad er vigtigst for kundens forretning?•Hvilke (tekniske) beslutninger ernødvendige for produktets stabilitet ogskalerbarhed?

•Hvordan passer det med releasens vision?

Release backlog kræver valg...

•Incident management håndteres af driften•Problem management – buffer tid er reserveret i sprintet

• Buffer-tiden nedskrives med tid forbrugt tilundersøgelse/analyse af incidenten

• Et backlog item laves til den detaljerededesign/udvikling/test når analysen er færdig

• Beslutning vedrørende prioriteten for de(n) nyebacklog item(s) I forhold til de eksisterende

•Hvis den tid, der er reserveret, overskrides – kansprintet afbrydes og gen-planægges eller der måaccepteres at fjerne fra scope – et aktivt valg skal tages

For portefølje vedligehold:

Produktejer – den praktiske implementering

• Vedligehold

– I forretningen udpeges en produktejer for hver

vedligeholdelsesopgave – en produktejer kan have flere opgaver

• Projekter

– Hvert projekt tildeles en produkt-ejer (denne person er ofte

forretningens projektleder)

• Produktejeren og ansvar

– I den agile vedligeholdelsesorganisation har ansvaret for koordinering

af krav mellem projekter og vedligehold historisk flyttet sig fra

udviklingsorganisationen til forretningen selv, men for at sikre

koordinering og prioritering af kravene faciliterer

udviklingsorganisationen kravsmøder hver 14. dag, hvor kravene

diskuteres – alle produktejere er tilgængelige sammen med

arktitekterne og udviklingsprojektleder.

Annette Klink Dalgaard – annettej@dk.ibm.com