Definition of Done i Jira: avtal hva «ferdig» betyr

En utvikler fullfører en endring og flytter Jira-saken videre. En tester oppdager at den nye skjermen fungerer, men at en eksisterende flyt er ødelagt. Kundestøtte hører om endringen fra en forvirret kunde. Alle brukte ordet ferdig, men mente forskjellige ting.

En Definition of Done gir teamet en felles ferdigstandard. Den gjør forventede kvalitetskontroller synlige før arbeidet begynner, slik at gjennomgangen blir mindre avhengig av hvem som husker å stille riktig spørsmål.

I denne veiledningen lager vi et eksempel for et fiktivt kundeportalteam, skiller felles kvalitetskontroller fra funksjonsspesifikke akseptansekriterier og legger begge ved siden av en Jira-sak med Power Packs Definition of Done & AC-verktøy.

Hva er en Definition of Done?

Scrum Guide beskriver Definition of Done som kvalitetsstandarden et inkrement må oppfylle. Den gir en felles forståelse av fullført arbeid. Når en organisasjon har fastsatt en standard, er den minimum for Scrum-teamene. Se den offisielle Scrum Guide.

I det praktiske eksemplet kan du se den som et lite sett spørsmål teamet stiller om hver relevant endring. Er implementeringen gjennomgått? Har de avtalte kontrollene bestått? Er informasjonen som trengs for å støtte endringen tilgjengelig?

De nøyaktige spørsmålene avhenger av produktet og risikoene. En offentlig kundeportal, en intern rapport og et sikkerhetskritisk system trenger ulike standarder. Å kopiere et annet teams sjekkliste uten diskusjon kan gi viktige hull og samtidig legge til arbeid uten formål.

En nyttig standard beskriver et observerbart resultat. «Høy kvalitet» uttrykker en ambisjon. «De avtalte regresjonskontrollene er bestått, med resultater lenket fra Jira-saken» beskriver noe en kontrollør kan undersøke.

Skill felles kvalitet fra funksjonens atferd

Det fiktive teamet legger til varslingsinnstillinger. Kundene skal kunne slå en ukentlig oppsummeringsmail på eller av. Viktige kontomeldinger er utenfor denne innstillingen.

Funksjonen trenger egne akseptansekriterier. Et lagret valg må for eksempel fortsatt vises etter at kunden logger ut og kommer tilbake. Kravet hører til denne funksjonen fordi det beskriver kundens forventede opplevelse.

Definition of Done dekker den bredere ferdigstandarden. Gjennomgang av implementeringen, kontroll av påvirket eksisterende atferd og oppdatering av støtteveiledning kan gjelde mange forskjellige endringer.

Begge listene er viktige. En funksjon kan oppføre seg som ønsket og fortsatt mangle vesentlig kvalitetsarbeid. Tilsvarende viser ikke gjennomgått kode og beståtte regresjonskontroller at den ønskede funksjonen oppfører seg riktig.

Start med hullene teamet faktisk ser

Samle dem som bygger, kontrollerer og støtter produktet til en kort diskusjon. Bruk et nylig eksempel på arbeid som virket ferdig, men krevde uventet oppfølging.

Portalteamet identifiserer tre tilbakevendende problemer. Gjennomgangskommentarer blir noen ganger stående uløst. Eksisterende kontoinnstillinger får lite regresjonsdekning. Støtteinstruksjoner kommer etter at funksjonen er tilgjengelig.

Problemene peker mot nyttige kontroller. De gir også teamet en grunn til å holde standarden kort: hvert punkt bør forhindre en gjenkjennelig feil eller fastsette en nødvendig kvalitetsbetingelse.

Spør hvordan hvert foreslått punkt skal verifiseres. Hvis ingen kan beskrive dokumentasjonen, forbedre ordlyden før punktet tas i bruk. «Dokumentasjon ferdig» kan gjelde utgivelsesnotater, interne designnotater eller en hjelpeartikkel for kunder. Avtal hvilken informasjon som trengs og hvor den hører hjemme.

Avtal også hvem som vanligvis utfører kontrollene. Samtalen kan skje i den vanlige planleggingsprosessen. En sjekkliste alene tilordner ikke en kontrollør og reserverer ikke tid i noens kalender.

Lag et praktisk utkast til en felles sjekkliste

Her er portalteamets første utkast. Det er en illustrerende arbeidsavtale, ikke en universell standard.

• Implementeringsgjennomgangen er fullført og påkrevde kommentarer er løst.
• Sakens avtalte akseptansekriterier er verifisert.
• Avtalte regresjonskontroller for berørte kontoflyter er bestått.
• Avtalte tilgjengelighetskontroller for endrede skjermer er bestått.
• Støtteveiledningen gjenspeiler den endrede kundeatferden.
• Verifiseringsresultater og relevante gjennomgangslenker er registrert på Jira-saken.

Før sjekklisten brukes, skriver teamet ned hva regresjons- og tilgjengelighetskontrollene omfatter. Ellers kan to personer krysse av samme setning etter å ha gjort forskjellig arbeid.

For portalen omfatter det avtalte regresjonssettet innlogging, åpning av kontoinnstillinger og oppdatering av et eksisterende profilfelt. Tilgjengelighetsgjennomgangen av endrede kontroller omfatter tastaturbruk, synlig fokus og forståelige etiketter. Dette er eksempler på teamets valgte kontroller, ikke en fullstendig tilgjengelighetsstandard.

Støttepunktet trenger også en praktisk tolkning. Hvis en endring ikke påvirker kundene, bør teamet på forhånd fastsette en passende standard for den typen arbeid. Unngå at kontrollører må improvisere unntak bare for å gjøre listen grønn.

