Ako deliť požiadavky, časť 2: Podľa operácií

Ako deliť požiadavky? User stories splitting, práca s epikom, delenie epikov. Jedno veľké umenie. V prvej časti sme vám ukázali príklady pre delenie požiadaviek na menšie podľa procesu. Aj keď mnohí produktoví vlastníci tu s delením končia, v rozumnej aplikácii to nestačí. V tejto časti sa tak pozrieme na ďalšiu šikovnú možnosť. Podľa operácie.

Hmm, a čo myslíte pod pojmom „operácia“?

Vývojári poznajú skratku CRUD. Označuje operácie Create, Read, Update, Delete. A práve tieto operácie sú najbežnejším príkladom. ďalšími môžu byť napr. Archivácia, Export, Import, Registrácia, Prihlásenie.

Prečo to takto deliť, keď sa to najčastejšie dá naprogramovať naraz? Pretože to, že sa to dá naprogramovať naraz, neznamená, že to musíme publikovať naraz. Neznamená, že musíme investovať čas do všetkých týchto operácií.

Požiadavky nie sú o vývoji. Sú o dodávke. To zahŕňa aj testovanie, dokumentáciu, marketing atď. A to všetko stojí čas, peniaze a prostriedky.

A práve toto všetko nám môže chýbať pre niečo oveľa dôležitejšie, čo v danom čase potrebuje klient viac. No my mu to nevieme dať dostatočne rýchlo, lebo vývojárom sa spraví CRUD naraz jednoduchšie. A najčastejší argument vývoja je, že to predsa nebudú prerábať na niekoľkokrát. Nuž, ak treba, tak treba.

Rozdelenie podľa operácie, napr. CRUD, neznamená zbytočnú prerábku.

Príbeh o komentároch a user stories splitting

Pred niekoľkými rokmi som ako produktový vlastník stál pred rozhodnutím, čo všetko bude možné v ScrumDesk aplikácii s komentármi. Ako vvývojárovi mi srdce hučalo jednoznačne. Celý CRUD. Veď to spravíme naraz. No akurát v danom sprinte sme mali aj iné kritickejšie požiadavky. Hľadal som priestor ako „ušetriť“ a odsunúť menej dôležité veci.

Bolo to veľmi zlé, všetko bolo potrebné a kritické.

V určitom momente som pristál na user story Komentáre pre task. Hmmm, čo s tým? Veď predsa komentár treba zapísať, zobraziť. Používateľ ho určite bude chcieť zmazať. A keď sa pomýli, tak upraviť. Jasné ako facka, nie?

Ibažeby nie. Tak som sa pozrel do predošlej Windows verzie kde som v dátach s prekvapením zistil, že len malé percento komentárov bolo upravovaných. Mnohé však mali časté dve operácie. Zápis a zmazanie. Vlastne ich bolo viac ako editácie.

Jednoducho ľudia ten komentár radšej zmazali a napísali nanovo. Čudné, že? To predsa nedáva logiku!

A to je to. Ja si myslím, že to nedáva logiku, pretože mám nejaký pattern zaužívaný. Realita produktového vlastníka vždy prekvapí.

Takže, v nasledujúcej verzii bolo možné komentár pridať a zmazať. A, ani sám som tomu neveril, po niekoľkých mesiacoch mi to už bolo trápne, že nevieme editovať komentár, tak som to dorobil. Až oveľa neskôr. A medzitým sme dali iné vlastnosti.

Že prečo? Pretože aj s tak jednoduchou funkcionalitou zrazu otvárate niekoľko ďalších komnát:

1. Testovanie minimálnej dĺžky.
2. Maximálna dĺžka.
3. Znakové sady.
4. Ukladanie.
5. Ukladanie s výpadkom siete.
6. Prepísanie komentára iným človekom, nie autorom.
7. Prepísanie komentára autorom.
8. atď.

Takže malá zmena, ale veľa nových test cases, dlhší regresný test, viac kódu, viac chýb ( empiricky vraj 10 riadkov približne 1 chyba).

Netflix

