Definice hotového v Jira: dohodněte, co znamená „hotovo“

Vývojář dokončí změnu a posune úkol v Jira dál. Tester zjistí, že nová obrazovka funguje, ale existující postup se rozbil. Zákaznická podpora se o změně dozví od zmateného zákazníka. Všichni použili slovo hotovo, ale každý jím myslel něco jiného.

Definice hotového dává týmu společný standard dokončení. Zviditelňuje očekávané kontroly kvality ještě před začátkem práce, takže kontrola méně závisí na tom, kdo si vzpomene položit správnou otázku.

V této příručce vytvoříme příklad pro fiktivní tým zákaznického portálu, odlišíme společné kontroly kvality od akceptačních kritérií konkrétní funkce a obojí umístíme k úkolu v Jira pomocí nástroje Definition of Done & AC v Power Pack.

Co je definice hotového?

Průvodce Scrum popisuje definici hotového jako standard kvality, který musí přírůstek splňovat. Vytváří společné porozumění dokončené práci. Pokud organizace stanovila standard, je pro její Scrum týmy minimem. Viz oficiální Průvodce Scrum.

V našem praktickém příkladu ji chápejte jako malou sadu otázek, které tým klade ke každé relevantní změně. Byla implementace zkontrolována? Prošly dohodnuté ověřovací kontroly? Jsou dostupné informace potřebné pro podporu změny?

Konkrétní otázky závisí na produktu a jeho rizicích. Veřejný zákaznický portál, interní report a bezpečnostně kritický systém potřebují odlišné standardy. Kopírování seznamu jiného týmu bez diskuse může ponechat důležité mezery a přidat zbytečnou práci.

Užitečný standard popisuje pozorovatelný výsledek. „Vysoká kvalita“ vyjadřuje ambici. „Dohodnuté regresní kontroly prošly a výsledky jsou odkazované z úkolu v Jira“ popisuje něco, co může kontrolující prozkoumat.

Oddělte společnou kvalitu od chování funkce

Náš fiktivní tým přidává nastavení oznámení. Zákazníci budou moci zapínat a vypínat e-mail s týdenním souhrnem. Důležité zprávy účtu zůstávají mimo toto nastavení.

Funkce potřebuje vlastní akceptační kritéria. Například uložená volba musí zůstat viditelná po odhlášení a opětovném přihlášení zákazníka. Tento požadavek patří k funkci, protože popisuje zákaznickou zkušenost.

Definice hotového pokrývá širší standard dokončení. Kontrola implementace, ověření ovlivněného existujícího chování a aktualizace pokynů podpory se mohou týkat mnoha různých změn.

Oba seznamy jsou důležité. Funkce se může chovat podle požadavku, ale postrádat zásadní práci na kvalitě. Stejně tak zkontrolovaný kód a úspěšné regresní kontroly neprokazují správné chování požadované funkce.

Začněte nedostatky, které tým skutečně pozoruje

Pozvěte k krátké diskusi lidi, kteří produkt vytvářejí, ověřují a podporují. Použijte nedávný příklad práce, která vypadala dokončená, ale vyžadovala nečekané následné zásahy.

Náš tým portálu určí tři opakující se problémy. Připomínky ke kontrole někdy zůstávají nevyřešené. Existující nastavení účtu má malou regresní pokrytost. Pokyny pro podporu přicházejí až po zpřístupnění funkce.

Tyto problémy napovídají užitečné kontroly. Dávají také důvod držet standard stručný: každá položka má předcházet rozpoznatelnému selhání nebo stanovit potřebnou podmínku kvality.

Ptejte se, jak někdo ověří každou navrženou položku. Pokud nikdo neumí popsat důkazy, před přijetím upravte formulaci. „Dokumentace dokončena“ může znamenat poznámky k vydání, interní návrhové poznámky nebo článek zákaznické nápovědy. Dohodněte, jaké informace jsou potřeba a kam patří.

Dohodněte také, kdo kontroly obvykle provádí. To lze probrat při běžném plánování. Samotný kontrolní seznam nepřiřadí kontrolujícího ani mu nezarezervuje čas v kalendáři.

Navrhněte praktický společný seznam

Zde je první návrh týmu portálu. Je to ilustrativní pracovní dohoda, nikoli univerzální standard.

• Kontrola implementace je dokončena a povinné připomínky jsou vyřešeny.
• Dohodnutá akceptační kritéria úkolu byla ověřena.
• Dohodnuté regresní kontroly ovlivněných postupů účtu prošly.
• Dohodnuté kontroly přístupnosti změněných obrazovek prošly.
• Pokyny podpory odrážejí změněné chování pro zákazníka.
• Výsledky ověření a relevantní odkazy na kontroly jsou zaznamenány u úkolu v Jira.

Před použitím seznamu tým zapíše, co zahrnují jeho regresní kontroly a kontroly přístupnosti. Jinak mohou dva lidé odškrtnout stejnou větu po provedení rozdílné práce.

Pro portál zahrnuje dohodnutá regresní sada přihlášení, otevření nastavení účtu a aktualizaci existujícího pole profilu. Kontrola přístupnosti změněných prvků zahrnuje ovládání klávesnicí, viditelný fokus a srozumitelné popisky. Jde o příklady kontrol zvolených tímto týmem, nikoli úplný standard přístupnosti.

Praktický výklad potřebuje i položka podpory. Pokud změna nemá dopad na zákazníka, tým by měl předem stanovit vhodný standard pro tento druh práce. Nenutte kontrolující improvizovat výjimky jen proto, aby seznam zezelenal.

Přidejte standard k úkolu v Jira

