GuiderPower Pack8 min läsning

Definition of Done i Jira: kom överens om vad ”klart” betyder

Bygg en praktisk kvalitetschecklista, tillämpa den på ett Jira-ärende och granska färdigställandet med underlag.

Olika ändringar kan dela en färdigstandard och samtidigt ha egna acceptanskriterier.

En utvecklare slutför en ändring och flyttar Jira-ärendet vidare. En testare upptäcker att den nya skärmen fungerar, men att ett befintligt flöde har gått sönder. Kundsupporten får höra om ändringen från en förvirrad kund. Alla använde ordet klart, men menade olika saker.

En Definition of Done ger teamet en gemensam standard för färdigt arbete. Den gör de förväntade kvalitetskontrollerna synliga innan arbetet börjar, så att granskningen blir mindre beroende av vem som kommer ihåg att ställa rätt fråga.

I den här guiden bygger vi ett exempel för ett fiktivt kundportalteam, skiljer gemensamma kvalitetskontroller från funktionsspecifika acceptanskriterier och placerar båda intill ett Jira-ärende med Power Packs verktyg Definition of Done & AC.

Vad är en Definition of Done?

Scrum Guide beskriver Definition of Done som den kvalitetsstandard ett inkrement måste uppfylla. Den ger en gemensam förståelse av färdigt arbete. När en organisation har fastställt en standard är den miniminivån för dess Scrum-team. Se den officiella Scrum Guide.

I vårt praktiska exempel kan du tänka på den som ett litet antal frågor som teamet ställer om varje relevant ändring. Har implementationen granskats? Har de överenskomna kontrollerna godkänts? Finns informationen som behövs för att stödja ändringen?

De exakta frågorna beror på produkten och dess risker. En offentlig kundportal, en intern rapport och ett säkerhetskritiskt system behöver olika standarder. Att kopiera ett annat teams checklista utan diskussion kan lämna viktiga luckor och samtidigt lägga till meningslöst arbete.

En användbar standard beskriver ett observerbart resultat. ”Hög kvalitet” uttrycker en ambition. ”De överenskomna regressionskontrollerna har godkänts, med resultat länkade från Jira-ärendet” beskriver något en granskare kan inspektera.

Skilj gemensam kvalitet från funktionens beteende

Vårt fiktiva team lägger till aviseringsinställningar. Kunder ska kunna slå på eller av ett veckosammanfattningsmejl. Viktiga kontomeddelanden ligger utanför inställningen.

Funktionen behöver egna acceptanskriterier. Ett sparat val måste till exempel fortfarande visas när kunden har loggat ut och kommer tillbaka. Kravet hör till funktionen eftersom det beskriver vad kunden ska uppleva.

Definition of Done omfattar den bredare färdigstandarden. Att granska implementationen, kontrollera påverkat befintligt beteende och uppdatera supportvägledning kan gälla många olika ändringar.

Vad kontrollerar vi?De överenskomna regressionskontrollerna har godkänts.Att stänga av veckosammanfattningar stoppar nästa tillämpliga sammanfattning.
Var gäller det?Relevanta ändringar i hela produkten.Ärendet för aviseringsinställningar.
Vilket underlag hjälper?Länkade regressionsresultat för ändringen.En dokumenterad kontroll med ett konto där sammanfattningar är avstängda.

Båda listorna spelar roll. En funktion kan bete sig som önskat men sakna viktigt kvalitetsarbete. På samma sätt fastställer inte granskad kod och godkända regressionskontroller att den efterfrågade funktionen fungerar rätt.

Börja med luckorna teamet faktiskt ser

Samla personerna som bygger, verifierar och stödjer produkten till en kort diskussion. Använd ett nyligt exempel på arbete som verkade klart men krävde oväntad uppföljning.

Vårt portalteam identifierar tre återkommande problem. Granskningskommentarer lämnas ibland olösta. Befintliga kontoinställningar får liten regressionstäckning. Supportinstruktioner kommer efter att funktionen blivit tillgänglig.