V aplikáciách typu Netflix, Spotify, Podcast Go a iných prehrávačoch, je delenie podľa operácií veľmi výhodné a jednoduché. V prvej verzii napr. môžete ponúknuť iba prehrávanie, pauzu a stop. V ďalších verziách rýchle pretáčanie a potom, neskôr ak treba, aj preskakovanie po 10 sekundách.

Ďalšou príležitosťou sú napr. prihlasovanie, alebo správa zoznamu obľúbených položiek. Príklad delenia backlogu produktu typu Netflix podľa operácií ja na nasledujúcej mape.

V user story mape si produktový vlastník vie jednotlivé user stories zoradiť a vytvoriť tak adekvátne minimálne použiteľné, alebo predateľné produkty. Tie viete vypublikovať, overiť ako fungujú a až potom pridávať ďalšiu funkčnosť, keď bude mať zmysel. A možno si ju ľudia sami vypýtajú, zahlasujú za niektoré.

eCommerce

eCommerce aplikácie ako napr. Amazon alebo Alza majú viacero funkčností, ktoré sa dajú použiť pri delení požiadaviek na menšie. Zaujímavé na nich je aj to, že často jedna funkcionalita má viacero variánt, ako napr. kúpiť a kúpiť okamžite.

Ďalšími vhodnými operáciami môžu byť Pridanie medzi obľúbené položky, Odstránenie z obľúbených položiek, Porovnať, Hlasovať, Sledovať. Tieto operácie sa často identifikujú už veľmi skoro. Už pri samotnom brainstormingu funkcionalít produktový vlastník zistí, ktoré funkčnosti sú fakt dôležité. Už tu sa eliminuje kopa zbytočností.

Ak aj vám napadlo vyvinúť ďalší eCommerce systém, možno práve zmapovanie požiadaviek týmto spôsobom vám umožní si vybrať vhodné, už existujúce, riešenie.

Banková aplikácia

V bankových aplikáciách je tento typ delenia vhodný pri:

• prezeraní stavu účtov a tranzakciách,
• pri operáciách s kartami,
• pri operáciách so samotnými tranzakciami ako napr. export, tlač, share,
• dnes už moderné bankové aplikácie (ako napr. od Tatra banky) majú aj vytvorenie účtu a prihlásenie skrz biometriu.

Poistenie

Aplikácie v poisťovníctve používajú tento typ delenia požiadaviek pri výbere poistného produktu a jeho kúpe. V podstate je to už veľmi podobné deleniu podľa business procesu, ale nakoniec je to jedno. Hlavne že sú požiadavky menšie, nie?

Telekomunikačný operátor, self-care aplikácia

Používate ecare aplikáciu svojho mobilného operátora? Či už mobilná, alebo web aplikácia, obe umožňujú vykonávať základné operácie so svojim telefónnym účtom, resp. iným produktom.

• Prezeranie stavu produktu – Ako klient operátora si chcem prezerať stav kúpeného produktu, aby som poznal svoje náklady.
• História volaní – Ako klient operátora si chcem pozrieť históriu volaní, aby som vedel riadiť svoju spotrebu v nasledujúcom období.
• Export zoznamu volaní – Ako klient operátora si chcem vyexportovať zoznam volaní v aktuálnom období, aby som mohol spraviť ďalšie podrobnejšie analýzy.
• Prikúpenie produktov – Ako klient operátora potrebujem prikúpiť ďalší produkt.

HR

Aplikácie pre HR oddelenia sú komplikovanejšie, keďže aj HR procesy pokrývajú rôzne štádiá vzťahu zamestnávateľa a zamestnanca. V tomto príklade sa zameriame na prijímací proces a tréningový proces.

• Práca s poznámkami z prijímacieho procesu.
• Tlač profilu.
• Email profilu iným kolegom.
• Archivácia poznámok a profilu.
• Hľadanie tréningu.
• Pozvanie na tréning.
• Zdieľanie detailov o tréningu.

Napadá vám niečo ďalšie?

Tak neváhajte si to zapísať do svojho backlogu a vyskúšať, že všetko veľké sa skladá z malých vecí. A menšie veci dokončíte skôr, s menším počtom chýb a hlavne s rýchlejším feedbackom a overením zo strany používateľov.