AGILE og SCRUM for små webteams – introduktion
Hvis du er en del af et lille webteam på 2-4 personer og for nylig har været i kontakt med et konsulenthus, har du sikkert hørt om agil udvikling og SCRUM. Og hvis konsulenthuset holdt en god præsentation, spørger du sikkert dig selv, om SCRUM og agil udvikling er noget for jer.
Det vil jeg se nærmere på i denne Agil/SCRUM føljeton hvor jeg vil gå i dybden med et par metodiske guldkorn og dele ud af mine egne erfaringer fra hverdagens slagmark.
For at skyde blogføljetonen godt i gang, vil jeg starte med en kort introduktion til SCRUM som jeg forstår det.
Introduktion til SCRUM og agil udvikling
SCRUM og Agil udvikling er det seneste skud på stammen hos mange konsulenthusene. Agil udvikling er en overordnet beskrivelse for en række fleksible måder at udvikle software på, og SCRUM, som er meget på mode for øjeblikket, er en af de forskellige agile varianter.
Kernen i SCRUM udvikling er gensidig tillid, tæt samarbejde og plads til justering efterhånden som konsulenthus og kunde bliver klogere på projektet. Ideen er, at kunde og fx konsulenthusets tekniske projektleder ved starten af et projekt lader være med at specificere i detaljer, men i stedet koncentrerer sig om den fælles vision som projektet skal virkeliggøre, den værdi som projektet skal skabe for kunden. Denne vision omsættes ved projekt start til en række overordnede fortællinger (Epics), der vil kunne virkeliggøre visionen.
Selve projektet består herefter af en række udviklingscyklusser (Sprints). Ved indledningen af hvert sprint præciserer kunde og udviklerteam den eller de epics, der skal arbejdes med i dette og det kommende sprint i form af en række brugerhistorier, User Stories. Forskellen mellem epics og user stories er, at epics er løst definerede overordnede beskrivelser, mens user stories er mere detaljerede specifikationer.
Brug for et professionelt webbureau i Trekantsområdet?
Det er lidt et spørgsmål om overbevisning, hvor detaljet en user story skal være. Nogle mener, at hver enkelt user story kun må beskrive én handling for én bestemt brugertype. Andre bruger user stories til at beskrive, hvordan en given user får et givent behov opfyldt (det betyder, at en user story godt kan omfatte flere handlinger). Andre igen bruger som rettesnor, at opfyldelsen af en user story bør tage 4-8 timers udvikling, eller at en user story skal kunne skrives på en post-it.
Den bedste anbefaling er nok at eksperimentere sig lidt frem. Uanset hvordan I definerer jeres user stories, er det vigtigt altid at beskrive klart, hvilken type bruger, historien handler om (altså fx ”som webredaktør vil jeg gerne kunne…), og at det entydigt kan bekræftes, om historien er opfyldt eller ej.
En epic kan for eksempel være, at jeg som kunde i eshop X gerne vil kunne sende en besked til eshoppen. For denne epic kunne user story’erne være, at jeg som bruger gerne vil kunne a) vælge en kategori for henvendelsen, b) indtaste en tekst, c) rette i min tekst, d) slette min tekst, e) se teksten, inden jeg sender den, og f) kunne sende teksten, når jeg er tilfreds med den. Når user story’erne er besluttet, nedbryder udviklerne dette sprints user stories til en række opgaver (tasks) som fx at opsætte en mailserver, lave en formular med felterne x, y, z osv.
Samtidig med formuleringen af user stories aftaler kunde og udviklerteamet klare verificerbare kriterier for, hvornår en user story er opfyldt. Herefter går udviklerne i gang med at udføre opgaverne. Når opgaverne i en user story er gennemført, demonstrerer udviklerne for kunden, at user story’en opfylder de aftalte krav, og kunden ser på denne måde, hvordan projektet løbende akkumulerer resultater, indtil den samlede sum af resultater virkeliggør visionen.
Hvorfor SCRUM
Gevinsten ved at bruge SCRUM i webprojekter for kunde og konsulenthus er, at man løbende forventningsafstemmer og godkender, og dermed minimerer risikoen for graverende misforståelser og uenigheder. Samtidig sikrer SCRUM, at man kun bruger et minimum af tid på at at specificere opgaver, der ender med at blive droppet, og ikke spilder tid på at specificere opgaver tidligt i et projekt, for derefter at være nødt til at specificere dem igen, når de skal løses, fordi de i mellemtiden er blevet radikalt omdefineret i forhold til den gang, man specificerede dem.
Mange af disse gevinster kan også opnås, hvis der er tale om et webteam og teamets interne kunder, i stedet for en kunde og et konsulenthus. Men det er ikke alle, eftersom SCRUM er indrettet efter projekter på omkring 6 måneders varighed, hvor hvert sprint er ca. 3 uger.
Derfor vil jeg i de efterfølgende indlæg præsentere mine udvalgte SCRUM guldkorn, som kan bruges i små teams på et par personer, og mine egne erfaringer med dem. For at skabe lidt forventnings-hype kan jeg løfte en flig af sløret for emnerne i de kommende posts: ikke-funktionelle krav, KANO modellen, estimering og just-in-time beskrivelser.
Inspiration og videre læsning
Dette indlæg er inspireret af Roman Pichlers bog ”Agile Product Management with SCUM – Creating Products that Customers Love”.