Definicja Ukończenia (ang. Definition of Done) jest kluczową częścią Scruma, którego nie da się bez niej używać. Co zaskakuje, wiele Zespołów, które deklarują, że stosują tę metodę, jednocześnie albo nie ma w ogóle określonej Definicji Ukończenia, albo nie stosuje jej w praktyce. Nie jest to jedynie moje podejrzenie, ale efekt analizy danych zebranych od uczestników szkoleń, jakie prowadzę. Na podstawie ankiety, którą wypełniło kilkaset osób w czasie szkoleń związanych ze Scrumem (Scrum Masterów, Product Ownerów, Developerów), sporządziłem następujący wykres:

Czy mamy Definicję Ukończenia?

Zaledwie 32% respondentów deklaruje, że ich Zespoły mają Definicję Ukończenia i stosują ją w praktyce. Oczywiście, jest to subiektywna ocena wypełniających ankietę, dlatego sądzę, że poziom faktycznego przestrzegania Definicji Ukończenia może być nieco niższy, niż deklarowany, a niezwykle mało prawdopodobne jest, by był wyższy.

Prawie tyle samo osób (33%) twierdzi, że co prawda ma Definicję Ukończenia, ale jej nie stosuje, albo nie robi tego konsekwentnie. Niezależnie od tego, jaki jest powód niestosowania się do istniejącej formalnie Definicji Ukończenia, takie działanie skutkuje praktycznym brakiem Definicji w rozumieniu Scruma. Tym samym respondentów tej grupy można śmiało połączyć z kolejną, która deklaruje, że Definicji Ukończenia nie ma w ogóle (24%).

Czy Definicja Ukończenia, o której istnieniu nic nie wiadomo, może mimo to istnieć i działać? Nie, nie może. A więc trzeba przyjąć, że odpowiedź ostatniej grupy (11%) oznacza, że ich Zespoły Definicji Ukończenia nie mają. I zsumować ich głosy z poprzednimi dwoma grupami.

Daje to porażający odsetek 68% Zespołów, które deklarują, że posługują się Scrumem, a nie zadbały w nim o rzecz absolutnie fundamentalną, bez której niemożliwe jest zastosowanie empiryzmu w procesie rozwoju produktu.

Jak to w ogóle możliwe?

Przyczyn może być wiele, a ich niekompletna i zupełnie subiektywna lista może wyglądać na przykład tak:

  • Nikt w tych Zespołach nie rozumie Scruma i stosowany jest on mechanistycznie.
  • Nikt nie wie, czym Definicja Ukończenia jest i jak ją stworzyć.
  • Nikomu nie zależy na tym, by cokolwiek było ukończone.
  • Definicja Ukończenia, gdyby miała opisać, co naprawdę Zespół potrafi, obnażyłaby jego niskie możliwości, więc na wszelki wypadek Definicji nie sporządzono.

Tę listę bez trudu dałoby się rozszerzyć o kolejne powody i wykręty uzasadniające, dlaczego Definicji stworzyć się nie dało. Nie można do niej natomiast dodać uzasadnienia, które często słyszę w Zespołach, gdy pytam, czemu Definicji nie mają: „organizacja narzuciła nam Definicję, z którą się nie zgadzamy”.

Cóż to, u licha, za powód, by nie mieć i nie posługiwać się własną Definicją? Niechże się rozjeżdża z tą „organizacyjną”, skoro nie ma innego wyjścia, ale niechaj istnieje i jest stosowana. Przynajmniej widoczny stanie się problem z rozbieżnością opinii o tym, jak budować należy produkt nadający się do użycia. Będzie też wiadomo, co Zespół zrobił, jeśli ogłasza, że pracę nad jakąś zmianą w produkcie zakończył. A tak? Nikt nic nie wie… i pewnie o to tak naprawdę chodzi.

Przyjmijmy litościwie, że wiele Zespołów po prostu nie wie, czym jest Definicja Ukończenia, dlaczego ona jest potrzebna i jak ją stworzyć, co powoduje, że takiej Definicji nie posiada.

Definicja Ukończenia – powtórka z teorii

