Jak psát akceptační kritéria v Jira — s praktickými příklady

„Zákazníci mohou měnit nastavení oznámení“ zní jako jasný úkol v Jira, dokud jej někdo nezačne vytvářet. Uloží se změna okamžitě? Co když ukládání selže? Zůstane nastavení i zítra? Kterých e-mailů se týká?

Akceptační kritéria proměňují otevřené otázky v dohodnuté, pozorovatelné výsledky. Pomáhají lidem, kteří změnu požadují, vytvářejí a kontrolují, pracovat se stejnými očekáváními.

V této příručce vytvoříme kritéria pro fiktivní funkci zákaznického portálu, vylepšíme nejasné požadavky a přidáme praktický seznam do Definition of Done & AC v Power Pack. Pro začátek nepotřebujete speciální formát zápisu. Stačí jasné podmínky a výsledky.

Co jsou akceptační kritéria?

Akceptační kritéria popisují podmínky, které musí konkrétní práce splnit, aby byla přijata. Zaměřují se na očekávaný výsledek dané položky. Atlassian je odlišuje od definice hotového, která popisuje širší standard kvality dokončené práce. Viz příručka akceptačních kritérií od Atlassianu.

V našem příkladu je „Uložená volba oznámení zůstává vybraná po opětovném přihlášení zákazníka“ akceptačním kritériem. „Implementace byla zkontrolována“ patří do společné definice hotového.

Toto rozlišení udržuje oba seznamy užitečné. Akceptační kritéria vysvětlují, zda funkce dělá to, co tým dohodl. Definice hotového vysvětluje, zda práce splňuje širší standard dokončení týmu.

Ani jeden seznam nemusí obsahovat každý implementační krok. „Vytvořit databázové pole“ může být potřebný vývojový úkol, ale zákazníkovi ani kontrolujícímu neřekne, zda se nastavení chová správně.

Začněte jedním zákaznickým výsledkem

Náš fiktivní úkol se jmenuje „Umožnit zákazníkům řídit e-mail s týdenním souhrnem“. Cílem je, aby přihlášený zákazník mohl rozhodnout o přijímání týdenního souhrnu bez změny nezbytných zpráv účtu.

Před psaním kritérií tým dohodne několik rozhodnutí o rozsahu. Nastavení má výslovné tlačítko Save. Zákazník mění pouze vlastní volbu. Volba ovlivňuje souhrny, které ještě nebyly zařazeny do fronty. Zprávy již ve frontě jsou mimo pravidlo doručování tohoto úkolu.

Tyto podrobnosti jsou pro příklad smyšlené. Váš tým má určit skutečné chování, nikoli je kopírovat jako produktové požadavky.

Krátká poznámka o rozsahu může zabránit tomu, aby dlouhý seznam nesl veškerý kontext. V popisu Jira tým zaznamená, že úkol pokrývá jednu volbu na stránce nastavení účtu. Volba dnů doručování, změna e-mailových adres a správa nastavení jiných zákazníků jsou samostatnou prací.

Kritéria se nyní mohou soustředit na výsledky určující, zda tato konkrétní změna funguje.

Nejprve napište běžný průchod

Začněte zkušeností, kterou očekáváte u většiny zákazníků. Běžným jazykem popište výchozí podmínku, akci a pozorovatelný výsledek.

Například: „Když přihlášený zákazník vypne týdenní souhrny a úspěšně uloží změnu, po opětovném otevření nastavení účtu jsou souhrny vypnuté.“ Kontrolující může vytvořit výchozí stav, provést akci a prohlédnout výsledek.

Tato věta je užitečnější než „Nastavení se správně ukládá“. Určuje, která volba se mění, kdy změna začne platit a jak ji lze zkontrolovat.

Tým potřebuje i opačný směr. Ovládací prvek, který souhrny úspěšně vypne, ale neumí je zapnout, je neúplný. Pokud opačné chování zaslouží vlastní ověření, napište samostatné kritérium.

Nevkládejte nesouvisející výsledky do jediné položky. Ukládání, ovládání klávesnicí, doručování e-mailů i chybové stavy mohou být důležité, ale jedno obří kritérium ztěžuje ukázat, která část ještě potřebuje pozornost.

Přidejte chybové a hraniční případy

Běžný průchod předpokládá úspěšné uložení. Zeptejte se, co má zákazník vidět, když tento předpoklad neplatí.

Náš tým volí pravidlo: pokud požadavek na uložení selže, stránka ukáže chybu a nezobrazí potvrzení úspěchu. Po opětovném otevření stránky zůstane předchozí uložená volba. Kontrolující tak získá konkrétní chybový případ k vyzkoušení v testovacím prostředí týmu.

Poté prověřte hranici funkce. Nastavení týdenního souhrnu nesmí zastavit e-mail pro obnovení hesla. Volba zákazníka musí také přežít nové přihlášení. Jde o různé otázky, a proto dostanou samostatná kritéria.

Nepište „Všechny krajní případy jsou ošetřeny“. Pojmenujte důležité případy. Užitečná diskuse často začíná třemi otázkami: co může selhat, co musí zůstat neovlivněné a co se stane později?

Pokud se tým neshodne na očekávaném výsledku, zaznamenejte nevyřešené rozhodnutí dříve, než implementace příliš pokročí. Nezodpovězená otázka se nestane použitelným kritériem jen tím, že je v seznamu.

Propracovaný seznam akceptačních kritérií

Zde je první úplný návrh fiktivního úkolu. Každá položka popisuje výsledek, který může tým ověřit samostatně.

