Akceptační kritéria jsou připravená odebrat se do starého železa. Už nejsou potřeba, a upřímně, nikdy to nebyl dobrý nápad. Byl to takový malý link, kterým se firmy snažily předstírat, že jsou agilní, ale mohly stále mentálně a mindsetem zůstat ve starém klasickém světě. Akceptační kritéria jsou totiž pozůstatkem detailní specifikace, kdy vývojář – rozumějme coding monkey – aby mohl začít pracovat, musel dostat detailní popis chování a řešení. Říkali jsme těm rozsáhlým dokumentům requirements a specifikace. A bez ní ani kuře nehrabe a vývojář nedá ruku na klávesnici.
Jak to že najednou nejsou potřeba? No ony vlastně nikdy nebyly. Ale zvyk je železná košile. Dělali jsme to tak vždy a tak proč v tom nepokračovat. Dodávaly nám jistotu. Měli jsme díky akceptačním kritériím pocit, že věci máme víc pod kontrolou. Že je můžeme vzít jako checklist a na konci Sprintu odškrtat, že jsme udělali vše, co bylo v zadání. Bohužel to nám ale nepomáhalo v tom mít fokus na dodání hodnoty, a týmy často jen dodaly, co tam bylo zadáno, a nepřemýšlely, jestli dosáhneme požadovaného efektu u zákazníka a v produktu.
Co tedy dělat aby to celé fungovalo? Celý tým by měl mít jasnou představu o tom, co za produkt dělá, které věci jsou z pohledu našeho businessu důležité a které ne. Toho se dá docílit tím, že se tým zapojí do visioning workshopů v rámci Backlog Refinementu, věnuje se nejen technologii, ale porozumí zákazníkovi a jeho potřebám. To je něco, o co se v Agilu snažíme už od začátků s Extreme Programmingem, kdy tím nejextrémějším kouskem XP bylo mít zákazníka v týmu. V momentě kdy tým porozumí celkovému smyslu produktu, mohou se začít podílet na jeho rozvoji. Teprve tehdy jsme vytvořili tu pravou end to end vazbu na zákazníka a změnili své vnímání vývoje softwaru z kódování na dodávání hodnoty pro zákazníka. A pak už můžeme s klidným svědomím použít User Story as a Card – tak jak byla vždy definovaná, kde důraz není kladen na detailní popis chování, ale na business hodnotu kterou dodáváme. Proto se nám vše, co potřebujeme vědět, v pohodě vejde na malou podlouhlou index kartičku. Detaily, jak této hodnoty dosáhneme, vznikají v rámci konverzace o funkcionalitě v průběhu Sprintu v době, kdy na dané UserStory tým pracuje. Výhoda konceptu UserStory as a Card je to, že udržuje Backlog jednoduchý, klade důraz na konverzaci a pomáhá týmům spolu Product Ownerem proritizovat a dodávat tu nejdůležitější hodnotu nejdříve. Kdybyste stále měli pocit, že je škoda nechat druhou stranu kartičky pro User Story prázdnou, zkuste tam napsat tzv. Conditions of Satisfaction. Rozdíl je, že takto definovaná kritéria úspěchu nejsou seznamem, co to musí dělat a jak, ale co se má stát až to naimplementujeme. Tedy jaký má věc vzbudit v zákazníkovi pocit, co má udělat, jak má produkt používat. Je to takový funkční test, který pomáhá lépe definovat možný směr řešení, ale stále nechává volnost jak danou UserStory vyřešit.
Jako John,
si chci vybrat piva na párty,
abychom měli zajímavý výběr pití.
Akceptační kritéria by mohly vypadat následovně:
- Výběr podle zemí, značek, druhů a chuti
- Full text vyhledávání
- Omezení ceny
Takto definovaný list v podstatě definuje řešení a tým už to jen slepě naimplementuje.
Na rozdíl od toho, když píšeme Conditions of Satisfaction, zaměříme se na hodnotu:
John vidí, nakolik jsou vybraná piva různorodá, a dostává doporučení na další piva do výběru.
Tento příklad dává větší možnost řešení ovlivnit a vymyslet něco kreativního a v podstatě dodefinovává UserStory. Zároveň se na danou funkcionalitu dívá z pohledu zákazníka, což je vždy dobře. Jak jistě víte, zákazník nemusí být vždy koncovým uživatelem, např:
Jako Beer Shop CEO,
chci zákazníkům nabízet prioritně dražší značky,
abychom měli větší zisk.
Conditions of satisfaction pak mohou vypadat následovně:
Zákazníci nabídky často využijí, ale necítí se pod tlakem kupovat drahá piva.
Takhle definované parametry úspěchu mimo jiné donutí tým napsat nějaký trackovací mechanismus jak sledovat kolikrát a kteří zákazníci nabídky využili a funkcionalitu na základě toho upravovat a zlepšovat.
Asi je to běh na dlouhou trať a nejde do něj naskočit hned. Ale je to směr, ke kterému bychom se jako industry měli blížit. Jedině tím směrem lze dosáhnout je pravé Agility a úspěchu.