Scrum opiera się o empiryczną kontrolę procesu. A mówiąc po ludzku, decyzje o tym, co, jak i po co robić, podejmuje się w nim na bazie faktów, a nie założeń i domysłów. Dlatego do oceny tego, czy rozwój produktu idzie w dobrą stronę i czy budowany produkt jest zgodny z rzeczywistymi potrzebami interesariuszy (klientów, użytkowników), nie stosuje się jakiegoś abstrakcyjnego oszacowania postępu prac, mierzonego np. procentem zrealizowanych planów. Zamiast tego sprawdza się regularnie, jaki właściwie produkt jest w tym momencie. To pozwali odpowiedzieć jednoznacznie na kilka istotnych pytań:

  • Czy w ogóle udało się coś wytworzyć?
  • Jeśli nie, czy warto dalej się tym zajmować?
  • A jeśli coś powstało, czy jest tym, czego potrzebują interesariusze?
  • Jeśli nie, co trzeba zmienić?
  • Jeśli tak, co robić dalej?

Taka ocena oczywiście nie polega na sprawdzeniu w planach i projektach, czy „idziemy w dobrą stronę” i czy „plan realizowany jest zgodnie z założeniami”. Jest przecież całkiem prawdopodobne, że plany i założenia były kompletnie chybione i trzymając się ich, uzyskamy niewłaściwe rezultaty.

A jeszcze bardziej prawdopodobne jest, że plany i założenia, jakkolwiek były dobre na początku, szybko stają się nieaktualne i trzeba je zmienić, kiedy tylko uświadomimy sobie taką potrzebę. Żeby to odkryć, nie można analizować wyłącznie informacji o tym, jak idzie realizacja planów, ale trzeba przyjrzeć się efektom tych działań. Jeśli produkt zaczyna się rozjeżdżać z potrzebami interesariuszy, jest to sygnał, że idziemy w złą stronę i zmiana planów jest niezbędna.

Na tym właśnie polega empiryczna kontrola procesu (a krócej empiryzm). Robimy coś, sprawdzamy, co udało się wytworzyć i czy to jest faktycznie to, czego potrzebujemy, po czym na podstawie tej wiedzy decydujemy o kolejnych krokach.

Abyśmy mieli co sprawdzać, Scrum definiuje trzy artefakty (czyli wytwory procesu), z których jeden nosi nazwę Przyrostu (ang. Increment). Najprościej mówiąc, jest to nowa wersja produktu ze zmianami, jakich dokonał w nim Zespół Scrum. Zwracam uwagę, że nazwa Przyrost odnosi się do przyrostu wartości produktu, który następuje w efekcie działań Zespołu, a nie powiększenia się samego produktu. Jest przecież możliwe, że jego wartość wzrośnie dzięki usunięciu zbędnych funkcjonalności, czyli na skutek redukcji produktu.

Aby Zespół Scrum wiedział, czy powstał Przyrost, konieczne jest ustalenie kryteriów, jakie taki artefakt musi spełniać. W Scrumie kryteria te noszą nazwę zobowiązań (ang. commitments), przy czym nie chodzi tu jakiś kontrakt zawarty między Zespołem a interesariuszami lub choćby kierownictwem organizacji, która produkt wytwarza. Te kryteria definiuje Zespół, umawiając się sam ze sobą, co będzie traktował jako Przyrost (jakie ma mieć cechy, jak ma być wytwarzany). Jest to więc w istocie deklaracja intencji, jakimi kierować będą się Developerzy w swej pracy.

Definicja Ukończenia jest właśnie takim zobowiązaniem związanym z Przyrostem. Jej podstawową funkcją jest określenie, jaki musi być stan i jakość nowej wersji produktu, jaką wytworzył Zespół, by w ogóle można uznać ją za najnowszy Przyrost. W ten sposób staje się jasne (w Scrumie powiedzielibyśmy: przejrzyste), co trzeba zrobić, by Przyrost powstał. Albo, spoglądając na to z innej perspektywy, jest jasne (przejrzyste), co zostało rzeczywiście zrobione i jaka jest jakość nowego produktu w momencie, gdy Zespół mówi, że ukończył nad nim pracę.

