Blog

Definicja Ukończenia (ang. Definition of Done) jest jednym z trudniejszych do zrozumienia pojęć związanych ze Scrumem, a jednocześnie jednym z najistotniejszych. Gdyby redukować reguły i elementy tej metody do absolutnego minimum, empiryzm i Definition of Done właśnie musiałby pozostać do samego końca. Na szczęście nie musimy takiej redukcji robić, co nie oznacza, że możemy nie rozumieć, czym Definicja Ukończenia jest.

Czym jest Definicja Ukończenia?

Definicja określa, w jaki sposób praca powinna być wykonana, aby powstał produkt nadający się do użytkowania. Odpowiada na postulat zapewnienia nie tylko jakości strukturalnej produktu (czyli tego, jak on jest zrobiony), ale również przejrzystości jego stanu (co faktycznie zostało zrobione). To ostatnie jest niezbędne, by móc działać empirycznie. Inaczej mówiąc, Definicja ma pozwolić na ustalenie, jaki produkt aktualnie istnieje i czy w ogóle powstał.

Bez Definicji Ukończenia każdy inaczej może rozumieć, co mają na myśli Developerzy, gdy mówią, że zakończyli pracę nad jakimś wymaganiem. Przykładowo, jeśli produktem jest oprogramowanie, do którego dodawana jest nowa funkcjonalność, ktoś uzna, że done obejmuje wyłącznie napisanie kodu. Ktoś inny będzie przekonany, że kod został ponadto przetestowany przez Developerów. Kolejna osoba uzna, że rozwiązanie zostało przekazane do testów akceptacyjnych, które wykonać mają wybrani użytkownicy. A co poniektórzy będą spodziewać się, że nowa funkcja jest już dostępna w produkcie dla każdego, kto z niego korzysta.

W praktyce każdy z tych domysłów może być słuszny, ale równie dobrze może być błędny. Dlatego należy uciąć konieczność snucia domysłów i jasno określić, co znaczy done w tym konkretnym Zespole Scrum.

Co więcej, dzięki Definicji Ukończenia możliwe staje oszacowanie pracochłonności planowanych zmian w produkcie, bo wszyscy dokonujący oszacowań Developerzy tak samo rozumieją, jaki poziom jakości rozwiązań trzeba uzyskać i jakie działania będą do tego niezbędne. Bez Definicji każdy mógłby mieć zupełnie inną wizję tego, w jaki sposób zmiany w produkcie mogą być wprowadzane, przez co de facto każdy szacowałby co innego.

Co warto wiedzieć o Definicji Ukończenia

Definition of Done określa, jakie cechy musi mieć produkt i jak ma być budowany, aby dało się go przekazać użytkownikom (niektórzy powiedzą: aby go wydać). Jeśli wymogi takiej Definicji są spełnione, jedynym co pozostało do zrobienia to sam proces udostępnienia produktu osobom, które z niego będą korzystać. Co więcej, decyzja o użyciu produktu nie spowoduje, że Developerzy nagle „przypomną sobie” o szeregu rzeczy, które pozostały do zrobienia, a bez których produkt działał nie będzie.

Oczywiście jest możliwa sytuacja, że Definition of Done nie będzie opisywało produktu, który faktycznie nadaje się do natychmiastowego użycia, tylko rozwiązanie gotowe do złożenia w całość z innymi produktami, z którymi stanowi razem jedną całość. W takim przypadku użycie produktu musi być poprzedzone wykonaniem niezbędnych działań integracyjnych, ale też tylko tę integrację trzeba zrobić, aby użytkownicy z produktu mogli zacząć korzystać.

Czy w Scrumie dopuszczalne jest stosowanie Definicji Ukończenia, która nie wymaga zbudowania produktu gotowego do natychmiastowego użycia? Tak, choć oczywiście nie jest to sytuacja pożądana. Pamiętać należy, że Definicja jest przede wszystkim narzędziem zapewnienia przejrzystości stanu produktu i tego, co znaczy done w konkretnym Zespole.

Jeśli Developerzy z jakiegoś powodu nie potrafią wytworzyć produktu gotowego do użycia, Definicja ma ujawniać ten fakt, żeby było wiadomo, co pozostało do zrobienia. Wiadomo też dzięki temu, czego pilnie muszą nauczyć się Developerzy, aby można było Definicję Ukończenia rozszerzyć i zacząć budować produkt faktycznie gotowy do przekazania użytkownikom.

Druga istotna kwestia dotycząca Definicji: ma ona minimalizować ryzyko pojawienia się w produkcie długu technicznego (niedoróbek, rzeczy zrobionych marnie, trudnych do dalszego rozwoju itd.). Powinna zatem uniemożliwić albo przynajmniej utrudnić działania, które w przyszłości spowodują konieczność wykonywania dodatkowej pracy (spłacenia zaciągniętego długu).

