Definicja gotowości (Definition of Ready): zalety i zagrożenia

Rzadziej stosowana niż Definition of Done, Definition of Ready jest używana przez niektóre zespoły do określenia, które elementy Product Backlogu mogą być przyjęte do iteracji.

Definition of Ready można sobie wyobrazić jako dużego, silnego bramkarza stojącego przed drzwiami kolejnej iteracji. Podobnie jak bramkarz, który wpuszcza do klubu tylko określone osoby – młodych, modnych i dobrze ubranych – Definition of Ready wpuszcza do iteracji tylko określone User Stories.

I tak jak klub może sam zdecydować, kogo bramkarze mogą wpuścić, a kogo nie, każdy zespół i każda organizacja może sama zdecydować, jak brzmi jej Definition of Ready. Nie ma uniwersalnie obowiązującej Definition of Ready dla wszystkich zespołów.

Wzorzec Definition of Ready

Jakie rodzaje Stories mógłby więc nasz bramkarz wpuścić do iteracji? Mógłby np. wpuścić Stories spełniające te lub podobne kryteria:

• Warunki akceptacji dla danej Story zostały w pełni określone.

• Story została oszacowana i ma ustaloną maksymalną wielkość. Jeśli np. zespół pracuje ze Story Points, członkowie zespołu ustalają określoną liczbę Story Points i pozwalają do iteracji wejść tylko Stories, które odpowiadają tej liczbie lub są mniejsze. Często ta maksymalna wielkość wynosi około połowy velocity zespołu.

• Projektant interfejsu użytkownika stworzył już makietę lub kompletny projekt ekranów związanych ze Story.

• Zewnętrzne zależności zostały usunięte, niezależnie od tego, czy są to zależności wewnętrzne, czy zewnętrzne wobec zespołu.

Definition of Ready definiuje warunki wstępne

Definition of Ready umożliwia zespołowi ustalenie kryteriów, które muszą być spełnione, zanim Story może zostać przyjęta do iteracji. Celem jest zapobieganie problemom, zanim w ogóle będą miały szansę się pojawić.

Stwierdzenie, że do iteracji mogą być przyjęte tylko Stories do określonej maksymalnej wielkości, zapobiega na przykład rozpoczęciu pracy nad Story, która jest za duża, aby zostać ukończona w jednej iteracji.

Podobnie nieprzyjmowanie do iteracji Stories z zewnętrznymi zależnościami może chronić przed tym, że te zależności zagrożą Story lub całej iteracji, jeśli drugi zespół nie wywiąże się ze swojego zobowiązania.

Wyobraź sobie na przykład, że Twój zespół jest czasem zależny od tego, że inny zespół najpierw wykona część pracy. Twoje User Stories można więc ukończyć tylko wtedy, gdy drugi zespół wykona swoją pracę – i to na czas, aby Twój zespół miał szansę zintegrować te rzeczy.

Jeśli ten zespół regularnie zawodził Twój zespół, bo nie kończył czegoś w obiecywanym terminie, logiczne byłoby, gdyby Twój zespół zdecydował się nie przyjmować już Stories do iteracji, przy których nadal istnieje nierozwiązana zależność od drugiego zespołu.

Definition of Ready stwierdzająca, że wszystkie zewnętrzne zależności muszą być usunięte przed przyjęciem Story do iteracji, mogłaby być sensowna dla takiego zespołu.

Definition of Ready nie zawsze jest dobrym pomysłem

Niektóre zasady naszego bramkarza są więc najwyraźniej dobrym pomysłem. Na przykład nie mam nic przeciwko temu, gdy zespół decyduje, że do iteracji nie mogą trafiać Stories przekraczające określoną maksymalną wielkość.

Jednak niektóre zasady, które częściej widzę w Definition of Ready, mogą powodować problemy – duże problemy. Pozwólcie, że to wyjaśnię.

Definition of Ready jest jak brama do iteracji. Zasady są ustalane, a nasz bramkarz dba o to, aby wpuścić tylko Stories spełniające te zasady.

Jeśli te zasady między innymi stanowią, że coś musi być w 100% ukończone, zanim Story może zostać przyjęta do iteracji, Definition of Ready staje się dość dużym krokiem w kierunku sekwencyjnego podejścia stage-gate. To powstrzymuje zespół od bycia zwinnym.

Definition of Ready może prowadzić do etapów i bram

Pozwólcie, że to pokrótce wyjaśnię. Podejście stage-gate charakteryzuje się serią etapów (stages) dla procesu wytwarzania. Ponadto w podejściu stage-gate definiuje się tzw. bramy (gates) lub punkty kontrolne. Prace mogą przejść z jednego etapu do następnego tylko po przejściu przez bramę.

