Akceptační kritéria a definice, kdy je hotovo (DoD)

Jedním ze základních pilířů Agilního plánování a tvorby požadavků je definice toho, co má výstup přinést uživateli (tzv. akceptační kritéria), nutným doplňujícím pohledem je pak definice, kdy je hotovo (Definition of Done) z pohledu vývojového týmu. Tyto dva pohledy jsou často mixovány dohromady nebo v projektech chybí, což způsobuje problémy s dokončením či akceptací výstupu. V tomto článku se podíváme na problematiku blíže.

Hned na úvod tohoto postu musím sdělit jeden podstatný fakt. Popis use case, scénáře či story není kompletní dokumentace ani nenahrazuje komunikaci se zákazníkem v průběhu sprintu. Use case, scénář či story je pouze prostředek podporující komunikaci mezi lidmi! To je jeho účel a proto má takovou strukturu jakou má. Proto, i když budeme v článku klást důraz na akceptační kritéria a DoD (Definition of done), tak to neznamená odstranění komunikace v průběhu sprintu ani záruku úspěšného doručení výsledku. Takto nastavené prostředí „pouze“ nastavuje podmínky pro přímou, otevřenou a efektivní komunikaci uvnitř týmu a mezi týmem a okolím (jak zákazníkem, tak týmem provozu a údržby, pokud se liší od týmu vývoje).

Co to tedy jsou ta akceptační kritéria? V podstatě se dá říct, že se jedná o definici hodnoty z pohledu zákazníka. Definují nám očekávané chování výstupu: aplikace či implementované funkčnosti z pohledu uživatele. Akceptační kritéria tedy:

  • Pomáhají týmu pochopit, co je předmětem dané story, co přináší zákazníkovi hodnotu.
  • Pomáhají pochopit, kdy již přidávání nových funkčností nepřinese zákazníkovi další přidanou hodnotu, ale naopak se promění v plýtvání (které znamená časové zpoždění a čas strávený vývojem samozřejmě musí někdo zaplatit).
  • Pomáhají testerům derivovat testovací scénáře.

Akceptační kritéria definují a pomáhají pochopit záměr uživatele, nedefinují a nezaměřují se na implementaci, na konkrétní způsob řešení. Detaily jako jsou konkrétní pravidla (business rules), minimální a maximální hodnoty, technologické zpracování, vzhled apod. nejsou předmětem akceptačních kritérií. Tyto jsou zachyceny ve formě unitových testů, testovacích scénářů, náčrtů GUI, případně v jiné formě interní dokumentace.

Akceptační kritéria mohou existovat na různé úrovni: pro požadavek (use case, scénář, story), sprint nebo release. Tato kritéria jsou připravována budoucími uživateli či jejich reprezentantem (např. ve Scrumu role Product Owner) a mohou mít různou formu buď manuální, nebo automatizovanou ve formě akceptačních testů (např. ve Fitnesse, Seleniu). Pro story „Jako vývojář chci reportovat na projekt za účelem vyplacení výplaty“ můžeme definovat následující akceptační kritéria:

  • Mohu reportovat na projekt, kterého jsem členem.
  • Mohu reportovat maximálně 8 hodin denně.
  • Nemohu reportovat na projekt, který je již ukončen.
  • Nemohu reportovat na projekt, jehož nejsem členem.
  • Pokud nemohu reportovat na nějaký projekt, zobrazí se hláška s důvodem.

Typickou námitkou zákazníka, ale i týmů je, že pokud musí připravovat taková kritéria, potom příprava scénářů či stories zabere mnohem více času, který ale nemá. Mou odpovědí je podle kontextu a problémů projektu většinou následující. Sice strávíme více času přípravou akceptačních kritérií, ale díky tomu má vývojový tým lepší pochopení toho, co má vlastně vyvíjet (méně ad hoc komunikace v průběhu sprintu, která uživatele zatěžuje), testeři vědí, jak funkcionalitu testovat, strávíme méně času dohady při demonstraci a akceptaci a daná kritéria slouží i uživatelům k ujasnění si potřeb a konečnému akceptačnímu testování.

Ve výsledku je tedy méně přepracování a chyb (= dříve dodaná funkcionalita v lepší kvalitě), méně naštvaných lidí na straně zákazníka a více efektivní otevřené komunikace. V konečném důsledku nám tedy tato počáteční časová investice ušetří čas i peníze a pomůže k budování důvěry mezi námi a zákazníkem. Tudíž má velký vliv na úspěch či neúspěch projektu.

Definice stavu, kdy je hotovo (DoD)

