Definition of Done i Jira: aftal, hvad ”færdig” betyder

En udvikler afslutter en ændring og flytter Jira-sagen videre. En tester opdager, at den nye skærm virker, men at et eksisterende forløb er gået i stykker. Kundesupport hører om ændringen fra en forvirret kunde. Alle brugte ordet færdig, men mente noget forskelligt.

En Definition of Done giver teamet en fælles standard for færdiggørelse. Den gør de forventede kvalitetskontroller synlige, før arbejdet begynder, så gennemgangen afhænger mindre af, hvem der husker at stille det rigtige spørgsmål.

I denne vejledning laver vi et eksempel for et fiktivt kundeportalteam, skelner mellem fælles kvalitetskontroller og funktionsspecifikke acceptkriterier og placerer begge ved siden af en Jira-sag med Power Packs Definition of Done & AC-værktøj.

Hvad er en Definition of Done?

Scrum Guide beskriver Definition of Done som den kvalitetsstandard, et inkrement skal opfylde. Den giver en fælles forståelse af afsluttet arbejde. Hvis en organisation har fastlagt en standard, er den minimum for dens Scrum-teams. Se den officielle Scrum Guide.

Tænk i vores praktiske eksempel på den som et lille sæt spørgsmål, teamet stiller om hver relevant ændring. Er implementeringen gennemgået? Har de aftalte kontroller bestået? Er den information, folk skal bruge for at understøtte ændringen, tilgængelig?

De præcise spørgsmål afhænger af produktet og dets risici. En offentlig kundeportal, en intern rapport og et sikkerhedskritisk system kræver forskellige standarder. At kopiere et andet teams tjekliste uden diskussion kan efterlade vigtige huller og samtidig tilføje arbejde uden formål.

En nyttig standard beskriver et observerbart resultat. ”Høj kvalitet” udtrykker en ambition. ”De aftalte regressionskontroller er bestået med resultater linket fra Jira-sagen” beskriver noget, en reviewer kan undersøge.

Adskil fælles kvalitet fra funktionens adfærd

Vores fiktive team tilføjer notifikationsindstillinger. Kunderne skal kunne slå en ugentlig opsummeringsmail til eller fra. Vigtige kontobeskeder ligger uden for den indstilling.

Funktionen kræver sine egne acceptkriterier. For eksempel skal et gemt valg stadig vises, efter at kunden logger ud og vender tilbage. Kravet hører til denne funktion, fordi det beskriver kundens forventede oplevelse.

Definition of Done dækker den bredere standard for færdiggørelse. Gennemgang af implementeringen, kontrol af berørt eksisterende adfærd og opdatering af supportvejledning kan gælde mange forskellige ændringer.

Begge lister er vigtige. En funktion kan virke som ønsket og stadig mangle væsentligt kvalitetsarbejde. Tilsvarende fastslår gennemgået kode og beståede regressionskontroller ikke, at den ønskede funktion opfører sig korrekt.

Start med de huller, teamet faktisk ser

Saml de personer, der bygger, kontrollerer og understøtter produktet, til en kort diskussion. Brug et nyligt eksempel på arbejde, der virkede færdigt, men krævede uventet opfølgning.

Vores portalteam identificerer tre tilbagevendende problemer. Reviewkommentarer forbliver nogle gange uløste. Eksisterende kontoindstillinger får begrænset regressionsdækning. Supportinstruktioner kommer, efter at funktionen er tilgængelig.

Problemerne peger på nyttige kontroller. De giver også teamet en grund til at holde standarden kort: hvert punkt skal forhindre en genkendelig fejl eller fastlægge en nødvendig kvalitetsbetingelse.

Spørg, hvordan hvert foreslået punkt skal verificeres. Hvis ingen kan beskrive dokumentationen, skal formuleringen forbedres, før punktet vedtages. ”Dokumentation færdig” kan betyde udgivelsesnoter, interne designnoter eller en hjælpeartikel til kunder. Aftal, hvilken information der er nødvendig, og hvor den hører til.

Aftal også, hvem der normalt udfører kontrollerne. Den samtale kan foregå i jeres sædvanlige planlægningsproces. En tjekliste alene tildeler ikke en reviewer og reserverer ikke tid i nogens kalender.

Lav et udkast til en praktisk fælles tjekliste

Her er portalteamets første udkast. Det er en illustrativ arbejdsaftale, ikke en universel standard.

• Implementeringsgennemgangen er afsluttet, og påkrævede reviewkommentarer er løst.
• Sagens aftalte acceptkriterier er verificeret.
• Aftalte regressionskontroller af berørte kontoforløb er bestået.
• Aftalte tilgængelighedskontroller af ændrede skærme er bestået.
• Supportvejledningen afspejler den ændrede kundeadfærd.
• Verifikationsresultater og relevante reviewlinks er registreret på Jira-sagen.

Før teamet bruger tjeklisten, skriver det ned, hvad regressions- og tilgængelighedskontrollerne omfatter. Ellers kan to personer sætte kryds ved samme sætning efter at have udført forskelligt arbejde.

For portalen omfatter det aftalte regressionssæt login, åbning af kontoindstillinger og opdatering af et eksisterende profilfelt. Tilgængelighedsgennemgangen af ændret betjening omfatter tastaturbetjening, synligt fokus og forståelige labels. Det er eksempler på teamets valgte kontroller, ikke en komplet tilgængelighedsstandard.

Supportpunktet kræver også en praktisk fortolkning. Hvis en ændring ikke påvirker kunderne, bør teamet på forhånd fastlægge en passende standard for den type arbejde. Undgå at lade reviewere improvisere undtagelser blot for at gøre en liste grøn.

Tilføj standarden til en Jira-sag

