Séria: Ako písať dokumentáciu a manuály v IT projekte
Minimálny model riešenia
Najjednoduchší spôsob, ako zlepšiť kvalitu zadania, je porovnať slabé a dobré príklady.
Na prvý pohľad často vyzerajú podobne, ale rozdiel v zrozumiteľnosti pre tím je veľký.
Nižšie je niekoľko typických situácií z projektov.
Príklad 1 – príliš všeobecná user story
Slabé zadanie
User story:
Pridať export objednávok.
Akceptačné kritériá:
Export funguje správne.
Prečo je to slabé
Nie je jasné:
- kto export používa
- aké údaje sa exportujú
- aký je formát exportu
- čo sa stane pri chybách
Dobré zadanie
User story:
Ako účtovníčka chcem exportovať objednávky do CSV, aby som ich mohla spracovať v účtovnom systéme.
Akceptačné kritériá:
- export je dostupný pre rolu Účtovník
- export obsahuje číslo objednávky, dátum a cenu
- po kliknutí na Export sa stiahne CSV súbor
Prečo je to dobré
Je jasné:
- kto funkcionalitu používa
- aký je jej účel
- aké je očakávané správanie systému
Príklad 2 – technické riešenie namiesto problému používateľa
Slabé zadanie
User story:
Implementovať endpoint /orders/export.
Akceptačné kritériá:
- endpoint vracia CSV
Prečo je to slabé
Opisuje technické riešenie, nie problém používateľa.
Zadanie je zrozumiteľné pre vývojára, ale nie pre testerov, analytikov alebo dokumentáciu.
Dobré zadanie
User story:
Ako administrátor chcem exportovať zoznam objednávok, aby som mohol pripraviť report.
Akceptačné kritériá:
- export je dostupný len pre rolu Administrátor
- export obsahuje všetky objednávky za vybrané obdobie
- export je vo formáte CSV
Prečo je to dobré
User story opisuje biznis potrebu, nie technickú implementáciu.
Príklad 3 – chýbajúce výnimky
Slabé zadanie
User story:
Používateľ môže zmeniť heslo.
Akceptačné kritériá:
- používateľ môže zmeniť heslo
Prečo je to slabé
Nie je jasné:
- aké sú pravidlá pre nové heslo
- čo sa stane pri nesprávnom hesle
- aké sú bezpečnostné obmedzenia
Dobré zadanie
User story:
Ako používateľ chcem zmeniť heslo, aby som mohol zvýšiť bezpečnosť účtu.
Akceptačné kritériá:
- používateľ musí zadať pôvodné heslo
- nové heslo musí mať minimálne 8 znakov
- ak pôvodné heslo nesedí, zobrazí sa chybová hláška
Prečo je to dobré
Opisuje základné správanie aj jednu typickú výnimku.
Príklad 4 – viac funkcionalít v jednej user story
Slabé zadanie
User story:
Upraviť fakturáciu a export faktúr.
Akceptačné kritériá:
- fakturácia funguje správne
Prečo je to slabé
User story obsahuje viacero funkcionalít.
Nie je jasné, čo je vlastne predmetom implementácie.
Dobré zadanie
User story:
Ako účtovník chcem exportovať faktúry, aby som ich mohol spracovať v účtovnom systéme.
Akceptačné kritériá:
- export obsahuje číslo faktúry, dátum a sumu
- export je dostupný pre rolu Účtovník
Prečo je to dobré
User story rieši jednu konkrétnu funkcionalitu.
Príklad 5 – zložitejší problém s nedostatočným opisom
Niektoré funkcionality sa nedajú opísať jednou vetou.
Ak je problém zložitejší, user story môže obsahovať aj kratší opis situácie.
Slabé zadanie
User story:
Upraviť reklamácie objednávok.
Akceptačné kritériá:
- reklamácia funguje správne
Prečo je to slabé
Nie je jasné:
- kto môže reklamáciu vytvoriť
- v akých situáciách
- čo sa má v systéme stať po jej vytvorení
Príklad 6 – zložitejší problém s kontextom
Niektoré funkcionality sa nedajú opísať jednou vetou.
Ak je problém zložitejší, user story môže obsahovať aj kratší opis situácie.
Slabé zadanie
User story:
Upraviť reklamácie objednávok.
Akceptačné kritériá:
- reklamácia funguje správne
Prečo je to slabé
Nie je jasné:
- kto môže reklamáciu vytvoriť
- v akých situáciách
- čo sa má v systéme stať po jej vytvorení
Dobré zadanie
User story:
Zákazníci môžu reklamovať objednávky, ak bol tovar poškodený alebo doručený nesprávny produkt.
Reklamáciu vytvára operátor zákazníckej podpory na základe požiadavky zákazníka.
Ako operátor podpory chcem vytvoriť reklamáciu objednávky, aby bolo možné sledovať jej vybavenie a informovať zákazníka o stave riešenia.
Akceptačné kritériá:
- reklamáciu môže vytvoriť používateľ s rolou Support
- reklamácia je viazaná na konkrétnu objednávku
- po vytvorení reklamácie sa nastaví stav „Nová“
- reklamácia obsahuje dôvod reklamácie a poznámku operátora
Prečo je to dobré
Zadanie vysvetľuje kontext problému a zároveň opisuje správanie systému.
Krátke zhrnutie
Dobrá user story opisuje:
- kto má problém
- čo chce dosiahnuť
- prečo je to dôležité
Dobré akceptačné kritériá opisujú:
- ako sa má systém správať
- aké sú základné výnimky
- kedy je funkcionalita považovaná za hotovú
Keď sú tieto dve vrstvy napísané dobre, vzniká z nich prirodzený základ pre testovanie, dokumentáciu aj zrozumiteľné release notes.