Dokumentácia biznisových požiadaviek zákopovou metódou

Článok z blogchainu: zákopová metóda.

Na tomto mieste nenájdeš ďalšiu úžasnú prevratne prepracovanú wordovskú šablónu, ktorá Ti pomôže zdokumentovať (pochovať do neštruktúrovaného peklíčka) ďalší balíček biznisových požiadaviek. Nájdeš tu návrh excelovskej tabuľky, ktorá v štruktúrovanej forme zachytáva good enough verziu biznisových požiadaviek, ktoré sú podkladom na vytvorenie alebo úpravu existúceho softvérového riešenia.

Tento partizánsky spôsob (tabuľka, zdielaný Excel, alebo Google Sheet), ktorý volím nielen pre ilustráciu, ale aj pre bezproblémové nabootvanie, vyskúšanie metódy, môžeš posunúť do ďalšieho levelu pomocou flexibilného nástroja ako je airtable, alebo infinity (to pre dobrodruhov), prípadne si takto nakonfiguruješ JIRU.

Excel > Word

Rozdiel a výhoda voči dokumentácii vo forme eseje, spočíva v tom, že všetky požiadavky sú udržiavané v štruktúrovanej forme, v ktorej sa dá rýchlo prehľadávať (filtrovať). Viem, už sa opakujem, ale kritická vlastnosť je štruktúrovanosť evidencie požiadaviek, aký predpis je aplikovaný je menej dôležitý. Ak si neodnesieš nič iné, tak prosím nad týmto sa prosím zamysli.

Ako dokumentovať čo biznis potrebuje

Pochopeniu príležitostí, alebo problémov sme sa dotkli v dizajne riešení. Pre zdokumentovanie biznisových požiadaviek existuje nespočet možnosti. Kazateľom ktorých som ešte minule nespomenul pri JTBD by user story pripadala príliš preskriptívna, čo sa týka našepkávania aké je riešenie. Use case v ich očiach bude niečo ako návod z IKEA (apropos, keď sme pri návodoch, tak tu jeden ultimátny od Alistair-a Cockburn-a). Každopádne to je želaný stav (byť viac špecifický). Keď sa z definície dopytu presúvame do bližšej špecifikácie ponuky máme už snahu, aby sa riešenie potreby začalo viac zhmotnovať do niečoho menej efemerálneho ako je customer job. V prípade zákopovej metódy je nosným spôsobom dokumentácie požiadaviek user story (a eposy).

User story

As a [role], I want [some action], so that [outcome]

User story odpovedá na tri základne otázky:

• Kto (je to, aká rola)?
• Čo (chce urobiť)?
• Prečo (to chce, aký má dôvod)?

A nedefinuje odpoveď na otázku Ako?

User story používa bežný (biznisový) jazyk, nie je to žiadna programátorska hantírka. Napísať user story kvalitne bolí a chce to prax (potom to bolí už menej). Môj cieľ však je, že tvorbu user stories nerobí len produktový vlastník, alebo biznis analytik. Ale že to dokáže a chce každý, kto sa v projekte vyskytuje, teda aj sám (kľúčový) používateľ, alebo stakeholder.

recruiter create candidate contact info for reuse and share with recruiters
recruiter view candidate contact overview be able to reach out
recruiter view candidate contact overview be able to see latest activities
recruiter search in candidate contacts be able to reach out

Evidencia požiadaviek v štrukturovanej forme

Odpovedá tvoja aktuálna projektová dokumentácia biznisových požiadaviek elegantne a ľahko na otázky ako:

• čo všetko dokáže aplikácia vo verzii X.Y.Z? (hodí sa pre GAP analýzu)
• čo všetko dokáže používateľ U1 aplikacie? (hodí sa na reflexiu, či niečo nedokážem (aspoň) workaroundom)
• Koľko požiadaviek je vo výrobe, koľko v príprave? (monitoring work in progress)
• ktoré požiadavky majú prioritu? (riešime doležité veci)