• Otevření nastavení účtu ukazuje aktuálně uloženou volbu týdenního souhrnu zákazníka.
• Po vypnutí týdenních souhrnů a úspěšném uložení je při opětovném otevření nastavení účtu volba vypnutá.
• Po zapnutí týdenních souhrnů a úspěšném uložení je při opětovném otevření nastavení účtu volba zapnutá.
• Po úspěšném uložení se volba zachová i po odhlášení a opětovném přihlášení.
• Pokud ukládání selže, zobrazí se chyba, neobjeví se potvrzení úspěchu a opětovné otevření nastavení ukáže předchozí uloženou volbu.
• Zákazník s vypnutou volbou nedostane žádný týdenní souhrn nově zařazený do fronty po úspěšném uložení.
• Zákazník se zapnutou volbou zůstává způsobilý pro následující týdenní souhrn podle existujících pravidel plánování.
• Vypnutí týdenních souhrnů nebrání zákazníkovi přijmout vyžádaný e-mail pro obnovení hesla.

Položky doručování závisejí na rozhodnutí o rozsahu zpráv ve frontě. Tým tento kontext zaznamená u úkolu, aby kontrolující nepředpokládal, že nastavení stahuje e-maily, které se již odesílají.

Kritéria také potřebují proveditelný způsob ověření. Pro doručování tým určí, jak souhrn v testovacím prostředí spustit nebo sledovat. Kritérium může být jasně napsané, a přesto obtížně ověřitelné, pokud nikdo nemá přístup k potřebnému účtu nebo dokladům doručení.

Před přidáním zpřesněte nejasná kritéria

Rychlá kontrola formulací často předchází delším pozdějším sporům. Přečtěte každou položku a zvažte, zda by dva lidé mohli úspěch vyložit odlišně.

Poslední příklad sám o sobě neprokazuje použitelnost. Nahrazuje jednu nejasnou větu jednou užitečnou, omezenou kontrolou. Širší cíle použitelnosti mohou potřebovat výzkum nebo několik dohodnutých pozorování.

Pozor i na smyšlenou přesnost. Požadavek na odezvu do dvou sekund zní měřitelně, ale vytváří skutečný závazek. Před zařazením výkonnostního limitu dohodněte podmínky a důvod.

Vložte kritéria do Power Pack

Otevřete úkol v Jira a najděte kartu Definition of Done & AC. Vyberte Acceptance Criteria. Její seznam je oddělený od Definition of Done, proto před zadáváním obsahu zkontrolujte vybranou záložku.

Pro jedno kritérium napište název a zvolte Add nebo stiskněte Enter. Používejte stručné názvy, které zachovají očekávaný výsledek. Potřebuje-li kritérium rozsáhlý kontext, udržujte jej v popisu Jira nebo odkazované dokumentaci týmu.

Pro více položek zvolte Bulk Import a vložte odrážkový seznam Markdown. Můžete zkopírovat příklady výše s pomlčkou a mezerou před každým. Podporovány jsou i seznamy Markdown se zaškrtávacími políčky.

Po importu zkontrolujte výsledné položky. Akce přidává do aktuálního seznamu, takže opakovaný import stejného seznamu může vytvořit existující položky. Zaškrtnuté položky Markdown přicházejí jako hotové; začněte nezaškrtnutými, pokud výsledky aktuálního úkolu nebyly skutečně ověřeny.

Je-li položka chybná, proberte s týmem náhradní formulaci, přidejte opravenou položku a zastaralou smažte s potvrzením. Pokud změna ovlivňuje dohodnutý rozsah, zachovejte jasnou doprovodnou diskusi v úkolu.

Před označením za hotové ověřte výsledky

Před implementací požádejte někoho zapojeného do ověřování, aby prošel navržená kritéria. Může odhalit chybějící výchozí podmínky nebo výsledek, který nelze sledovat s dostupným testovacím vybavením.

Po implementaci ověřte každý výsledek a zaznamenejte důkazy běžným postupem Jira nebo dokumentace týmu. Když dohodnutý výsledek projde, zvolte Done. Opětovná volba vrátí položku mezi nedokončené, pokud pozdější zjištění kontrolu znovu otevře.

Nastavení například může přežít obnovení stránky, ale po novém přihlášení se resetovat. Kritérium opětovného otevření stránky může projít, zatímco zachování mezi relacemi zůstává nedokončené. Samostatné položky toto užitečné rozlišení zachovávají.

Power Pack sleduje dokončení seznamu; nespouští testy ani automaticky neurčuje, kdo je kontroloval. Vyžaduje-li kontrola jmenovité ověření nebo datovaný výsledek, zaznamenejte tyto údaje výslovně běžným postupem.

Používejte oba počty, ale nezaměňujte je za důkaz

Acceptance Criteria a Definition of Done mají vlastní počty dokončených a všech položek. Ukazatel připravenosti zobrazuje Ready for Release, pouze pokud oba seznamy nejsou prázdné a všechny položky jsou hotové. Jinak ukazuje In Verification.

Jde o souhrn stavu zadaného seznamu. Neprokazuje, že kritéria pokrývají veškeré důležité chování nebo že podpůrné důkazy jsou kvalitní. Nevynucuje ani přechody pracovního postupu Jira a neblokuje slučování.

Náš úkol oznámení může mít hotových všech osm akceptačních kritérií, zatímco v Definition of Done zbývají pokyny podpory. Výsledky funkce prošly, ale širší dohoda týmu o dokončení má stále otevřenou položku.

Začněte jedním připravovaným úkolem v Jira. Napište zákaznický výsledek, dohodněte důležité podmínky a výsledky a přidejte kritéria do Power Pack vedle společné definice hotového. Projděte seznam s lidmi, kteří změnu vytvoří a ověří. Přínosem je méně předpokladů skrytých za větou, která původně zněla samozřejmě.

• Atlassian — Co jsou akceptační kritéria?