akceptačné kritériá

Dokumentácia a používateľské príručky, User story a akceptačné kritériá

Ako rozoznať dobré vs slabé user story a akceptačné kritériá (praktické ukážky)

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.…

Dokumentácia a používateľské príručky, User story a akceptačné kritériá

Ako z user story a akceptačných kritérií vznikajú testy, dokumentácia a release notes (Epic → Story → Task → Bug v Jire)

Séria: Ako písať dokumentáciu a manuály v IT projekte

Reálny problém z praxe

V projekte pribudne nová funkcionalita.

V Jire existuje Epic, niekoľko user story a pár taskov. Vývoj prebehne, tester pripraví testy a funkcionalita sa nasadí do produkcie.

Potom príde moment, keď treba pripraviť:

  • text do používateľského manuálu
  • informáciu pre support
  • release notes k novej verzii

A tím začne hľadať, kde vlastne je napísané:

  • čo mala funkcionalita robiť
  • pre koho bola určená
  • aké sú výnimky
  • čo sa v systéme zmenilo

Časť informácií je v user story.…

Dokumentácia a používateľské príručky, User story a akceptačné kritériá

Najčastejšie chyby v akceptačných kritériách

Séria: Ako písať dokumentáciu a manuály v IT projekte

Reálny problém z praxe

V Jire sa objaví user story s jedným akceptačným kritériom:

„Systém správne spracuje objednávku.“

Vývojár začne rozmýšľať, čo presne má implementovať.
Tester sa neskôr snaží zistiť, ako to vlastne funguje.
A keď niekto píše manuál, musí funkcionalitu najprv skúšať v systéme, aby zistil, čo robí.…

Dokumentácia a používateľské príručky, User story a akceptačné kritériá

Ako písať testovateľné akceptačné kritériá

Reálny problém z praxe

Séria: Ako písať dokumentáciu a manuály v IT projekte

User story je často jedna veta. A akceptačné kritériá k nej buď nie sú vôbec, alebo sú tiež len „nejaké poznámky“.

Potom to dopadne vždy rovnako:

  • vývoj implementuje podľa svojho výkladu,
  • tester testuje podľa svojho výkladu,
  • dokumentácia sa píše podľa toho, čo sa „náhodou“ správa v systéme.
Návrat hore