Definition of Done czyli DoDa

Kontynuujemy naszą drogę po zawiłościach metodyk zwinnych. Mogłoby się wydawać, że wyczerpaliśmy już ten temat do cna, ale wciąż jest o czym pisać. Dziś zmierzymy się  z DoD, czyli Definition of Done, czasem pieszczotliwie zwanej DoDą. I nie, nie chodzi tu o polską “królową pop-u”.

 

Definicja Definition of Done

Definition of Done to zestaw kryteriów, które spełnić musi wymaganie, aby można było je uznać za skończone. To kolejna checklista, obok HLAC-ów znanych User Stories, którą sprawdzamy przed otworzeniem butelki szampana. Przed uznaniem wymagania za skończone łączymy obie te listy i skrupulatnie weryfikujemy. Tu trzeba zaznaczyć, że HLAC-i dotyczą jednego wymagania, ale DoD to zestaw uniwersalny na przestrzeni całego projektu.

Często pada w tym miejscu pytanie: czy każde wymaganie powinno być zgodne z Definition of Done? Nie może być innej odpowiedzi niż gromkie, chóralne “tak”.

Nie ma tutaj znaczenia, w jakim projekcie pracujemy, ani czy realizujemy wymagania funkcjonalne czy niefunkcjonalne. Do każdego z nich powinniśmy przyłożyć kryteria odbioru i sprawdzić, czy efekt pracy w bieżącym sprincie, czyli inkrement spełnia wymagania, które sami zdefiniowaliśmy. Sami, ponieważ to zespoły ustalają kryteria odbioru na podstawie swoich wniosków po spotkaniu Sprint Retrospective.

Oczywiście, powinniśmy rozróżnić w tym miejscu kwestię wielkości projektu (ilość zespołów) czy złożoność tworzonego oprogramowania (np. back-end, font-end), ale co do zasady kryteria te powinny zostać ustalone przez zespoły.

Co ważne, muszą być one wspólne dla całego projektu, a więc dla wszystkich zespołów. Jest to istotne z punktu widzenia poprawności i jakości przyrostu oprogramowania. Nie możemy dopuścić do sytuacji, w której poszczególne części przyrostu odpowiadać będą różnym kryteriom akceptacji. Chociaż oczywiście poszczególne zespoły jak najbardziej mogą je rozszerzać o kolejne punktu, to istnieje część wspólna na którą zgodzili się wszyscy.

 

Co powinno znajdować się w DoD?

Twórcą kryteriów jest zespół. Jeśli na naszym projekcie mamy do czynienia z większą ich liczbą, są one ustalane na zasadzie wspólnego kompromisu. I tak naprawdę od tego kompromisu zależy, co znajdzie się w Definition of Done.

Na pewno powinny się na niej znaleźć elementy pozwalające nam uzyskać wewnętrzne przekonanie, że ukończony kawałek przyrostu spełnia wymagania pozwalające nam z czystym sumieniem wdrożyć go na środowisko produkcyjne.

Najczęstszymi elementami Definition of Done są konieczność wykonania testów manualnych i napisania testów automatycznych. Równie często w zestawie kryteriów znajduje się wymóg napisania testów jednostkowych. Czasami pojawiają się też wymagania dotyczące zaktualizowanej dokumentacji i przygotowania instrukcji wdrożeniowej bądź skryptów używanych przy aktualizacjach.

Dość ciekawie wygląda możliwość odbioru historyjki z błędami o określonym priorytecie. Mam tutaj na myśli przyzwolenie na zaakceptowanie rozwiązania zawierającego błąd, który jednak pozwala na bezproblemowe używanie aplikacji. Będą to więc proste błędy, dotyczące np. koloru czcionki, wielkości przycisku na GUI czy długiego czasu oczekiwania na wykonanie akcji. Powyższe defekty powiększą nam jednak dług technologiczny konieczny do zniwelowania w kolejnych iteracjach.

Najważniejsze jest, żeby na liście kryteriów nie znalazły się te, których nikt nie będzie chciał przestrzegać albo których przestrzeganie zajmie nam dużo czasu. Nie oszukujmy się, jeśli zdefiniowane przez nas kryteria będą trudne bądź niemożliwe do przestrzegania to nikt nie będzie chciał tego robić.

Spotkamy się wówczas z sytuacją, w której będziemy oszukiwani nie tylko siebie, ale również innych. Kłóci się to ze wspomnianą przez nas już wielokrotnie transparentnością.

 