Kiedy byłem małym dzieckiem, moja mama stosowała podejście stage-gate przy kolacji. Deser dostawałem tylko wtedy, gdy zjadłem wszystko. Nie wolno mi było jeść kolacji i deseru jednocześnie.

Aby wyrazić to przykładem z wytwarzania produktów, wyobraź sobie proces z oddzielnymi etapami projektowania i kodowania. Aby przejść z etapu projektowania do etapu kodowania, prace muszą przejść przez bramę przeglądu projektu. Brama ma zapewnić kompletność i dokładność pracy w poprzednim etapie.

Jeśli teraz Definition of Ready zawiera zasadę, że coś musi być gotowe, zanim coś innego może zostać rozpoczęte, prowadzi to zespół niebezpiecznie blisko podejścia stage-gate. I to wpłynie negatywnie na zdolność zespołu do bycia zwinnym. Podejście stage-gate to bowiem tylko inne słowo na proces kaskadowy.

Zwinne zespoły powinny ćwiczyć równoczesne wytwarzanie

Gdy jedna rzecz nie może zostać rozpoczęta, dopóki inna nie zostanie ukończona, praca zespołu nie może już odbywać się równocześnie. Równoczesne wykonywanie pracy jest jednak jednym z najbardziej oczywistych wskaźników tego, że zespół jest zwinny. Zwinny zespół powinien zawsze wykonywać odrobinę pracy analitycznej, projektowej, testowej i kodowania jednocześnie. Budując bramy w procesie wytwarzania, uniemożliwia się jednak właśnie to.

Zwinne zespoły powinny ćwiczyć równoczesne wytwarzanie, przy którym różne działania zmierzające do dostarczenia działającego oprogramowania nakładają się na siebie. Działania takie jak analiza, projektowanie, pisanie kodu i testowanie nigdy nie będą odbywać się w dokładnie tym samym czasie – i to nie jest celem. Celem jest po prostu, aby te działania jak najbardziej się na siebie nakładały.

Poprzez to, że w podejściu stage-gate określone działania muszą być w 100% ukończone, uniemożliwia się rozpoczęcie innych działań. A Definition of Ready może bezpośrednio prowadzić do takiego podejścia stage-gate, jeśli takie zasady zostaną włączone do Definition of Ready.

Z tego powodu polecam większości zespołów nie pracować z Definition of Ready. Często jest to niepotrzebny wysiłek. I co jest jeszcze gorsze, może to być duży i niebezpieczny krok powrotu do procesu kaskadowego.

W niektórych przypadkach Definition of Ready może jednak rozwiązać problemy i wówczas warto z niej korzystać.

Właściwe stosowanie Definition of Ready

Aby móc skutecznie korzystać z Definition of Ready, powinieneś unikać zasad, które mówią, że coś musi być w 100% ukończone, zanim Story może zostać przyjęta do iteracji – być może z wyjątkiem zależności od określonych zespołów lub dostawców. Ponadto powinieneś raczej decydować się na wytyczne zamiast zasad w swojej Definition of Ready.

Oto przykład zasady, którą zespół powinien jeszcze raz przeformułować: „Do każdej Story muszą być dla wszystkich nowych ekranów szczegółowe makiety."

Taka zasada stanowi bramę. Uniemożliwia równoczesne wykonywanie pracy. Zespół z tą zasadą nie może praktykować równoczesnego wytwarzania. Dopóki dla każdej pojedynczej Story nie zostanie opracowany szczegółowy projekt, nie ma pracy po drugiej stronie bramy.

Lepszym wariantem byłoby: „Jeśli Story zawiera ważne nowe ekrany, powinny wcześniej zostać już stworzone makiety nowych ekranów w wystarczającym stopniu, aby zespół mógł wyjaśnić pozostałe pytania i problemy w trakcie iteracji."

Mała zmiana, duże znaczenie w Definition of Ready:

1. Zasada staje się wytyczną.
2. Mówiąc, że makiety muszą być jedynie wystarczające, a nie gotowe, pozwalamy na równoczesną pracę.

Te dwie zmiany wprowadzają nieco więcej subiektywności do stosowania Definition of Ready. Nadal mówimy bramkarzowi, że chcemy mieć w naszym klubie młodych, modnych i dobrze ubranych ludzi. Dajemy mu jednak więcej swobody w samodzielnym decydowaniu, co właściwie oznacza „dobrze ubrany".

Niniejszy tekst pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony na język polski.