Definition of Done dla produktu czy wymagania? - Code Sprinters

Definition of Done dla produktu czy wymagania?

Definition of Done jest jednym z trudniejszych do zrozumienia konceptów 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 Definition of Done (dla uproszczenia DoD) jest.

Co to jest DoD?

DoD określa jaka praca powinna być wykonana, aby uznać, że wymaganie zostało zrealizowane. Odpowiada na postulat zapewnienia przejrzystości, która jest niezbędna, by móc działać empirycznie. Bez DoD każdy inaczej może rozumieć, że wymaganie jest zrealizowane („done”). Jedni uznają, że to oznacza, iż kod został napisany. Inni, że poza napisaniem kodu ktoś wykonał testy. Ktoś może być przekonany, że „done” implikuje, iż rozwiązanie jest dostępne do testów akceptacyjnych, a co poniektórzy będą twierdzić, że tylko wdrożenie produkcyjne (wydanie rozwiązania) można uznać za zakończenie prac.

Jasne określenie co to znaczy „done” ucina te dyskusje. Co więcej, dużo łatwiej dokonać oszacowań pracochłonności, bo dokładnie wiadomo, co trzeba będzie zrobić. To oznacza, że wszyscy dokonujący oszacowań developerzy, albowiem to oni w Scrum są za to odpowiedzialni, tak samo rozumieją zakres prac.

Co warto wiedzieć o DoD

Definition of Done określa jakie cechy musi spełnić produkt, aby był technicznie używalny, czyli aby dało się go wydać. To oznacza, że jeśli DoD jest spełnione i Product Owner zechce wydać produkt, zespół developerski nie może sobie „przypomnieć” nagle, że jeszcze coś zostało do zrobienia, i że produktu nie da się wydać. Skoro technicznie jest gotowy, to życzenie Product Ownera bez trudu można spełnić.

Druga istotna kwestia dotycząca DoD: ma ono gwarantować, że w produkcie nie pojawia się dług techniczny, czyli że nie podejmowane są decyzje, które w przyszłości spowodują konieczność dodatkowej pracy, a więc spłacenia tego długu. Oczywiście czasami świadomie ten dług jest zaciągany, im „lepsze” DoD mamy, tym większa jego siła w blokowaniu takich zapędów. A zatem w DoD zakodować powinniśmy reguły, które wymuszą taki sposób pracy, aby produkt zachował (lub poprawiał) swoją jakość strukturalną (technologiczną).

Trzecia istotna kwestia to fakt, że DoD tworzone 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. To zaś oznacza, że w DoD umieścić można tylko te rzeczy, które dla zespołu są realnie osiągalne w sposób powtarzalny. Jeśli umieszczone tam wpisy będą „na wyrost” i zespół nie będzie w stanie ich zaspokoić, wartość DoD będzie nikła, bo ignorując jeden element rychło przestaniemy zwracać uwagę na pozostałe.

Jeśli zdarzy się, że nie da się pogodzić tych trzech kwestii – a nie jest to rzadka sytuacja – czyli aby uzyskać produkt gotowy do wydania musielibyśmy stosować praktyki, jakich zespół użyć nie potrafi, wtedy DoD będzie niekompletne. Zespół musi wtedy dążyć do jak najszybszego wyeliminowania tej luki, ucząc się nowych praktyk, zmieniając proces jakim się posługuje, korzystając z nowych narzędzi.

Co umieszczamy w DoD?

Kryteria, które muszą być spełnione, aby produkt był technicznie gotowy do użycia. Najczęściej są ta zapisy o konieczności stosowania praktyk wspierających tworzenie dobrego oprogramowania, wymóg testowania na odpowiednim poziomie, przeprowadzania przeglądów (code review) i tak dalej.

Jeśli zespół jest częścią większej organizacji developerskiej, ta najczęściej ma jakieś standardy, które powinny być przestrzegane. Wtedy istnieje DoD tej organizacji, które nawiązuje do tych standardów, ale nic nie stoi na przeszkodzie, by niektóre zespoły dodały dla siebie więcej praktyk, jeśli potrafią ich użyć, i kryteriów, które potrafią spełnić. Natomiast usuwanie ze wspólnego DoD czegokolwiek oznaczałoby naruszenie standardów i próbę działania poniżej absolutnego minimum wymaganego przez organizację, a zatem jest to niedopuszczalne.

