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 naszymi 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 Ready, DoR) jest zdecydowanie rzadziej wykorzystywanym 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ół Deweloperski przed wykonywaniem pracy narażonej na ryzyko zmian (na przykład przez to, że nie zostały przedstawione/potwierdzone 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ć wszystkie 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 zależy od jego składu, kontekstu produktu/projektu 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ć elementy 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 powodów: wraz z cyklem życia produktu/projektu 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 powinien być kontraktem między jego interesariuszami. 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ć. Wobec 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 Definition of Ready powinny uczestniczyć wszystkie zainteresowane osoby: osoby, które będą korzystały z artefaktu DoR – osoby, które między sobą zawrą Kontrakt. Będą to zarówno 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ć zachowany komfort wypowiedzenia się dla każdej ze stron i wszyscy powinni wyjść z przekonaniem, że został obrany odpowiedni kierunek. Facylitator zdarzenia zobowiązany jest poprowadzić je w taki sposób, aby zostały zachowane wszystkie elementy dyskusji. Ś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? Zastanówmy się, kiedy najbardziej efektywnie zespół pracuje nad zadaniem, a kiedy traci czas, na przykład na domyślanie się, dopowiadanie sobie pewnych założeń bądź przyjmowanie założeń (bez uzgodnień) powodujących wysokie ryzyko powrotu do zadania w przyszłości.
Listę pomysłów należy pogrupować, zredundować powielające się informacje. Spisać w jednym dokumencie i voilà – mamy utworzony ż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 mogłoby wyglądać potencjalne DoR do zadania produktu IT.
Cykl życia DoD powinien zawierać element weryfikacji jego prawidłowości. Dobrym 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ę otwarciem dyskusji o wprowadzaniu usprawnień.
Ostatni bardzo ważny element – Kontrakt 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 Confluence. Miejsce nie ma większego znaczenia – ważne jest zapewnienie jego dostępności.
Przykład Definition of Ready dla zadania produktu ITNiebezpieczeństwo DoR
Zalet DoR jest wiele – sama jestem zwolennikiem 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 zrealizowanych 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 traktował 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 zacznie 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 „gubimy” 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ć szkodliwe 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.
Project Leader o technicznym backgroundzie i product managementowej przeszłości. Ex-perfekcjonistka po „odwyku” identyfikująca się z mottem „bądź najlepszym niedoskonałym sobą, jakim zdołasz”. Fanka specyficznego humoru półświatka IT, wiernego kompana (psa) Astona i kryminalnych podcastów!