Analýza v produktovom backlogu?

Ako pristupovať k analýze v agilne vyvíjanom produkte a v jeho produktovom backlogu. Tipy pre jednoduché ale aj komplexné a komplikované požiadavky. Prečo je analýza v backlogu veľmi pravdepodobne chybou?

V roku 2010, keď sme začali pomáhať so zavádzaním Agile v slovenských firmách, bola najčastejšia otázka projektových manažérov a novovznikajúcej skupiny Produktových vlastníkov ‚A čo s analýzou?‘.

Veď softvér je komplikovaná problematika a tak si musíme najprv viacero vecí premyslieť a zanalyzovať. Navyše klient chce po nás v zmluve odhady a na ich základe cenové ponuky. Takže analyzovať musíme a to dosť podrobne a presne.

V tom čase sme už produkovali náš ScrumDesk nástroj pre projektový manažment. Tú slobodu rozhodnutia o tom či potrebujem analýzu alebo hotovú funkčnosť za nás robil náš biznis model a to, že sme produkovali produkt a zodpovedali sme sa iba sami sebe. Sloboda ale zároveň zodpovednosť.

Funkčnosť mala u nás vždy prednosť pre bajtami textu. Správne riešenie v agilnom prístupe, a práve to sme aplikovali, odporúča aby v produktovom backlogu boli odpovede na ‘What/Čo’ má produkt poskytovať používateľom. Teda funkcionalitu.

Analýza malých požiadaviek

Analýza bola v našom prípade iba procesnými krokom, aktivitou, ktorú je potrebné spraviť pre efektívnejšiu, zmysluplnejšiu a možno lacnejšiu verziu funkcionality. V našom svete bola takáto analýza rýchlym krokom, krátkou aktivitou rádovo za max jeden deň. Bol to subtask v danej User story. A keďže sme boli schopní narezať funkčnosť na malé User stories,  vďaka tomu sme riešili nekomplikované problémy. Analýza bola skôr dizajnom riešenia na úrovni jednej alebo viacerých tried a jedného max zopár API endpointov.

Malá, dobre narezaná, požiadavka výrazne zrýchlila proces.

Mali sme to šťastie, že k riešeniu komplexného problému sme sa dostali až po niekoľkých mesiacoch.

V prípade komplexných problémov takáto analýza prináša podklady pre rozhodnutia. Komplexné problémy vzhľadom na svoju povahu vyžadujú nielen analýzu, potrebujú aj štúdium, identifikáciu a návrh variant riešenia, neraz dokonca pokusné aplikácie pre rýchle prototypovanie.

Výsledkom analýzy komplexných problémov sú rozhodnutia, pripadne ideálne priamo obohatený backlog s ďalším smerovaním produktu poskytujúceho riešenie takéhoto komplexného produktu.

A aj keď sa to dá zjednodušene považovať za analýzu, v skutočnosti bol robený výskum. Hľadal sa takzvaný Enabler podporujúci ďalšie smerovanie produktu.

V tomto prípade sa analýza samotná stala hodnotným výsledkom, za ktorý ste ochotní zaplatiť. V tomto, a snáď iba v tomto prípade, položka v backlogu má zmysel.

Čo ak je väčšina funkcionalít komplikovaná, resp. komplexná?

V prípade veľkej komplexity, napr. v produktoch v bankách, telco, poisťovniach nie je neobvyklé, že skoro každá požiadavka je komplikovaná alebo dokonca komplexná. Veľká väčšina si  v podstate vyžaduje analýzu.

Komplexné problémy sú tie, kedy neviete čo neviete. Komplikované tie, kedy viete čo neviete.

Ak by sme použili predchádzajúci postup, mali by sme na každú funkčnosť minimálne dve položky v backlogu. Analýza a implementácia. Backlog by narástol a stal sa neprehľadným. Na každom plánovaní by sme sa bavili o dvoch časových aspektoch. Čo ďalšie pripraví a čo teraz realizovať. Nastáva zmätok, pridajú sa k tomu otázky ohľadom story pointov pre analýzy, metriky sa zhoršujú, pretože analýzy je nemožné odhadnúť a tak sa naťahuje a nestíha. A keď sa nestíha tak sa skloňuje, presúva do ďalšieho sprintu.

Analýza sa stáva overkill.

A pritom to tak vôbec nemusí byť. Stačí si uvedomiť, že analýzu robíme zakaždým a že bude chvíľu trvať. Na analýze sa v komplexných produktoch zvyčajne zúčastňuje len malá časť a to tá istá časť tímu. Je to taká skupina v tíme.

V tomto prípade pomáha zmeniť proces. Požiadavky prichádzajú do tzv. Funnela.

Z tohto zberného miesta sa požiadavky vyberajú na zhodnotenie či majú zmysluplný potenciál pre firmu, zákazníkov a produkt samotný. Už tu sa dejú určité aktivity, ktoré stačí iba sledovať. Požiadavka je v stave Review čo označuje zvažovanie jej ďalšej realizácie.

Ak sa rozhodnete, že požiadavka má zmysel, požiadavka sa posunie na Analýzu. Presunie sa jej karta na Kanban tabuli. V tomto stave vyššie spomínaná skupina, napr. Business architekt, IT ARCHITECT, CC, UX a PO, pripravia tie spomínané prototypy, dizajny riešenia, architektúry a rozvíja požiadavku na menšie epiky, Features, user stories. Nájdu MVP/MMP/MLP a pripravia plány či už na kvartál alebo aj niekoľko ďalších šprintov. Ak treba, tak sa takýto návrh schváli.

A po ukončení analýzy posuniete kartu požiadavky do stavu Backlog, čo indikuje, že strom tejto požiadavky sa dá nájsť v produktovom backlogu a je pripravený na realizáciu. A tak na ďalšom plánovaní si tím už ťahá tieto, realizačné, user stories. Suma sumárum, v backlogu mate iba toľko kariet, koľko funkčnosti chcete dodať.

Analýza je v komplexných a komplikovaných porduktoch mnohokrát iba procesný krok. V prípade komplikovaných, komplexných, produktoch tak stojí za zváženie mať dve tabule. Program Kanban Board pre sledovanie prípravy, implementácie a dodávky požiadaviek a tímovú Kanban tabuľu pre podrobnejšiu koordináciu tímu na dennej báze.

O tomto prístupe a ďalších zmysluplných postupoch Produktového vlastníka sa môžete naučiť na vašich produktoch v našom jedinečnom Product Ownership Mastermind programe preverenom desiatkami produktových vlastníkov. Ich produkty veľmi pravdepodobne používate aj vy.