W Scrumie zadanie może być zakodowane, przetestowane przez developera i pokazane na środowisku testowym, a mimo to nadal nie być naprawdę ukończone. Jeśli wymaga jeszcze integracji, testów regresyjnych, dokumentacji albo kontroli bezpieczeństwa, część pracy pozostaje ukryta.
Definition of Done, czyli DoD, określa wspólny standard jakości, który musi spełnić Increment, aby można było uznać go za ukończony. Dzięki temu słowo Done znaczy dla developera, Product Ownera, Scrum Mastera i interesariuszy dokładnie to samo.
Scrum Guide definiuje Definition of Done jako formalny opis stanu Incrementu, który spełnia wymagane dla produktu miary jakości. Praca, która nie spełnia DoD, nie może zostać uznana za część Incrementu. (scrumguides.org)
Dobrze zbudowany DoD nie jest jednak wielostronicową procedurą ani checklistą stworzoną raz na początku projektu. Powinien być realnym, możliwym do stosowania standardem jakości, który chroni zespół przed odkładaniem niedokończonej pracy na później.
Czym jest Definition of Done?
Definition of Done, często skracane do DoD, jest zobowiązaniem powiązanym z Incrementem w Scrumie.
Opisuje minimalny stan jakości produktu, który musi zostać osiągnięty, zanim praca może zostać uznana za Done.
Scrum Guide wskazuje, że w momencie, gdy Product Backlog Item spełnia Definition of Done, powstaje Increment. Jeśli tych kryteriów nie spełnia, nie może zostać wydany ani przedstawiony podczas Sprint Review jako ukończona część Incrementu. (scrumguides.org)
DoD tworzy więc wspólne rozumienie tego, co oznacza ukończenie pracy.
Bez niego jedna osoba może przez Done rozumieć:
kod został napisany
inna:
kod został przetestowany
a jeszcze inna:
funkcja działa na środowisku produkcyjnym i jest monitorowana.
Każda z tych interpretacji może prowadzić do zupełnie innej oceny postępu.
Definition of Done usuwa tę niejednoznaczność.
Dlaczego Definition of Done ma tak duże znaczenie?
DoD przede wszystkim zwiększa transparentność jakości.
Jeżeli zespół mówi, że w Sprincie ukończył pięć elementów, interesariusze powinni wiedzieć, jaki poziom jakości kryje się za słowem ukończone.
Bez wspólnego standardu bardzo łatwo powstaje ukryta praca:
Development Done → czeka na testy → czeka na security → czeka na deployment → czeka na dokumentację
Na tablicy zadanie wygląda jak skończone, ale z perspektywy produktu nadal wymaga kilku etapów.
Scrum.org podkreśla, że DoD ma zapewnić wszystkim wspólne rozumienie kompletności Incrementu i jakości pracy, którą obserwują podczas inspekcji produktu. (scrum.org)
Realny Definition of Done pomaga więc ograniczyć:
- ukrytą pracę,
- rework,
- odkładanie testów na później,
- kumulowanie długu technicznego,
- nieporozumienia dotyczące jakości,
- sztuczne zawyżanie liczby ukończonych elementów.
Nie chodzi przy tym o perfekcję.
DoD ma określać minimalny poziom jakości potrzebny produktowi, a nie wszystkie możliwe usprawnienia, jakie można jeszcze wykonać.
Definition of Done a acceptance criteria – jaka jest różnica?
To jedno z najczęstszych źródeł nieporozumień.
Acceptance criteria opisują oczekiwane zachowanie konkretnego Product Backlog Item.
Definition of Done określa wspólny standard jakości obowiązujący Increment.
Przykład.
Dla funkcji resetowania hasła acceptance criteria mogą określać, że:
- użytkownik może poprosić o reset hasła,
- system wysyła wiadomość na zapisany adres,
- link wygasa po określonym czasie,
- nieważny link nie pozwala zmienić hasła.
To wymagania specyficzne dla tej funkcjonalności.
Definition of Done może natomiast wymagać, aby każda zmiana:
- została zintegrowana,
- przeszła code review,
- posiadała wymagane testy,
- przeszła automatyczny pipeline,
- spełniała wymagania bezpieczeństwa,
- była odpowiednio obserwowalna.
Scrum.org zwraca uwagę, że acceptance criteria są praktyką uzupełniającą i dotyczą konkretnych Product Backlog Items, podczas gdy Definition of Done jest formalnym elementem Scrum i opisuje jakość Incrementu. (scrum.org)
| Obszar | Definition of Done | Acceptance Criteria |
|---|---|---|
| Zakres | Increment / wspólny standard produktu | Konkretny Product Backlog Item |
| Scrum wymaga? | Tak | Nie |
| Główne pytanie | Czy produkt osiągnął wymagany poziom jakości? | Czy funkcja zachowuje się zgodnie z oczekiwaniem? |
| Powtarzalność | Stosowany regularnie | Zwykle inne dla każdego PBI |
| Przykład | Testy i review zakończone | Użytkownik może zresetować hasło |
Oba mechanizmy mogą działać jednocześnie.
Element powinien realizować oczekiwaną funkcjonalność i spełniać standard jakości produktu.
Definition of Done a Definition of Ready
Definition of Ready często pojawia się w zespołach Agile, ale nie jest formalnym elementem Scrum.
Jest dodatkową praktyką, która może określać, kiedy Product Backlog Item jest wystarczająco zrozumiały, aby zespół mógł rozważyć jego realizację.
Scrum.org wprost wskazuje, że Definition of Ready jest praktyką komplementarną, a nie elementem Scrum Guide. (scrum.org)
Można więc uprościć:
Definition of Ready → czy jesteśmy wystarczająco przygotowani, żeby rozpocząć pracę?
Definition of Done → czy ukończona praca osiągnęła wymagany standard jakości?
Trzeba jednak uważać, aby DoR nie zamienił się w rozbudowaną bramkę blokującą rozpoczęcie pracy, dopóki każdy szczegół nie zostanie opisany z góry.
Kto tworzy Definition of Done?
Scrum Guide rozróżnia dwie sytuacje.
Jeżeli organizacja posiada własny standard Definition of Done, wszystkie Scrum Teams muszą przestrzegać go jako minimum.
Jeżeli taki standard nie istnieje, Scrum Team tworzy Definition of Done odpowiedni dla produktu.
Developers są następnie zobowiązani do przestrzegania DoD podczas tworzenia Incrementu. (scrumguides.org)
Scrum.org podkreśla również, że zespół może wprowadzić bardziej rygorystyczne kryteria niż minimum organizacyjne, ale nie powinien obniżać ustalonego standardu. (scrum.org)
Nie jest więc dobrą praktyką sytuacja, w której Scrum Master sam przygotowuje DoD i wysyła go zespołowi do stosowania.
Standard powinien wynikać ze wspólnego rozumienia produktu, jego ryzyka i oczekiwanej jakości.
Jeden produkt powinien mieć wspólny standard Done
Problem staje się bardziej widoczny, gdy nad jednym produktem pracuje kilka Scrum Teams.
Zespół A uznaje element za Done po zakończeniu testów jednostkowych.
Zespół B wymaga dodatkowo testów integracyjnych i kontroli bezpieczeństwa.
Zespół C odkłada integrację do końca Sprintu.
Po połączeniu efektów trudno określić rzeczywistą jakość całego produktu.
Scrum Guide wymaga, aby wiele Scrum Teams pracujących nad jednym produktem wspólnie definiowało i stosowało ten sam Definition of Done. (scrumguides.org)
Zespół może stosować bardziej rygorystyczne praktyki we własnym obszarze, ale wspólne minimum musi pozwalać tworzyć jeden zintegrowany Increment.
To szczególnie ważne w większych systemach, gdzie praca zespołów trafia do tego samego produktu, API albo platformy.
Jakie elementy mogą znaleźć się w Definition of Done?
Nie istnieje uniwersalny DoD pasujący do każdego produktu.
Inne wymagania będzie mieć:
- aplikacja SaaS,
- system bankowy,
- aplikacja medyczna,
- strona marketingowa,
- system embedded.
DoD powinien wynikać z rzeczywistych potrzeb jakościowych produktu.
Najczęściej można rozważyć kilka obszarów.
Jakość kodu
Przykładowe wymagania:
- kod znajduje się w docelowym repozytorium,
- został poddany wymaganej formie review,
- nie zawiera znanych krytycznych problemów z analizy statycznej,
- jest zgodny ze standardami projektu.
Sformułowanie:
kod jest dobrej jakości
jest za mało precyzyjne.
DoD powinien pozwalać stwierdzić, czy warunek rzeczywiście został osiągnięty.
Testowanie
Standard może obejmować:
- wymagane testy jednostkowe,
- testy integracyjne,
- automatyczną regresję,
- testy krytycznych ścieżek,
- brak znanych defektów określonej klasy.
Nie ma natomiast uniwersalnego procentu code coverage, który powinien znaleźć się w każdym DoD.
Jeśli organizacja wymaga określonego progu, powinien on wynikać z konkretnego celu jakościowego, a nie z założenia, że wyższa liczba automatycznie oznacza lepszy produkt.
Bezpieczeństwo
W zależności od produktu DoD może wymagać:
- poprawnego skanowania zależności,
- braku krytycznych podatności,
- przejścia SAST,
- prawidłowej obsługi danych wrażliwych,
- zgodności z określonym standardem organizacyjnym.
W produkcie regulowanym wymagania będą inne niż w niewielkiej aplikacji wewnętrznej.
Integracja
Increment powinien działać jako część produktu, a nie tylko na komputerze developera.
DoD może więc uwzględniać:
- merge do właściwej gałęzi,
- poprawny build,
- integrację z pozostałymi komponentami,
- wykonanie testów integracyjnych,
- poprawne migracje danych.
Observability
W systemie produkcyjnym samo działanie funkcji może być niewystarczające, jeśli później nie da się sprawdzić, co dzieje się po jej wdrożeniu.
Standard jakości może obejmować:
- wymagane logowanie,
- metryki,
- tracing,
- alerty dla krytycznych scenariuszy.
Dokumentacja
Nie każda zmiana wymaga aktualizacji dokumentacji.
Jeżeli jednak jest ona potrzebna do prawidłowego użytkowania lub utrzymania funkcji, nie warto odkładać jej do osobnego zadania wykonywanego kilka tygodni później.
DoD może uwzględniać aktualizację:
- dokumentacji API,
- instrukcji użytkownika,
- runbooka,
- dokumentacji technicznej.
Przykład Definition of Done dla aplikacji SaaS
Realny DoD nie musi zawierać kilkudziesięciu punktów.
Przykładowy standard dla produktu SaaS może wyglądać następująco:
Increment jest Done, gdy:
- praca została zintegrowana z aktualną wersją produktu,
- wymagane acceptance criteria są spełnione,
- code review zostało zakończone,
- wymagane testy automatyczne przechodzą,
- testy integracyjne nie wykazują regresji,
- pipeline CI zakończył się sukcesem,
- nie występują znane krytyczne defekty,
- wymagane kontrole bezpieczeństwa zostały zaliczone,
- zmiany bazy danych posiadają zweryfikowaną migrację,
- wymagane logi i metryki są dostępne,
- dokumentacja została zaktualizowana, jeśli zmiana tego wymaga.
To przykład, nie gotowy szablon do skopiowania.
Jeżeli dana organizacja nie wykorzystuje migracji baz danych, taki punkt jest zbędny.
Jeśli natomiast rozwija system płatniczy, standard bezpieczeństwa może być znacznie bardziej rygorystyczny.
Dobry DoD powinien opisywać rezultat, a nie rytuał
Rozważ dwa zapisy:
Kod został sprawdzony.
oraz:
Code review zostało zakończone i wszystkie uwagi blokujące zostały rozwiązane.
Drugi zapis daje znacznie większą transparentność.
Podobnie:
Testy wykonane
jest słabsze od:
wymagany zestaw testów automatycznych przechodzi bez błędów.
Definition of Done powinien składać się z kryteriów, które są:
- zrozumiałe,
- możliwe do sprawdzenia,
- powtarzalne,
- związane z jakością produktu.
Nie musi każdy punkt być automatycznie mierzalny, ale dwie osoby powinny możliwie rzadko dochodzić do innych odpowiedzi na pytanie, czy warunek został spełniony.
Jak zbudować Definition of Done krok po kroku?
Najlepszym punktem wyjścia nie jest znalezienie gotowej checklisty w internecie.
Zacznij od realnych problemów jakościowych
Przeanalizuj ostatnie Sprinty i produkcyjne problemy.
Sprawdź, co regularnie trzeba poprawiać po uznaniu pracy za skończoną.
Przykłady:
- testy regresyjne są wykonywane dopiero kilka dni później,
- funkcje trafiają bez wymaganych logów,
- dokumentacja API jest stale nieaktualna,
- deployment ujawnia problemy z migracją bazy,
- code review odbywa się już po zamknięciu zadania.
Takie obserwacje są znacznie lepszym źródłem DoD niż abstrakcyjna lista najlepszych praktyk.
Sprawdź standardy organizacyjne
Organizacja może posiadać wymagania związane z:
- security,
- compliance,
- architekturą,
- audytem,
- testami,
- dokumentacją.
Jeżeli stanowią standard dla produktu, Scrum Team musi je uwzględnić jako minimum. (scrumguides.org)
Oddziel standard wspólny od kryteriów konkretnej funkcji
DoD powinien zawierać elementy regularnie potrzebne do zapewnienia jakości Incrementu.
Warunek:
użytkownik może filtrować faktury według daty
nie należy do Definition of Done.
To kryterium konkretnej funkcjonalności.
Natomiast:
wymagane testy funkcjonalne przechodzą
może być elementem DoD, jeśli jest wspólnym standardem produktu.
Formułuj kryteria jednoznacznie
Unikaj:
- przetestowane,
- wystarczająco szybkie,
- dobrze udokumentowane,
- bezpieczne,
- gotowe do wdrożenia.
Każde z tych określeń może być interpretowane inaczej.
Lepszy standard wskazuje, po czym poznajemy spełnienie wymagania.
Sprawdź, czy DoD jest możliwy do osiągnięcia w Sprincie
Jeżeli Definition of Done wymaga czynności, której zespół systematycznie nie jest w stanie wykonać przed końcem Sprintu, powstaje problem organizacyjny.
Przykład:
każdy release musi zostać ręcznie zatwierdzony przez dział bezpieczeństwa, którego czas odpowiedzi wynosi dwa tygodnie.
Przy tygodniowym Sprincie taki standard uniemożliwia regularne osiąganie Done.
Nie oznacza to, że należy usunąć kontrolę bezpieczeństwa z DoD tylko po to, żeby tablica była zielona.
Trzeba zmienić proces:
- automatyzować część kontroli,
- zbudować wcześniej uzgodnione standardy,
- włączyć security bliżej zespołu,
- usunąć niepotrzebne handoffy.
DoD może w ten sposób ujawniać problemy systemowe, których wcześniej nie było widać.
Automatyzuj sprawdzanie Definition of Done tam, gdzie to możliwe
Jedną z najlepszych metod utrzymania realnego DoD jest automatyczne sprawdzanie części kryteriów.
Pipeline CI/CD może weryfikować:
- build,
- unit tests,
- integration tests,
- analizę statyczną,
- zależności,
- security scanning,
- testy API,
- wybrane E2E.
Jeżeli krytyczna kontrola nie przechodzi, pipeline może zatrzymać zmianę.
DORA wskazuje automatyczne, szybkie i wiarygodne testy jako jeden z fundamentów continuous delivery. Zespół powinien otrzymywać informację o jakości zmian możliwie wcześnie, a testy powinny przepuszczać kod, który rzeczywiście nadaje się do wydania. (dora.dev)
Dzięki temu DoD nie jest checklistą, o której ktoś musi pamiętać pod koniec Sprintu.
Część standardu jakości zostaje wbudowana bezpośrednio w proces developmentu.
Nie wszystko warto jednak automatyzować.
Testy eksploracyjne, decyzje produktowe czy ocena użyteczności nadal mogą wymagać udziału człowieka.
Definition of Done nie powinien być sprawdzany dopiero pod koniec Sprintu
To częsty błąd.
Zespół przez prawie cały Sprint rozwija funkcje, a dwa dni przed końcem rozpoczyna:
- integrację,
- testowanie,
- dokumentację,
- security review.
Powstaje mini-Waterfall wewnątrz Sprintu:
development → testy → poprawki → koniec Sprintu
Wtedy wiele elementów pozostaje prawie Done.
Znacznie lepiej traktować DoD jako standard stosowany przez cały czas tworzenia elementu.
Jeżeli testy są częścią Done, powinny powstawać w trakcie pracy.
Jeżeli integracja jest częścią Done, kod powinien być integrowany regularnie.
Jeżeli wymagane są kontrole bezpieczeństwa, warto przesunąć je możliwie wcześnie.
To dobrze współgra z praktykami continuous delivery. DORA zaleca ciągłe testowanie zamiast osobnej fazy po zakończeniu developmentu. (dora.dev)
Definition of Done a release – czy Done oznacza produkcję?
Nie zawsze.
Scrum Guide wymaga, aby Increment był użyteczny i spełniał Definition of Done. Może zostać dostarczony interesariuszom przed zakończeniem Sprintu, a Sprint Review nie jest bramką wymaganą przed wydaniem. (scrumguides.org)
Warto więc rozróżnić:
Done – Increment osiągnął wymagany standard jakości.
Released – organizacja zdecydowała się udostępnić go użytkownikom.
Produkt może być Done, ale wydanie zostanie zaplanowane na konkretny termin z powodów biznesowych.
Nie powinno natomiast działać to odwrotnie: praca niespełniająca DoD nie powinna być przedstawiana jako ukończony Increment.
Jeżeli organizacja chce umieścić deployment produkcyjny bezpośrednio w Definition of Done, również może mieć to sens, o ile jest to realny standard produktu i zespół może go regularnie spełniać.
Zbyt słaby Definition of Done tworzy ukryty dług
Załóżmy, że DoD zespołu brzmi:
- kod ukończony,
- code review wykonane.
Po każdym Sprincie pozostają jednak:
- testy automatyczne,
- poprawki bezpieczeństwa,
- dokumentacja,
- optymalizacja wydajności.
Formalnie velocity wygląda dobrze.
Realnie zespół buduje rosnącą kolejkę pracy, która prędzej czy później musi zostać wykonana.
To forma ukrytego długu.
Scrum.org podkreśla, że Definition of Done jest właśnie standardem jakości potrzebnym do zapewnienia, że Increment rzeczywiście jest kompletny i użyteczny. (scrum.org)
Jeżeli organizacja regularnie tworzy elementy, które wymagają późniejszego utwardzania, stabilizacji albo dodatkowej fazy QA, warto sprawdzić, czy DoD nie jest ustawiony zbyt nisko.
Zbyt rozbudowany DoD też może być problemem
Druga skrajność to lista składająca się z kilkudziesięciu punktów stosowanych niezależnie od rodzaju zmiany.
Na przykład aktualizacja jednego tekstu w interfejsie musi formalnie przejść:
- pełne performance testing,
- aktualizację dokumentacji architektury,
- testy migracji bazy,
- dodatkowy review infrastruktury.
Takie kryteria nie zwiększają jakości. Zwiększają koszt procesu.
DoD powinien reprezentować minimalny standard wymagany przez produkt, a nie wszystkie możliwe działania związane z software developmentem.
Jeżeli część wymagań jest warunkowa, można je opisać odpowiednio.
Na przykład:
migracja bazy została zweryfikowana, jeśli zmiana obejmuje strukturę danych.
To bardziej praktyczne niż dodawanie fikcyjnego obowiązku do każdej funkcjonalności.
Najczęstsze błędy związane z Definition of Done
Done oznacza tylko development complete
Jeśli po Done pracę nadal musi wykonać osobny zespół QA, security lub operations, definicja może nie odzwierciedlać rzeczywistej gotowości Incrementu.
DoD istnieje tylko w Confluence
Dokument został przygotowany pół roku temu, ale nikt nie korzysta z niego podczas codziennej pracy.
Dobry standard powinien być łatwo dostępny i widoczny podczas developmentu oraz Sprint Review.
DoD zmienia się zależnie od presji
Pod koniec Sprintu zespół pomija część kryteriów, żeby zwiększyć liczbę zamkniętych ticketów.
Jeżeli kryterium jakości można pominąć tylko dlatego, że kończy się Sprint, nie jest realnym standardem.
Każdy Product Backlog Item ma osobny DoD
Zwykle oznacza to pomieszanie Definition of Done z acceptance criteria.
DoD opisuje wspólną jakość Incrementu.
DoD jest kopią z innej firmy
Lista zawierająca Kubernetes, określone skanery czy 90% coverage nie ma wartości, jeśli nie wynika z potrzeb konkretnego produktu.
DoD jest niemożliwy do osiągnięcia
Jeśli zespół regularnie ma 70–80% pracy Done, a reszta czeka na proces organizacyjny poza jego kontrolą, warto poprawić cały system zamiast przyzwyczajać się do permanentnie niedokończonej pracy.
Jak sprawdzić, czy obecny Definition of Done działa?
Najlepszym testem jest spojrzenie na to, co dzieje się po oznaczeniu pracy jako Done.
Jeżeli regularnie trzeba jeszcze:
- dopisywać testy,
- integrować kod,
- wykonywać ręczną regresję,
- naprawiać konfigurację,
- pisać dokumentację,
- przygotowywać monitoring,
- usuwać problemy bezpieczeństwa,
warto sprawdzić, czy część tych czynności nie powinna należeć do standardu ukończenia.
Dobrym źródłem informacji jest Sprint Retrospective.
Zamiast prowadzić abstrakcyjną dyskusję o jakości, można przejrzeć ostatnie kilka elementów i sprawdzić:
Jakiej pracy potrzebowały już po tym, gdy uznaliśmy je za Done?
Powtarzające się działania są kandydatami do poprawy Definition of Done albo całego procesu delivery.
Przykład: jak poprawić zbyt słaby Definition of Done
Zespół rozwija aplikację SaaS.
Początkowo jego DoD wygląda następująco:
- kod ukończony,
- code review zakończone,
- acceptance criteria spełnione.
Po kilku Sprintach okazuje się, że przed każdym wydaniem potrzebny jest dodatkowy tydzień na:
- testy regresyjne,
- poprawki integracyjne,
- naprawę konfiguracji,
- przygotowanie monitoringu.
Zespół analizuje źródła problemów i stopniowo rozszerza standard.
Nowy DoD obejmuje:
- integrację zmian,
- przechodzące testy jednostkowe,
- przechodzące testy integracyjne,
- krytyczną automatyczną regresję,
- zakończone code review,
- wymagane kontrole security,
- gotową konfigurację,
- telemetrykę dla nowych krytycznych funkcji.
Równocześnie część tych elementów zostaje przeniesiona do CI/CD.
W rezultacie problem nie jest przenoszony z końca Sprintu do większej checklisty.
Zmienia się sposób tworzenia produktu, dzięki czemu jakość powstaje razem z funkcjonalnością.
To właśnie powinien robić dobry Definition of Done.
Zacznij od standardu, który naprawdę jesteście w stanie stosować
Nie trzeba pierwszego dnia tworzyć idealnego DoD obejmującego wszystkie możliwe aspekty jakości.
Znacznie wartościowsze jest ustalenie kilku konkretnych kryteriów, których zespół rzeczywiście przestrzega przy każdym Increment.
Następnie warto obserwować:
- jakie problemy trafiają na produkcję,
- jaka praca pozostaje po Sprincie,
- co powoduje rework,
- które kontrole można automatyzować,
- gdzie Definition of Done nie odpowiada już rzeczywistemu ryzyku produktu.
Jeżeli np. testy integracyjne regularnie wykrywają błędy dopiero przed release, warto przesunąć je bliżej developmentu. Jeśli bezpieczeństwo stale tworzy późny bottleneck, część kontroli można włączyć do pipeline’u. Jeśli dokumentacja nie jest potrzebna dla każdego typu zmiany, nie ma sensu stosować jej mechanicznie.
Realny Definition of Done nie jest dokumentem opisującym idealną jakość. Jest wspólną granicą, poniżej której zespół nie nazywa pracy ukończoną.
Dzięki temu Done przestaje oznaczać prawie gotowe i zaczyna rzeczywiście informować, jaki stan produktu można bezpiecznie inspectować, rozwijać i — gdy pojawia się taka decyzja biznesowa — dostarczyć użytkownikom.
