Definition of Done (DoD) to formalna lista kryteriów jakościowych, które Inkrement musi spełnić, zanim uznasz pracę za ukończoną i potencjalnie gotową do wydania. To wspólna umowa całego Scrum Teamu, dzięki której każdy tak samo rozumie słowo “skończone”. Bez niej programista, tester i Product Owner mogą mieć trzy różne definicje ukończenia tego samego zadania.
Zgodnie z The 2020 Scrum Guide DoD to jedyny standard jakości formalnie wymagany przez Scrum. Definition of Ready, o której często mówi się w tym samym kontekście, nie jest artefaktem opisanym w przewodniku.
Definition of Done jako brama wyjściowa dla pracy
DoD działa jak brama wyjściowa (exit gate): element pracy przechodzi dalej dopiero wtedy, gdy spełni wszystkie kryteria z listy. Zakres tej listy zależy od produktu i dojrzałości zespołu, ale typowo znajdziesz na niej:
- przegląd kodu wykonany przez inną osobę;
- testy jednostkowe i integracyjne, które przechodzą;
- zaktualizowaną dokumentację techniczną i użytkową;
- zgodność ze standardami kodowania przyjętymi w zespole;
- weryfikację wymagań niefunkcjonalnych (wydajność, bezpieczeństwo, dostępność);
- gotowość do wdrożenia na środowisko produkcyjne.
Kryteria zapisz w sposób sprawdzalny. “Kod przetestowany” jest nieostre, natomiast “pokrycie testami minimum 80% dla nowych modułów” można jednoznacznie zweryfikować. Więcej praktycznych przykładów znajdziesz w opisach na Scrum.org oraz w glosariuszu Agile Alliance.
DoD a Definition of Ready – dwie różne bramy
Definition of Ready określa, kiedy element backlogu jest gotowy, by zespół rozpoczął nad nim pracę. To brama wejściowa. DoD dotyczy wyłącznie warunków zakończenia. Obie odpowiadają na inne pytanie: DoR pyta “czy możemy zacząć?”, DoD pyta “czy faktycznie skończyliśmy?”.
Rozróżnienie ma praktyczne znaczenie. Element może spełniać DoR, przejść przez sprint i mimo to nie spełnić DoD, bo brakuje testów albo dokumentacji. Wtedy nie trafia do Inkrementu. Opis obu pojęć z perspektywy narzędzi znajdziesz u Atlassian.
Jak DoD chroni przed długiem technicznym
Silna DoD to jeden z najtańszych mechanizmów prewencji długu technicznego. Kiedy automatyczne testy i przegląd kodu są warunkiem akceptacji pracy, zespół nie ma jak przemycić skrótów “na później”. Skróty, które nie przejdą przez bramę, po prostu nie zostaną uznane za ukończone.
Efekt widać w tempie pracy. Zespoły bez wymagającej DoD początkowo dostarczają szybciej, ale po kilku sprintach zwalniają, bo coraz więcej czasu pochłania naprawianie wcześniejszych niedoróbek. Kryteria jakości wpisane w DoD przesuwają ten koszt na moment, w którym poprawka jest najtańsza.
DoD jako artefakt żywy
Definition of Done nie jest dokumentem, który piszesz raz i zamykasz. Nowe zespoły startują od podstawowego zestawu kryteriów, a potem rozszerzają listę wraz ze wzrostem dojrzałości. Z czasem pojawiają się:
- szersze pokrycie testami automatycznymi;
- twardsze wymagania niefunkcjonalne;
- osobne poziomy DoD dla sprintu i dla wydania (multiple levels of done).
Miejscem przeglądu DoD jest Sprint Retrospective. To tam zespół ocenia, czy dotychczasowe kryteria wciąż odpowiadają jakości, jakiej oczekuje, i decyduje o zmianach. Dzięki temu DoD wpisuje się bezpośrednio w trzy filary Scruma: przezroczystość kryteriów jakości, inspekcję ich spełnienia i adaptację samej listy. Jeśli chcesz zrozumieć, jak te filary działają w praktyce, przeczytaj o trzech filarach Scruma, które zna każdy, a połowa zespołów ignoruje.
Najczęstsze pytania o Definition of Done
Kto tworzy Definition of Done?
DoD tworzy i utrzymuje cały Scrum Team. To umowa wspólna, a nie lista narzucona przez jedną osobę. Jeśli organizacja ma standardy nadrzędne, DoD zespołu musi je co najmniej spełniać, może natomiast być bardziej wymagająca.
Czym różni się DoD od kryteriów akceptacji?
Kryteria akceptacji dotyczą konkretnej historyjki użytkownika i opisują, co dana funkcja ma robić. DoD obowiązuje wszystkie elementy pracy i opisuje ogólny poziom jakości, który musi spełnić każdy z nich. Historyjka bywa zaakceptowana funkcjonalnie, ale wciąż nie spełnia DoD, jeśli brakuje na przykład testów.
Co się dzieje, gdy element nie spełnia DoD na koniec sprintu?
Taki element nie trafia do Inkrementu i nie jest prezentowany jako ukończony podczas Sprint Review. Wraca do Product Backlogu, a zespół decyduje o dalszym postępowaniu. Zgłaszanie niedokończonej pracy jako gotowej podważa transparentność, na której opiera się cały Scrum.
Jak często zmieniać Definition of Done?
Nie ma sztywnego harmonogramu. Naturalnym momentem przeglądu jest Retrospektywa, gdy zespół dostrzega powtarzające się problemy z jakością lub czuje, że dojrzał do wyższych standardów. Częste, drobne korekty są lepsze niż jedna wielka rewizja raz do roku.