Problemen pekar på användbara kontroller. De ger också teamet ett skäl att hålla standarden kort: varje punkt bör förebygga ett igenkännbart fel eller fastställa ett nödvändigt kvalitetsvillkor.

Fråga hur varje föreslagen punkt ska verifieras. Om ingen kan beskriva underlaget, förbättra formuleringen innan ni antar den. ”Dokumentation klar” kan avse releaseinformation, interna designanteckningar eller en hjälpartikel för kunder. Kom överens om vilken information som behövs och var den hör hemma.

Kom också överens om vem som normalt utför kontrollerna. Det samtalet kan ske i er vanliga planeringsprocess. En checklista tilldelar inte i sig en granskare och reserverar inte tid i någons kalender.

Skapa ett praktiskt utkast till en gemensam checklista

Här är portalteamets första utkast. Det är ett illustrativt arbetsavtal, inte en universell standard.

  • Implementationsgranskningen är klar och obligatoriska granskningskommentarer är lösta.
  • Ärendets överenskomna acceptanskriterier har verifierats.
  • Överenskomna regressionskontroller för påverkade kontoflöden har godkänts.
  • Överenskomna tillgänglighetskontroller för ändrade skärmar har godkänts.
  • Supportvägledningen speglar det ändrade kundbeteendet.
  • Verifieringsresultat och relevanta granskningslänkar finns på Jira-ärendet.

Innan teamet använder checklistan skriver det ned vad regressions- och tillgänglighetskontrollerna omfattar. Annars kan två personer bocka av samma mening efter att ha gjort olika arbete.

För portalen omfattar den överenskomna regressionsuppsättningen inloggning, öppning av kontoinställningar och uppdatering av ett befintligt profilfält. Tillgänglighetsgranskningen av ändrade reglage omfattar tangentbordsanvändning, synligt fokus och begripliga etiketter. Detta är exempel på teamets valda kontroller, inte en fullständig tillgänglighetsstandard.

Supportpunkten behöver också en praktisk tolkning. Om en ändring inte påverkar kunderna bör teamet i förväg fastställa en lämplig standard för den typen av arbete. Undvik att låta granskare improvisera undantag bara för att få en grön lista.

Lägg till standarden på ett Jira-ärende

Öppna det relevanta Jira-ärendet och hitta Power Packs kort Definition of Done & AC. Det har separata flikar för Acceptance Criteria och Definition of Done. Välj Definition of Done innan du lägger till de gemensamma kontrollerna.

För en liten lista skriver du en kontrolltitel och väljer Add eller trycker på Enter. Låt varje titel fokusera på ett granskningsbart villkor. En lång mening med tre orelaterade kontroller gör det svårt att visa delvis färdigställande.

Du kan också välja Bulk Import och klistra in en Markdown-lista. Klistra till exempel in de sex punkterna ovan med bindestreck och mellanslag i början av varje rad. Vanliga Markdown-kryssrutor stöds också.

Import lägger till poster på den valda fliken. Kontrollera fliken innan du bekräftar och inspektera listan efteråt. Att importera samma innehåll igen kan lägga till poster som redan finns, så använd funktionen medvetet och inte som en uppdateringsåtgärd.

Använd omarkerade poster för arbete som ännu inte har verifierats. Markerade Markdown-kryssrutor importeras som klara; kopierade bockar från ett tidigare ärende ska inte ersätta granskning av den aktuella ändringen.

Den överenskomna standarden måste läggas in manuellt i varje relevant ärende. Behåll en referenskopia i teamets vanliga dokumentation och klistra in lämpliga kontroller i nya ärenden. Processen är en teamrutin, inte en automatisk koppling mellan en central standard och varje ärende.

Gå igenom en verklig granskning

Anta att aviseringsinställningarna är redo för granskning. Maya kontrollerar kundresultaten medan Priya verifierar den överenskomna regressionsuppsättningen. Leo löser återstående kommentarer från implementationsgranskningen och länkar granskningsunderlaget.

