Ferdigdefinisjon: Hva det er, og hvordan den brukes
Jevn kvalitet: En felles ferdigdefinisjon forebygger forvirring og forbedrer kvaliteten på arbeidet i hele teamet.
Bedre prognoser: En tydelig ferdigdefinisjon bidrar til nøyaktige prognoser for gjennomføringsevne og bedre prosjektplanlegging.
Vanlige fallgruver: Unngå å gjøre definisjonen for detaljert eller å unnlate å håndheve den, ettersom begge deler kan føre til problemer.
Praktiske trinn: Artikkelen beskriver konkrete trinn for å lage en vellykket ferdigdefinisjon for smidige team.
Definisjonen av ferdig (DoD) er den felles standarden som avgjør når arbeidet virkelig er fullført. Den bidrar til å forhindre kvalitetsmangler, omarbeid og overraskelser helt på slutten av sprinten. Jeg har sett utviklingsteam miste tillit, ikke rekke tidsfrister og skape unødvendige konflikter fordi alle hadde ulik tolkning av hva «ferdig» betydde.
I denne veiledningen lærer du hvordan du lager en definisjon av ferdig som samordner det smidige teamet ditt, forbedrer forutsigbarheten og styrker kvaliteten, i tillegg til at du får praktiske eksempler, maler og vanlige feil du bør unngå.
Hva er definisjonen av ferdig?
Definisjonen av ferdig er et formelt, felles sett med kriterier som et produktkøelement eller et inkrement må oppfylle før teamet anser det som fullført og mulig å lansere. Tenk på den som kvalitetsavtalen teamet ditt blir enige om å følge for hver arbeidsoppgave, uavhengig av størrelse eller kompleksitet.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Her er de viktigste kjennetegnene ved en effektiv definisjon av ferdig:
- Åpenhet: Alle i teamet og sentrale interessenter kan se den, lese den og bruke den som referanse når som helst.
- Målbar: Hvert kriterium er binært. Arbeidet oppfyller det enten eller ikke, men tersklene du velger for kvantitative kriterier, fortjener grundig vurdering. Et mål om 80 % kodedekning håndheves binært, men valget av 80 % fremfor 70 % eller 90 % er en skjønnsmessig vurdering du bør gjøre bevisst
- Universelt forstått: Alle medlemmer av Scrum-teamet må kunne tolke hvert punkt på samme måte.
- Konsekvent anvendt: Den samme sjekklisten må brukes på hver leveranse og hvert produktkøelement.
- Oppnåelig innenfor en sprint: Kriteriene bør være realistiske nok til at teamet kan oppfylle dem i løpet av én sprint eller iterasjon.
I programvareutviklingsprosjekter er det vanligvis utviklerne som eier definisjonen av ferdig, fordi det er de som er ansvarlige for å følge den. Når det er sagt, bør produkteieren og Scrum-masteren bidra.
Hvis organisasjonen din har egne standarder for definisjonen av ferdig, må alle Scrum-team følge disse som et minimumsnivå. Teamene kan alltid legge til strengere kriterier, men de kan ikke gå under organisasjonens minimumskrav.
Hvorfor definisjonen av ferdig er viktig
En tydelig definisjon av ferdig er viktig fordi den hindrer at delvis fullført arbeid slipper gjennom sprekkene, og gir en felles kvalitetsstandard.
Her er noen flere grunner til at en felles definisjon av ferdig er viktig:
- Fungerer som en innebygd kvalitetsport: Hvert element må oppfylle den samme standarden før det kan være ferdig. Dette hindrer at halvferdig arbeid sniker seg inn i produktinkrementet og hoper seg opp som teknisk gjeld.
- Fjerner uklarhet: Når teamet deler én definisjon, havner dere ikke i situasjoner der motstridende definisjoner påvirker arbeidets hastighet eller kvalitet. En felles definisjon av ferdig betyr færre konflikter, færre overraskelser og ryddigere demonstrasjoner.
- Forbedrer prognoser: Når ferdig betyr det samme i hver sprint, kan du beregne hastigheten med større trygghet og planlegge lanseringer uten å legge inn ekstra tid i estimatene for å ta høyde for omarbeid.
- Bygger tillit hos interessentene: Når produkteiere, ledelsen og eksterne interessenter ser at teamet håndhever en tydelig kvalitetsstandard, får de tillit til leveransene deres.
- Forhindrer integreringskaos: Hvis dere arbeider på en måte som krever at teamet integrerer arbeidet sitt i et felles inkrement, er en felles forståelse av definisjonen av ferdig grunnlaget for konsekvente inkrementer som kan lanseres.
Slik lager du en definisjon av ferdig
Her er de viktigste trinnene i prosessen med å lage en definisjon av ferdig.
- Gå gjennom den nåværende arbeidsflyten: Kartlegg hvert trinn arbeidet allerede går gjennom før det når produksjon. Snakk med utviklere, testere, designere og alle andre som arbeider med oppgaven. Du vil oppdage uformelle kvalitetstrinn som bør formaliseres.
- Identifiser ufravikelige kvalitetskriterier: Bestem hvilke aktiviteter som må gjennomføres for hver arbeidsoppgave. Dette omfatter vanligvis kodegjennomgang, automatisert testing, oppdatering av dokumentasjon og sikkerhetsskanninger. Vær ærlig om hva dere hopper over i dag.
- Utarbeid sjekklisten i fellesskap: Samle hele teamet og diskuter den ved hjelp av en tavle eller et delt dokument der alle kan legge til, utfordre og forbedre punkter i sanntid. En ferdigdefinisjon som er vedtatt gjennom konsensus, tåler press langt bedre enn en som ble stemt gjennom til tross for innvendinger.
- Valider mot organisasjonens standarder: Sammenlign utkastet med eventuelle kvalitetsretningslinjer som gjelder for hele selskapet, regulatoriske krav eller bransjestandarder produktet må oppfylle. Hvis organisasjonen allerede har en grunnleggende ferdigdefinisjon, kan du ta utgangspunkt i den og bygge videre på den.
- Gjør den synlig: Plasser ferdigdefinisjonen der teamet arbeider hver dag. Det kan være en plakat på veggen, en festet melding i Slack eller et panel i prosjektstyringsverktøyet.
- Forplikt dere til å håndheve den: En ferdigdefinisjon som settes til side når tidsfristene nærmer seg, er verre enn å ikke ha noen i det hele tatt, fordi den skaper en falsk følelse av kvalitet.
Eksempler på ferdigdefinisjoner
Her er noen eksempler på ferdigdefinisjoner for ulike typer prosjekter:
Ferdigdefinisjon for programvareutviklingsprosjekter
Programvareprosjekter står overfor et bredt spekter av kvalitetsrisikoer: feil, sikkerhetssårbarheter, ytelsesregresjoner og integrasjonsfeil. Ferdigdefinisjonen for et programvareteam må dekke hele veien fra kode til en utgivelsesklar tilstand.
Den kan se slik ut:
- All kode er skrevet og fagfellevurdert av minst én annen utvikler
- Enhetstester består med den avtalte terskelen for testdekning
- Integrasjonstestene er godkjent i CI/CD-pipelinen
- Ingen åpne feil med kritisk eller høy alvorlighetsgrad
- Den tekniske dokumentasjonen er oppdatert i tråd med endringene
- Koden er slått sammen med hovedgrenen
- Produkteieren har gjennomgått og godkjent arbeidet
- Ytelsesreferansene oppfyller de avtalte tersklene
Ferdigdefinisjon for markedsføringsprosjekter
Markedsføringsarbeid har ofte samsvars-, merkevare- og målingsaspekter som skiller seg fra programvare.
Slik kan ferdigdefinisjonen se ut for et markedsføringsprosjekt:
- Innholdet er gjennomgått og godkjent av juridisk avdeling
- SEO-sjekklisten er fullført, inkludert metabeskrivelser, alternativ tekst og interne lenker
- Alle ressurser er lastet opp til CMS-et og riktig formatert
- Analysesporing er konfigurert og bekreftet i testmiljøet
- Den endelige teksten er korrekturlest av et annet teammedlem
- Sjekklisten for kampanjelansering er godkjent av teamlederen
Ferdigdefinisjon for designprosjekter
Designteam trenger at ferdigdefinisjonen bygger bro mellom kreativ intensjon og teknisk overlevering. Uten en slik definisjon kommer designene ufullstendige til utviklingen, med manglende spesifikasjoner, uvalidert responsiv oppførsel eller tilgjengelighetsmangler som oppdages for sent.
Her er et eksempel på en ferdigdefinisjon for et designprosjekt:
- Designet er gjennomgått mot tilgjengelighetsstandardene i henhold til WCAG 2.2
- Overleveringsfilen er klargjort i det avtalte verktøyet med alle spesifikasjoner, ressurser og merknader
- Godkjenning fra interessentene er mottatt og dokumentert
- Designsystemets komponenter er oppdatert hvis nye mønstre ble introdusert
- Responsiv oppførsel er validert på tvers av de avtalte brytpunktene
Ferdigdefinisjon kontra akseptansekriterier
Ferdigdefinisjonen er teamets kvalitetsstandard, mens akseptansekriterier er funksjonelle krav på funksjonsnivå.
Tenk på definisjonen av ferdig som grunnlinjen som gjelder universelt, og akseptansekriterier som unike for hvert element i sprintkøen eller produktkøen. Et element i produktkøen er ferdig når det oppfyller både akseptansekriteriene og teamets definisjon av ferdig.
| Aspekt | Definisjon av ferdig | Akseptansekriterier |
|---|---|---|
| Omfang | Gjelder for hvert element i produktkøen og hver inkrement | Spesifikt for en individuell brukerhistorie eller et element i produktkøen |
| Eierskap | Eies av utviklerne, med innspill fra hele Scrum-teamet | Skrevet av eller sammen med produkteieren |
| Spesifisitet | Generelle kvalitetsstandarder for alt arbeid | Detaljerte funksjonelle krav for én arbeidsoppgave |
| Endringsfrekvens | Endres sjelden; oppdateres under sprintretrospektiver | Endres med hver nye brukerhistorie |
| Kontrollpunkt | Kontrolleres før et element merkes som fullført | Verifiseres under gjennomgang av historien eller akseptansetesting |
Vanlige fallgruver og feil
Her er noen vanlige feil du bør unngå når du lager definisjoner av ferdig:
- Hoppe over punkter for å jobbe raskere: Team under tidspress dropper ofte kriterier som sikkerhetsgjennomgang, tilgjengelighetstesting eller dokumentasjon. Dette skaper skjult teknisk gjeld som senere viser seg som feil, omarbeid eller problemer med etterlevelse.
- Gjøre sjekklisten for detaljert: En overdrevent detaljert definisjon av ferdig blir et byråkratisk pliktløp. Hvis sjekklisten har 30 punkter og utviklerne bruker mer tid på å krysse av bokser enn på å utvikle programvare, har dere gått for langt. Vær spesifikk nok til at den er meningsfull, men generell nok til at den forblir praktisk.
- Endre definisjonen av ferdig for hver historie: Hele poenget med definisjonen av ferdig er konsistens. Funksjonsspesifikke betingelser hører hjemme i akseptansekriteriene (for eksempel akseptansekriterier med gitt–når–så), ikke i definisjonen av ferdig.
- Aldri ta den opp til ny vurdering: En definisjon av ferdig bør utvikle seg etter hvert som praksisene modnes, verktøyene endres eller produktet vokser. Jeg foreslår å gå gjennom den under retrospektiver minst én gang i kvartalet, og å justere den når teamet oppdager mangler eller friksjon.
- Ikke håndheve den: En definisjon som fravikes når noen viktige ber om det, er ubrukelig. Scrum-masterens oppgave er å beskytte definisjonen, selv når en interessent ønsker å lansere noe som ikke oppfyller standarden. Hvis kriteriene jevnlig overstyres, mister teamet tilliten til standarden og slutter å ta den på alvor.
- Forveksle «ferdig» med distribuert: Definisjonen av ferdig avgjør om et inkrement kan lanseres, ikke om det er lansert. Et element i produktkøen kan være ferdig uten å være distribuert. Ikke legg til «distribuert til produksjon» i definisjonen av ferdig med mindre teamet faktisk har ansvar for hele lanseringsprosessen fra ende til annen.
- Unnlate å vise til den: Mange team har teknisk sett en definisjon av ferdig, men hvis ingen har sett på den siden den ble opprettet for seks måneder siden, fungerer den ikke som en kvalitetsstandard.
Hva skjer videre?
Bygg videre på de smidige prosessene og arbeidsmåtene dine med praktiske verktøy, maler og ekspertinnsikt gjennom et gratis DPM-medlemskap, og styrk systemene som hjelper team med å levere kvalitetsarbeid på en jevn måte.
