Vi bruger Scrum hos CodeLean – men hvad er nu Scrum for noget?

Scrum er et rammeværk, der understøtter planlægning og eksekvering af iterative udviklingsprojekter, hvor effektive teams med udgangspunkt i en forretningsorienteret produktvision er i stand til at levere kvalitet på kortere tid, end det normalt er muligt med traditionelle udviklingsmetoder. Samtidig understøtter Scrum håndtering af en dynamisk verden, hvor nye forretningskrav løbende kommer til.

Et Scrum projekt tager udgangspunkt i en produktvision

Et Scrum projekt tager typisk sit udspring i en ikke-teknisk produktvision. Produktvisionen ”ejes” af Produktejeren (Product Owner) og det er dennes opgave at formulere en Product Backlog, der indeholder kravene til det produkt eller system, som skal udvikles for at realisere forretningens vision. De enkelte krav skal prioriteres i Product Backlog i henhold til den forretningsværdi, som de kan tilføre forretningen, og således sikres det, at udviklerne hele tiden fokuserer på at levere den funktionalitet, som det bedst kan betale sig at udvikle. Product Backlog er i modsætning til de traditionelle kravspecifikationer et levende dokument, som Product Owner hele tiden skal holde opdateret i takt med, at forretningssiden identificerer nye krav til produktet eller systemet. Kravene i Product Backlog nedbrydes i såkaldte User Stories (beklager alle de engelske ord, men der findes ikke rigtig gode danske termer for disse begreber). En User

Story er en kort specifikation af det enkelte krav formuleret i få almindelige sætninger og kunne f.eks. se sådan her ud:

Ny bruger registrerer sig
Når en ny bruger registrerer sig, skal brugeren angive et ønsket brugernavn og password

Fra Product Backlog til konkret produkt

Når Product Owner er på plads med en Product Backlog, der understøtter forretningens visioner, er tiden kommet til at igangsætte selve udviklingsprojektet. Lad os lige se på en simpel oversigtstegning, der viser forløbet, og så forklarer vi bagefter de enkelte leverancer og roller m.v.

Med udgangspunkt i Product Backlog defineres et antal Sprints hver af en varighed på 2-4 uger. Reglen er, at hver eneste Sprint skal resultere i et produkt, der kunne sættes i drift, såfremt forretningen måtte ønske det. Dvs. at en Sprint skal levere et færdigt produkt uden væsentlige fejl og mangler samt med den nødvendige dokumentation. Det lyder lidt flot, og i praksis må man jo nok bryde sammen og tilstå, at de helt indledende Sprints ofte benyttes til at realisere eksempelvis en grundarkitektur, som efterfølgende Sprints kan bygge videre på, og man ville jo ikke sende en grundarkitektur på markedet. Men det skal forstås således, at en Sprint skal producere et færdigt produkt sat i forhold til det efterfølgende forløb, hvilket eksempelvis kunne betyde, at man ikke skal levere en ”hullet” og dårligt dokumenteret arkitektur, som de efterfølgende Sprints så skal bruge ualmindelige tider på at rydde op i.

Omfanget af en Sprint defineres i en Sprint Backlog, som er en delmængde af Product Backlog. Sprint Backlog indeholder således et antal forretningskrav, som Scrum teamet nedbryder i en række aktiviteter, som skal til for at realisere det pågældende krav. Det er en regel, at en enkelt aktivitet ikke må tage længere end 16 timer, og hvis den gør, skal den nedbrydes i flere aktiviteter. Herudover er det et grundprincip, at man ikke tildeler aktiviteter til teammedlemmerne, men i stedet for er det de enkelte medlemmer af teamet, der melder sig på banen og vælger aktiviteter. Dette sikrer en højere grad at motivation.

Hvordan foregår en Sprint?

En Sprint har som tidligere nævnt en varighed af 2-4 uger, og det arbejde, som skal udføres i Sprinten, er indeholdt i en Sprint Backlog. Et Sprint team består typisk af 5-9 personer, og teamet skal dække alle de kompetencer, som er nødvendige for at udføre de forestående opgaver.

Teamet mødes hver dag til det daglige Scrum møde, der har en varighed af blot 15 minutter. Dette møde har kun 3 faste punkter på agendaen, idet hvert team-medlem redegør for følgende:

· Hvad er nået siden sidste Scrum møde?

· Hvad skal der arbejdes med i dag?

· Hvilke forhindringer er der for at udføre de igangværende opgaver?

Det er kun team-medlemmerne, der har taleret ved disse møder, hvilket skyldes, at de ikke skal udvikle sig til diskussionsklubber, som kan risikere at føre til, at fokus bliver drejet. Hvis der opstår emner i løbet af mødet, som er relevante at diskutere yderligere, så skal de tages efterfølgende af de parter, som de involverer.

Scrum teamet opdaterer hver dag Sprint Backlog, således at der konstant foreligger et opdateret overblik over status og fremdrift. Det fulde overblik kan man få ved at kigge på det såkaldt Burn-down Chart, der viser det akkumulerede udestående arbejde på daglig basis.

Sprint Review

Når en Sprint er gennemført, afholdes der et Sprint Review, hvor teamet præsenterer det produkt, som er blevet bygget i løbet af Sprinten. Product Owner (kunden) er målgruppen for dette Sprint Review, og denne har til opgave at indsamle feedback fra alle mht., hvad der kan forbedres ved det, som er blevet konstrueret. Hvis der fremkommer gode ideer til selve produktet, er det også Product Owners opgave at opdatere Product Backlog med disse.

Et Sprint Review varer typisk ikke mere end 2 timer og holdes i en ganske uformel atmosfære. Ofte kan det være en ide at definere et sæt regler for sine Sprint Review møder, f.eks. at man ikke skal forberede lange, kedelige PowerPoint-præsentationer osv.

ScrumMaster

ScrumMasteren var vi lige ved at glemme. ScrumMasteren har en særdeles vigtig rolle i et Scrum projekt, idet han/hun dels forestår det daglige Scrum møde, og dels har til opgave at sikre, at teamet overholder Scrum spillereglerne igennem hele udviklingsforløbet. Samtidig er det ScrumMasterens opgave at eliminere de forhindringer, som teamet i forbindelse med de daglige Scrum møder påpeger som stående i vejen for udførelsen af deres aktiviteter, og endelig har ScrumMasteren den særdeles vigtige opgave at skulle skærme (beskytte) teamet fra udefrakommende forstyrrelser.

Hvis I vil vide mere?

Hvis Scrum er noget, som kunne være interessant for jeres produktudvikling, eller hvis I blot er interesserede i at høre nærmere om fordelene ved at udvikle i henhold til Scrum, så er I meget velkommen til at kigge forbi CodeLean’s hjemmeside på http://www.codelean.com/, hvor I kan finde vores kontaktoplysninger og i øvrigt læse lidt mere om vores virksomhed.

En dansk model for offshore it-udvikling

CodeLean er en dansk virksomhed, der har fokus på at sikre velfungerende offshore it-outsourcing til blandt andet softwareproducenter, udviklere af webbaserede produkter samt it-afdelinger i mellemstore og større danske virksomheder. Vores model for offshore it-udvikling baserer sig på en solid portion dansk tænkning, hvilket vil sige, at vi har danske ledelsesprincipper og syn på kvalitet integreret som en helt afgørende del af vores måde at arbejde på. Vi har kontorer i både Danmark og offshore i Manila, Filippinerne, således at vi kan give vores kunder fordelen af nærhed for de opgavetyper, der kræver nærhed som eksempelvis initial projektdefinition, kravforståelse m.fl. samt de mange fordele ved at kunne placere hovedparten af udviklingsopgaven offshore på vores kontor i Manila, Filippinerne.

Vi fokuserer primært på .NET baseret udvikling af software- og webbaserede produkter samt komponentudvikling, databaseopgaver o.l.

Et typisk projektforløb
Det typiske scenarie er en kunde, der står med et behov for at få udviklet eksempelvis et softwareprodukt eller en webbaseret løsning. I den indledende fase handler det for os og kunden om at få klædt CodeLean godt på i forhold til at forstå de behov / krav, som er indeholdt i kundens projekt. Kravene kan omfatte forretningsmæssige krav, krav til brugergrænseflader, krav til systemstruktur/-design, krav til sammenhæng med eksisterende arkitektur osv.

Den indledede opgave med projektdefinitionen / dokumentation af krav udføres typisk bedst tæt på kunden, hvor it-leverandøren har nemmest mulighed for at etablere en tæt dialog med forskellige projektinteressenter. Derfor starter CodeLean op hos kunden i Danmark, hvor en CodeLean facilitator har til opgave at sikre en solid opgaveforståelse samt overbringe kunden viden omkring, hvordan selve offshore it-udviklingen kommer til at fungere. Herudover arbejder facilitatoren sammen med kunden omkring projektplanlægning, vurdering af kompetencebehov til opgavens løsning m.v.

Vi arbejder med SCRUM i CodeLean, og det indledende arbejde med definition af arbejdsopgaven / projektet vil i SCRUM typisk blive betragtet som en såkaldt sprint med en varighed på 2-4 uger. Denne første sprint resulterer i en ganske konkret leverance, der udgøres af en projektdefinition, opgaveforståelse og en køreplan for det videre projektforløb.

Offshore it-udvikling
Når projektet er klar til gå i offshore produktion, er det CodeLean facilitatorens opgave at "bære" opgaven til CodeLean's udviklingscenter i Manila, Filippinerne. På udviklingscenteret skal projektgruppen etableres og sættes i gang med den første sprint i udviklingsprojektet. Herfra forløber udviklingsprojektet som en serie af sprints af 2-4 ugers varighed, der har til formål at realisere projektets Product Backlog (kravspecifikation). Hvert sprint gennemføres med fuld gennemsigtighed for kunden og bliver afsluttet med et konkret resultat. SCRUM sætter fokus på hele tiden at levere forretningsværdi, og det er dokumenteret, at SCRUM principperne øger teamets produktivitet samt sikrer en bedre håndtering af skiftende krav igennem et projektforløb.

Overdragelse til kundens organisation
Når udviklingsprojektet er nået til vejs ende på udviklingscenteret i Manila, Filippinerne, kan CodeLean tilbyde bistand til overdragelse / implementering i Danmark - naturligvis fortsat med mulighed for at trække på teknisk bistand fra Manila kontoret. Herudover vil CodeLean naturligvis tilbyde kunden at indgå en support- og vedligeholdelsesaftale, der sikrer, at nye krav og ændringsønsker kan implementeres af de folk, der i forvejen har en solid forståelse af kundens forretning og systemer.