Atribúty evidencie user story

Poďme si rozobrať jednotlivé atribúty (stĺpce tabuľky), ktoré je dobrý nápad pre user story (v štruktúrovanej forme) evidovať.

ID

Referencovať na jednoduchý číselný kód je omnoho efektívnejšie, ako papagájovať dookola meno user story (alebo číslo riadka v exceli, ktoré sa môže kedykoľvek zmeniť).

Ako zo mňa v procese dokumentácie vypadávajú user stories, najprv nečíslujem, snažím sa všetko dostať von. Postupujem zvyčajne s číslovaním takto:

1.10 recruiter create candidate contact info for reuse and share with recruiters
1.20 recruiter view candidate contact overview be able to reach out
1.25 recruiter view candidate contact overview be able to see latest activities
1.30 recruiter search in candidate contacts be able to reach out

Číslovanie pre manuálnu evidenciu "v exceli" je vo formáte MM.NN.PP.

• MM reprezentuje okruh definovaných eposom.
• NN číslujem v prírastkoch po 10. Ak chcem (neskôr) logicky / opticky doplniť, rozšíriť evidenciu okolo seba stojacich user story o novú story, toto mi umožní evidovať ju "medzi" (medzi 1.10 a 1.20 pomocou 1.25, alebo bližie na začiatok intervalu 1.22 alebo ku koncu 1.28).
• PP úroven využijem vtedy, ak potrebujem zabezpčiť rozdelenie user story. Potrebujem rozbiť 1.10 na menšie stories, vyňať z 1.10 časť z menšou prioritou, vyrobím 1.10.1

Epos (epic)

Meno eposu, do ktorého story patrí. Epos je súbor user stories, ktoré majú príbuznosť. Je dobrý nápad, keď v iniciačnej fáze projektu na identifikácii, dizajne user stories v jednom épose, kým sa narodia prvé stories, jeden človek.

Čo je épos?
Reprezentuje logický okruh, ktorý je identifikovaný na vyššej úrovni.
Príklad lepší ako 100 teoretických poučiek:
- manažment používateľov
- manažment objednávok
- objednávka
- reklamácia

User story

Odporúčam rozbiť user story minimalne na 2 samostatné stlpce (kto a čo+prečo), ideálne však na 3, v ktorých sa definuje:

• Kto? (As user) - Rola, používateľ, persóna, na ktorú budeme user story viazať
• Čo? (I want ) - toto je mäso, ktoré popisuje správanie systému/aplikácie z pohľadu bežného biznis používateľa
• Prečo (to have benefit/outcome) - nastavujem zrkadlo aj sám sebe, v ktorom odhaľujem prečo je moja potreba opodstatnená. Písať user stories bez benefitu je určite rýchlejšie, ale často krát sa môže stratiť podstatná informácia.

Akceptačné kritéria

Formou číslovaného zoznamu definujú vlastnosti, ktoré user story ohraničujú, bližšie špecifikujú. De facto sa bavíme o biznisových pravidlách. Ak je riešením naplnená esenciálnej podstata user story a sú naplnenie aj akceptačné kritéria považujeme rozsah danej požiadavky za splnený.

user story:
storeman see all orders for stockout (actual warehouse state)

acceptance criteria:
1) default ordering for list of orders is based on latest stockout date DESC (e.g. orders that should leave are first in list)
2) list of orders will have these attributes: order date, order nr, sender name, sender address, recipient name, recipient address, order intake date
3) latest stockout date is calculated based on order arrival date plus 7 working days (take holidays and opening hours in consideration)
4) orders after latest stockout date will be visually marked (colour, sign)
5) able to search free text in attributes order number, consignee/consignor name/address