Jak DoD ma się do kryteriów akceptacyjnych wymagań?

Każde wymaganie opisujące problem lub potrzebę biznesową powinno 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 DoD musi być spełnione, by produkt technicznie nadawał się do użycia, tak kryteria akceptacyjne powinny być spełnione, by produkt robił to, czego od niego oczekujemy. Przy czym nie ma tu automatyzmu: z faktu spełnienia DoD nie wynika, że produkt działa poprawnie od strony funkcjonalniej; z faktu spełnienia wszystkich kryteriów akceptacyjnych nie wynika, że produkt nie został wytworzony w sposób wprowadzający do niego długu technicznego (czyli że nie kleiliśmy w nim niczego taśmą i nie wiązaliśmy tego sznurkiem).

DoD 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ć co znaczy „done” dla tego zespołu, i by pamiętać o trzymaniu się umieszczonych w DoD zapisach. Ale Scrum nie zalicza DoD do artefaktów, z dwóch względów.

Pierwszy jest oczywisty: DoD nie jest wytworem Scruma, ale czymś stałym, co pozwala Scrumowi działać. Oczywiście zmienia się, ale nie w sposób ciągły, a jedynie w momencie, gdy dokonujemy usprawnień i udaje nam się nauczyć nowych praktyk, dających lepszej jakości produkt.

Drugi powód jest mniej oczywisty, ale dużo ważniejszy: DoD opisuje co musi być zrobione, aby produkt był „wydawalny”. A więc można go traktować jako cechę produktu. Jeśli tak, to DoD nie jest artefaktem, ale zbiorem charakterystyk innego artefaktu – przyrostu produktu, czyli nowej wersji produktu wytworzonej w sprincie.

Czy DoD może być spełnione tylko dla jednego z kilku wymagań?

Produkt jest jeden, co oznacza, że mówienie, iż „DoD zostało spełnione dla wymagania X” nie jest trafne. Powinniśmy raczej mówić, że „DoD 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 DoD „per wymaganie”, możliwe się stanie obejście Definition of Done. Przykład: podjęliśmy się realizacji pięciu wymagań, tylko jedno zostało naprawdę skończone (DoD spełnione), a cztery są na różnych etapach realizacji, przy czym rozgrzebany kod jest w tym momencie częścią produktu i nie został z niego usunięty. Jeśliby DoD przyłożyć jedynie do kodu napisanego na potrzeby jednego wymagania, może się wydawać, że jest ono zrealizowane. Niestety, ponieważ produkt nie spełnia DoD jako zintegrowana całość, wszystko co się w nim znajduje, w tym i wymaganie uznawane za „skończone” jest niegotowy do wydania.

W sytuacji opisanej powyżej albo musimy „zaizolować” kod niedokończony tak, by nie był on używany po wydaniu (należy testami potwierdzić, że izolacja się udała), albo kod ten należy z produktu usunąć tak, by jedynie skończone wymagania, spełniające DoD się w produkcie znajdowały.

Dobrą praktyką jest realizowanie wymagań sekwencyjnie, dzięki czemu ryzyko i koszt „wycofania” lub „izolowania” niedokończonego kodu jest możliwie najmniejszy, bo czasu braknąć nam może w trakcie realizacji jednego wymagania. Jeśli idziemy 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 może być nierealne.


SZKOLENIA ZWIĄZANE Z TEMATYKĄ ARTYKUŁU


O autorze: Rafał Markowicz
Scrum Master z wieloletnim doświadczeniem, w branży IT od 2001. Praktyk Agile, ekspert w zakresie inżynierii testów i zapewnienia jakości. Pracował jako analityk systemowy i biznesowy, jest doświadczonym developerem, managerem i konsultantem.

Inne artykuły tego autora