Oczywiście czasami Zespół świadomie zaciąg dług techniczny, ale im lepsze jest jego Definition of Done, tym większa jego siła w blokowaniu takich zapędów. Developerzy powinni zawrzeć w nim reguły, które wymuszą taki sposób pracy, aby produkt zachował (lub poprawiał) swoją jakość strukturalną (technologiczną), zamiast tracić ją ze Sprintu na Sprint.

Trzecia istotna kwestia to fakt, że Definicja Ukończenia tworzona jest przez Developerów. Product Owner uczestniczy w tym procesie jedynie jako doradca i dąży do zapewnienia, że Definition of Done rzeczywiście obejmuje listę czynności, jakie trzeba wykonać, by produkt był zdatny do użycia. Nie może jednak niczego narzucić Developerom. To zaś oznacza, że w Definicji umieścić można tylko te rzeczy, które dla Developerów (a ogólniej rzecz mówiąc całego Zespołu) są realnie osiągalne w sposób powtarzalny. Nic przecież nie da wpisywanie do Definicji wymogów, których nie da się spełnić. Co gorsza, taka „Definicja na wyrost” przestałaby skutecznie informować, co tak naprawdę oznacza done w tym Zespole – bo faktycznie stosowane byłyby tylko niektóre jej zapisy.

Z czego składa się Definicja Ukończenia?

Znajdują się w niej kryteria, które muszą być spełnione, aby produkt był technicznie gotowy do użycia. Najczęściej są ta zapisy o konieczności stosowania konkretnych praktyk, użycia określonych narzędzi, wykonania zdefiniowanej listy czynności itd. Mogą tam też się znaleźć wymogi nadania produktowi określonych cech (wydajności, bezpieczeństwa itd.) wraz z określeniem, jak ma być dokonane sprawdzenie, że faktycznie je posiada.

Jeśli Zespół jest częścią większej organizacji developerskiej, ta najczęściej ma ona jakieś standardy, które powinny być przestrzegane. Możliwe nawet, że istnieje jakieś domyśle Definition of Done dla wszystkich produktów, które powstają w tej organizacji. Taka Definicja powinna stać się podstawą do sporządzenia Definition of Done w poszczególnych Zespołach, ale nic nie stoi na przeszkodzie, by niektóre z nich rozszerzyły tę bazę o dodatkowe praktyki i kryteria, o ile potrafią je spełnić. Natomiast usuwanie ze wspólnego Definition of Done czegokolwiek oznaczałoby naruszenie standardów organizacji i próbę działania poniżej absolutnego minimum wymaganego przez nią, a zatem jest to mało rozsądne (choć niewykluczone, że w specyficznych sytuacjach byłoby uzasadnione).

Jak Definicja Ukończenia ma się do kryteriów akceptacyjnych wymagań?

Każde wymaganie opisujące problem lub potrzebę biznesową może zostać uzupełnione o kryteria akceptacyjne (choć nie jest to praktyka wymagana, warto z niej korzystać). Te kryteria dla każdego wymagania są różne, tak jak potrzeby opisane wymaganiami są różne. Kryteria akceptacji mówią jakie działanie produktu lub jakie jego cechy są pożądane, a często wręcz określają, jak należy sprawdzić (udowodnić), że ta funkcjonalność lub cecha jest w produkcie obecna.

A zatem tak, jak wymogi Definicji Ukończenia muszą być spełnione, by produkt technicznie nadawał się do użycia, tak kryteria akceptacyjne powinny być spełnione, by móc twierdzić, że produkt działa zgodnie z oczekiwaniami.

Przy czym nie ma tu automatyzmu: z faktu spełnienia Definicji nie wynika, że produkt działa poprawnie od strony funkcjonalniej. A z faktu spełnienia wszystkich kryteriów akceptacyjnych nie wynika, że produkt nie został zbudowany w sposób urągający standardom (czyli że nie kleiliśmy w nim niczego taśmą i nie wiązaliśmy tego sznurkiem).

Dlatego traktować należy Definicję Ukończenia i kryteria akceptacyjne jako dwa zestawy warunków, które jednocześnie muszą być spełnione. Definicja steruje tym, jak budować produkt, a kryteria akceptacji wskazują, jaki produkt ma być zbudowany.

Jest jeszcze jedna różnica między kryteriami akceptacji a Definition of Done. Kryteria dotyczą zawsze jednego wymagania, jednej funkcjonalności, jednej zmiany w produkcie itd. Natomiast Definicja jednocześnie dotyczy każdej takiej zmiany, jak i produktu jako całości. To oznacza, że realizując wymaganie, trzeba zrobić to w sposób zgodny z Definicją Ukończenia, ale też w taki sposób, by pozostała (niezmieniona) część produktu też nadal wymogi tej definicji spełniała.

Definicja Ukończenia to nie artefakt w Scrumie

Wiele Zespołów zapisuje Definition of Done jako listę na dużym kawałku papieru i wiesza go na ścianie, by każdy mógł zobaczyć, czym dla nich jest done, i by pamiętać o trzymaniu się umieszczonych Definicji zapisach. Scrum nie traktuje jednakże tej Definicji jako artefaktu z kilku powodów.

Pierwszy jest dość oczywisty: Definicja nie jest wytworem działania procesu w Scrumie, ale zbiorem wskazówek, jak proces ten powinien przebiegać. Inaczej mówiąc, Zespół Scrum nie wytwarza Definicji, tylko używa jej, by wytworzyć produkt (a dokładniej kolejne Przyrosty).

Drugi powód jest mniej oczywisty, bo wiąże się z tym, dlaczego w ogóle w Scrumie potrzebne są jakiekolwiek artefakty. Mają one zapewnić w procesie empirycznym podmiot inspekcji, dzięki czemu możliwe staje się ustalenie bieżącego stanu spraw:

• Backlog Produktu pozwala sprawdzić, jakie są plany dalszego rozwoju produktu, czy następuje postęp w osiąganiu Celu Produktu (co zostało jeszcze do zrobienia) i czy zawartość Backlogu ma w ogóle szansę umożliwić osiągnięcie tego Celu.
• Backlog Sprintu pozwala sprawdzić postęp prac w Sprincie i adekwatność planu osiągnięcia Celu Sprintu.
• Przyrost pozwala sprawdzić, jaki produkt istnieje w tym momencie i w jakim stopniu jest on adekwatną odpowiedzią na bieżące potrzeby interesariuszy.

Definicja Ukończenia nijak nie pasuje do tej listy artefaktów, bo sama z siebie jest jedynie zbiorem warunków. Ujawnia możliwości Zespołu Scrum, ale nic nie mówi o bieżącej kondycji produktu i sposobie jego postępowania. Dopiero sprawdzenie, czy warunki zawarte w Definicji są spełnione przez produkt, daje informację niezbędną do empirycznego działania.

I tak dochodzimy do trzeciego powodu, dla którego Definicja Ukończenia nie jest osobnym artefaktem. Jest ona opisem tego, w jaki sposób powinien powstawać Przyrost i jakie cechy powinien posiadać. Nie jest zatem samodzielnym artefaktem, ale stanowi narzędzie zapewnienia przejrzystości artefaktu, jakim jest wspomniany Przyrost.

Czy Definicja Ukończenia może być spełniona tylko dla jednego z kilku wymagań?

Produkt jest jeden, co oznacza, że mówienie, iż „Definition of Done zostało spełnione dla wymagania X” nie jest trafne. Powinniśmy raczej mówić, że „Definition of Done zostało spełnione przez produkt, który zawiera funkcjonalność lub cechy opisane wymaganiem X”.

Dlaczego ma to znaczenie? Bo jeśli oceniamy spełnienie Definicji Ukończenia per wymaganie, możliwe się stanie jej obejście, czyli formalne spełnienie wymogów jakościowych przy jednoczesnym faktycznym braku ich zaspokojenia. Jakim cudem?

Weźmy przykład: podjęliśmy się realizacji pięciu wymagań, ale na koniec Sprintu tylko jedno zostało naprawdę skończone (zgodnie z zapisami w Definicji). Cztery pozostałe są na różnych etapach realizacji, przy czym ich niekompletne rozwiązania są w tym momencie nadal częścią produktu, bo nie zostały z niego usunięte. Patrząc z punktu widzenia tego pierwszego wymagania, Definicja Ukończenia jest spełniona i produktu można użyć. Gdy zaś spojrzymy na produkt całościowo, to widać, że jest on w tym momencie rozgrzebany i Definicji nie spełnia – tylko szaleniec zdecydowałby się na przekazanie go użytkownikom.

Konieczne jest w tej sytuacji wycofanie z produktu nieukończonych zmian – co spowoduje, że jako całość będzie spełniał on warunki zawarte w Definition of Done. Można też ukryć w jakiś sposób niedokończone funkcjonalności i przetestować, że faktycznie tak zmodyfikowany produkt jest done w myśl obowiązującej Definicji. Wtedy faktycznie będzie możliwe udostępnienie produktu użytkownikom, by mogli korzystać z jedynej ukończonej w tym Sprincie funkcjonalności.

Dobrą praktyką jest realizowanie wymagań sekwencyjnie, po jednym na raz. Dzięki temu ryzyko wystąpienia opisanej sytuacji będzie minimalne, a koszt wycofywania lub izolowania niedokończonych rozwiązań możliwie najmniejszy. W najgorszym razie w Sprincie pojawi się jedna rzecz, na której dokończenie braknie czasu – pozostałe będą albo w pełni ukończone i gotowe do użycia, albo nawet nie zostaną rozpoczęte.

Jeśli idziemy przez Sprint szeroką ławą, robiąc wszystko na raz, może się okazać, że prawie wszystko jest zaczęte, a niewiele udało się skończyć… Wtedy doprowadzenie do tego, by produkt był rzeczywiście zdatny do wydania na koniec iteracji, może być nierealne.