Första genomgången visar att inställningen sparas korrekt, men att tangentbordsfokus försvinner efter valet Save. Teamet lämnar tillgänglighetskontrollen ofärdig, dokumenterar problemet i sin vanliga Jira-diskussion och rättar det innan den relevanta kontrollen upprepas.

Supportvägledningen är också ofärdig. Det förblir synligt trots att funktionens acceptanskriterier är klara. De separata listorna hjälper till att förklara varför teamet fortfarande har arbete kvar.

Välj kontrollens Done-knapp när den faktiskt har godkänts. Välj den igen om ny information innebär att punkten ska återgå till att göra. Dokumentera testresultat, granskningslänkar och viktiga beslut genom teamets vanliga Jira- eller dokumentationsprocess.

En färdig punkt registrerar teamets bedömning. Den utför inte kontrollen, samlar inte underlaget och fastställer inte vem som verifierade. Om granskarens identitet eller tidpunkten spelar roll, dokumentera informationen uttryckligen i er vanliga granskningsprocess.

Läs beredskapsindikatorn noggrant

Verktyget visar antalet färdiga poster och totalt antal på varje flik. Beredskapsindikatorn visar Ready for Release endast när båda listorna innehåller minst en post och alla poster i båda listorna är klara. Annars visas In Verification.

Regeln gör indikatorn användbar för att upptäcka ofärdiga poster. Den förklarar också varför en färdig Definition of Done-lista inte ger läget helt klart medan Acceptance Criteria är tom.

Se formuleringen som en sammanfattning av checklistans status. Den bevisar inte att kontrollerna var tillräckliga, att underlaget var övertygande eller att produkten är säker att släppa. Ett team kan markera en dåligt formulerad kontroll som klar lika lätt som en användbar.

Checklistan blockerar inte heller en Jira-övergång eller sammanslagning av en pull request. Fortsätt använda teamets vanliga leverans- och releaseprocess för besluten.

Håll standarden användbar när arbetet förändras

Granska standarden när ett återkommande fel avslöjar en saknad kontroll, när produkten förändras väsentligt eller när en befintlig kontroll inte längre ger användbar information.

Portalteamet kanske till exempel upptäcker att inställningsändringar fungerar direkt men misslyckas efter en fördröjd synkronisering. Det kan leda till en bredare verifieringsregel för funktioner som beror på fördröjd behandling. Teamet bör först bestämma vilka ändringar regeln gäller och vilket underlag som visar framgång.

Uppdatera referensstandarden och diskutera hur ändringen ska tillämpas på pågående arbete. Befintliga ärendelistor ärver inte ändringen automatiskt. Inspektera påverkade ärenden och lägg manuellt till de nya överenskomna kontrollerna där det passar.

Utöka inte checklistan efter varje isolerat misstag. Ibland är ett specifikt acceptanskriterium, en tydligare implementationsuppgift eller en ändring i granskningsprocessen ett bättre svar. Den gemensamma standarden bör förbli något teamet kan förstå och faktiskt tillämpa.

Prova på ett aktuellt ärende

Välj ett ärende som närmar sig granskning. Kom överens om en kort gemensam kvalitetsstandard, lägg den på fliken Definition of Done och lägg ärendets specifika kundresultat under Acceptance Criteria.

Gå igenom kontrollerna tillsammans och länka underlaget där teamet normalt dokumenterar det. Markera poster som klara först efter verifiering och granska sedan återstående arbete genom er vanliga leveransprocess.

Det användbara resultatet är ett tydligare samtal. När någon säger att ändringen av aviseringsinställningar är klar kan teamet förklara vilka resultat som fungerar, vilka kvalitetskontroller som godkänts och vad slutsatsen bygger på.

Relaterade artiklar

Kontakta Oss

Frågor om artikeln? Låt oss diskutera era tekniska mål.

Dina Uppgifter