Mnohokrát se jsem v pozici Product Ownera dostal do situace, kdy jsem potřeboval k řešení přiblížit user story, která nebyla, objektivně řečeno, zcela vyjasněná. Vývojáři se bránili, já jsem naléhal. V článku popisuji, jak k řešení takových situací přistupovat.

“Máme tam TBD, to nemůžeme označit jako Ready in PB!!!,” křičeli vývojáři (Ready in PB = stav v naší JIRA, kterým jsme označovali user stories připravené k zaplánování do sprintu, začátku jejich vývoje). “Panebože, takový detail tam chybí. Brání vám to, abyste na user story začali pracovat? TBD vyřešíme hned v pondělí po startu sprintu!,” křičel jsem já zpět.

Agilní teorie je v tomto ohledu na první pohled celkem jednoznačná. User story by měla být vyjasněna, naceněna a až pak může být zaplánována do sprintu (resp. označena jako připravena k zaplánování). Agilní praxe ve firmách je ovšem dost různorodá.

Vyjasněná user story

Co vlastně znamená “vyjasněná user story”? Jsou týmy, které jdou při groomingu do relativně velkého detailu. Na druhé straně jsou týmy, kde vývojářům zůstává vyšší míra volnosti v interpretaci byznysového zadání (týká se to především techničtěji orientovaných produktů).

Při hodnocení míry vyjasnění user story je potřeba přihlédnout k podmínkám a zvyklostem v daném týmu. Míra nutného vyjasnění se může měnit v průběhu času, ale zpravidla se tak neděje skokově. Není správné, aby Product Owner na jednom groomingu smetl námitky vývojářů ze stolu a tlačil na posvěcení user story, která není v takovém detailu, na který je tým zvyklý.

Zda by tým měl pustit do vývoje nevyjasněnou user story záleží na typu a rozsahu nevyjasnění. Typové nevyjasnění může být:

  • nedostatečný detail zadání,
  • chybějící specifikace volané sĺužby,
  • chybějící vizualizace,
  • chybějící šablona (nebo jiný typ podkladu).

Nedostatečný detail zadání

“Má mít tlačítko pro pokračování modrou nebo zelenou barvu? Co se má stát po kliknutí na něj? Bude notifikace řešena ve stránce nebo jako lightbox? Platí popsaný scénář pro všechny typy zákazníků?” To všechno jsou otázky, které mohou v průběhu groomingu zaznít a pokud Product Owner nezná odpověď, je z toho menší či větší TBD. Může být taková user story puštěna do vývoje? Záleží na závažnosti nevyjasnění.

Barvu tlačítka je jednoduché změnit a jde tedy o věc, kterou je jednoduché doplnit později nebo změnit v průběhu vývoje (pomíjím vhodnost / nutnost konzistence v ovládacích prvcích napříč celým webem). Zpravidla jde tedy o situaci, ve které je možné připustit označení user story jako připravené pro vývoj. Výjimkou může být situace, kdy případnou úpravu nemůže provést přímo vývojář, ale musí ji provést např. přímo HTML kodér, který je jen omezeně dostupný apod.

Popis následného chování po kliknutí na ovládací prvek je naproti tomu nutnou součástí zadání – definice nového chování nebo informace o využití některého ze stávajících flow je nutnou podmínkou, aby user story bylo možné začít vyvíjet.

Na co se často zapomíná je rozdílné chování pro různé typy zákazníků. Pokud v aplikaci existují různé typy zákazníků (ať už na základě vlastní identifikace v průběhu nákupního procesu nebo příznaku na profilu přihlášeného zákazníka), tak je potřeba definovat pro jaké typy zákazníků je daná user story platná a zda se nějak pro různé typy zákazníků liší. Typicky, podle architektury aplikace, se opět jedná o informaci, která je nezbytná pro zahájení vývoje.

Chybějící specifikace volané služby

Specifikace volané služby nebo přímo WSDL popisující dané volání je v případě online produktů s FE / BE architekturou nezbytnou součástí pro realizaci user story, která toto volání využívá nebo upravuje. Absence takového dokumentu by tedy měla být jasnou stopkou pro realizaci takové úpravy. Nebo ne?

Takovou user story je možné zpravidla rozdělit na tasky upravující front-end a na úpravy BE volání. Teoreticky je tak možné začít pracovat na FE části a BE volání upravit, jakmile bude dokument k dispozici. Samozřejmě, user story jako celek bude byznysově funkční až po realizaci obou částí úprav.

Další zajímavou otázkou je identifikace osoby, která je zodpovědná za získání aktuální specifikace rozhraní. Je to Product Owner, který přichází s požadavkem jež bude rozhraní používat? V tomto bodě bych to viděl spíše na roli Scrum Mastera, který má odstraňovat překážky blokující práci členů týmu. Požádat o dokumentaci nebo specifikaci rozhraní je přesně takový typ požadavku.

