Scrum er en smidig metodikk for programvareutvikling som nå blir tatt i bruk av mange selskaper og bedrifter som en del av digitale transformasjonsinitiativer.
Innholdsfortegnelse
Om Scrum
Rollen til Scrum-metodikken er å gi et rammeverk for smidig programvareutvikling som gjør det mulig for team å samarbeide og effektivt for å levere programvareprodukter av høy kvalitet.
Det er et rammeverk for team å jobbe sammen for å utvikle komplekse produkter. I stedet for å gi ut et produkt etter lange faser med planlegging, design, utvikling og testing, tar scrum sikte på å levere klare til bruk produkter helt fra begynnelsen i små trinn.
Scrums hovedprinsipper er transparent teamkommunikasjon, regelmessig kvalitetsverifisering og evnen til å tilpasse seg endringer. Hvis de tas i bruk og brukes på riktig måte, kan team levere programvareprodukter av høy kvalitet på en rettidig og effektiv måte.
Viktige fordeler med Scrum
Kilde: scrum.org
- Du kan oppnå økt produktivitet. Å være et Scrum-team betyr at teamet bryter ned komplekse problemer i små biter. Deretter blir de små bitene levert innen sprints som sprintøkninger. Teammedlemmer kan fokusere på spesifikke oppgaver innenfor en Sprint (definert tidsperiode trinnene utvikles på f.eks. to uker).
- Scrum oppmuntrer til regelmessig kommunikasjon mellom hele teamet. Dette sikrer da at alle er tydelige på omfanget og forventningene. Det reduserer ganske betydelig mengde misforståelser som ellers kunne skje. Spesielt hvis man ønsker å gå videre med høyt tempo fra sprint til sprint, må hele laget jobbe mot samme mål fra dag til dag.
- Scrum er designet for å være fleksibelt, slik at team kan tilpasse seg endrede krav og prioriteringer. Dette gjør at teamene kan reagere raskt på endringer i prosjektomfanget eller kundenes behov. I stedet for å vente til hele utviklingssyklusen er over, kan du bare endre innholdet mellom spurtene.
- Scrum understreker viktigheten av testing og kvalitetssikring, ideelt sett på en automatisert måte. Det endelige målet er å øke sluttproduktets kvalitet. Dette reduserer risikoen for feil og sikrer at produktet oppfyller kundens krav.
- Scrum er designet for å være kundefokusert, noe som betyr at kunden er involvert i utviklingsprosessen fra start til slutt, vanligvis i rollen som produkteier eller med direkte tilknytning til produkteier (mer om det senere). Dette sikrer at sluttproduktet møter kundens behov og med riktig prioritet.
Deretter vil vi diskutere rollen til scrum-metodikk.
Rollen til Scrum-metodikk
Kilde: hangoutagile.com
Målet med Scrum-metodikken er å gi et rammeverk for smidig programvareutvikling som gjør det mulig for team å samarbeide. Du bygger et Scrum-team som møtes daglig og regelmessig og har planlagte diskusjoner (seremonier) innenfor en sprint som gjentar hver sprint. Vanligvis er følgende seremonier en del av det grunnleggende oppsettet til et scrum-team:
- Daglige standups – En tid og et sted hvor alle teammedlemmene vil møtes og diskutere hva som ble gjort siste dag, hva som vil være arbeidet neste dag, og hva som er aktuelle hindringer, hvis noen.
- Forbedring av historier – Det er her nytt innhold (for de neste spurtene) diskuteres og avsluttes.
- Sprintplanlegging – Under denne seremonien estimerer teamet innholdet som er klart til å ta (definert i Stories) og forplikter seg deretter til et spesifikt delsett fra dem, hovedsakelig basert på prioriterings- og innsatsestimater.
- Sprintgjennomgang – Her møter teamet interessenter og presenterer for dem hva teamet oppnådde i siste sprint.
- Sprint retrospektiv – En dialog dedikert til teamet kun for å diskutere hva som kan forbedres eller hva teamet føler må endres fremover.
Betydningen av Scrum-metodikk ligger i dens evne til å hjelpe team til å jobbe mer effektivt. Kjerneprinsippene i Scrum-metodikken er basert på Agile Manifesto, og de er følgende.
Empirisk prosesskontroll
Scrum er basert på ideen om at fremgang best oppnås gjennom en empirisk prosess med kontinuerlig inspeksjon og tilpasning. Dette betyr at team regelmessig bør inspisere arbeidet sitt og tilpasse prosessene sine for å forbedre ytelsen.
Selvorganiserende team
Scrum-team er selvorganiserende, noe som betyr at de er ansvarlige for å administrere arbeidet sitt og ta beslutninger om å nå sine mål. Dette bidrar til å fremme samarbeid og ansvarlighet i teamet.
Tidsboksede iterasjoner
Du kan dele scrum-prosjekter inn i time-boxede iterasjoner, kalt sprints, som vanligvis varer mellom én og fire uker. Dette sikrer at teamet jobber mot et spesifikt mål og gjør fremgang med jevne mellomrom.
Prioritert produktbacklog
Produktbacklog er en prioritert liste over funksjoner og krav som teamet skal jobbe med i løpet av prosjektet. Produkteieren er ansvarlig for å opprettholde produktbacklog og sikre at den reflekterer kundens behov og prioriteringer.
Kontinuerlig forbedring
Scrum understreker viktigheten av kontinuerlig forbedring. Både når det gjelder produktet som utvikles og prosessene som brukes for å utvikle det. Dette betyr at team regelmessig bør reflektere over arbeidet sitt og se etter måter å forbedre ytelsen på.
Utfordringer
Kilde: scrum.org
Mens Scrum-metodikk kan være svært effektiv i programvareutvikling, er det også noen utfordringer som team kan møte når de implementerer den.
Motstand mot endring
Scrum krever et betydelig skifte i tankesett og kultur, noe som kan være vanskelig for noen teammedlemmer å akseptere. Noen teammedlemmer kan være motstandsdyktige mot endringer, noe som kan gjøre det utfordrende å implementere Scrum effektivt. Med andre ord, du må «få det». Inntil du ikke gjør det, er du ikke med.
Mangel på erfaring
Du trenger et visst nivå av erfaring og ekspertise for å implementere effektivt. Hvis teammedlemmer ikke er kjent med Scrum- eller Agile-metoder, representerer det en utfordring å overvinne.
Mangel på engasjement
Scrum trenger høyt engasjement fra alle teammedlemmer, inkludert produkteier, Scrum-mester og utviklingsteam. Hvis teammedlemmene ikke er helt forpliktet til prosessen, kan det være vanskelig å oppnå de ønskede resultatene.
Dårlig kommunikasjon
Scrum er avhengig av kommunikasjon og samarbeid mellom teammedlemmer. Hvis teammedlemmene ikke kommuniserer ofte og effektivt, kan det være utfordrende for dem.
Overvekt på prosess
Mens Scrum gir et rammeverk for smidig programvareutvikling, er det viktig å huske at det bare er et rammeverk. Hvis teammedlemmer blir for fokuserte på å følge prosessen, kan de miste det endelige målet om å levere høykvalitets programvareprodukter av syne.
Rollene til et Scrum-team
Hvert scrum-lag skal, for å være effektivt, bestå av noen få konkrete roller. Hvis disse rollene ikke er dedikert til laget eller i feil antall, kan den vellykkede oppbyggingen av et slikt scrum-team være i fare.
#1. Utviklingsteam
Dette er utførelsesdelen av teamet, så fra levering av produktperspektiv, kanskje den viktigste delen av teamet. Et typisk scrum-utviklingsteam består av utviklings-/test-/arkitektur-/analytikerspesialister i en total mengde på 4-10 personer. Er det mindre spørs det om man fortsatt kan kalle det et lag. Hvis det er mer, vil alle seremoniene og ledelsen av teamets diskusjoner bli altfor komplekse og egentlig ikke verdt innsatsen å opprettholde.
Utviklingsteamet tar historiene fra backlog, anslår dem og implementerer dem i sprints. Teamet er ansvarlig for historieutvikling og testing, og når det er gjort, også for distribusjon til produksjon.
#2. Scrum Master
En scrummaster fungerer som orkestrator for utviklingsteamet. Han planlegger jevnlige møter, sørger for at utviklingsteamet er tydelig i innholdet, og organiserer aktivitetene under en sprint med mål om å nå sprintplanen og målene.
Dette er egentlig ikke en innholdsrolle. Faktisk trenger ikke scrum-mesteren teknisk forstå noe fra historieinnholdet utviklingsteamet løser (selv om det hjelper helt sikkert). Scrummasteren betjener imidlertid utviklingsteamet og beskytter det mot det ytre miljøet. Med å beskytte mener jeg å la teamet jobbe basert på smidige prinsipper. Vær her foredragsholderen for teamet og ikke tillat å endre den nåværende avtalte sprintplanen ved uplanlagte forespørsler.
#3. Produkteier
Produkteier (PO) servere for kobling mellom utviklingsteamet og forretningsbrukere (interessenter) utenfor teamet. PO diskuterer innholdet vil alle relevante parter og bringer det avtalte innholdet til scrum-teamet.
Så lager PO historier for teamet med klare beskrivelser og forventninger. PO må sørge for at utviklingsteamet forstår dette innholdet slik at teamet kan anslå hver historie. Som sådan eier PO diskusjonene om historieforedling i teamet.
Bortsett fra innholdet og hele backlog-håndteringen, er PO også ansvarlig for å sette opp prioriteringer for hver historie i backlog. PO er imidlertid ikke ansvarlig for utvelgelsen av konkrete historier inn i sprinten. Det er det bare utviklingsteamet som kan gjøre ved å forplikte seg til omfanget, vil teamet velge for neste sprint. PO kan bare påvirke dette valget ved å angi og kommunisere prioriteringene på riktig måte.
Interaksjoner mellom roller i et Scrum-team
Kilde: scrum.org
Selv med alle menneskene og rollene som håndteres, er kommunikasjon virkelig nøkkelen til suksess. Viktigst, riktig kommunikasjon fordi det er så mange måter å gjøre det feil på. Og det er faktisk den største enkeltårsaken til at mange scrum-team ikke lykkes. De gjør det bare ikke riktig.
Produkteiere ber for eksempel ofte utviklingsteamet om å komme med nye innholdshistorier. Men det er ikke utviklingsteamets hensikt å skape etterslepet. Jada, de kan bidra til å definere historiene, gjøre dem detaljerte og dele dem opp for å være mulige å utføre innenfor spurter. Men produkteieren er ansvarlig for etterslepet. PO skal ideelt sett ikke be utviklingsteamet om å få kontakt med forretningsinteressenter.
På en annen måte, verken scrum-mesteren eller produkteieren skal definere nøyaktig hva som skal være omfanget av neste sprint. Dette skjer veldig ofte uansett siden rollene som scrum master og produkteier er en slags naturlige lederroller i scrum-teamet. Men i realiteten er de ikke i posisjon til å bestemme hva utviklingsteamet skal eller ikke skal ta inn i spurten. Utviklingsteamet er det eneste som kan utføre dette, så det er utviklerteamet som bestemmer. Det betyr at PO gir informasjon om hvor viktig hvilken historie er fra et forretningsperspektiv; PO kan til og med bestille etterslepet av historier fra de viktigste til de minst viktige. På denne måten har utviklingsteamet en følelse av hvilke historier de skal ta først.
Produkteieren skal gjøre en innsats for å jevnlig diskutere med teamet nytt innhold som PO ønsker at teamet skal levere. PO er her for grundig å diskutere hver historie han/hun lager eller bringer til etterslepet. Alle i utviklingsteamet må forstå historien, og det er klart for dem hva som er akseptkriteriene.
Scrum-mesteren er ikke bare orkestrator for laget; på en eller annen måte beskytter SM teamet mot produkteieren, ledelsen eller andre eksterne interessenter. SM holder de interne scrum-prosessene i gang og leder de fleste seremoniene for laget. På daglige statussamtaler sørger SM for at alle bare sier de viktige oppdateringene for dagen slik at møtet ikke tar lengre tid enn planlagt. Det gjelder faktisk alle samtalene.
SM organiserer også regelmessige retrospektive samtaler for teamet, hvor han/hun hjelper teamet med å reflektere tilbake på arbeidet som er gjort i forrige sprint og identifisere områder hvor teamet kan forbedre seg.
Siste ord
Å etablere et vellykket scrum-team er vanligvis en lang vei. Du må bygge erfaring i teamet, selv om konkrete medlemmer av teamet allerede har noe tidligere erfaring. Hvert scrum-team er unikt, og det tar alltid tid å finne en måte å jobbe og samarbeide sammen på som et team om vanlige emner.
Det viktigste er å holde laget stabilt når du allerede har dannet det. Først da kan laget begynne å forbedre seg for hver neste sprint. Det endelige målet er å konvertere til et selvorganiserende team, der selv en avskummester tilstedeværelse ikke er obligatorisk lenger mesteparten av tiden. Hvis du ikke klarer å holde teamet samlet, vil du fortsatt være i læringsfasen.
Deretter kan du sjekke ut de beste scrum-verktøyene for en oppstart til mellomstor bedrift.