Spelar det någon roll hur man skriver stories om man vill stänga dom? Definitivt! Skrivandet och den tillhörande konversationen reflekteras på implementationen och senare om det är möjligt att stänga objektet. Det lönar sig att lägga ner kraft på detta. Så hur skriver man för att stänga? Läs vidare för att få reda på det.
Det är lätt att försumma skrivandet - och börja jobba på - halvfärdiga objekt. Jag har sett många exempel (och gjort mig skyldig till ett antal själv) ärenden som inte är mycket mer än "one liners" med otydliga acceptanskriterier och som inte är avgränsade, en öppen inbjudan till extra funktionalitet och scope creep.
Först vill jag påminna om den centrala frågan som jag skrev om i den förra artikeln:
❱ Kommer det här bli färdigt? ❰
Vem ska man ställa frågan till (eller vilka ska fråga sig själva) detta? Givetvis teamet som ska utveckla objektet. Att få saker redo för implementation är en team-insats med stöd från intressenter. Allt eftersom konversationen sker behöver intressenter vara närvarande och redo att svara på frågor och dela med sig av insikter kring förväntningar och affärskontext.
Utkomsten från konversationen dokumenteras kopplat till ärendet.
Så utan vidare omsvep, här är stegen för att skriva (och facilitera konversationen) ärenden som ni kommer att stänga.
Steg #1: Fokusera på utfall
Kanske icke-intuitivt – ett för definierat eller specifikt objekt med fokus mer på "vad" än på "varför" kan leda till ökat arbete. Att fokusera på utfall och vad man vill uppnå hjälper teamet föreslå effektiva tekniskt realiserbara lösningar.
Som komplement till fokus på utfall, och för att avgränsa omfång, beskriv funktionalitet explicit med hjälp av acceptanskriterier:
Step #2: Skriv acceptanskriterier
Acceptanskriterier är objektspecifika villkor behöver uppfyllas för att objektet ska anses som färdigt. Acceptanskriterier kan skrivas på olika sätt. Ett vanligt format är BDD formatet "given-when-then".
Skriv inte uppenbara saker och upprepa inte Definition of Done (DoD). Försök skriva kriterier som beskriver funktionaliteten och kvalitetsattribut.
För att fånga alla aspekter av ett ärende och hitta acceptanskriterier:
Steg #3: Fundera på de 7 produktdimensionerna
Dom sju produktdimensionerna är ett jättebra hjälpmedel för att säkerställa att alla aspekter av ett objekt täcks.
Användare - vem interagerar med systemet
Aktion - vad gör användaren
Data - vilket data opererar användaren på
Kontroll - vilka affärsregler och villkor gäller
Gränssnitt - hur interagerar användaren med systemet
Miljö - vilka miljöer (t.ex. klienter eller operativsystem)
Kvalitetsattribut - vilka begränsningar finns (t.ex. prestanda, robusthet och säkerhet)
Men att bara fokusera på vad som ska göras räcker oftast inte. Man behöver också ha en konversation kring vad som inte är en del av ärendet, vilket leder oss till:
Steg #4: Ange avgränsningar uttryckligen
Att ange avgränsningar, saker som inte är en del av ett specifikt objekt, är ett utmärkt sätt att ytterligare låsa in funktionalitet och se till att innehållet inte oväntat växer.
Vissa saker kommer aldrig behövas. Andra saker kan senareläggas eller är del av andra ärenden.
Avgränsningar hjälper till att:
Steg #5: Se till att saker är tillräckligt små
Små saker blir fortare klara och innehåller färre överraskningar.
Ett sätt att verifiera att storleken är okej och samtidigt se till att alla har samma förståelse kring syfte och scope är att (trumvirvel) estimera tillsammans som team med hjälp av relativa uppskattningar.
Saker som är för stora behöver delas upp i mindre delar. Acceptanskriterier och produkt-dimensionerna är bra ställen att börja leta efter möjliga delningar. Ibland erbjuder ett "och" i ärendets titel också en ledtråd.
Oavsett hur litet något är så kan det ändå stanna av helt om teamet är beroende av någonting utanför teamets kontroll, så gör ert bästa för att:
Steg #6: Minimera beroenden
Beroenden kan delas upp i interna och externa beroenden.
Generellt kan interna beroenden inte undvikas, men som tur är kan de hanteras relativt enkelt. Oftast.
Externa beroenden finns oftast också och bör hanteras med större försiktighet. Undvik att påbörja ärenden med externa beroenden så långt det går.
Om man jobbar i iterationer så är det en bra idé att planera några iterationer framåt och koordinera arbete mellan team.
När man följt alla steg hittills så ta slutligen några minuter och:
Steg #7: Återbesök Definition of Done (DoD)
Innan man svarar "ja" på frågan om ärendet kommer bli klart, återbesök er DoD och dubbelkolla att allt är täckt.
DoD är en hanterbar (läs: den kan hållas i huvudet och får plats på en slide utan att använda ett typsnitt med storlek 7) lista med saker alla objekt behöver uppfylla för att ses som färdiga. Medan acceptanskriterier är specifika per objekt är DoD gemensamt för alla objekt.
Exempel på saker du oftast hittar i en DoD är:
Koden är refaktoriserad och granskad av en kollega
Alla nödvändig dokumentation skriven
Tester implementerade och gröna
Inga defekter eller annan teknisk skuld introducerad
Nu skulle man kunna argumentera att saker kan bli klara fortare om man tar genvägar med DoD 🤯. Det här är självklart en farlig väg att vandra som ofelbart leder till evig fördömelse (om man med det menar teknisk skuld, missade deadlines och en utvecklingsorganisation som sakta men säkert blir helt stillastående).
Avslutningsvis
Att komponera ärenden som är enkla att stänga, men ändå är värdefulla och låter teamet samarbeta på dem är en konstform i sin egen rätt. Men att "skriva för att stänga" är en färdighet värd att förfina som kan ha en stor inverkan på en organisations effektivitet.
Lycka till. Om du behöver ett bollplank kommentera nedan eller kontakta mig direkt.
Comments