Dołącz do 8 edycji programu i:

Stań się Product Ownerem, który wiedzę, kompetencje i procesy ma w jednym palcu i systematycznie buduje swoją pozycję eksperta.

Czym jest Definition of Ready i czemu desperacko go potrzebujesz?"

Czym jest Definition of Ready i czemu desperacko go potrzebujesz?

Dlaczego Definition of Ready jest niezbędny?

W tym filmie tłumaczę czym jest ta definicja i dlaczego każdy zespół deweloperski desperacko go potrzebuje.

👉 Zobacz pełne wideo

Definition of Ready — czyli definicja gotowości — to jedno z tych narzędzi, których brak w projekcie od razu widać. Szokująco często, kiedy doradzam w projektach, nie widzę go spisanego. Czasem brakuje nawet wiedzy, czym jest definition of ready. A bez niego możesz tylko strzelać, czy wymaganie jest gotowe do implementacji, czy nie.

Co to jest Definition of Ready (DoR)?

Ta definicja mówi zespołowi, kiedy dane wymaganie jest gotowe do zaimplementowania. Brzmi prosto — i jest proste, ale diabeł tkwi w szczegółach. W zależności od projektu może znaczyć zupełnie coś innego. Co więcej, w jednym projekcie definition of ready może się różnić w zależności od rodzaju wymagania.

Kto to tworzy?

DoR musi powstać kolektywnie — razem z całym zespołem deweloperskim. To tylko oni wiedzą, czego potrzebują, żeby zacząć development. Jedna osoba nie ma pełnego wglądu ze wszystkich punktów widzenia. Dlatego to ćwiczenie trzeba wykonać wspólnie.

Gotowe definition of ready musi być spisane, zaakceptowane przez wszystkich i umieszczone we wspólnej przestrzeni — w wiki projektu, np. w Confluence.

Co może znaleźć się w Definition of Ready?

U mnie zawsze są te elementy:

  • Kryteria akceptacji spisane i zaakceptowane przez sponsora — samo porozmawianie o wymaganiu to za mało. Dopiero gdy zapiszesz to krowie na rowie pod punktami, wyjdzie czy sponsor miał to samo na myśli. Akceptację zebieram na tzw. PEO meetingu — przechodzimy krok po kroku przez wymagania na kolejny okres.
  • Kryteria zaakceptowane przez zespół — dzieje się to najczęściej na refinemencie. Zespół musi potwierdzić, że wszystko jest dla nich zrozumiałe.
  • Designy — jeśli wymaganie ma warstwę frontendową, designy muszą być gotowe zanim zacznie się development.
  • Decyzja o testach end-to-end — warto z góry ustalić, czy dla tego wymagania piszemy testy.
  • Estymacja — dla mnie to ostatni i finalny punkt. Jeśli zespół jest w stanie wyestymować wymaganie, znaczy że ma wszystko, czego potrzebuje. Jeśli nie — czegoś brakuje.

Definition of Ready w Jira — filtr, który to sprawdza

Możesz stworzyć filtr w Jirze, który automatycznie weryfikuje, czy DoR jest spełnione. Na przykład:

  • czy w opisie jest fraza “acceptance criteria”
  • czy sponsor dodał komentarz “accepted”
  • czy jest link do Figmy
  • czy wymaganie ma estymację

Jeżeli estymacja jest Twoim ostatnim punktem — filtr jest prosty: estymacja jest albo jej nie ma.

Po co to wszystko?

DoR buduje platformę porozumienia między zespołem a biznesem. Biznes często nie zdaje sobie sprawy, czego potrzebuje zespół do implementacji. Dlatego jasne spisanie tych wymagań ułatwia komunikację obu stronom — i Tobie jako PO pozwala wprost powiedzieć: jesteśmy gotowi albo nie jesteśmy gotowi.

ROADMAPA ROZWOJU PRODUCT OWNERA

Podaj dalej:

🎯 Szkolenie za 0zł

3 sposoby dla Product Ownera jak poukładać pracę w projekcie i mieć poczucie kontroli.

Warto przeczytać: