Scrum: Forskelle mellem versioner

Content deleted Content added
No edit summary
No edit summary
Linje 1:
'''Scrum''' er en [[Agil systemudvikling|agil]] udviklingsmetode skabt i starten af 1990'erne med meget fokus på [[projektledelse]].
 
Historisk er Scrum 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. Der er dog ingen grund til at studere rugby for at forbedre systemudviklingsprocessen i sin organisation.
 
== Overordnet ==
Linje 19:
* Samarbejde mellem udviklingshold
 
== Roller ==
Ordet Scrum er en term fra [[rugby]] og en forkortelse for 'scrummage' som betyder skærmydsler.
 
; Product Owner
På dansk er det en produktejer eller systemejer, begge betegnelser bruges på dansk. Scrum er udvikling drevet af forretningsværdi og produktejeren er derfor uundværlig. Det gør samtidig produktejeren til den 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]]. <br>
Forretningsværdien bestemmer prioritering og dermed leveringsrækkefølgen, hvor det bliver fastsat efter devisen om levere de vigtigste 10% af kravene så hurtigt som muligt og derefter analyserer og designe de sidste 90% af kravene. Scrum bruger to af de mest betydningsfulde faktorer i succesfulde projekter, som er brugerindflydelse direkte i projektet og effektiv kravstyring, hvor produktejeren står for kravstyringen og samtidig også med til at reducere risikoen for fejlagtige investeringer i systemudvikling og afgør / beslutter behovet for ændringer.
 
Produktejeren kan behøve hjælp med det rent praktiske i at vedligeholde ProductBacklog i at få oprettet gode Userstories i produktbackloggen. Denne hjælp ydes ofte af projektets Scrum Master.
 
; Scrum Master
Scrum Master er ikke holdets leder, men virker som en buffer mellem holdet og eventuelle forstyrrende påvirkninger. Det kan dog ofte være den 'normale' daglige leder, for eksempel gruppe- eller projektlederen, men der er intet i vejen for at have en Scrum Master, der udpeges specifikt til jobbet. Det er alene et spørgsmål om at have ressourcer til det. Der er desuden stor forskel på projektlederprofiler i forskellige organisationer, og man skal vurdere, om de projektledere, man har, er i stand til at fjerne problemer og rydde vejen for teamet. Der er ikke brug for administratorer, men der er brug for handlekraft. En Scrum Master er dog ofte og fejlagtigt omtalt som en projektleder. Forskellen er, at mens projektlederen også kan have folk ledelsesansvar udover rollen som Scrum Master, skal en Scrum Master ikke have et sådant ekstra personaleansvar.
 
Scrum Master er projektets daglige adgang til virksomhedens ledelse.
 
Selvfølgelig er en ScrumMaster's arbejde ikke alene at imødekomme behovene i det team, han eller hun er ansvarlig for. Han eller hun skal også hjælpe produktejeren og maksimere produktiviteten. Det gøres blandt andet ved at synliggøre produktiviteten for produktejeren som kan omfatte hjælpe med vedligeholde produktets backlog, release plan eller andre iøjnefaldende Scrum artefakter for at sikre at produktejeren er informeret om teamets fremdrift.
 
; Development Team
Teamet påtager sig arbejde til den kommende Sprint på SprintPlanningWorkshop og afgør selv, hvor meget man kan påtage sig til et [Sprint]. Det er en skidt begyndelse, hvis der trækkes urealistiske eller for den sags skyld blot ukendte estimater ned over hovedet på dem. Teamets størrelse er identisk med de teamstørrelser, der arbejdes med i [[eXtreme Programming]]. 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 idet teamet arbejder med en høj grad af selvforvaltning og arbejder cross-functional i det videst mulig omfang. Det vil sige at de påtager sig alle de aktiviteter der er mulige og hjælper hinanden, teamet, og dermed sig selv.
 
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 og pligt at ændre på det eksisterende estimat. 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. Herudover orpetter teamet selv en 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.
 
== Artefakter ==