Tym samym Definicja Ukończenia eliminuje konieczność zgadywania lub domyślania się, co zostało zrobione. Jeśli Zespół deklaruje, że ukończył pracę, to znaczy, że wszystko, czego wymaga Definicja Ukończenia, zostało wykonane (oczywiście przy założeniu, że celowo nie oszukuje swego otoczenia, ale pomińmy takie patologiczne scenariusze w rozważaniach i przyjmijmy, że skupiamy się na Zespołach grupujących profesjonalistów). Mogło być zrobione jeszcze coś dodatkowego, czego Definicja nie wymaga, ale na pewno nie zostało zrobione mniej.

Definicja ujawnia też, co tak Zespół realnie potrafi zrobić. Patrząc na jego Definicję Ukończenia, nie będziemy musieli się tego domyślać.

Przy czym Definicja nie jest tworzona na potrzeby otoczenia Zespołu, bo przede wszystkim on sam z niej korzysta. W jaki sposób? Skoro Definicja określa, co należy zrobić, aby wytworzyć działający produkt, stanowi doskonałą podpowiedź konkretnych działań, jakie trzeba będzie wykonać w ramach realizacji poszczególnych elementów Backlogu Produktu. Pozwala to na bardziej świadome szacowanie ilości pracy niezbędnej do zrealizowania poszczególnych zmian w produkcie i ułatwia Planowanie Sprintu, które w oczywisty sposób odbywa się w kontekście obowiązującej Definicji Ukończenia, której wymogi Developerzy będą musieli spełnić.

Dlaczego Definicja Ukończenia jest kluczowa w Scrumie?

Jest tak ze względu na wspomniany już wcześniej empiryzm. Ponieważ decyzje o tym, w jaki sposób dalej rozwijać produkt, zapadają na podstawie sprawdzenia najnowszej wersji produktu, jaki powstał (czyli Przyrostu), trzeba ustalić:

  • czy faktycznie jakiś Przyrost powstał,
  • co to właściwie znaczy, że powstał (co rzeczywiście zostało zrobione).

Po uzyskaniu odpowiedzi na te dwa pytania nie ma potrzeby spekulowania odnośnie do tego, co zostało zrobione, czy powstał produkt oczekiwanej jakości itd. Zamiast zmagać się z ustaleniem, czy w ogóle mamy działający produkt, możemy dyskutować nad tym, czy produkt ten jest właściwy.

Żeby jednak tak się stało, sama Definicja Ukończenia musi spełniać kluczowy warunek, jakim jest możliwość uzyskania jednoznacznej odpowiedzi na pytanie, czy zawarte w niej kryteria zostały zaspokojone. Inaczej mówiąc, zapisy Definicji muszą pozwalać na jednoznaczne potwierdzenie, że żaden nie został zignorowany. I musi to być możliwe do ustalenia bez szacowania, zgadywania, wyciągania średnich z różnych opinii członków Zespołu itd.

Celem jest osiągnięcie stanu, w którym Zespół używa bez wysiłku Definicji Ukończenia w ten sposób: jeśli nie wiadomo na pewno, że wymogi Definicji zostały spełnione, to znaczy, że spełnione nie zostały i nowa wersja produktu nie powstała. Żadnych niedopowiedzeń, żadnych „prawie ukończonych” zmian w produkcie, które deklarowane są jako ukończone.

Da się też wtedy bezspornie ustalić, jakie cechy i funkcjonalności posiada aktualnie istniejący produkt (co w nim zostało zrobione), a co wymaga developmentu (jego rozpoczęcia albo dokończenia, jeśli już trwa). Wszystkie potrzeby interesariuszy, jakie produkt ma zaspokoić i problemy, które dzięki produktowi mogą zostać rozwiązane, rozdzielone zostają na dwa nieprzecinające się zbiory rzeczy już ukończonych i tych, które wciąż pozostają do zrobienia.

Gdy brak Definicji Ukończenia…

Wyobraźmy sobie, że nie mamy ustalonej Definicji Ukończenia. Zespół ciężko pracuje, by zrealizować jakieś plany rozwoju produktu, a czekający na efekty tych prac interesariusze (np. klienci lub użytkownicy) monitorują postęp, starając się ograniczyć ryzyko inwestycyjne. Na co będą patrzyć? Zapewne na plany, z którymi zderzać będą przeróżne wskaźniki, które pozwolą ocenić, w jakim stopniu plany te udaje się realizować, ile procent zakresu prac już wykonano itd. Być może co jakiś czas odbędzie się demonstracja tego, co już jest gotowe, by uzyskać potwierdzenie, że rzeczywiście „dobrze idzie”.

Problem w tym, że w tym scenariuszu nie istnieją jasne kryteria tego, co to znaczy zrobione. Wiadomo tylko, że jakaś część planu została wykonana i coś udało się zademonstrować. Nie wiadomo natomiast, co tak naprawdę zrobił Zespół. Czy trzymał się obowiązujących standardów? Czy na pewno fakt, że Zespół postępuje wedle planów, oznacza, że powstaje produkt dobrej jakości? Czy uda się dokończyć pracę na czas bez cięcia jej zakresu? Czy nie ma ryzyka, że 99% prac zostanie zakończonych, a ostatni 1% przekroczy możliwości Zespołu lub wręcz okaże się obiektywnie niewykonalny?

Poza tym, co to właściwie znaczy, gdy Zespół nieposiadający Definicji Ukończenia mówi, że zakończył pracę? Każdy może wyciągnąć z tej informacji zupełnie inne wnioski. Niektórzy pomyślą, że zostało zrobione absolutne minimum prac; inni, że o wiele więcej. Ba, niewykluczone, że sam Zespół (Developerzy w nim) będą mieli rozbieżną opinię o tym, co zostało zrobione, a co zrobione być powinno. Szansa, że jakość produktu dostarczonego przez Zespół będzie wysoka i stabilnie będzie się utrzymywać przez długi czas, jest znikoma.

Dlaczego tak? Bo Mietek, jeden z Developerów, może uznać, że czegoś nie trzeba robić i tego nie zrobi. A Zenek, jego kolega, będzie przekonany, że coś powinno być zrobione i słysząc od Mietka, że ten skończył pracę, będzie przekonany, że Mietek zrobił również i to coś. W efekcie obaj pójdą do interesariuszy z przekazem „mamy ukończony produkt”, przy czym obaj będą mieć różną wiedzę na temat tego, co tak naprawdę zostało zrobione. Co więcej, żaden z nich nie będzie wiedział na pewno, w jakim stanie faktycznie jest produkt.

Efektem tego braku empirycznej wiedzy jest podejmowanie decyzji na podstawie założeń (w najlepszym razie) lub fałszywego obrazu stanu spraw. Skutki tego mogą być opłakane, bo ów faktyczny stan spraw w końcu się ujawni, zapewne w najmniej oczekiwanym momencie.

Kto powinien stworzyć Definicję Ukończenia?

Wydaje mi się, że odpowiedź na to pytanie jest oczywista: Zespół Scrum. Jest to jego zobowiązanie względem samego siebie i interesariuszy, że będzie dostarczał produkt określonej jakości, wyjaśniające przy okazji, w jaki sposób zamierza to robić.

Ktoś zakrzyknie zaraz, że przecież Definicja Ukończenia powstaje w organizacji developerskiej, a Zespół tworzy ją tylko wtedy, jeśli takowej organizacyjnej Definicji nie ma. Faktycznie, był taki zapis w starszych wersjach Scrum Guide, ale został usunięty, bo był zwyczajnie źle rozumiany. W szczególności przepychał zbyt mocno odpowiedzialność za powstanie Definicji z Zespołu na organizację, co często uniemożliwiałoby Zespołowi traktowanie jej jako własne zobowiązanie względem siebie (bo byłaby to Definicja narzucona z zewnątrz). A jest przecież zasadnicza różnica między efektywnością Definicji rozumianej jako deklaracja „tak będziemy budować produkt” i tej rozumianej jako przymus rodzaju „tak kazali nam pracować”.

Ciąg dalszy nastąpi

W drugim artykule z serii traktującej o Definicji Ukończenia piszę o tym, co właściwie składa się na Definicję, przy okazji wyjaśniając, skąd się wziął ów historyczny zapis o organizacji developerskiej. Odpowiadam też na pytanie, kto w Zespole Scrum ma ostateczną decyzyjność odnośnie do tego, co znajdzie się w Definicji.