Po co nam Definition of Done?

Definition of Done daje nam poczucie, że potencjalnie wdrażalny przyrost oprogramowania spełnia standardy w kontekście jakości i użyteczności. Upewniamy się więc w przekonaniu, że po jego wdrożeniu (ang. deploy) wszystko nadal będzie funkcjonowało zgodnie z przewidywaniami. Spełniając DoDę powinniśmy zapewnić sobie spokojny sen w trakcie weekendowego wdrożenia.

Po drugie, DoDa pozwala nam na zachowanie transparentności w środowisku, w którym istnieje więcej niż jeden zespół deweloperski. Szczególnie, jeśli wzajemnie od siebie zależymy. Jasne i transparentne ustalenie co to znaczy “zrealizowanie” wymagania poprzez wspólne stosowanie jednolitego Definition of Done pozwala nam na zaoszczędzenie czasu w przyszłości.

Po trzecie, przestrzegana DoDa spowoduje wzrost jakości wytwarzanego przyrostu i to pomimo potencjalnego powstawania długu technologicznego, o którym pisałem powyżej. Wypracowanie kryteriów na właściwym poziomie konserwatywności umożliwi znaczący wzrost zadowolenia z tworzonego inkrementu u jego odbiorców – u interesariuszy

 

Życie bez DoDy

Czy bez DoDy da się żyć? Pewnie, że się da, ale co to za życie. Definicja ukończenia znajduje się w Scrum Guide, jest więc istotną i niezbędną częścią tego frameworku. Nie należy więc jej pomijać, tym bardziej, że jest ona nie tylko praktyczna, ale i pragmatyczna.

Definiując kryteria ukończenia zadbajmy o to, aby były one jasne i “ostre” dla wszystkich uczestników procesu. Nie ma nic gorszego niż “Wymaganie będzie zakończone po ukończeniu wszystkich tasków w Jira” czy “Testy jednostkowe powinny pokryć wystarczającą ilość klas”.

Unikajmy zapisów, które nic nie wnoszą do naszego życia. Zapomnijmy o takich, o których z góry wiemy, że nie będziemy się ich trzymać. Wyłom w postaci jednego kryterium, na które przymykamy oko, z czasem spowoduje zupełne zignorowanie całego Definition of Done. Mówiliśmy już o tym przy okazji Broken Window Theory.

Będąc częścią dużego projektu, w którym pracujemy nad różnymi warstwami aplikacji miejmy na uwadze, że wypracowanie jednej DoDy dla wszystkich zespołów może być trudne, a czasem nawet niemożliwe. W takiej sytuacji pozostaje nam, jak zwykle, podejść zdroworozsądkowo.

Tam gdzie się da, możemy wprowadzić wspólną listę kryteriów ukończenia. Pozostawmy ją na tyle liberalną, aby mogły się w nią wpasować wszystkie warstwy i zespoły. Natomiast w pozostałych obszarach musimy jasno i wyraźnie powiedzieć sobie, że każdy z zespół posiada swoje dodatkowe kryteria akceptacji, rozszerzające oficjalną Definition of Done.

 

Istnieją również inne formy “Definition of…”, jak chociażby Definition of Ready. Ale o tym wspominaliśmy już przy okazji omawiania Product Backlog Refinement.

Łukasz Bręk

14 lat doświadczenia w IT, 7 lat doświadczenia w Scrum, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy, trener Scrum

Click Here to Leave a Comment Below

Kamil - 29 lipca 2020

Czy DoD powinien weryfikować wymagania, czy jednak Przyrost? “Definition of Done to zestaw kryteriów, które spełnić musi wymaganie, aby można było je uznać za skończone” vs. “efekt pracy w bieżącym sprincie, czyli inkrement spełnia wymagania, które sami zdefiniowaliśmy”. W końcu na Przyrost składają się zaimplementowane wymagania, ale wymaganiem może też być stworzenie dokumentacji czy technical task.

Reply
    Tomasz Dzierżek - 29 lipca 2020

    Stworzenie dokumentacji czy technical task to zdecydowanie elementy składowe służące do realizacji wymagania. To “Story”, rozumiane jako wymaganie, ma spełniać Definition of Done. Niektóre zespoły dodają osobną bramkę/Definition of Done w kontekście przyrostu, ale opisane w artykule DoD zdecydowanie dotyczy poszczególnych wymagań.

    Reply
Leave a Reply: