Co to jest DoD?

Umowa ma dwie strony – tych, którzy mówią co, i tych którzy mówią jak.

Pewnie słyszeliście już nie raz o  Definition of Done. DoD jest ważne i potrzebne. Tylko  do czego służy Product Ownerowi?

Konia z rzędem pierwszemu Product Ownerowi, który nie zdębiał na dźwięk jakichś „Continuous Integration”, „TDD”, „BDD”, „feature toggle” i innych magicznych haseł, rzucanych przez zespół. Nie widać tego, pomacać się nie da, a żeby zrozumieć trzeba się wczytać w jakieś podejrzane szlaczki.

Zacznijmy od tego, co to jest za wynalazek, to całe Definition of Done.

DoD to umowa – umowa o poziom jakości. Odpowiada na pytanie:  jak bardzo bezawaryjny i przemyślany ma być nasz system? Ile pieniędzy chcemy poświęcić na zachowanie jakości?

W przypadku produkcji butów jest to dość proste – ustawiamy maszyny testujące na wybrane egzemplarze z partii i je rozciągamy, naciskamy, imitujemy zużycie. Wszystko widać. Koszty jakości i ryzyka jej niezachowania bardzo łatwo policzyć. Bułka z masłem.

Tu są smoki

W przypadku softu sprawa jest nieco bardziej interesująca.

DoD to jedno miejsce, w którym znajdziemy warunki określające, co to znaczy, że coś jest zrobione, czyli wykonane i gotowe do wydania (w niektórych przypadkach już wydane) oraz jakich praktyk jakościowych dotrzymaliśmy, żeby do tego dotrzeć. Brzmi bardzo prosto. DoD przykładane jest do każdego elementu Product Backlogu (PBI), jaki bierzemy do pracy, czyli musi być jakościową częścią wspólną.

DoD jest też często mylone z kryteriami akceptacji – czyli specyficznymi warunkami, które dotyczą konkretnego zadania.

Budujemy nowy dom…

Definition of Done w działaniu

Budujemy sobie dom. W domu ma być piwnica, parter i poddasze. Na parterze ma być kuchnia, salon, łazienka, gabinet i wiatrołap. Mamy z tego backlog wyglądający tak:

– Kuchnia (Parter)

– Łazienka (Parter)

– Salon (Parter)

– Wiatrołap (Parter)

– Gabinet (Parter)

– Piwnica

– Poddasze

Jakie może być tu DoD? Na przykład:

– Podłogi panele Krono Sound

– Ściany farba bezlateksowa (Dzieci mają uczulenie)

– Ściany z porothermu

– Okna drewniane, trzyszybowe

– Osprzęt elektryczny biały, Simon54

Zauważcie, że powyższe warunki dotyczą wszystkich pomieszczeń. W kryteriach akceptacji znajdziemy wytyczne dla danego pomieszczenia– na przykład wanna w łazience, albo biurko w gabinecie.

Mogą też być wyjątki – w łazience nie będzie podłogi z panelami, tylko kafle. Ale to już trzeba dokładnie zaznaczyć w opisie.

W przypadku softu DoD pełni taką samą funkcję.

Przykład:

Kod w repozytorium, opisany i zgodny z ustaleniami czytelności

Algorytmy stworzone w Pair Programmingu i TDD

Metody nie dłuższe niż 40 linii

Regresja przechodzi

Pokrycie min. 78%

Kto to ma rozumieć?

Warto rozmawiać.

Zespoły są zobowiązane wytłumaczyć PO, na czym polegają różne elementy DoD. Chociaż PO także musi mieć elementarną wiedzę z tego zakresu. Tak jak budując dom, jego właściciel uczy się o aspektach budownictwa.

A co się stanie jeśli DoD nie zostanie zachowane? Właśnie w taki sposób tworzy się dług technologiczny. Jak z bajki o Wielkim-Złym-Project-Managerze.

Format

Najlepiej na początku spisać sobie DoD w formie umowy. Z podpisami. Dlaczego tak? Bo umów z własnym podpisem raczej się pilnuje i przestrzega, a każde od nich odstępstwo musi być zgłaszane. Pamiętajcie tylko, że co prawda ciężar DoD spoczywa na zespole, jednak jest to umowa, a umowa ma dwie strony. Może się zdarzyć że PO jakaś praktyka wydaje się niepotrzebna. Wtedy trzeba to przedyskutować na retro. Podobnie jeśli jakieś nieścisłości widzi Zespół.

Niektóre zespoły wbudowują DoD w swoje Sprint Backlogi tak, żeby przy dodawaniu elementu ten automatycznie rozwijał się we wszystkie elementy DoD.

A inne używają do tego po prostu kartki na ścianie.

Zgodność

A co w takim razie ze sprawdzaniem zgodności DoD? Skąd mamy wiedzieć, że oddany element ją spełnia?

Po pierwsze trzeba sobie uświadomić, że PO nie ma zwykle wystarczającej wiedzy, żeby taką zgodność sprawdzać. Kto zatem pilnuje żeby wszystko się z DoD zgadzało? Pewnie już się domyślasz – Scrum Master, DoD to w końcu część procesu. W tym akurat przypadku bardzo rzadko SM osobiście  sprawdza, czy wszystko jest zgodne. DoD jest weryfikowana podczas sprintu, na bieżąco. Kiedy tylko PBI  jest ukończone. DoD jest zwykle używana przy planowaniu sprintu, więc nic nie umyka. Zdarza się, że kiedy zespół jeszcze się uczy pracy w Scrumie, SM sprawdza od czasu do czasu, czy coś nie umknęło, ale na pewno nie kontroluje zgodności dla każdego PBI.

Idealna DoD

Byle z umiarem

Warto też nadmienić, że problemy z DoD często są powodowane tym, że jest ona albo za prosta albo zbyt skomplikowana. W pierwszym przypadku wszystko ją spełnia, więc nie ma sensu się wysilać, a w drugim zespół po prostu nie pamięta wszystkich jej ustaleń. Warto więc trzymać DoD w sensownej wielkości.

Mentorka o niezwykłej charyzmie. Jeden z najbardziej doświadczonych ekspertów Scruma i pierwszy trener Scaled Professional Scrum w Polsce.