Definition of Done (DoD) to uzgodniony przez zespół opis stanu Przyrostu (Incrementu), w którym spełnione są wszystkie wymagania jakościowe potrzebne do uznania pracy za ukończoną. Nie jest tylko listą zadań. To zobowiązanie wobec jakości produktu i wspólny standard, który eliminuje „prawie gotowe” oraz „u mnie działa”.
Czym jest Definition of Done?
W Scrumie Definition of Done określa, kiedy element Backlogu Produktu przyczynia się do powstania wartościowego Przyrostu. Zgodnie ze Scrum Guide 2020 DoD jest zobowiązaniem powiązanym z Incrementem. Oznacza to, że zespół nie uznaje pracy za ukończoną tylko dlatego, że kod został napisany albo funkcja działa na komputerze jednej osoby.
„Done” oznacza stan, w którym nie pozostała już praca wymagana do spełnienia przyjętego standardu. Przyrost jest przetestowany, zgodny z wymaganiami jakościowymi, odpowiednio udokumentowany i gotowy do użycia lub wdrożenia zgodnie z zasadami produktu.
Można powiedzieć, że DoD jest sercem Sprintu. Sprinty są pulsem Scruma, ale bez regularnie dostarczanych Przyrostów spełniających Definition of Done sam rytm spotkań i planowania nie tworzy działającego procesu.
Dlaczego Definition of Done ma znaczenie?
Wspólny standard sprawia, że każda osoba w zespole oraz interesariusze tak samo rozumieją słowo „ukończone”. Dzięki temu praca nie znika w ukrytych zadaniach, które ktoś musi dopisać po zakończeniu Sprintu. DoD wpływa przede wszystkim na następujące obszary:
- Przejrzystość – status Przyrostu wynika z obiektywnych kryteriów, a nie z deklaracji autora.
- Jakość – testy, przegląd kodu, dokumentacja i wymagania pozafunkcjonalne nie są odkładane „na później”.
- Przewidywalność – zespół może planować na podstawie faktycznie ukończonych elementów, a nie liczby zadań rozpoczętych.
- Szybsza inspekcja i adaptacja – niespełnione kryterium pokazuje, gdzie brakuje kompetencji, narzędzi, czasu albo lepszego planowania.
- Mniej ukrytej pracy – zespół nie przenosi nieprzetestowanych funkcji, brakującej dokumentacji czy poprawek do kolejnych Sprintów.
DoD wspiera częste dostarczanie działającego oprogramowania, co pozwala wcześniej sprawdzać założenia biznesowe i reagować na zmianę. Jedno rzeczywiście ukończone zadanie daje więcej informacji niż wiele elementów oznaczonych jako „w trakcie” lub „prawie gotowe”.
Definition of Done a Kryteria Akceptacji – czym się różnią?
Definition of Done i Kryteria Akceptacji uzupełniają się, ale nie oznaczają tego samego. DoD jest wspólnym standardem jakości stosowanym do wszystkich elementów Backlogu Produktu. Kryteria Akceptacji opisują natomiast konkretną funkcję lub rezultat pojedynczego elementu, na przykład historyjki użytkownika.
| Cecha | Definition of Done | Kryteria Akceptacji |
|---|---|---|
| Zakres | Obowiązuje dla każdego elementu objętego wspólnym standardem zespołu. | Dotyczą konkretnej historyjki użytkownika lub innego elementu Backlogu. |
| Poziom | Globalny, procesowy i jakościowy. | Lokalny, funkcjonalny i związany z celem danej funkcji. |
| Przykłady | Przegląd kodu, testy, dokumentacja, wdrożenie na środowisko testowe. | Płatność kartą, BLIK-iem i przelewem online w konkretnym procesie zakupowym. |
| Cel | Potwierdza, że Przyrost spełnia przyjęty standard jakości. | Potwierdzają, że element rozwiązuje określony problem biznesowy. |
W praktyce element można uznać za ukończony dopiero wtedy, gdy spełnia swoje Kryteria Akceptacji oraz Definition of Done. Kryteria mówią, co funkcja ma robić, a DoD określa, w jakim stanie jakościowym musi się znaleźć.
Jak stworzyć pierwszą Definition of Done?
Pierwsza DoD powinna być wystarczająco wymagająca, ale możliwa do spełnienia w realnych warunkach zespołu. Zbyt wysoka poprzeczka może uniemożliwić dostarczanie Przyrostów, a zbyt niska będzie utrwalać błędy i dług techniczny. Scrum Master może przeprowadzić warsztat według poniższego schematu.
- Przygotuj pytanie otwierające – zapisz na tablicy „Co oznacza DONE w naszym produkcie?”. Wyjaśnij, że na tym etapie wszystkie pomysły są zapisywane bez oceniania.
- Przeprowadź burzę mózgów – poproś zespół o opisanie pracy, która musi zostać wykonana, aby element rzeczywiście był gotowy. Pomocne pytania dotyczą błędów, testów, automatyzacji, długu technicznego, wydajności, architektury, dokumentacji, bezpieczeństwa i wartości dla użytkownika.
- Posegreguj pomysły – umieść propozycje w trzech obszarach: NOW dla rzeczy możliwych od najbliższego Sprintu, NEXT dla usprawnień trudnych, lecz realnych w niedalekiej przyszłości, oraz FUTURE dla celów odległych lub obecnie nieosiągalnych.
- Sprawdź obiektywność kryteriów – usuń sformułowania typu „kod jest dobrej jakości” i zastąp je warunkami możliwymi do zweryfikowania, na przykład „zmiana przeszła przegląd kodu” albo „testy integracyjne zakończyły się powodzeniem”.
- Ustal wspólną wersję – wybierz elementy, które będą obowiązywać od kolejnego Sprintu. Zespół powinien rozumieć konsekwencje każdego kryterium i mieć możliwość zakomunikowania, gdy nie jest w stanie go spełnić.
- Udostępnij zobowiązanie – umieść DoD w miejscu dostępnym dla zespołu i interesariuszy. Można zakończyć warsztat symbolicznym potwierdzeniem, że zespół przyjmuje wspólny standard.
W czasie burzy mózgów przydatne są pytania, które kierują rozmowę na efekt, a nie wyłącznie na używane narzędzia:
- Jak potwierdzimy, że rozwiązanie nie zawiera krytycznych błędów?
- Jakie testy muszą zostać wykonane i z jakim wynikiem?
- Co możemy zautomatyzować, aby ograniczyć ryzyko powtarzalnych błędów?
- Jak spełnimy wymagania dotyczące wydajności, bezpieczeństwa i dostępności?
- Jak zapewnimy zgodność z architekturą oraz standardami produktu?
- Jaka dokumentacja musi zostać uzupełniona przed uznaniem pracy za ukończoną?
- W jaki sposób potwierdzimy, że Przyrost dostarcza oczekiwaną wartość użytkownikowi?
Nie trzeba wpisywać do DoD nazw konkretnych praktyk, takich jak TDD czy programowanie w parach, jeśli nie opisują one wymaganego rezultatu. Lepszy zapis wskazuje efekt, na przykład „kod został zweryfikowany i nie zawiera znanych błędów krytycznych”, zamiast wymuszać określone narzędzie bez związku z wartością produktu.
Przykład Definition of Done
Poniższy wzorzec można potraktować jako punkt wyjścia. Ostateczna lista powinna uwzględniać rodzaj produktu, standardy organizacji i dojrzałość zespołu:
- Kryteria Akceptacji dla elementu zostały spełnione.
- Zmiana przeszła code review wykonane przez inną osobę z zespołu.
- Testy jednostkowe i integracyjne zostały wykonane, a ich wynik jest pozytywny.
- Nie ma otwartych błędów blokujących ani krytycznych związanych z daną zmianą.
- Rozwiązanie spełnia uzgodnione wymagania niefunkcjonalne, takie jak bezpieczeństwo, wydajność lub dostępność.
- Dokumentacja techniczna i użytkowa została zaktualizowana, jeśli zmiana tego wymaga.
- Funkcja została wdrożona na środowisko testowe lub staging.
- Przyrost jest gotowy do prezentacji, użycia albo wdrożenia zgodnie z zasadami produktu.
W przypadku zadań projektowych, frontendowych, integracyjnych czy dokumentacyjnych DoD może zawierać dodatkowe sekcje. Nie zmienia to jej podstawowej roli: ma opisywać stan ukończonego i wartościowego Przyrostu, a nie tylko listę czynności wykonanych przez zespół.
Jak utrzymywać Definition of Done?
DoD jest żywym uzgodnieniem. Zespół powinien okresowo sprawdzać, czy nadal odpowiada potrzebom produktu i jego możliwościom. Dobrym miejscem na taką rozmowę jest Retrospekcja Sprintu, choć częstotliwość zależy od sytuacji. Niektóre zespoły wracają do DoD co kilka Sprintów, inne po większej zmianie technologicznej lub organizacyjnej.
Jeżeli przez wiele Sprintów nie powstaje żaden Przyrost zgodny z DoD, trzeba sprawdzić, czy poprzeczka nie została ustawiona zbyt wysoko albo czy zespół nie potrzebuje wsparcia. Jeżeli kryteria są spełniane bez wysiłku i nie chronią już jakości, można zaplanować ich rozszerzenie. W ten sposób DoD dojrzewa razem z zespołem i ogranicza narastanie długu technicznego.
Dobra Definition of Done nie służy do udowadniania, że zespół był zajęty. Służy do wspólnego potwierdzenia, że powstał kompletny, sprawdzony i wartościowy Przyrost.
