Ak Ti sú známe 4 piliere agilného manifesta, potom pochopíš, prečo (z)brojím proti siahlodlhým dokumentáciam, plánom... keďže sa vo väčšine softvérových projektov nachádzame v prostredí neistoty, nie je efektívne tráviť veľa času teoretizovaním - písaním 30 stranového wordu, ktorý pôjde ešte na 3 schvaľovacie kolečká, a potom sa vráti ako 60 stranová funkčná špecifikácia.

Je lepšie konať. Ja viem, že sa to môže javiť ako prílišné zjednodušovanie. Ok. Ale fakt si treba opakovane pokladať otázku ako štíhly je proces, ktorý zabezpečuje riešenie od vzniku potreby. Ako dlho trvá, kým sa (dobrá) idea stane skutočnosťou?

Čo je WD-40 pre softvérové projekty?

Kto netuší, čo je WD-40, tak šup, pozrieť stránku výrobcu.

WD-40 Multi-Use Product protects metal from rust and corrosion, penetrates stuck parts, displaces moisture and lubricates almost anything.
Zdroj: https://www.wd40.com/

Tak ako je WD-40 schopné rozhýbať niečo zahrdzavené (zaseknuté), ako je schopné zároveň hrdzaveniu (zaseknutiu) zabrániť, tak je kontexte softvérového projektu možné nájsť artefakty, postupy a odporúčania, ktoré pomáhajú efektívnejšie zabezpečovať tvorbu hodnoty - funkčný softvér (viď hodnota č. 2 agilného manifesta), eliminovať plýtvanie.

Dnes sa pozrieme bližšie na detail artefaktu: user story. Internety sú plné vystvetlení, čo je user story. Ja som sa tomu tiež venoval, a rovnako som písal ako o tom, ako napísať dobrú user story).

User story je z môjho pohľadu neukecaná dokumentácia toho, čo biznis potrebuje z pohľadu rolí (aktérov), ktorí s aplikáciou (systémom) interagujú. Plus, okrem toho, že to je efektívný spôsob popísania to be stavu, a rovnako po doručení sa stáva zoznam user stories aj efektívnym prehľadom stavu as is (toho čo máme, aké už funkcionality už naše softvérové riešenia majú).

Kde použiť user story?

IMO, všade tam, kde sa popisuje interakcia bežných ľudí so strojom. V ľudskej reči pisujem, čo očakávam, že bude na vstupe a čo dostanem vo finále na výstupe. Zároveň nič nebráni tomu, aby sa aj zo stroja stal "človek", a jeho úlohy boli zaznamenané v tejto forme.

As robot I sent automatic email reminders about not paid invoices to ensure better cashflow.

Doména doma

Ak Ti softvérové riešenie dodáva externý partner, ak user stories tvoríš, vieš vytvoriť, (s)poznáš lepšie svoje problémy, aj (potencionálne) softvérové riešenia. S user story preberáš viac porozumenia vlastnej doméne na seba. Ako biznisový problém alebo výzva sú dopytom po po riešení, je práve riešenia zadokumentovávané vo forme user stories ponukou na tento dopyt. Ty nepotrebuješ vedieť softvér vytvárať (byť prográmatorom). Áno, je dobré ak poznáš diely, z ktorých programátori riešenia vytvárajú, ale nie je to nevyhnutné predispozícia.

User story nie je vytesaná do kameňa. Je spôsobom, ako odovzdáš tvoju myšlienku, ako myslíš, že by riešenie na problém mohlo vypadať. Ak sa tvojim prográmotorom nezdá, je práve vítané, aby sa žiadna strana nezaľúbila do svojho nápadu, a bola pripravená diskutovať (dávať spatnú väzbu). Preto aj oni by mali byť uvedený do kontextu a mal by im byť známy problém/cieľ.

Aj keď veľa krát finálna učesaná user story vypada jednoducho a elegantne, tak cesta k nej nie je až taká jednoduchá, a zvyčajne ju človek nenapíše na prvú dobrú.

Ale, ...

Je mi jasné, že nemôžeš formou user story zapísať všetko. Jasné, že nie, ale na popis riešenia sa snaž nestratiť zreteľ z toho, že user stories sú efektívny a zároveň štruktúrovaný (a) As ..., b) I want ... , c) so That ...) spôsob, ako dokumentovať.

Čo iné sa ponúka pre doplnenie user stories:

Épos (epic) - lepidlo, ktoré na jednom mieste dokumentuje kontext k identifikovaným problémom/výzvam. User stories naň referujú.
Iniciatíva (initiative) - združenie éposov, ktoré sa viaže na konkrétny cieľ biznisu. Stratégiu biznisu rozložíme do jednotlivých iniciatív. Tieto iniciativy následne reflektújú nase "stávky", hypotézy - old-schoolisti používajú slovo projekty :) - ktoré sa pokúšame overiť v praxi.
Platíme (dobre, veľa) programátorov preto, aby sa realizovali. A tí dobrí programátori potrebujú vedieť aj kontext, nielen len slepo sledovať príkaz, čo majú urobiť.
Job story - to je práve spôsob, ktorým situáciu tvojho zákazníka (či už interného alebo externého) efektívne zachytíš pre zvyšok tímu. Formalizácia informácií, ktoré zistíš pri rozhovore so zákazníkom.
Chyba (bug) - jasné, ak narazíš na chybu v existujúcom riešení, nebudeš sa ju snažiť napasovať do formátu user story.
Problem story - niektoré atribúty enterprise architektúry nie je možné priamo prepojiť na funkčné očakávania biznisových používateľov. Stav architektúry softvérových riešení podlieha entropii (neporiadku). Ak EA necháme hniť, dobehne nás to. Popísanie (často technického) problému a k nemu riešenie, sa rovnako nebudem snažiť našiť do formátu user story. Tak ako sú chyba, alebo user story viditeľné, odstraňovanie (mitigácia) rizík, alebo technologického dlhu, je neviditeľná ale za to kľúčová pre našu agilitu do budúcna.

Život je tak komplikovaný, aký si ho urobíme. Skúsme si ho zjednodušiť. Už píšeš prvé user stories? Ak máš problém, otázku, kľudne ma kontaktuj.