Vidnesbyrd
From AgileUserGroup
Contents |
Kunsten at nedbryde et projekt
"For at et større udviklingsprojekt kan blive overkommeligt, er det en god ide at opdele det i mindre dele som kan prioriteres og evt. fravælges. Den store kunst er at få disse dele til at være af en karakter så de hver især udgør funktionelle helheder. Med dette forstår jeg funktioner som når de er udviklet kan lægges på en maskine og testes. Det vigtige i denne sammenhæng er at det skal være funktioner som giver mening når man afvikler programmet og at de giver mening for kunden.
Hvis udviklingsopgaven er en udvidelse til et bestående program, virker dette meget ligetil at gennemføre – tilføj ny funktionalitet og test den. Er det derimod et helt nyt program som skal udvikles, er det store spørgsmål, hvordan kommer man overhovedet i gang.
Bare at få skabt noget kode som kan køre på en computer er en barriere og så skal det ydermere ske på utrolig kort tid 1-2 iterationer. Ofte ender man derfor op i at falde tilbage til gamle vaner med at skrive størstedelen af programmet før der sættes strøm på – ud fra devisen ”alle ved jo godt hvad det skal kunne og det hele skal alligevel være på plads inden det kan sættes i drift”. Herved mister man muligheden for at afprøve om man er på rette spor og kunden får ikke mulighed for at b live klogere under vejs.
I mit projekt er situationen den samme. Vi skal udvikle et helt nyt system som skal være på et vist niveau før det kunne sættes i drift. Det var derfor en nærmest uoverstigelig opgave at nedbryde de meget specifikke krav til hvad systemte skulle kunne for at kunne gå i produktion. Da systemet samtidig var en genprogrammering af et bestående system var kundes holdning i starten at, det virker kunstigt at nedbryde opgaven i klumper som tilsyneladende ikke kunne stå alene, bare for at nedbryde det.
Der var dog enighed om at en god måde at starte på var at skabe en meget simpel udgave af programmet som kunne køre, men ikke havde den store funktionalitet. At få skrevet beskrivelserne for de enkelte funktioner var stadig ikke muligt.
Det var blevet sommer og jeg tog på en herlig 5 ugers ferie. Da jeg kom tilbage sad udviklerne og programmerede efter nogle tekniske beskrivelser om hvad databasen skulle kunne og hvilke interfaces der skulle udvikles. Man var dog kommet langt med at udvikle det minimale program, men der var ikke noget som kunne lægges til test.
Gennembruddet kom da jeg stille det meget simple og naturlige spørgsmål: hvad skal det minimale program kunne. Hvad er med og hvad er ikke med. Nu gik vi i gang med at beskrive de funktioner der var med og hvad man kunne forvente sig af programmet. Udviklerne fik nu en uge til at færdiggøre den manglende funktionalitet. Hvis der manglede noget interfase, database eller arkitektur så blev det lagt ind som opgaver under den enkelte funktionalitet. Fokus var nu på funktionaliteter i stedet for teknik.
Denne ændring i opfattelsen af opgaven medførte også at det var muligt at kommunikere hvad det var man lavede og det var derfor nemmere at afgrænse opgaven så den kunne blive færdig på en uge. Ydermere gave det mulighed for at kunne fortælle testerne som skulle teste leverancen hvad den indeholdt og hvad de kunne forvente.
Da vi nu var kommet over grænsen med at for beskrevet den første funktionalitet var det blevet noget nemmere at beskrive den efterfølgende. Et af problemerne som vi stadig måtte tumle med var afhængighed mellem de forskellige funktionaliteter, indtil at man accepterede at dette kunne klares ved at beskrive begrænsningen i det der blev leveret. Hele projektet er nu beskrevet i for af funktionelle helheder (User Stories). Disse helheder kan prioriteres og i visse tilfælde vælges fra hvis der ikke er tid nok.
Dette er Agil udvikling."
Hilsen Carsten Selvang
Agile udvikling af web-butik på to måneder
”Den 1. oktober blev jeg bedt om at hjælpe projektlederen på et projekt hos TDC med at sørge for, at få en web-butik færdig til 1. december. Datoen var meget vigtig, fordi målet med web-shop’en var, at få en stor andel af handlen i december, hvor der sælges mange mobiltelefoner til julegaver. Det gav os to måneder fra ide til produktion, hvilket føltes næsten umuligt. Vi skulle ikke bare udvikle et system fra bunden – og interface til en underleverandør af mobiltelefoner. Vi skulle også fastlægge og indføre ændrede arbejdsgange i administration og kundeservice. Vi besluttede os for at A. lægge lidt mindre vægt på kravspecifikationen end normalt, B. at igangsætte programmeringen i løbet af de første par uger, C. at udvikle og demonstrere systemet trinvist og D. at samle projektets deltagere fra Århus, Høje Tåstrup og Indien på een lokation – i Høje Tåstrup. Der var masser af udfordringer undervejs – og enkelte lange aftener, men det betød intet da vi den 30. november om eftermiddagen lagde den nye web-butik i produktion og gik hen og fejrede igangsætningen med et par fadøl.
Ole Jepsen, Capgemini.”
Agile metoder er nødvendige for innovation
Hvert år dør tusindevis alt for tidligt af hjertestop. Mange liv kan reddes ved en hurtig og effektiv indsats. Det kræver stor udbredelse af hjertestartere, men endnu vigtigere en bred og effektiv uddannelse i hjertemassage og medicin.
Laerdal Sophus producerer avancerede undervisningsprogrammer, som målrettet uddanner læger og sygeplejersker i hele verden i hvordan de hurtigt og effektiv kan diagnosticere og behandle en bred vifte af akutte sygdomme. Programmerne er udformet som realistiske simulatorer og er enestående i teknisk og uddannelsesmæssig kvalitet. De er kun blåstemplet af de førende lægefaglige organisationer grundet den enestående medicinske dybde.
Traditionelt vil man sige, at i en højkritisk verden som akutmedicin er det vigtigt at anvende en meget omfattende, formel og stringent proces med masser af dokumentation for at sikre kvaliteten. Vores erfaring er tværtimod, at sådanne metoder kommer til kort, når det gælder sådanne nyskabende produkter.
Disse produkter kan kun udvikles af et lille hold af specialister inden for uddannelse, medicin og datalogi i tæt samarbejde med uafhængige internationale eksperter. Det har krævet adskillige tekniske, medicinske og uddannelsesmæssige gennembrud at indfri de høje krav om medicinsk korrekthed, uddannelsesmæssig validitet og teknisk kvalitet.
Sådanne gennembrud opstår kun i et dynamisk og kreativt miljø med sammentømrede folk på tværs af discipliner. Vi er overbeviste om, at en iterativ og ubureautisk udviklingsmetode er nødvendigt for innovation. Hvis man skal skrive lange dokumenter og følge slaviske procedurer, er man simpelthen ikke i stand til at generere, implementere, afprøve og forædle de idéer, der skal til for at skabe et produkt, som gør en forskel.
Asger Ottar Alstrup
Ny web-løsning til BRFkredit
BRFkredit ville udvikle en hel ny web-løsning, som skulle gøre det muligt for vores kunder at selvbetjene sig i forbindelse med konverteringer af private bolig realkreditlån samt ændre låneparametre i forbindelse med en forestående rentetilpasning.
Det stod rimeligt hurtigt klart, at projektet ikke kunne realiseres med afsæt i vores kendte vandfalds metode, da løsningen ville blive alt for dyr og ikke mindst ville blive leveret meget senere end den release dato kunden stillede krav om. Vi måtte gribe dette projekt an på en helt ny måde – agilt inspireret.
Vi nedsatte et projektteam på 10 brugere fra forretningen og 20 udviklere ledet af en IT- og en forretningsprojektleder. Projektet blev fra start samlet i ét fælles projektlokale. Projektet blev delt op i 3 delprojekter. Hvert delprojekt afholdt en workshop over 1-2 dage (forskudt med 1 måneds mellemrum), hvor der blev indsamlet overordnede krav til løsningerne, som kort blev dokumenteret i usecases og aktivitets diagrammer. Rammerne for projekterne blev specificeret og godkendt på 2-3 uger, og herefter blev implementeringen igangsat og slutprodukter leveret til bruger-integrations-test hver 5. uge.
Det der i janaur 2004 på papiret lignede en helt umuligt opgave blev til færdige slutprodukter, som blev releaset i produktion 6, 8 og 11 måneder samme år. Her skal det måske lige tilføjes, at der udover helt ny forretningsmæssig funktionalitet også var tale om et teknisk platform og værktøjs skift.
Det var en sjov tid, der blev gennemført med en høj team ånd – vi ville bare nå i mål, men det kostede også en stor hold indsats og benhårde prioriteringer for kunden, som tog sit ansvar og bakkede fuldt op omkring den nye arbejdsform fra starten. Projektet leverede det produkt kunden ønskede, og det blev leveret til den aftalte tid.
Lone Klitgaard
