Verzia 1.0 — účinná od: [dopíš dátum]
Účel dokumentu
Táto smernica slúži na zjednotenie kritérií pripravenosti úloh pred začiatkom realizácie. Cieľom je minimalizovať nejasnosti, dodatočné otázky, nesprávne odhady a riziko implementácie na základe neúplných alebo nejasných požiadaviek.
Úloha sa nesmie zaradiť do vývoja, ak nespĺňa Definition of Ready (DoR).
Miesto Definition of Ready v procese
Nápad
↓
User Story (používateľský scenár)
↓
Definition of Ready (Pripravené na realizáciu)
↓
Vývoj
↓
Testovanie
↓
Dokumentácia
↓
Definition of Done (Podmienky dokončenia)
↓
Release (vydanie verzie)
Definition of Ready zabezpečuje kvalitu vstupu do realizácie.
Definition of Done zabezpečuje kvalitu výstupu z realizácie.
Spoločné základné DoR pre všetky úlohy
Každá úloha (User Story, Bug, Task, analýza alebo dokumentácia) sa považuje za pripravenú na realizáciu iba vtedy, ak sú splnené nasledovné podmienky:
- Úloha má jednoznačný názov.
- Je jasne definovaný cieľ úlohy.
- Je určený vlastník zadania.
- Je zrejmé, prečo sa úloha realizuje.
- Sú definované akceptačné kritériá.
- Je známy rozsah riešenia.
- Sú identifikované závislosti na iných úlohách alebo systémoch.
- Sú známe obmedzenia a výnimky.
- Sú dostupné všetky potrebné podklady.
- Tím rozumie zadaniu bez potreby dodatočných vysvetlení.
- Úloha bola predstavená a prediskutovaná tímom pred zaradením do vývoja.
- Úloha je odhadnuteľná z pohľadu času a náročnosti.
Povinné náležitosti podľa typu úlohy
Nová funkcionalita (Feature)
Musí obsahovať:
- Biznis dôvod realizácie.
- Popis očakávaného správania.
- Akceptačné kritériá.
- Hraničné podmienky.
- Chybové stavy.
- Informáciu, či ide o Core (štandardnú funkcionalitu produktu) alebo Custom (klientsku úpravu).
- UX návrhy (návrhy používateľského rozhrania) alebo wireframy (návrhy obrazoviek), ak sú potrebné.
- Dopad na existujúce funkcionality.
Chyba (Bug)
Musí obsahovať:
- Jednoznačný popis problému.
- Kroky na reprodukciu chyby.
- Očakávané správanie.
- Skutočné správanie.
- Prostredie, v ktorom chyba vznikla.
- Prioritu alebo závažnosť.
- Dôkazy (screenshot, video, log alebo chybové hlásenie).
Technická úloha (Task)
Musí obsahovať:
- Technický cieľ.
- Dôvod realizácie.
- Očakávaný výsledok.
- Riziká.
- Technické závislosti.
- Dopad na existujúcu architektúru systému.
Analýza
Musí obsahovať:
- Rozsah analýzy.
- Očakávaný výstup.
- Otázky, ktoré má analýza zodpovedať.
- Termín odovzdania.
Dokumentácia
Musí obsahovať:
- Zdrojové podklady.
- Cieľovú skupinu.
- Rozsah dokumentu.
- Účel dokumentu.
- Požadovaný výstup.
Definition of Ready podľa rolí
Produktový vlastník / Biznis analytik
- Zadanie je úplné a zrozumiteľné.
- Akceptačné kritériá sú definované.
- Sú známe biznis pravidlá.
- Sú identifikované výnimky.
- Zadanie bolo predstavené tímu.
Vývojár
- Rozumie rozsahu práce.
- Pozná technické závislosti.
- Vie navrhnúť riešenie.
- Vie odhadnúť náročnosť.
- Nemá otvorené zásadné otázky.
Tester / QA
- Vie pripraviť testovacie scenáre.
- Akceptačné kritériá sú testovateľné.
- Sú definované očakávané výsledky.
- Sú známe testovacie dáta alebo spôsob ich získania.
- Sú identifikované rizikové oblasti.
UX dizajnér
- Má dostupné požiadavky na používateľské rozhranie.
- Sú známe cieľové skupiny používateľov.
- Sú schválené návrhy alebo je určená osoba, ktorá ich schváli.
DevOps / Prevádzka
- Sú známe infraštruktúrne požiadavky.
- Sú identifikované nové závislosti.
- Je známy dopad na deployment (nasadenie novej verzie) alebo prevádzku systému.
- Sú známe požiadavky na monitoring a logovanie.
Kontrolné otázky pred začiatkom práce
Pred zaradením úlohy do sprintu (vývojového cyklu) alebo do vývoja si tím položí nasledovné otázky:
- Rozumieme tomu, čo sa má vytvoriť?
- Rozumieme tomu, prečo sa to vytvára?
- Vieme určiť, kedy bude úloha hotová?
- Vieme pripraviť testy?
- Vieme odhadnúť náročnosť?
- Poznáme riziká?
- Chýba nám nejaká informácia?
Ak je odpoveď na niektorú otázku „nie“, úloha ešte nie je pripravená na realizáciu.
Príklady DoR podľa typu úlohy
| Typ úlohy | Minimálne DoR |
| Bug | Kroky na reprodukciu, očakávané a skutočné správanie |
| Nová funkcionalita | Akceptačné kritériá, rozsah, biznis cieľ |
| Technická úloha | Technický cieľ, závislosti, očakávaný výsledok |
| Analýza | Rozsah a očakávaný výstup |
| Dokumentácia | Zdrojové podklady, cieľová skupina, rozsah dokumentu |
Revízia a zlepšovanie
- Definition of Ready je živý dokument a má byť pravidelne revidovaný.
- Zmeny sa prejednávajú na retrospektíve alebo plánovacom stretnutí tímu.
- Každý člen tímu môže navrhnúť doplnenie alebo úpravu.
- Ak sa opakovane objavujú nejasné zadania, tím má upraviť Definition of Ready tak, aby podobné problémy zachytila ešte pred začiatkom realizácie.
Súvisiace dokumenty
- Definition of Done (DoR)
- User Story a akceptačné kritériá
- Špecifikácie požiadaviek
- Testovacia stratégia
- Release proces
- Dokumentačné štandardy
Základné pravidlo:
Ak tester nevie pripraviť testy a vývojár nevie odhadnúť prácu, úloha ešte nie je pripravená na realizáciu.