Zapewne większość sympatyków Agile korzysta już z koncepcji Definicji Ukoń­czenia Prac (ang. Definition of Done, DoD), która informuje kiedy de facto zadanie można uznać jako zakończone. Korzyści wynikających z wdrożenia DoD jest wiele. W mojej opinii najważniejszą z nich jest to, że zapewnia ona poczucie bezpieczeń­stwa oddania produktu zgodnego z na­szymi oczekiwaniami oraz wyznaczonymi standardami.


To poczucie bezpieczeństwa nie powinno jednak być budowane wyłącznie przy odbiorze produktu. Można je także zapewnić jeszcze przed rozpoczęciem prac. Jak? Poprzez zawarcie umowy, informującej kiedy dane zadanie dopuszczamy do podjęcia.

Gotowość rozpoczęcia

Definicja Gotowości (ang. Definition of Re­ady, DoR) jest zdecydowanie rzadziej wy­korzystywanym konceptem niż Definicja Ukończenia Prac. I osobiście bardzo mnie to dziwi, ponieważ odpowiednio przygotowana i wdrożona DoR jest potężnym narzędziem. Z jednej strony zabezpieczającym Zespół De­weloperski przed wykonywaniem pracy nara­żonej na ryzyko zmian (na przykład przez to, że nie zostały przedstawione/potwierdzo­ne założenia z interesariuszami), z drugiej, wspierającym tworzenie zadań o wysokiej jakości przez osoby zlecające. Mamy zatem sytuację win-win.

Dobrze przygotowana Definicja Gotowości Rozpoczęcia Prac powinna zawierać wszyst­kie warunki, jakie zadanie spełni nim trafi do realizacji czy, wcześniej, na planowanie. Nie ma jednoznacznego przepisu jak powinien wyglądać taki Kontrakt – każdy zespół bę­dzie miał swoje DoR, ponieważ wszystko za­leży od jego składu, kontekstu produktu/pro­jektu oraz środowiska w którym funkcjonują. Pewne jest jednak, że Definicja Gotowości powinna przechodzić przez cykl, w którym to inkrementacyjnie podczas swojego życia może (ba, nawet powinna!) ulegać zmianom. Na pewno przy pierwszym podejściu okaże się, że o wielu elementach zapomnieliśmy, że stopień szczegółowości jest zbyt niski. Przy kolejnej iteracji prac można dodać elemen­ty DoR lub odjąć nadmiarowe. Jest to żywy artefakt, zmian można się więc spodziewać dopóki dany produkt czy też projekt będzie istnieć. Wynika to głównie z dwóch powo­dów: wraz z cyklem życia produktu/projek­tu mogą się też zmieniać względem niego wymagania, oraz w miarę z dojrzewaniem zespołu i doświadczania nowych sytuacji ma on potrzebę dokonania zmiany w podjętych wcześniej decyzjach. Jest to naturalne.

Proces zakończony Kontraktem

Artefakt Gotowości Rozpoczęcia Prac po­winien być kontraktem między jego intere­sariuszami. Aktualnie pracuję jako Product Owner i jestem absolutnym przeciwnikiem narzucania swoich przekonań zespołowi. Wolę wspólnie wypracowywać rozwiązania, niż w sposób dyktatorski je narzucać. Wo­bec tego, jestem zwolennikiem wspólnego wyznaczania DoR, dzięki czemu utrzymany zostanie wysoki poziom zaangażowania każ­dej ze stron.

W spotkaniu inicjującym powstanie Defi­nition of Ready powinny uczestniczyć wszyst­kie zainteresowane osoby: osoby, które będą korzystały z artefaktu DoR – osoby, które między sobą zawrą Kontrakt. Będą to zarów­no role wytwórcze, czyli członkowie zespo­łu deweloperskiego (w tym np. Programiści, Analitycy, Testerzy) jak i role „zarządcze”, takie jak Project Manager, Product Owner, Servant Leader. Generalnie: wszystkie osoby, które tworzą zadania, bądź mają wpływ na ich tworzenie, a także wszystkie osoby, któ­re będą pracować nad tym zadaniem.