Pri tvorbe akceptačných kritérii, pri ktorých sa v rámci (seba)reflexie nad vlastným výtvorom vynorí v tvorcovi otáznik nad ich nevyhnutnosťou, sú práve tieto zrelé na presunutie do samostatnej story, alebo odsúdené na zánik. Akceptačné kritérium pod číslom 5) je zrelé na diskusiu. Vytiahnuť ho do samostatnej user story: storeman is able to search in orders for stockout alebo ho ponechať, závisí od kontextu. Povedzme, ak tento sklad obhospodarujem FIFO princípom a potrebujem hľadať dľa mena príjemcu raz za uhorský rok, tak si môžem toto kritériu odpustiť a dať ho do samostatnej user story s nižšou prioritou.

Alternatívnou formou zachytenia akceptačných kritérií je ich spísanie form scenára.

(Given) some context
(When) some action is carried out
(Then) a particular set of observable consequences should obtain

Given my bank account is in credit, and I made no withdrawals recently,
When I attempt to withdraw an amount less than my card’s limit,
Then the withdrawal should complete without errors or warnings

Zdroj: https://www.agilealliance.org/glossary/gwt/

Výhoda zachytenia kritérií v tejto forme je v možnosti takto definované kritéria (scenár) automatizovane otestovať. Tento predpis sa však vzďaluje podstatne ľahšie uchopiteľnému číselnému zoznamu s kritériami.

Priorita

Používam číslovanie od 1 do 5, kde pomocou všetkých 1 je definovaný zoznam stories nevyhnutný pre dosiahnutie minimalistického životaschopného produktu (MVP). Na opačnom konci (5) sú výstrelky, pri ktorých používatelia a stakeholderi púšťajú uzdu fantázii, a definovanie časti prečo je neprítomné alebo stojí na veľmi tenkých nohách.

Poznámky

Všemožné poznámky vo fáze work in progress, ktoré upozorňujú na zapracovanie nejakého aspektu do požiadavky, a budú zapracované s odstupom času (teraz sú vo fáze zrodu, a nebol čas ich iniciačnú myšlienku dokonale zapracovať (do story, akceptačných kritérii). Poznámky sa zvyčajne po dodefinovaní user story a akceptačných kriterií stanú nepotrebnými.

Referovanie (závislosti)

Definujú závislosť, alebo vzájomná podobnosť medzi user stories. Prípadne odkazujú na dokumentácie, ktoré zasadzujú user story do kontextu (odkaz na dokumentáciu procesu, do ktorého user story vstupuje).

State (life cycle)

Stav reflektuje životný cyklus. Netreba to prehánať, nižšie som vymenoval viacero stavov, ale ak proces/workflow nevyžaduje žiadne extrémnosti a tanečky okolo schvaľovania, mal by si človek vystačiť so základnými (vyznačené boldom)

• new -  iniciačný stav, zvyčajne absentuje kompletný zápis (chýba prečo, akcpetačné kritéria)
• in definition - práve sa jej niekto venuje, tvaruje ju.
• waiting - čaka na nejaké vstupy (je blokovana)
• ready - zadávateľ považuje user story za dostatočne definovanú, aby mohla byť odozvdaná (na odhad, výrobu)
• estimated - accepted - rejected
• delivered - je súčasťou funkčného produktu (aplikácie)
• freezed - odložená na neurčito
• trashed - zahodená do koša (not doing)

Potrápiť sa pri spisovaní biznis požiadaviek vo forme user stories a zodpovedať pre každú aj prečo niekto niečo potrebuje, vyšpecifikovať nevyhnutné detaily formou akceptačných kritérií, zabezpečí, že riešenie, ktoré požiadavky bude adresovať sa trafí do čierneho. Nepochovať požiadavky do neštruktúrovaného peklíčka a dať ich na jedno spoločné a zdielané miesto (nástroj JIRA, alebo partizánsky zdielaný google sheet) je dobrým východiskom na to, aby sa s nimi dalo ďalej efektívne pracovať. Čoho efektom je menšia miera frustrácie (kde to je, v akom worde?!) a nedorozumení (na tomto sme sa nedohodli).