Skrytá cena vágních ticketů v Jiře
Vágní ticket v Jiře zřídka vypadá na první pohled riskantně. Skutečný problém se objeví až později, když různí lidé doplní prázdná místa různými domněnkami a několik dnů soustředěné práce míří na špatnou věc.
Proč vágní tickety přežívají
Backendová vývojářka si v pondělí ráno vezme ticket. Název zní konkrétně: „Přidat uživatelská oznámení o změnách objednávky.“ Popis má dvě věty a odkaz na slackové vlákno staré tři týdny. Na první pohled to vypadá dost jasně. Stráví tedy tři dny budováním e-mailové notifikační pipeline spouštěné při každé změně stavu objednávky.
Ve čtvrtek se při revizi PR objeví PM a řekne: „To jsem nemyslel. Potřebovali jsme jen oznámení přímo v aplikaci pro události kolem odeslání a uživatelé je měli mít možnost vypnout.“ Nikdo nebyl vedle. Nikdo nebyl líný. Ticket jen nikdy neodhalil rozhodnutí, která v sobě skrýval.
Nikdo nepíše vágní ticket schválně. Vznikne za dvě minuty mezi schůzkami s upřímným záměrem, že se k němu autor později vrátí a doplní detaily. To později ale nepřijde. Autor má v hlavě celý kontext. Ví, které události jsou důležité, jaké kanály má na mysli a kterých uživatelů se to týká.
Nic z toho se nedostane na stránku, protože to působí samozřejmě. Pro ostatní to samozřejmé není.
Jira to zhoršuje právě tím, jak snadné to je. Neexistuje povinné pole, které by se ptalo, co je výslovně mimo rozsah. Neexistuje žádná pojistka, která by odmítla popis kratší než dvacet slov. Můžete napsat tři slova do shrnutí, nechat popis prázdný a kliknout na Vytvořit. Jira se nebrání. To je její výhoda i past zároveň. Výsledkem je backlog plný ticketů, které na první pohled vypadají hotově, a svou vágnost ukážou až ve chvíli, kdy už někdo začal stavět.
Co opravdu obsahuje plán připravený k realizaci
Většina ticketů odpoví na jednu otázku: co chceme? Plán připravený k realizaci jich zodpoví šest.
| Část | Na co odpovídá |
|---|---|
| Rozsah | Co do práce patří a co je výslovně mimo |
| Omezení | Co se nesmí změnit ani rozbít |
| Kroky | Co se musí stát a v jakém pořadí |
| Okrajové případy | Co se stane, když zřejmá cesta selže |
| Závislosti | Co musí existovat předem |
| Definice hotovo | Jak všichni poznají, že je práce skutečně dokončená |
Není to kontrolní seznam pro každou drobnou opravu v backlogu. Ale cokoli, co jde do sprintu, cokoli, co pravděpodobně zabere víc než pár hodin něčí práce, tyto otázky potřebuje vyřešené před startem. Rozsah je oblast, kterou týmy vynechávají nejčastěji. Pojmenovat, co je venku, působí zbytečně, když jsou všichni nadšení z toho, co je uvnitř. Právě tam ale začíná překvapivě hodně předělávek.
Omezení jsou tiché požadavky:
- Nerozbít stávající e-mailový tok objednávek.
- Zůstat v současné službě pro oznámení.
- Tento sprint nepřidávat novou infrastrukturu.
Tyto detaily se málokdy zapisují, protože autor předpokládá, že je všichni znají. Neznají. A definice hotovo je hranice mezi „myslím, že je to hotové“ a „shodli jsme se, že je to hotové“. Dobrá definice hotovo je pozorovatelná a ověřitelná.
Otázky musí přijít dřív než struktura
Každá instance Jiry nakonec projde stejným cyklem. Někdo přidá šablonu popisu se sekcemi jako Shrnutí, Akceptační kritéria, Technické poznámky a Mimo rozsah. Několik týdnů ji lidé vyplňují. Pak se stejný vágní jazyk, který dříve žil v prázdném popisu, jen rozteče do více pojmenovaných polí. Struktura se zlepšila. Přemýšlení ne.
Šablony problém neřeší, protože problém není strukturální. Je kognitivní. Autor neví, co mu chybí. Prázdná sekce s názvem Okrajové případy nepomůže člověku, který na okrajové případy ještě nepomyslel. Otázky ano. Konkrétní otázky, které nutí rozhodnout.
Pět otázek obzvlášť dobře vytahuje skrytá rozhodnutí:
- Co se mění v chování systému?
- Kdo je hlavní aktér a čeho se snaží dosáhnout?
- Existuje případ, kdy by se to stát nemělo?
- Co se rozbije, když to nedodáme?
- Týká se to stávajících uživatelů, nových uživatelů, nebo obou?
Tyto otázky fungují, protože jsou dost konkrétní na to, aby se daly zodpovědět, a zároveň dost obecné na to, aby se hodily skoro pro každý feature ticket. Samotné odpovídání je už plánování. Šablona je jen místo, kam odpovědi dopadnou.
Celý příklad
Takto to vypadá v praxi. Původní ticket je drobný: „Přidat uživatelská oznámení o změnách objednávky.“ Popis jen říká, že uživatelé mají dostat oznámení při změně stavu objednávky, a obsahuje poznámku, že vizuální podobu je potřeba probrat s designem. To stačí na zařazení do sprintu, ale zdaleka ne na jistou realizaci.
Krátké kolo vyjasnění změní všechno:
| Upřesňující otázka | Odpověď |
|---|---|
| Které změny stavu jsou důležité? | Jen odesláno a doručeno |
| Jaké kanály? | V tomto sprintu jen v aplikaci |
| Mohou je uživatelé vypnout? | Ano, výchozí stav je zapnuto |
| Co s uživateli offline? | Oznámení se zařadí do fronty do dalšího přihlášení |
| Platí to i pro existující objednávky? | Ne, jen pro nové |
| Co když doručení selže? | Jednou zopakovat, pak zalogovat |
O patnáct minut později znamená ticket pro všechny jednu konkrétní věc. Nová verze má skutečný rozsah, skutečná omezení, seřazené kroky, skutečné okrajové případy a definici hotovo, kterou lze ověřit. Je to stejný ticket. Jen úplně jiná míra jasnosti. Rozdíl není v lepší šabloně. Rozdíl je v malé dávce záměrných otázek položených před začátkem práce.
Kam v tom procesu zapadá AI
AI tickety nepíše. Tickety píšou lidé. AI je ale užitečná v jednom velmi konkrétním bodě procesu: když už existuje záměr, ale struktura ještě není uzavřená. Jazykový model umí přečíst vágní popis a zeptat se: „Zohlednili jste, co se stane, když je uživatel offline?“ Umí vzít rozházené odpovědi ze slackového vlákna a uspořádat je do rozsahu, omezení a kroků. Umí si všimnout, že plán zmiňuje migraci databáze, ale seznam závislostí neobsahuje schválení od správných lidí.
V čem AI dobrá není, to je rozhodovat o produktu za vás. Může se zeptat, zda to má být e-mail, push notifikace nebo oznámení přímo v aplikaci. Nemůže rozhodnout, která z těchto možností je správná pro vaše uživatele a tento sprint. Může vygenerovat věrohodnou definici hotovo, ale jen člověk, který rozumí produktu, pozná, jestli je opravdu správná.
Vzorec je jednoduchý: lidé rozhodují, AI strukturuje. Lidé určují rozsah, AI odhaluje mezery. Přesně na tomto vzorci, vyjasnit, naplánovat, provést, stojí Just v Atlassian Marketplace uvnitř Jiry. Stejný vzorec funguje i ručně. AI jen celý cyklus zrychluje.
Tři věci, které můžete udělat ještě dnes
- Před příštím sprintem vyberte nejvágnější ticket z backlogu a položte pět otázek z tohoto článku dřív, než někdo začne psát kód. Téměř jistě objevíte alespoň dvě rozhodnutí, o nichž si nikdo neuvědomil, že ještě nebyla učiněna.
- Zapište odpovědi jako rozsah, omezení a ověřitelnou definici hotovo, ne do odděleného dokumentu, ale přímo do ticketu, kde je člověk, který bude práci dělat, skutečně uvidí.
- Berte výše uvedenou šablonu jako výchozí bod, ne jako pevný standard. Přizpůsobte ji jazyku svého týmu, ale nevynechávejte otázky. Pokud chcete širší rámec k tomu, proč je tento krok vyjasnění ještě důležitější ve chvíli, kdy se vágní tickety předávají přímo AI, první článek této série podrobně rozebírá problém alignmentu: Proč většina AI nástrojů pro Jiru problém alignmentu spíš zhoršuje, než řeší.
