Af Poul Staal Vinje
15.
Opsummering: Fordele ved at bruge Scrum
16.
Opsummering: Ulemper ved at bruge Scrum
17.
Scrum er til nødlidende projekter
Scrum,
- bruges til at styre og overvåge udviklingsforløb
- er en iterativ proces der leverer et potentielt brugbart produkt
- fungerer ved hjælp af Sprints i faste intervaller på 30 dage
- er Lean
- bruges til at afgøre konfliktende interesser
- bruges til at afgøre konfliktende behov
- giver maksimal kommunikation
- fungerer ved hjælp af samarbejde i praksis
- fjerner forhindringer systematisk
- giver førstehåndsindtryk af status
- skalerer
- bruger forretningsværdi som mål for produktivitet
- giver arbejdsglæde
- giver en oplevet følelse af at have ydet sit bedste
Scrum bruger tre roller, tre ceremonier og tre værktøjer. Rollerne er ProductOwner, Team og ScrumMaster. Ceremonierne er SprintPlanningWorkshop, Daily Scrum og SprintReviewMeeting, Værktøjerne er ProductBacklog, SprintBacklog og BurnDownChart.
De enkelte forløb kaldes 'Sprint'. Det er i denne forbindelse ligegyldigt, om der er tale om ny- eller videreudvikling. Til nyudvikling bruger man en række Sprints til at nå frem til et produkt, der kan releases. Til videreudvikling vil resultatet af forløbene blive releaset i den takt, de udgør en ny, brugbar udgave. Da Scrum er iterativ, kommer ny- og videreudviklingsforløb ofte til at ligne hinanden.
Scrum bruges kun til at lede og styre forløbet. Scrum indeholder ikke teknikker til de konkrete udviklingsaktiviteter. Scrum suppleres derfor med andre metoder, for eksempel Extreme Programming (XP). Scrum er meget velegnet til at levere XP-forløb.
Scrum skalerer ved at lade mange Sprints blive afviklet parallelt og overlappende.
Teamet organiserer selv arbejdet, efter at indholdet af den kommende Sprint er aftalt. Man kan kalde det autonomi, selvforvaltning eller selvorganisering.
Teams har deres fulde frihed, men inden for rammerne af organisationens standarder, vedtagne arkitekturer og koncepter.
Scrum bruger ikke projektplaner med ressourcer, aktiviteter og afhængigheder. Der følges op via daglige møder, der fungerer som kommunikationscentral. Ledelsen kan deltage, når den ønsker det, og få et førstehåndsindtryk af, hvordan det går. Teamet kan selvfølgelig anvende projektplaner og projektstyringsværktøjer, hvis de beslutter det.
Hvorfor fungerer Scrum så godt? Fordi Scrum baseres på:
- en systematisk og tydelig prioritering
- en regelmæssig og tæt opfølgning
- førstehåndsindtryk hos både ProductOwner og ScrumMaster
- sund fornuft
Scrum er et begreb fra rugby, hvor en ”Scrum” eller ”Scrummage” er, når holdet står tæt sammen i en cirkel eller klump, og aftaler den strategi og fremgangsmåde, der skal benyttes i den næste Sprint. Man samles med jævne mellemrum og afgør situationsbestemt, hvordan man skal komme videre.
Man skal i øvrigt ikke lægge mere i det, end at det er et godt navn. Der er ingen grund til at studere rugby for at forbedre systemudviklingsprocessen i sin organisation.
Se eventuelt
artiklen i Harward Business Review: "The New New Product
Development Game", Hirotaka Takeuchi og Ikujiro Nonaka.
Nu vi er ved navne, så må vi konstatere at der
på dansk veksles frit mellem de danske og engelske navne på begreberne i Scrum.
For eksempel ProductOwner og produktejer. Og ProdcutBaclog og produktbacklog.
Således som der også gøres i denne artikel.
Produktejer eller systemejer, begge betegnelser bruges på dansk. Det er fra engelsk, ProductOwner.
Scrum er udvikling drevet af forretningsværdi. ProductOwner er dermed uundværlig.
Produktejeren er en produktansvarlig. Enten i udviklings- eller brugerorganisationen. Det er vigtigt at vælge en beslutningsdygtig og handlekraftig person. Det er produktejeren der styrer produktbackloggen. Og det er produktejeren, der er den drivende kraft i prioriteringen af indholdet, og i processen med at vælge indholdet til næste Sprint.
Forretningsværdien bestemmer prioritering og dermed leveringsrækkefølgen. Hvorfor detaljere, analysere og designe de 90 % af kravene? Hellere levere de vigtigste 10 % så hurtigt det kan lade sig gøre.
ProductOwner er med til at reducere risikoen for fejlagtige investeringer i systemudvikling.
To af de mest betydningsfulde faktorer i succesfulde projekter, er:
- brugermedvirken direkte i projektet
-
nøgtern kravstyring
Scrum bruger begge dele. ProductOwner står for kravstyring.
ProductOwner afgør også behovet for ændringer? Beslutter hvornår det er nødvendigt..
ProductOwner kan behøve hjælp med det rent praktiske i at
vedligeholde ProductBacklog. I at få oprettet gode Userstories i
produktbackloggen.
Lidt detaljer på
ProductOwners aktiviteter:
Indsamler alle ønsker til funktionalitet, således at der ikke er andre kanaler ind til teamet.
Vurderer forretningsværdien af funktionalitet.
Indsamler alle udestående fejl og mangler.
Indsamler ønsker til tværgående egenskaber, jævnfør ISO 9126.
Prioriterer, enten 111, 222, 333 eller 1,2,4,5,6,7,8,9. Træffer selv valget mellem de to former.
Grovestimerer. Henter hjælp til det fra teamet, eller tilsvarende, når teamet ikke er udpeget.
Vælger indhold til næste Sprint.
Forandrer retning ved at ændre prioritering.
Afgør konfliktende interesser.
Afgør konfliktende behov.
Reagerer på synligheden der er til stede i Sprinten under vejs.
Reagerer på synligheden der er til stede ved afslutningen af en Sprint.
Reagerer på den samlede synlighed af de afsluttede Sprints.
Evaluerer resultatet efter 30 dage. Reel vurdering, gerne med offentlig plus/minus.
Vurderer det under
vejs. Hvorfor vente med accepttest.
Deltager på SprintPlanningWorkshop.
Deltager på
SprintReviewMeeting.
Deltager efter ønske
og behov på Daily Scrum. Ved at kigge ind som Chicken.
Produktejeren behøver ikke at afvise et ønske. Alt kan registreres på produktets backlog. Men alt bliver også prioriteret, og det betyder, at ønsker med laveste prioritet har begrænsede chancer for at blive en del af en Sprint. Det er alligevel vigtigt, at det optræder synligt på backloggen, så det er tydeligt, at ønsket er kendt og med hvilken prioritet, det optræder. Hvis nogen ønsker prioriteten ændret, må man henvende sig til ProductOwner.
Det er kun produktejeren, der kan opdatere backloggen, herunder prioritere indholdet.
Produktejeren skal aldrig præsentere en afsluttet backlog, hvor der er taget stilling til et endeligt produkt. Backloggen lever et aktivt liv, så længe produktet er levende.
Backloggen skal være synlig. Udgiv den på et intranet, og forsyn den gerne med notifikationer i form af automatiske e-mail til dem, der måtte ønske at vide, når der sker ændringer.
Indsamlingen og registreringen kan automatiseres ved at lade interessenterne selv oprette nye indgange direkte. Med nogle simple funktioner kan de få lov til at oprette forslag, der dog kun kan få status af at være ubehandlede og uprioriterede.
Alt kan komme på listen: ønsker, krav, egenskaber, teknologi, arkitektur og fejlrettelser. Desuden kan den indeholde generelle problemer, der endnu ikke er oversat til krav. Den kan for eksempel beskrive, at sikkerhedsniveauet er for lavt, og robustheden er mangelfuld, uden at der er taget stilling til, hvad der skal gøres konkret for at øge sikkerheden og forbedre robustheden. Problemer optræder på backloggen med tydelig identifikation, så man kan se, at produktejeren skal omsætte problemet til krav, før det bliver en del af en Sprint.
Alternativt kan produktejeren vælge at holde problemer ude af backloggen. Men det er i mange tilfælde en fordel for produktejeren selv, at det er tydeligt og offentliggjort, hvilke problemer der er registreret om produktet. I de tilfælde, hvor et problem allerede er registreret i en fejlrapport, skal man selvfølgelig overveje, om det er fornuftigt at skabe redundant information. Det samme gælder i forhold til et eventuelt call-centers database og andre supportfunktioners registreringer. Implementering af ITIL eller tilsvarende skal bruges, til ikke at øge redundans. Hellere arbejde sømløst sammen.
Krav i backloggen kan udvides med de oplysninger, man anser for nyttige. Det kan være:
- kilden til kravet
- link til en mere detaljeret beskrivelse
- referencer og links der er nyttige når det skal implementeres
Det er okay med en blanding af overordnede krav og detaljerede funktionsbeskrivelser. I takt med, at et overordnet ønske prioriteres højt nok til at skulle med i en Sprint, kan indholdet detaljeres. Estimatet på udviklingstiden kan som en konsekvens ændre sig - i den ene eller anden retning. Det kan give grund til at ændre prioriteringen - igen i den ene eller den anden retning. Produktets backlog er dynamisk, fordi den afspejler produktejerens viden på ethvert givent tidspunkt.
Der skal være estimater på alt i backloggen. Estimaterne kan beregnes med forskellige estimeringsteknikker, herunder Storypoints, Function Points, Use Case Points, Class-Method Points og successiv kalkulation.
Indholdet til produktets backlog kan komme fra mange kilder. Brugere og kunder kan foreslå ændringer. Interne dele af organisationen kan stille forslag til sikkerhed og til andre af de tværgående systemegenskaber. Marketingfolk kan stille forslag baseret på konkurrerende produkter. Fejlrapporter kan komme mange steder fra. Ønsker om integration til andre systemer kan komme fra de andre systemers produktejere.
Produktbackloggen består af opgavebeskrivelser. I modsætning til sprintbackloggen der består af aktiviteter.
Userstories er perfekt som beskrivelsesskabelon til indholdet i produktbackloggen.
Produktbackloggen lever så længe systemet lever. Med de på ethvert givent tidspunkt udestående krav og ønsker.
Sprintens indhold defineres på en workshop. Deltagerne er produktejeren, ScrumMaster og teamet. Formålet er at vælge det udsnit af backloggen, der ønskes gennemført af produktejeren, og som svarer til teamets formåen.
Workshoppen giver teamet en fælles forståelse for indholdet i den kommende Sprint.
Den typiske fremgangsmåde er at vælge fra højeste prioritet - for derefter at supplere med de dele med lavere prioritet, som det vil være naturligt, logisk eller bare let at tage med i samme Sprint.
Teamet vælger hvor meget de kan levere i Sprinten, udtrykt i Storypoints.
Teamet estimerer varigheden ved hjælp af Planning Poker.
Teamet opretter typisk indholdet i SprintBacklog ca. en tredjedel frem i Sprinten. Eller mere eller mindre, efter eget valg.
En sprint er en periode på en måned, hvor teamet arbejder på det valgte udsnit af produktbackloggen.
Teamet leverer produktet efter de 30/31 dage, men det er en god idé at teste og integrere løbende. Hvis den underliggende produktionsmetode er XP, giver det sig selv. Fordelen ved at teste og integrere produktet på det tidligst mulige tidspunkt er, at det er muligt at bruge de daglige møder til at fjerne problemer og dermed øge produktiviteten. Ved daglig integration reduceres risikoen for at beregne en forkert fremdrift og dermed en forkert færdiggørelse - og ultimativt en for sen indgriben. Det må erkendes, at forkert fremdrift stort set altid er i retning af for stor optimisme. Det er ikke uforståeligt, hvis det er problemerne, der ikke kommer tydeligt nok frem.
Teamet beregner løbende, hvor mange timers arbejde der udestår på Sprintbacklog, sammenholder det med de timer, der resterer i Sprinten, og arbejder sammen med ScrumMaster, hvis der opstår uoverensstemmelser. Der er i så fald brug for at reducere eller øge mængden af det arbejde, der skal præsteres i Sprinten.
Efter en eller flere Sprint foreligger der et produkt, som
produktejeren vælger at release. Der er i det tilfælde ofte brug for en Sprint,
der a
Teamet opretter og vedligeholder en liste over de aktiviteter, der skal udføres i den givne Sprint for at realisere målet. Den kaldes for en SprintBacklog. Det er aktiviteter som kodning, test og design. I modsætning til ProductBacklog der indeholder opgavebeskrivelser i forretningssprog.
Backloggen oprettes når Sprinten starter. Hvis et team kommer foran, kan der tilføjes. Modsat hvis det kommer bagud. Ændringerne der måtte besluttes af produktejeren vil normalt have konsekvenser for aktiviteterne i Sprintbacklog.
Aktiviteterne brydes ned til det niveau, som udviklerne finder, er tilstrækkeligt til at blive estimeret pålideligt. Det vil for de fleste sige mellem en halv og en hel arbejdsdag pr. aktivitet.
Andre arbejder med længere aktiviteter - afhængigt af deres fortrolighed med indholdet af opgaverne. Men brug 16 timer som maksimum for en aktivitet. Men der er forskel på om længden skyldes at det samme arbejde udføres mange gange, eller om den skyldes en høj kompleksitet.
Status på aktiviteterne holdes løbende ajour. Ændringer føres ind, så snart de kendes, således at backloggen er levende og ajourført i Sprintens levetid. Den må gerne offentliggøres og gerne på et intranet, som interessenterne har adgang til. SprintBacklog revideres kun af teamet.
Estimaterne revideres ligeledes løbende - både på eksisterende aktiviteter og når aktiviteter nedbrydes. Estimaterne føres ajour dagligt for at have den bedst mulige opfølgning på status under vejs.
SprintBacklog lever kun i den givne Sprint.
Alle estimater er restestimater. Altså udestående timer der skal bruges til færdiggørelse.
ScrumMaster afholder og leder den daglige Scrum. Hele teamet deltager hver dag - helst personligt, men ellers via webcam eller telefon.
DailyScrum har tre faste punkter på dagsordenen, hvor hver deltager i teamet efter tur fortæller:
1. hvad vedkommende har arbejdet med siden sidste møde
2. hvad vedkommende vil arbejde med frem til næste møde
3. om eventuelle hindringer for arbejdet
Mødet varer ca. et kvarter.
Der udføres ikke arbejde eller løses problemer på selve mødet.
Der er kun de tre punkter.
Hindringer for arbejdet gentages hver dag, indtil de er fjernet.
Mødet holdes samme sted og tid og med de samme deltagere - nemlig teamet.
Det bliver altså cirka 22 møder i en Sprint. Mødet er et genialt styringsredskab - ikke mindst fordi det er så enkelt.
Alle andre er velkomne til at deltage, kun begrænset af den plads, der er til rådighed. Men det er kun teamet, der tager ordet. De øvrige deltagere er tavse og befinder sig i baggrunden af lokalet - langs væggen eller på anden måde, så de ikke blander sig med teamet. De er Chickens. Deltagerne i teamet er Pigs.
DailyScrum giver et førstehåndsindtryk for enhver der måtte ønske det.
Opfølgningen vises som et BurnDownChart. Det viser den resterende mængde timer i Sprinten dag for dag. Det er basis for at reducere eller øge indholdet i Sprinten.
Virkelighedens fremdrift er ikke altid jævn og perfekt. Der kan forekomme udsving.
Tallene er en afspejling af SprintBacklog. De er en sum, beregnet på grundlag af SprintBacklog. Ikke konstrueret til formålet.
Den vedligeholdes som udgangspunkt af teamet, og det er alene teamets ansvar. Det er dog almindeligt at teamet beder ScrumMaster om at reviderede den dagligt. Og offentliggøre den. Indholdet er stadig teamets ansvar.
ScrumMaster kan være den 'normale' daglige leder, for
eksempel gruppe- eller projektlederen. Men der er intet i vejen for at have
ScrumMastere, der udpeges specifikt til jobbet. Det er a
ScrumMaster er projektets daglige adgang til virksomhedens ledelse.
Lidt detaljer på
ScrumMasters aktiviteter:
Leder den daglige Scrum.
Reviderer BurnDownChart hvis teamet beder om det.
Følger op på, om projektet er på vej til at realisere målet for den pågældende Sprint.
Løser de problemer og fjerner de forhindringer, der kommer frem på DailyScrum.
Fungerer som eneste kanal ind og ud af teamet.
Arbejder sammen med produktejeren på alle ledelsesmæssige områder, herunder etablering af grundlaget for en Sprint og evalueringen efter en Sprint.
Arbejder sammen med teamet på alle ledelsesmæssige områder.
Fungerer også som coach for teamet.
Teamet påtager sig arbejde til den kommende Sprint på SprintPlanningWorkshop.
Teamet afgør selv, hvor meget man kan påtage sig til en Sprint. Det er en skidt begyndelse, hvis der trækkes urealistiske - eller for den sags skyld blot 'fremmede' - estimater ned over hovedet på dem.
Teamets størrelse er identisk med de teamstørrelser, der arbejdes med i XP. Det vil sige 8-10 personer som foreslået af Kent Beck et al., selvom nogle organisationer med held eksperimenterer med teamstørrelser på op til 12 personer.
Et team er ansvarlig for alt det arbejde, der skal udføres, og det er en fordel, hvis teamet selv kan udføre det meste. Hvis en Sprint er afhængig af mange specialister eller konsulenter, der skal med i mindre dele af Sprinten, mistes der noget gruppedynamik. Derfor skal teamet omfatte udviklere, testere, designere og andre, der måtte være brug for. Det er det samme forhold, der gør sig gældende for projekter i almindelighed. Det er en fordel at have den viden og den ledelsesmæssige kompetence inden for projektet, der skal til for at udføre opgaven.
Teamet kan med fordel bruge roller og rollebeskrivelser. Man kan låne fra RUP, hvis man for eksempel mangler inspiration til at definere testerrollen og har brug for at arbejde med testdesigner, testanalytiker, tester eller testleder. Men roller i Scrum er ikke så formelle, som i RUP. Rollerne bruges primært for at skabe en fælles forståelse for, hvad man laver, når man har en rolle. Det vil sige, at når man påtager sig testerrollen i et tidsrum eller for nogle opgaver, så ved teamet, hvad der udføres af arbejde i den forbindelse.
Der etableres flere parallelle eller overlappende teams, når behovet for udvikling overstiger, hvad et team kan levere inden for de ønskede tidsfrister.
Teamet estimerer hver aktivitet, og det er teamets ret at ændre på det eksisterende estimat. Og pligt. Det er derfor en fordel, hvis teamet har haft indflydelse på estimatet, mens det optrådte på produktets backlog. Det giver et bedre grundlag for produktejerens prioritering.
Teamet opretter selv SprintBacklog med de aktiviteter og opgaver, der skal udgøre den kommende Sprint. Teamet organiserer derefter selv arbejdet og sørger selv for at overholde organisationens standarder og generelle krav til systemudvikling.
Teamet arbejder med en høj grad af selvforvaltning.
Teamet arbejder Cross-functional i det videst mulig omfang. Det vil sige at de påtager sig alle de aktiviteter der er mulige. Hjælper hinanden, teamet, og dermed sig selv.
Lidt detaljer på teamets aktiviteter:
Estimerer omfanget af de Userstories som produktejeren vælger fra produktbackloggen. Omfanget udtrykkes i Storypoints.
Estimerer hvor mange Storypoints de kan løse i den kommende Sprint.
Planlægger aktiviteter og opretter den i sprintbackloggen.
Udfører alle aktiviteter fra Userstory over design til konstruktion.
Arbejder sammen med flest mulige andre i teamet, typisk i par.
Beregner restestimater.
Beslutter under vejs om der er plads til nye opgaver.
- eller modsat om der skal reduceres i Sprintens indhold.
Fordeler opgaver og aktiviteter mellem sig.
Sprinten afsluttes med et review af det arbejde, der er blevet præsteret. Produktet skal svare til det, der blev aftalt ved SprintPlanningWorkshop. Korrigeret med de ændringer der er besluttet under vejs.
Reviewet ledes af ScrumMaster. Nøgleinteressenterne deltager, herunder teamet, brugere og ProductOwner. Andre er også velkomne som tilhørere.
Reviewet varer typisk 2-3 timer og gennemgår det fysiske, færdige produkt.
ProductOwner vurderer resultatet. En ligefrem nøgtern vurdering.
Hvis der er opgaver, der ikke er løst, som det var planlagt, kan de enten genoplives på produktbackloggen, eller registreres som nye og ændrede indgange på den.
Der er to. En ekstern der er en gængs projektevaluering. Og en intern der består af hver deltagers plusser og minusser. Samlet i en fælles intern.
Tre spørgsmål der stilles i en intern Retrospective:
1. Hvad gik godt?
2. Hvad kunne være gået bedre?
3. Hvad forbavsede os?
Skalering sker ved at sætte mange Sprints i gang. De koordineres ved hjælp af særlige Daily Scrums til netop dette formål. Plus at der findes en række teknikker til at koordinere indholdet i de parallelle og overlappende Sprints.
Skalering af Scrum er nødvendig når et stort projekt skal gennemføres på kort tid.
Trækket på ledelsessystemet lettes, uden at der mistes noget. Faktisk er det enklere at overvåge alle kørende projekter via sine ScrumMastere. Og set fra projektet er ledelsen dagligt tilgængeligt via ScrumMaster.
Scrum er 'Agile'. Den er altså adræt, eller smidig, og arbejder let sammen med andre metoder. Herunder XP og RUP. På dokumentationssiden kan man for eksempel benytte sig af UML som standard. Se om modellering i ’agile’ sammenhæng på www.agilemodeling.com (Scott W. Ambler).
Scrum fungerer godt med hensyn til de grundlæggende ledelsesmæssige forhold. Det er tydeligt, hvad der foregår, og det er let at gribe ind.
Scrum er velegnet til udvikling, der baseres på en ufuldstændig kravspecifikation eller en
kravspecifikation, der ændrer sig. For en god ordens skyld skal det bemærkes at Scrum også er velegnet til projekter med en komplet, korrekt og stabil kravspecifikation. For i den situation blot at nyde godt af den høje produktivitet i Scrum.
I et projektforløb er styring af risici noget nær alfa og omega, når vi taler forudsætninger for succes. Scrum handler lige præcis om at fjerne risici.
Alle dele af Scrum bidrager til at reducere risici
§ Produktejerens direkte prioritering
§ Den daglige opfølgning
§ Synliggørelsen af fremdrift
§ Synliggørelsen af problemer
§ Synliggørelsen af projektets aktiviteter på Sprintbacklog
Scrum kan iværksættes på et enkelt projekt - man kan få erfaringer og udvide brugen over tid. Scrum er let at implementere, da det er et enkelt koncept. Det hele kan prøves af med en begrænset investering.
De samme ulemper som i iterativ systemudvikling generelt.
Det vil sige, at produktet udvikles i en række konkrete leveringer. Der hver især først planlægges i detaljer umiddelbart før de gennemføres.
De store, sammenhængende dokumentationer produceres ikke. Man ender ikke med use cases, sekvensdiagrammer, klassemodeller og så videre, der alle hænger sammen og dokumenterer systemet. Selvfølgelig kan de produceres. Ved at oprette dem som aftalte produkter i ProductBacklog. No problem. De opstår blot ikke af sig selv i Scrum processen.
Men før de bliver det. Nødlidende.
Meget af det der gøres i Scrum er det vi gør i den sidste måned af at langt projekt. For eksempel klar prioritering og daglig opfølgning. Det gøres blot i den første måned. Og alle efterfølgende.