Podczas spotkania, powinien zostać za­chowany komfort wypowiedzenia się dla każdej ze stron i wszyscy powinni wyjść z przekonaniem, że został obrany odpowied­ni kierunek. Facylitator zdarzenia zobowią­zany jest poprowadzić je w taki sposób, aby zostały zachowane wszystkie elementy dys­kusji. Świetnie sprawdzi się tutaj technika burzy mózgów.

Najlepiej rozpocząć dyskusję od refleksji w obszarze falstartów nad zadaniami. Warto postawić sobie pytania: Co dla nas oznacza słabej jakości zadanie albo przeciwnie – co się składa na wysokiej jakości zadanie? Czego zazwyczaj brakuje nam, o jakich informacjach najczęściej zapominamy bądź pomijamy? Za­stanówmy się, kiedy najbardziej efektywnie zespół pracuje nad zadaniem, a kiedy traci czas, na przykład na domyślanie się, dopo­wiadanie sobie pewnych założeń bądź przyj­mowanie założeń (bez uzgodnień) powodu­jących wysokie ryzyko powrotu do zadania w przyszłości.

Listę pomysłów należy pogrupować, zre­dundować powielające się informacje. Spisać w jednym dokumencie i voilà – mamy utwo­rzony żywy artefakt Definition of Ready. Każ­dy z uczestników powinien dobrze się z nim czuć i zaakceptować ten Kontrakt.

Poniżej przedstawiam przykład, jak mo­głoby wyglądać potencjalne DoR do zadania produktu IT.

Cykl życia DoD powinien zawierać ele­ment weryfikacji jego prawidłowości. Do­brym miejscem na to jest retrospektywa. Podczas niej można dywagować na temat optymalizacji Definicji Gotowości Rozpoczę­cia, co w dalszej kolejności stanie się otwar­ciem dyskusji o wprowadzaniu usprawnień.

Ostatni bardzo ważny element – Kon­trakt Gotowości Rozpoczęcia powinien być transparentny! Dostępny dla wszystkich zainteresowanych. Może być wywieszony na tablicy wewnątrz pomieszczenia w którym pracuje zespół, załączany jako checklista do zadań w Jira czy dodany do Wiki w Conflu­ence. Miejsce nie ma większego znaczenia – ważne jest zapewnienie jego dostępności.

Przykład Definition of Ready dla zadania produktu IT

Niebezpieczeństwo DoR

Zalet DoR jest wiele – sama jestem zwo­lennikiem tej koncepcji. Pozwala mi ona na przygotowanie wysokojakościowych zadań dla zespołu. W sposób zauważalny widzę redukcję liczby powtórnych podejść do zre­alizowanych funkcjonalności.

Jest jednak jedna bardzo ważna kwestia którą chciałabym poruszyć. Jest to ryzyko związane z posiadaniem DoR, polegające na tym, że Zespół zbyt dosadnie będzie trak­tował zawarte w niej elementy. Rozpocznie się zero-jedynkowe podejście do klasyfikacji, czy dane zadanie może zostać rozpoczęte czy nie. Kiedy Definicja Gotowości zawiera regułę, że coś MUSI być zrobione, zanim za­cznie się kolejna rzecz, powoduje to, że tak naprawdę wprowadzamy kaskadowość. Na przykład jeżeli zespół uprze się na posiadanie zakończonych widoków UX przed rozpoczę­ciem pracy, cały etap projektowania będzie musiał być zakończony przed faktycznym programowaniem. W takim przypadku „gubi­my” zwinność. Odmowa podjęcia się zadania, które nie spełnia DoR może skutkować nie tylko frustracją, ale i także może być szko­dliwe dla samego projektu, na przykład nara­żać na ryzyko nieukończenia prac w terminie. Bardzo ważne są wobec tego zdrowy rozsą­dek, elastyczność oraz edukacja w zakresie zwinności.

Podsumowanie

Definicja Gotowości Rozpoczęcia Prac jest z pewnością koncepcją wspierającą osiągnięcie sukcesu. Dla osób zlecających pracę jest to swoisty przewodnik jak dane zadanie powinno zostać przygotowane. Dla wykonawców jest to lista kontrolna pozwalająca na upewnienie się, że sukces w dostarczeniu zadania jest w zasięgu ręki. Kontrakt zawarty między jego interesariuszami daje każdej stronie poczucie bezpieczeństwa w kontekście realizowania prac. W odpowiednich „rękach” i przy odpowiednim mindsecie staje się potężnym narzędziem.