Forventninger til Scrum-leveranser
Vanligvis forventes en utgivelse rett etter sprintens slutt, etter en vellykket demonstrasjon for kunden. Jeg har alltid stusset over denne automatiske forventningen, spesielt med tanke på de mange aktivitetene som må utføres før eller samtidig.
- Utvikling og fullføring av alle historier innenfor sprinten. Ofte blir historiene ferdige rett før sprintens slutt, kanskje til og med etter demonstrasjonen.
- Gjennomføring av alle planlagte tester for å sikre at koden er produksjonsklar.
- Håndtering og retting av feil oppdaget i testperioden.
- Sikre at distribusjonspipelinen er oppdatert med det nyeste innholdet og at den er pålitelig.
- Kjøring av pipelinen i alle relevante miljøer for å bringe dem til nyeste tilstand.
- Forberedelse av utgivelsesnotater og kommunikasjon med kunden om virkningen av utgivelsen.
- Synkronisering med andre scrum-team for å sikre at avhengigheter er på plass.
- Gjennomføring av alle scrum-seremonier, både for gjeldende og kommende sprint.
Tenk deg at en sprint varer i to uker. Disse aktivitetene krever tid og ressurser, men kan ikke ta for lang tid da neste sprint starter umiddelbart etter.
Virker forventningen om utgivelse etter hver sprint fortsatt like automatisk?
Behandling av utgivelsesinnhold
Hvis alle prosesser er automatisert, kan man kanskje bare «trykke på knappen» og installere nyeste kode i produksjon. Men jeg har sjelden sett dette i praksis. Det kan kanskje fungere i mindre private selskaper, men i større bedrifter er utgivelsesprosessen ofte forbundet med tidkrevende aktiviteter som strekker seg inn i neste sprint. Utgivelsen blir en stressende handling ingen ser frem til.
Derfor har jeg lett etter den beste løsningen for å håndtere utgivelser.
Løsningen ble å gjøre annenhver sprint til en utgivelsessprint. Her er hva det innebærer.
Separate kodeversjoner for neste utgivelse
Dette handler om å håndtere separate grener i Git. Det finnes mange måter å løse dette på, men jeg vil holde det enkelt for å demonstrere konseptet.
For å minimere påvirkningen på utviklingen, er det viktig å skille ut innholdet for neste utgivelse i en egen gren, kalt «Release Branch». Dette gir følgende fordeler:
- Utviklerne kan fortsette med nye historier i hovedgrenen uten avbrudd.
- Utgivelsesinnholdet er ikke utsatt for uventede endringer fra utviklingsteamet.
- Testaktiviteter kan gjennomføres i et isolert miljø, med kun nødvendige endringer for å rette feil.
- Utgivelses-pipelinen distribuerer kun innhold fra utgivelsesgrenen, og gir full kontroll over det som publiseres.
Dermed kan vi isolere utgivelsesinnholdet og la det modnes til en stabil versjon.
Tidsbestem utgivelser for repeterbarhet
Jeg måtte gi opp ambisjonen om utgivelse etter hver sprint. Det ble klart at dette ikke var praktisk gjennomførbart, da det:
- Påvirket innholdet i neste sprint.
- Gjorde det vanskelig å stabilisere utgivelsesinnholdet.
- Gjorde det vanskelig å gjennomføre nødvendige tester.
Målet ble å gjennomføre utgivelser etter annenhver sprint. Det vil innebære:
- En utgivelse vil inneholde historier fra de to foregående sprintene.
- En hel sprint er avsatt til testing og feilretting.
- Utgivelsesansvarlig har god tid til å samle informasjon (testsaker, notater) i sprinten uten utgivelse, og utviklingsteamet kan fokusere på nye historier.
- Ved feil, kan utgivelsesansvarlig raskt samarbeide med utviklerne om rettelser. Noe tid fra teamets kapasitet må settes av til feilretting.
Dette betyr at brukerne ikke får det nyeste innholdet i hver utgivelse, men over tid vil dette bli irrelevant da de uansett får to sprintes innhold hver gang.
Dette ser ut som et godt kompromiss mellom rask levering og et stabilt arbeidsmiljø.
Gjennomfør utgivelsesimplementeringen
Når testing, feilretting og forberedelse av pipelinen er fullført, er det enkelt å gjennomføre distribusjonen til produksjon. Dette kan i praksis være en umerkelig aktivitet. Dette er det beste scenarioet.
Forutsetningen er en robust automatisert DevOps-pipeline. Dette gjelder ikke bare for produksjonsmiljøet, men også for alle andre miljøer (dev, sandbox, test, QA, ytelse). Det skal være «ett-klikks»-distribusjon for alle miljøer.
En utgivelse skal ikke være stressende eller et mareritt alle frykter. Hvis ingen legger merke til det, er det det beste tegnet på en vellykket utgivelse.
Slå sammen utgivelsesgrenen tilbake til utviklingsgrenen
Utgivelsesgrenen inneholder rettelser fra testperioden som ikke finnes i utviklingsgrenen. Dette innholdet må slås sammen tilbake til utviklingsgrenen.
Utgivelsesgrenen fungerer som en nød-produksjonskode. Ved presserende feil, kan denne grenen brukes. Dette er den eksakte kopien av produksjonskoden uten uutgitt innhold.
Når ny testperiode starter, slettes forrige utgivelsesgren og erstattes med en ny. Den nye grenen er en kopi av den nåværende utviklingsgrenen.
Etabler regelmessige utgivelser
Dette gir en robust prosess for utgivelser. Det eneste som gjenstår er å holde det regelmessig, i dette tilfellet annenhver sprint.
Regelmessige utgivelser gjør prosessen enklere:
- Mindre innhold å installere til produksjon hver gang.
- Mindre testaktivitet og enklere testcases.
- Teamet blir vant til syklusen.
- Data i utviklings- og testmiljøer oppdateres jevnlig.
Konklusjon
Dette avslutter mine innlegg om scrum-livssyklusen og hva som fungerer i praksis.
Mange lag starter med scrum og gjør feil, men utvikler seg over tid. Denne serien kan hjelpe andre lag med å gjøre denne utviklingen raskere.
Denne tilnærmingen er ikke den eneste, og den er ikke uten utfordringer. Lag må håndtere disse. Forbedre det som kan forbedres og glem det som ikke fungerer.
Denne tilnærmingen, selv om den er enkel, viser at endring er mulig. Fra kaotiske spurter til stabil levering med regelmessige utgivelser som kan planlegges. Dette krever ikke komplisert metodikk, bare enkle regler og vilje til å følge planen.