Pokud mluvíme o akceptačních kritériích, je nutné zmínit také jejich doplněk k celku, tzv. Definition of Done (DoD). DoD je definicí toho, co musíme udělat v rámci implementace požadavku/sprintu/projektu na úrovni týmu, abychom mohli říct, že je daný požadavek/sprint/repase 100% hotový. Asi všichni z nás znají syndrom 90% hotovo. Přijdeme za kolegou a ptáme se, zda má hotovo a on odpoví: „Skoro hotovo, už jen posledních pár desítek minut…“. Přijdete druhý den a pořád stejná odpověď J. I když je tento syndrom spojen také s chybějícími akceptačními kritérii, demonstruje, jak je dobré mít checklist na úrovni projektu, sprintu či požadavku, který mi pravidelně připomene, co vše musím udělat pro úspěšné doručení. Příklad DoD na úrovni požadavku, scénáře, story může vypadat následovně (tedy 100% práce hotovo):

  • 0 chyb kritické a střední úrovně
  • existují unit testy pro nově vytvořenou funkčnost
  • všechny unit testy prošly
  • (v případě, že neproběhlo párové programování) byla provedeno párová revize kódu
  • všechny testovací případy prošly
  • akceptační testování testery prošlo
  • prošlo testování v různých prohlížečích
  • relevantní dokumentace byla aktualizována
  • proběhla demonstrace zákazníkovi

Důležité je také nezapomenout všechny tyto kroky zahrnout do odhadů komplexnosti/pracnosti daného požadavku při tvorbě odhadů v průběhu plánování projektu/sprintu! Podívejte se na použití planning pokeru pro odhadování pracnosti. Význam DoD není pouze pro tým vývoje, ale slouží i pro tým provozu a údržby k akceptaci do provozu, pokud provoz a údržba není prováděna stejným týmem.

Rozdělení požadavků na menší kousky

Ne vždy je požadavek triviální jako ve výše uvedených příkladech, ne vždy se také podaří popsat story či požadavek tak, aby se vešel do sprintu. Proto je nutné některé komplexní či na sobě závislé požadavky rozdělit na menší kousky, které je tým schopný v rámci sprintu zvládnout. Jaké strategie je pro toto rozdělení možné zvolit?

  • Rozdělení požadavku podle entit reálného světa (správa zákazníků, správa faktur)
  • Rozdělení podle funkčnosti: 1. sprint: pouze základní demonstrační funkčnost, základní scénář, aby uživatel měl představu a pochopení. 2. sprint: výjimečné stavy, speciální funkce, přihlašování, grafické efekty

Praxe říká, že není vhodné rozdělovat požadavky podle technologických úkolů:

  • sprint UI, abychom měli co ukázat nebo DB vrstva abychom měli datové entity připraveny
  • další sprinty dodělat funkčnost a DB, respektive UI.

Proč? Protože tento postup nepřináší uživateli žádnou hodnotu! Na co bude uživatel vyplňovat hodnoty, když je nemůže uložit? Nebo naopak, proč budeme implementovat ukládání v DB, když není co ukládat? Smyslem je vždy doručit něco, co je kompletně použitelné, proto radši implementujeme jen základní funkci, ale kompletně ve všech vrstvách (UI, aplikační logika i databáze).

Ještě dodám, že technologické úkoly jako tvorba UI šablon, změny architektury (refaktoring, nastavení parametrů, úprava rozhraní na ostatní systémy) nejsou scénáři či stories. Je ale nutné je zapracovávat do obsahu sprintu, kdykoliv je třeba.

Shrnutí

Představili jsme si, co jsou a k čemu se používají akceptační kritéria v Agilních projektech včetně příkladů. Řekli jsme si, že mohou být ručně psaná i automatizovaná ve formě akceptačních testů (pomocí nástrojů, jako je Fitnesse, Selenium či komerční produkty). I když tvorba těchto kritérií zabere čas, tato investice umožní ušetřit čas jinak strávený dohadováním při akceptaci a předěláváním nepochopené funkčnosti. Jako neoddělitelná část na úrovni týmu slouží tak zvaná DoD. Jedná se o checklist pro tým, aby dodal 100% dohodnutého a předešel syndromu 90%. Akceptační kritéria a DoD používáme při hodnocení iterace/sprintu. Daný koncept je také zapracován v šabloně pro iterační/sprint plánování a hodnocení. Velmi příbuzným tématem je také rozdělování velkých požadavků do menších, proto je na závěr zmíněno pár rad k tomuto tématu.

Na závěr se zbývá jen zeptat: Pomáhají vám akceptační kritéria, definujete je? Na jaké úrovni? Vidíte důsledky jejich nepoužití nebo vám naopak vůbec nechybí?

Příspěvek byl publikován v rubrice Články se štítky , , , , . Můžete si uložit jeho odkaz mezi své oblíbené záložky.

3 komentáře u Akceptační kritéria a definice, kdy je hotovo (DoD)

  1. Pingback: Nastupující technologické trendy dramaticky ovlivní způsob práce, co s tím? | Differ! Dělejte věci jinak…

  2. Pingback: Video: ukázka hodnocení iterace/sprintu | Differ! Dělejte věci jinak…

  3. Pingback: Problémy s adopcí agilních přístupů – část 3 | Differ! Dělejte věci jinak…

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *