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 przy tym jedynie moje podejrzenie, ale niepokojący wniosek, jaki wynika z 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 nie dość, że mają Definicję Ukończenia, to jeszcze stosują ją w praktyce. Nie posiadam oczywiście wiedzy na temat tego, jak ta praktyka wygląda, jest to subiektywna ocena wypełniających ankietę. Sądzę, że poziom faktycznego przestrzegania Definicji Ukończenia może być nieco niższy, niż deklarowany, za to 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, tak naprawdę takie działanie oznacza, że Zespoły nie mają 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 można przyjąć, że odpowiedź ostatniej grupy (11%) oznacza w praktyce, ż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 uważają, że posługują się Scrumem, a nie zadbały o kluczowy jego element, który umożliwia jakikolwiek empiryzm na poziomie produktu, jaki wytwarzają w tym rzekomym Scrumie.

Jak to w ogóle możliwe?

Przyczyn może być wiele, 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 tak naprawdę 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. 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ę i rozjeżdża z tą „organizacyjną”, skoro nie ma innego wyjścia, ale niechaj wciąż będzie stworzona i stosowana. Przynajmniej widoczny stanie się problem z rozbieżnością opinii o tym, co właściwie powinno być robione. Będzie też wiadomo, co Zespół realnie robi. 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 ze Scruma

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ć?
  • Czy to, co powstało, 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 dobre na początku, po prostu się zdezaktualizowały i trzeba je będzie zmienić, kiedy tylko odkryjemy taką potrzebę. Żeby to móc odkryć, nie możemy analizować wyłącznie informacji o tym, jak idzie nam realizacja planów, ale musimy przyjrzeć się efektom tych działań. I jeśli zaczną się one rozjeżdżać z potrzebami, będziemy wiedzieć, że zmiana jest niezbędna.

Na tym właśnie polega z grubsza empiryczna kontrola procesu (a krócej: empiryzm). Robimy coś, sprawdzamy, co udało się zrobić 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 „przyrośnięcia” samego produktu. Jest przecież możliwe, że wartość produktu wzrośnie dzięki usunięciu z niego zbędnych funkcjonalności – produkt więc zmniejszy się, ale ta jego nowa wersja będzie miała większą wartość, stanowić więc będzie Przyrost.

Aby Zespół Scrum wiedział, czy powstał artefakt niezbędny dla zadziałania empiryzmu (w przypadku Scruma: czy powstał Przyrost, który będzie można sprawdzić i na tej bazie podjąć decyzję co do dalszego rozwoju produktu), konieczne jest ustalenie kryteriów, jakie artefakt musi spełniać. W Scrumie kryteria te noszą nazwę zobowiązań (ang. commitments), a ta być może zaskakująca nazwa bierze się stąd, że kryteria te deklaruje sam Zespół, umawiając się „sam ze sobą”, jakie poszczególne artefakty mają być.

Zobowiązaniem związanym z Przyrostem jest, co zapewne nikogo nie zaskoczy, właśnie Definicja Ukończenia. 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 jakąkolwiek konieczność zgadywania, 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 coś jeszcze, czego Definicja nie wymaga, ale na pewno nie zostało zrobione mniej.

Definicja ujawnia też, co tak naprawdę Zespół realnie potrafi zrobić. Patrząc na jego Definicję Ukończenia, nie będziemy musieli się tego domyślać. W ten sposób ocena czy Przyrost faktycznie nadaje się do użycia staje się w ogóle możliwa.

Sam Zespół oczywiście również korzysta z Definicji, ona nie jest tylko na potrzeby otoczenia (interesariuszy, organizacji itd.). W jaki sposób z niej korzysta? Skoro Definicja określa, co należy zrobić, aby móc ogłosić, że Zespół ukończył pracę nad produktem, stanowi ona doskonałą podpowiedź konkretnych działań, jakie trzeba będzie wykonać w ramach realizacji poszczególnych elementów Backlogu Produktu. To ułatwia szacowanie również szacowanie tych elementów czy planowanie Sprintów, właśnie w kontekście Definicji Ukończenia, którą trzeba będzie 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 oceny (sprawdzenia, a w Scrumie powiedzielibyśmy: inspekcji) najnowszej wersji produktu, jaki powstał (czyli Przyrostu), musi być wiadomo, że:

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

W ten sposób nie ma żadnych domniemywań czy domysłów, co jeszcze trzeba zrobić, czy coś zostało zrobione, czy nie, czy powstał produkt oczekiwanej jakości, czy też niekoniecznie tak się stało. 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.

Z tego wynika jedna istotna cecha, jaką spełniać musi każda Definicja Ukończenia: musi umożliwiać uzyskanie binarnej odpowiedź na pytanie, czy została spełniona. Inaczej mówiąc, Zespół posługiwać się nią musi w następujący sposób: jeśli nie wiadomo na pewno, że Definicja Ukończenia jest spełniona, to nie jest spełniona, a fakt jej spełnienia jest bezdyskusyjny i nie wynika z domysłów czy oszacowań, tylko z faktów.

W ten sposób wiedza o produkcie dzieli się na dwa obszary: tego, co wiadomo, że jest w nim zrobione, i całą resztę, która być może i jest częściowo zrobiona, ale na pewno nie została ukończona (więc w praktyce jej nie ma).

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, jakie zostały poczynione i przeróżne wskaźniki, które pozwolą ocenić, w jakim stopniu ten plan udaje się realizować, ile procent planu 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ę? 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 i 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, że „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ć. Inaczej mówiąc, to zespołowa deklaracja, co to znaczy, gdy Zespół mówi, że ukończył pracę nad produktem.

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 „tak kazali nam pracować”.

Ciąg dalszy nastąpi

W drugiej części artykułu piszę o tym, co właściwie składa się na Definicję Ukończenia, 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.