Otevřete příslušný úkol v Jira a najděte kartu Definition of Done & AC v Power Pack. Obsahuje samostatné záložky Acceptance Criteria a Definition of Done. Před přidáním společných kontrol vyberte Definition of Done.

U malého seznamu zadejte název kontroly a zvolte Add nebo stiskněte Enter. Každý název zaměřte na jednu ověřitelnou podmínku. Dlouhá věta se třemi nesouvisejícími kontrolami ztěžuje zachycení částečného dokončení.

Můžete také zvolit Bulk Import a vložit seznam Markdown. Například vložte výše uvedených šest položek s pomlčkou a mezerou na začátku každého řádku. Podporovány jsou i běžné zaškrtávací položky Markdown.

Import přidává položky do vybrané záložky. Před potvrzením záložku zkontrolujte a potom prohlédněte výsledný seznam. Opětovný import stejného obsahu může přidat již existující položky, proto jej používejte záměrně, ne jako obnovení.

Pro dosud neověřenou práci používejte nezaškrtnuté položky. Zaškrtnuté položky Markdown se importují jako hotové; značky zkopírované z dřívějšího úkolu nemají nahrazovat kontrolu současné změny.

Dohodnutý standard je třeba vložit do každého relevantního úkolu ručně. Udržujte referenční kopii v běžné dokumentaci týmu a příslušné kontroly vkládejte do nových úkolů. Jde o týmovou praxi, nikoli automatické propojení centrálního standardu s každým úkolem.

Projděte skutečnou kontrolu

Předpokládejme, že funkce nastavení oznámení je připravena ke kontrole. Maya ověřuje zákaznické výsledky, zatímco Priya kontroluje dohodnutou regresní sadu. Leo vyřeší zbývající připomínky k implementaci a připojí záznam kontroly.

První průchod odhalí, že nastavení se ukládá správně, ale po volbě Save zmizí fokus klávesnice. Tým nechá kontrolu přístupnosti nedokončenou, zaznamená problém v běžné diskusi v Jira a opraví jej před opakováním příslušné kontroly.

Nedokončené jsou i pokyny podpory. To zůstává viditelné, přestože akceptační kritéria funkce jsou hotová. Oddělené seznamy pomáhají vysvětlit, proč týmu ještě zbývá práce.

Teprve po skutečném úspěšném ověření zvolte tlačítko Done. Zvolte je znovu, pokud nové informace znamenají návrat položky mezi nedokončené. Výsledky testů, odkazy na kontroly a důležitá rozhodnutí zaznamenávejte běžným procesem Jira nebo dokumentace týmu.

Dokončená položka zaznamenává úsudek týmu. Nespouští kontrolu, nesbírá důkazy ani neurčuje, kdo ověření provedl. Pokud záleží na identitě kontrolujícího nebo čase, tyto informace výslovně zaznamenejte běžným postupem kontroly.

Pečlivě čtěte ukazatel připravenosti

Nástroj pro každou záložku ukazuje počet dokončených a všech položek. Ukazatel připravenosti zobrazuje Ready for Release pouze tehdy, když oba seznamy mají alespoň jednu položku a všechny položky v obou jsou hotové. Jinak zobrazuje In Verification.

Díky tomuto pravidlu pomáhá ukazatel odhalovat nedokončené položky. Vysvětluje také, proč dokončený seznam Definition of Done nevyvolá stav úplného dokončení, pokud je Acceptance Criteria prázdný.

Berte označení jako souhrn stavu seznamu. Nedokazuje dostatečnost kontrol, přesvědčivost důkazů ani bezpečnost vydání produktu. Tým může stejně snadno označit za hotovou špatně napsanou kontrolu jako užitečnou.

Seznam také neblokuje přechod stavu Jira ani sloučení pull requestu. Pro tato rozhodnutí nadále používejte běžný proces realizace a vydávání týmu.

Udržujte standard užitečný při změnách práce

Standard přehodnoťte, když opakovaná chyba odhalí chybějící kontrolu, produkt se významně změní nebo existující kontrola přestane přinášet užitečné informace.

Tým portálu může například zjistit, že změny nastavení fungují okamžitě, ale po opožděné synchronizaci selžou. To může vést k širšímu pravidlu ověřování funkcí závislých na odloženém zpracování. Tým nejprve rozhodne, na které změny se vztahuje a jaké důkazy prokážou úspěch.

Aktualizujte referenční standard a proberte použití změny na rozpracované úkoly. Existující seznamy tuto revizi automaticky nepřebírají. Prohlédněte dotčené úkoly a podle potřeby ručně přidejte nově dohodnuté kontroly.

Nerozšiřujte seznam po každé ojedinělé chybě. Někdy je lepší konkrétní akceptační kritérium, jasnější implementační úkol nebo změna kontrolního procesu. Společný standard má zůstat něčím, čemu tým rozumí a co skutečně dokáže používat.

Vyzkoušejte jej na jednom současném úkolu

Vyberte úkol blížící se kontrole. Dohodněte stručný společný standard kvality, vložte jej do Definition of Done a konkrétní zákaznické výsledky úkolu přidejte do Acceptance Criteria.

Projděte kontroly společně a propojte důkazy tam, kde je tým obvykle zaznamenává. Označujte položky za hotové až po ověření a zbývající práci posuďte běžným realizačním procesem.

Užitečným výsledkem je jasnější rozhovor. Když někdo řekne, že změna nastavení oznámení je hotová, tým může vysvětlit, které výsledky fungují, které kontroly kvality prošly a z čeho závěr vychází.

• Průvodce Scrum — Definice hotového