Legg standarden til en Jira-sak

Åpne den relevante Jira-saken og finn Power Packs Definition of Done & AC-kort. Det har separate faner for Acceptance Criteria og Definition of Done. Velg Definition of Done før du legger til felles kontroller.

For en kort liste skriver du kontrollens tittel og velger Add eller trykker Enter. La hver tittel fokusere på én vurderbar betingelse. En lang setning med tre urelaterte kontroller gjør delvis ferdigstillelse vanskelig å vise.

Du kan også velge Bulk Import og lime inn en Markdown-liste. Lim for eksempel inn de seks punktene ovenfor med bindestrek og mellomrom først på hver linje. Vanlige Markdown-avkrysningsbokser støttes også.

Import legger til punkter i valgt fane. Kontroller fanen før bekreftelse og listen etterpå. Å importere samme innhold igjen kan legge til punkter som allerede finnes, så bruk handlingen bevisst fremfor som en oppdatering.

Bruk uavkryssede punkter for arbeid som ikke er verifisert. Avkryssede Markdown-punkter importeres som ferdige; kopierte avkrysninger fra en tidligere sak erstatter ikke kontroll av den aktuelle endringen.

Den avtalte standarden må legges manuelt inn i hver relevant sak. Hold en referansekopi i teamets vanlige dokumentasjon, og lim passende kontroller inn i nye saker. Dette er en teampraksis, ikke en automatisk forbindelse mellom en sentral standard og hver sak.

Gå gjennom en reell kontroll

Anta at funksjonen for varslingsinnstillinger er klar for gjennomgang. Maya kontrollerer kunderesultatene, mens Priya verifiserer det avtalte regresjonssettet. Leo løser gjenstående implementeringskommentarer og lenker til gjennomgangsnotatet.

Første gjennomgang viser at innstillingen lagres riktig, men at tastaturfokus forsvinner etter valg av Save. Teamet lar tilgjengelighetskontrollen stå uferdig, registrerer problemet i den vanlige Jira-diskusjonen og retter det før den relevante kontrollen gjentas.

Støtteveiledningen er også uferdig. Det er fortsatt synlig selv om de funksjonsspesifikke akseptansekriteriene er fullført. De separate listene forklarer hvorfor teamet fortsatt har arbeid igjen.

Velg kontrollens Done-knapp når den faktisk har bestått. Velg den igjen hvis ny informasjon betyr at punktet bør tilbake til ugjort. Registrer testresultater, gjennomgangslenker og viktige beslutninger gjennom teamets vanlige Jira- eller dokumentasjonsprosess.

Et ferdig punkt registrerer teamets vurdering. Det utfører ikke kontrollen, samler ikke dokumentasjonen og fastslår ikke hvem som verifiserte. Hvis kontrollørens identitet eller tidspunktet er viktig, registrer det uttrykkelig i den vanlige gjennomgangsprosessen.

Les klarhetsindikatoren nøye

Verktøyet viser ferdige og totale antall for hver fane. Klarhetsindikatoren viser bare Ready for Release når begge listene inneholder minst ett punkt og alle punktene i begge listene er ferdige. Ellers viser den In Verification.

Regelen gjør indikatoren nyttig for å oppdage uferdige punkter. Den forklarer også hvorfor en ferdig Definition of Done-liste ikke gir den helt ferdige tilstanden mens Acceptance Criteria er tom.

Behandle teksten som en oppsummering av sjekklistestatusen. Den beviser ikke at kontrollene var tilstrekkelige, dokumentasjonen overbevisende eller produktet trygt å gi ut. Et team kan merke en dårlig skrevet kontroll som ferdig like lett som en nyttig.

Sjekklisten blokkerer heller ikke en Jira-overgang eller sammenslåing av en pull request. Fortsett å bruke teamets vanlige leveranse- og utgivelsesprosess for disse beslutningene.

Hold standarden nyttig når arbeidet endres

Gjennomgå standarden når en gjentatt feil avdekker en manglende kontroll, produktet endres vesentlig eller en eksisterende kontroll slutter å gi nyttig informasjon.

Portalteamet kan for eksempel oppdage at innstillingsendringer fungerer umiddelbart, men feiler etter en forsinket synkronisering. Funnet kan føre til en bredere verifiseringsregel for funksjoner som avhenger av forsinket behandling. Teamet bør først avgjøre hvilke endringer regelen gjelder og hvilken dokumentasjon som viser suksess.

Oppdater referansestandarden og diskuter hvordan endringen skal brukes på pågående arbeid. Eksisterende sakslister arver ikke revisjonen automatisk. Undersøk berørte saker og legg til nye avtalte kontroller manuelt der det passer.

Unngå å utvide sjekklisten etter hver enkeltstående feil. Noen ganger er et spesifikt akseptansekriterium, en tydeligere implementeringsoppgave eller en endring i gjennomgangsprosessen et bedre svar. Den felles standarden bør forbli noe teamet kan forstå og faktisk bruke.

Prøv den på én aktuell sak

Velg en sak som nærmer seg gjennomgang. Avtal en kort felles kvalitetsstandard, legg den i Definition of Done-fanen og legg sakens spesifikke kunderesultater under Acceptance Criteria.

Gå gjennom kontrollene sammen og lenk dokumentasjonen der teamet vanligvis registrerer den. Merk punkter ferdige først etter verifisering og vurder resten av arbeidet gjennom vanlig leveranseprosess.

Det nyttige resultatet er en tydeligere samtale. Når noen sier at endringen av varslingsinnstillinger er ferdig, kan teamet forklare hvilke resultater som fungerer, hvilke kvalitetskontroller som besto, og hvor konklusjonen kom fra.

• Scrum Guide — Definition of Done