Åbn den relevante Jira-sag, og find Power Packs Definition of Done & AC-kort. Det har separate faner for Acceptance Criteria og Definition of Done. Vælg Definition of Done, før du tilføjer de fælles kontroller.

Ved en kort liste skriver du en kontrols titel og vælger Add eller trykker Enter. Hold hver titel fokuseret på én betingelse, der kan gennemgås. En lang sætning med tre uafhængige kontroller gør delvis færdiggørelse svær at vise.

Du kan også vælge Bulk Import og indsætte en Markdown-liste. Indsæt for eksempel de seks punkter ovenfor med en bindestreg og et mellemrum først på hver linje. Almindelige Markdown-afkrydsningsfelter understøttes også.

Import tilføjer punkter til den valgte fane. Kontrollér fanen, før du bekræfter, og gennemgå listen bagefter. Import af samme indhold igen kan tilføje punkter, der allerede findes, så brug funktionen bevidst frem for som en opdateringshandling.

Brug umarkerede punkter til arbejde, der endnu ikke er verificeret. Markerede Markdown-afkrydsningsfelter importeres som færdige; kopierede markeringer fra en tidligere sag må ikke erstatte gennemgang af den aktuelle ændring.

Den aftalte standard skal placeres manuelt i hver relevant sag. Behold en referencekopi i teamets normale dokumentation, og indsæt de passende kontroller i nye sager. Processen er en teampraksis, ikke en automatisk forbindelse mellem en central standard og alle sager.

Gennemgå en reel reviewproces

Antag, at funktionen til notifikationsindstillinger er klar til gennemgang. Maya kontrollerer kunderesultaterne, mens Priya verificerer det aftalte regressionssæt. Leo løser de resterende kommentarer fra implementeringsgennemgangen og linker reviewdokumentationen.

Første gennemgang viser, at indstillingen gemmes korrekt, men at tastaturfokus forsvinder efter valg af Save. Teamet lader tilgængelighedskontrollen stå uafsluttet, registrerer problemet i sin normale Jira-diskussion og retter det, før den relevante kontrol gentages.

Supportvejledningen er også ufærdig. Det forbliver synligt, selvom de funktionsspecifikke acceptkriterier er færdige. De separate lister hjælper med at forklare, hvorfor teamet stadig har arbejde tilbage.

Vælg en kontrols Done-knap, når den faktisk er bestået. Vælg den igen, hvis nye oplysninger betyder, at punktet skal tilbage til at gøre. Registrer testresultater, reviewlinks og vigtige beslutninger gennem teamets normale Jira- eller dokumentationsproces.

Et afsluttet punkt registrerer teamets vurdering. Det udfører ikke kontrollen, indsamler ikke dokumentationen og fastslår ikke, hvem der verificerede. Hvis reviewerens identitet eller tidspunktet er vigtigt, skal oplysningerne registreres udtrykkeligt i jeres normale reviewproces.

Læs parathedsindikatoren omhyggeligt

Værktøjet viser antal færdige punkter og samlet antal for hver fane. Parathedsindikatoren viser kun Ready for Release, når begge lister indeholder mindst ét punkt, og alle punkter på begge lister er færdige. Ellers vises In Verification.

Reglen gør indikatoren nyttig til at opdage uafsluttede punkter. Den forklarer også, hvorfor en færdig Definition of Done-liste ikke giver den helt færdige status, mens Acceptance Criteria er tom.

Betragt teksten som en opsummering af tjeklistens status. Den beviser ikke, at kontrollerne var tilstrækkelige, at dokumentationen var overbevisende, eller at produktet er sikkert at udgive. Et team kan markere en dårligt formuleret kontrol som færdig lige så let som en nyttig.

Tjeklisten blokerer heller ikke en Jira-overgang eller sammenfletning af en pull request. Fortsæt med at bruge teamets normale leverings- og udgivelsesproces til de beslutninger.

Hold standarden nyttig, når arbejdet ændres

Gennemgå standarden, når en gentagen fejl afslører en manglende kontrol, når produktet ændres væsentligt, eller når en eksisterende kontrol ikke længere giver nyttig information.

Portalteamet kan for eksempel opdage, at ændringer i indstillinger virker straks, men fejler efter en forsinket synkronisering. Det kan føre til en bredere verifikationsregel for funktioner, der afhænger af forsinket behandling. Teamet bør først afgøre, hvilke ændringer reglen gælder, og hvilken dokumentation der viser succes.

Opdater referencestandarden, og drøft, hvordan ændringen anvendes på igangværende arbejde. Eksisterende sagslister arver ikke ændringen automatisk. Gennemgå berørte sager, og tilføj de nye aftalte kontroller manuelt, hvor det er passende.

Undgå at udvide tjeklisten efter hver enkeltstående fejl. Nogle gange er et konkret acceptkriterium, en tydeligere implementeringsopgave eller en ændring af reviewprocessen en bedre reaktion. Den fælles standard skal forblive noget, teamet kan forstå og reelt anvende.

Prøv det på én aktuel sag

Vælg en sag, der nærmer sig review. Aftal en kort fælles kvalitetsstandard, placér den på fanen Definition of Done, og tilføj sagens specifikke kunderesultater under Acceptance Criteria.

Gennemgå kontrollerne sammen, og link dokumentationen der, hvor teamet normalt registrerer den. Markér først punkter som færdige efter verifikation, og gennemgå derefter det resterende arbejde via jeres sædvanlige leveringsproces.

Det nyttige resultat er en tydeligere samtale. Når nogen siger, at ændringen af notifikationsindstillinger er færdig, kan teamet forklare, hvilke resultater der virker, hvilke kvalitetskontroller der er bestået, og hvad konklusionen bygger på.

• Scrum Guide — Definition of Done