Chybějící vizualizace

Na tenhle problém jsme naráželi až překvapivě často. Jistě, pokud definujete registrační formulář, tak je vhodné doplnit ho vizualizací, protože se jedná o stěžejní část online služby a její špatné provedení bude mít zásadní dopad na obchodní výsledky služby. Product Owner by tedy měl svoji představu připravit v co největším detailu, tedy vizualizovat za pomoci wireframu nebo jiné úrovně vizualizace (grafika).

Nicméně, je potřeba vizualizace ve chvíli, kdy do existujícího formuláře chcete na definované místo doplnit další input field? Zpravidla ne. Na druhou stranu, potřebu vývojářů na komplexnost zadání i v tomto případě chápu. Je to jejich “obrana” před situací, kdy na demu někdo z širšího okruhu byznys vlastníků přišel s doplňujícím požadavkem, který byl stále podle definice user story (stále to bylo o přidání dalšího input fieldu), ale už v user story nebylo řečeno, že ve chvíli kdy se zákazník do tohoto políčka proklikne, tak se má vedle něj zobrazit specifická doplňující informace. Ano, tohle lze popsat i slovně, ale už se jedná o úroveň detailu, kde vizuální provedení vydá za tisíc slov.

Nicméně, v odstavci výše dávám slovo “obrana” do uvozovek záměrně. Agile není zákopová válka, kdy proti sobě na jedné straně stojí vývojáři a na druhé jejich zákazníci (ať už je to Product Owner, lidé za ním nebo reální uživatelé produktů). Bylo by jistě vhodné, kdyby se na problém, který by odhalila chybějící vizualizace, přišlo dříve, ale o tom agile není. Díky prezentaci na demu se na problém přišlo ještě relativně včas, daleko dříve než by se na podobný problém přišlo při klasickém waterfallu. To je hlavní deviza agilu, vyšší efektivita v porovnání s jinými styly řízení, nikoliv v krátkodobém pohledu několika málo týdnů. Nicméně i tady platí, že je vhodné co nejvíce eliminovat prostor pro podobné drobné přešlapy.

Na jedné straně tedy chápu vnímání vývojářů, kteří vizuální podklady chtějí i na user story, kde na první pohled nejsou potřeba, na druhou stranu podporuji, aby dodání podkladů nebylo showstopper ve chvíli, kdy to způsobuje problémy jinde (např. nedostatečná kapacita u Product Ownera nebo dalších, jím využívaných zdrojů).

Ve finále jsou to totiž prostředky (časové, resp. finanční), za jejichž správné využití je zodpovědný Product Owner. Je tedy na něm, aby zvážil, zda čas (= peníze), který stráví přípravou vizualizace stojí za případné zdržení nebo dodatečné náklady, pokud se na nedostatek vzniklý v důsledku chybějící části zadání přijde až na demu.

Chybějící šablona (nebo jiný typ podkladu)

Případ chybějící šablony lze rozdělit na dvě části. V prvním případě je šablona vyžadována, protože neexistuje repository kódu, který by vývojář mohl použít. V takovém případě je požadavek na šablonu legitimní, protože nelze chtít po vývojáři, aby si z jiných stránek bral kusy kódu a ty používal ve vytvářeném řešení. Nebude to efektivní.

Design manuál (repository HTML kódu / CSS)

Jednou z velkých chyb ve vývoji online projektů je chybějící design manuál, který umožní rychlé sestavení stránky z předpřipravených prvků, k nimž je připravený již hotový HTML kód / CSS styl. Mnohdy není vedení repository designových prvků definující podobu formulářů, tlačítek, nadpisů atd. správně zavedeno ani ve velkých firmách (resp. právě ve velkých firmách často chybí úplně nebo je vedeno velmi špatně). Ono totiž správné udržování design manuálu jako repository pro vývoj je totiž poměrně nákladné, pracné a vyžaduje disciplínu.

Druhá situace nastává ve chvíli, kdy repository kódu sice existuje, ale vývojář se odvolává na to, že kód z repository není dobře a bez dalších úprav použitelný. V takovém případě jde pravděpodobně o nekvalitně připravený kód. Design manuál slouží k tomu, aby prvky z něj bylo možné seskládat jednoduše, jako kostičky lega.

Závěr

Krátké shrnutí dlouhého povídání:

  • všichni členové týmu – Product Owner, Scrum Master i vývojáři mají společný cíl – dodat požadovanou funkcionalitu,
  • za kvalitu zadání je zodpovědný Product Owner,
  • pokud je začátek vývoje možný i s nekompletním zadáním, je na akceptaci Product Ownera, že tím mohou být způsobeny dodatečné náklady.