Kan man bygge et hus agilt?
I mit forrige indlæg, gav jeg en kort introduktion til hvordan det agile opstod.
For at forstå det lidt bedre, vil jeg prøve i dette indlæg at give mit bud på hvad man typisk gør i et agilt projekt (a la Scrum) sammenlignet med hvad man gør i en mere ren vandfaldsmodel. Og sidst i artiklen vil jeg så prøve om man kunne bruge de agile metoder andre steder, f.eks. ved bygning af et hus.
Igen: Dette er baseret på min erfaring, som både stammer fra mange forskellige projekter og uddannelser/certificeringer indenfor de forskellige metoder. Men som man siger på udenbysk: Your mileage may vary (på godt dansk: Du kan have andre oplevelser og andre holdninger, så dem vil jeg da gerne høre om).
For at kunne sammenligne metoderne bliver vi nødt til at have en fælles reference, og der kunne man jo prøve at lave en slags skitse af produktet, lige når det er helt færdigt og kunden skal i gang med at benytte sig af det. Sådan en skitse burde jo være uafhængig af hvordan man er kommet frem til slutproduktet. Man kan lave en grov skitse som et hierarki med de forretningsmæssige behov øverst, f.eks. de forventede gevinster koblet sammen med den funktionalitet, der skal levere disse. Under dette har man så den egentlige IT-mæssige implementering af funktionaliteten med den teknologiske stak nedenunder. Det kunne se ca. sådan ud:
Ovenstående er en meget grov skitse, og lagene kan have mange andre navne, men forhåbentlig forstår man pointen. Den tykke streg angiver grænsefladen mellem forretningen og selve IT-produktet. Hvis man har anvendt teknikken produktbaseret planlægning, er denne type diagram nok ikke noget nyt, men i princippet kan man lave diagrammet uanset hvordan man fik produceret systemet. Hvis man ville lave et meget detaljeret diagram, skal man forestille sig at man inde i hver af de store kasser har en masse små kasser, der er forbundet på kryds og tværs med afhængighederne vist som linjer. Et rigtigt diagram af denne type ville sandsynligvis ikke være et ægte hierarki, men have afhængigheder, der kører på tværs på forskellige underlige måder.
F.eks. kunne en forretningsmæssig anvendelse af funktionaliteten bestå af et flow, der involverer flere af de udstillede funktioner, sådan at man ikke kan benytte systemet forretningsmæssigt, før al den krævede funktionalitet er leveret. Denne afhængighed ser man dog tydeligst, hvis man har gennemanalyseret de to øverste lag først, og det giver en risiko for at den måske ikke bliver opdaget før ret sent, hvis man anvender en meget agil metode.
Hvis man så prøver at trække en linje tilbage til hvordan hhv. en vandfaldsmodel og en mere agil model som Scrum typisk vil implementere ovenstående, kommer man frem til noget lignende dette:
Det er selvfølgelig forsimplet for at fremme forståelsen, men man kan se at man i en vandfaldsmodel arbejder på hvert lag først, inden man går videre til det næste. Fordelen ved det, er at man bør kunne få et overblik over sammenhængene i det enkelte lag. Man kommer dog nemt til at bruge meget tid og opbygge en masse dokumentation, hvis man arbejder med den rene vandfaldsmodel. Samtidig er det måske svært at gennemskue de afhængigheder, der går på tværs af lagene, før man har bygget dele af produktet.
I virkeligheden vil man oftere anvende en variant af v-modellen (i forskellige udgaver også ofte kaldt w-modellen), da man så har hele kvalitets- og testdelen med. Den er ikke vist i ovenstående diagram, men skal ikke glemmes.
Hvordan kunne det så se ud med en mere agil tilgang til det? Ja, vi ønsker jo ikke at bruge for meget tid på analyse og at skabe en masse dokumentation, som måske er unødvendig, så vi prøver i stedet at gribe fat i enkelte dele af den ønskede funktionalitet og så bygge den del til kunden. Det ville måske se sådan her ud, baseret på den første tegning:
Vi kan se at vi her skærer produktet på den anden led, hvor vi forsøger at implementere en mindre del af produktet hele vejen igennem. Det har den fordel at kunden har en mulighed for at se på produktet og dermed vurdere om det var den rigtige vej ved simpelthen at afprøve det, frem for at skulle lave en masse beskrivelser først. Men måske får man ikke noget, der helt kan anvendes endnu forretningsmæssigt, selv om det tilsyneladende virker rent teknisk - enten fordi man ikke har bygget det helt rigtigt i den teknologiske stak, fordi man mere anvender en form for prototyping (se bl.a. en af kommentarerne fra sidste artikel for at få et godt eksempel på dette) eller fordi der helt mangler funktionalitet, fordi man ikke har brugt tid nok på den forretningsmæssige analyse. Så begynder man typisk at kigge på hvad man kan levere som det mindste brugbare system (MVP - Minimum Viable Product).
Det kan også være at man fokuserer for meget på den forretningsmæssige brug og glemmer det egentlige formål, nemlig de gevinster man gerne skulle have ud af at gennemføre projektet. Jeg er sikker på at min blog-kollega Martin Ernst her inde ved siden af har en masse at sige i den sammenhæng om brug af Business Case og gevinstrealisering.
Kan man bygge et hus agilt?
Lad os prøve at lave en afstikker til endnu en analogi for at prøve at forstå hvad forskellen er. I stedet for den sædvanlige bil-analogi, så lad os bygge et hus i stedet for. Vi nøjes med en almindelig villa med plads til to voksne og to børn. Det har mange ting fælles med et IT-projekt, så man kan udmærket bruge det som sammenligningsgrundlag.
Et husprojekt vil normalt blive udført af mange forskellige slags håndværkere, f.eks. murere, vvs-folk, elektrikere, kloakmestre, tømrere osv. osv. (et lille tip: Det gælder også IT-projekter)
Normalt vil man lave en tegning først, så man ved hvor stort huset skal være. Man har også en form for tidsplan, så de forskellige håndværkere ved nogenlunde hvornår de skal involveres.
Rækkefølgen er nogenlunde som følger: Først støber man fundamentet. Det skal så helst stå et stykke tid, inden man går videre. Derefter følger væggene, og først når de er på plads, kan man lægge tag på. Ind imellem er der en masse udvendige og indvendige arbejder i form af gulv, vinduer, lofter, døre samt diverse forsyningslinjer. Der er altså nogle hårde bindinger til nogle af aktiviteterne, f.eks. fundament, vægge og tag, mens andre opgaver kan løses lidt mere fleksibelt. Man kan f.eks. godt have nogen i gang med at male i ét værelse, mens andre lægger gulv i et andet. Det er slet ikke ulig hvordan et IT-system normalt bygges op.
Så vi må umiddelbart konstatere at et normalt husbyggeri kører efter en form for vandfaldsmodel. Det betyder dog ikke at man ikke kan ændre på ting undervejs uden at skulle helt tilbage til start hver gang, men man bliver hver gang nødt til at undersøge hvad konsekvenserne er, f.eks. hvis man skulle ønske at flytte et vindue eller en dør, afhængig af hvor langt vi er henne i processen.
- Vi kan altså konstatere at man godt kan reagere på ændringer, også selv om man bruger en vandfaldsmodel.
Kunne vi så forestille os at bygge et hus på den agile måde? Tja, hvorfor ikke?
De agile tanker handler jo om at få leveret noget så hurtigt som muligt, og man er godt klar over at det så kun er en lille del af produktet, der leveres.
Hvis vi skulle forestille os at bygge et hus agilt kunne vi se hvordan vi kunne nøjes med at levere ét værelse, f.eks. et soveværelse. Det er typisk et værelse, der ikke kræver lige så meget som f.eks. et køkken eller badeværelse. Vi skal godt nok have noget lys og varme, men vi behøver ikke at tænke på rindende vand eller afløb.
Hvad skulle formålet så være med det? Det kunne jo enten være fordi husbyggeren (bygherren) slet ikke har noget at bo i, og gerne vil kunne flytte ind hurtigst muligt. Men det kunne også være fordi man ikke helt ved hvad man vil og gerne vil kunne se hvordan ét værelse tager sig ud, før man bestemmer sig til resten.
Hvordan ville man så gribe det an?
Vi bliver jo stadig nødt til at starte med et fundament, men vi kan nøjes med at støbe det lige der hvor værelset skal være. Hvis vi virkelig går op i at vi skal levere det hurtigt, kan vi overveje at springe op og falde ned på at et fundament skal stå et stykke tid, før man lægger noget ovenpå. Her risikerer vi så at vores agile metode kommer til at påvirke kvaliteten. Vi kan nemt sætte vægge op, og vi kan også montere både dør og vinduer. Lige med døren bliver vi dog nødt til at gøre et eller andet, da det jo normalt skulle være en indendørs dør, der skal monteres, men nu bliver man jo nødt til at sikre døren imod vejr og vind. Vi kan godt lægge gulv og montere loft på værelset, men det kommer til at knibe med taget, da det skulle være med høj rejsning, og det er lidt svært når vi mangler resten af huset. Så vi kommer til at etablere nogle midlertidige foranstaltninger over loftet og ved døren. Mht. lys kan det være vi blot nøjes med at sætte nogle batteridrevne lamper op i første omgang.
- Men vi har bevist at vi godt kan bygge en del af et hus agilt.
Jeg håber man kan se udfordringerne, og også kan se parallellerne til et IT-projekt. Et IT-system har jo også et fundament, som består af vores valgte arkitektur og f.eks. datamodellen. Så hvad er problemet egentlig?
Tja, vi kan jo se hvad kunden fik ud af det. Et værelse, som egentlig ikke er særlig funktionelt og som man nok ikke reelt har lyst til at bo i. Måske havde kunden været bedre tjent med en midlertidig skurvogn, indtil hele huset var færdigt?
Og hvad sker der så, når vi skal til at bygge resten af huset? Hvis vi holder fast i at et fundament skal stå et stykke tid, før man bygger ovenpå, har vi nu en forsinkelse af resten af huset sammenlignet med hvis vi var startet på hele fundamentet med det samme. Vi har en risiko for at fundamentet under soveværelset er dårligere end resten (f.eks. at den del af huset har en større risiko for at sætte sig), og vi skal nu bruge ekstra tid på at pille de midlertidige løsninger ned, inden vi f.eks. lægger det rigtige tag på.
Vi kan altså se her at den agile løsning gav os et samlet set dårligere, dyrere og mere forsinket resultat i forhold til hvis vi havde fulgt vores plan.
Er det så også sådan med agile IT-projekter? Det håber jeg bestemt ikke, men jeg har virkelig på fornemmelsen at meget kunne gøres meget smartere, hvis man ikke hele tiden havde fokus på sprintet (dvs. tid).
Den agile måde at udvikle på kan jo både bruges i en forvaltningsmæssig sammenhæng – altså når man laver mindre løbende rettelser til et eksisterende system – og i egentlige projekter.
Et projekt er kendetegnet bl.a. ved at man slutter på et tidspunkt, nemlig når man har leveret det endelige produkt. Derfor mener jeg man bør være ekstremt opmærksom på hvordan man griber det agile an, afhængig af hvad behovet er. Er man i et projekt, bør man aktivt kigge på projekttrekanten og bede kunden vælge hvad der er vigtigst: Tid, produkt eller pris. Jeg vil senere komme mere ind på projekttrekanten, da det er noget der har potentiale til at kunne bruges mere aktivt end det gør i projekter, i forhold til hvordan jeg har oplevet det.
Og så har vi slet ikke snakket kvalitet endnu. Min egen erfaring er at hvis man hele tiden arbejder med meget korte sprint, kommer man ikke udenom at skulle etablere automatiske regressionstest, og det er jo en ekstra investering som måske ikke var nødvendig i samme omfang, hvis man udviklede på en anden måde. Og lige her er der nok meget forskel på om man bygger videre på et eksisterende system eller man er ved at bygge noget helt nyt.
Hvad mener læserne? Er jeres erfaring med agile projekter at de nogle gange kunne være løst smartere, hvis man ikke havde fokuseret på et 14 dages sprint? Hvordan løser man afhængighederne, når man har flere Scrum teams? Hvordan sikrer man en høj kvalitet? Bliver man nødt til at etablere automatiske regressionstest for at kunne arbejde agilt?
Andre interessante spørgsmål:
- Kan udviklere lide Scrum/agilt, eller tror de bare det er det forretningen gerne vil have?
- Kan forretningen lide det agile, eller tror de bare det er det udviklerne gerne vil have?
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.