Definition of Done, czyli jak zgrać oczekiwania zespołu

Programista mówi, że funkcja jest gotowa. Tester wciąż czeka, żeby ją sprawdzić. Dział utrzymania potrzebuje instrukcji wdrożenia. Biznes oczekuje czegoś, z czego ludzie mogą korzystać. Wszyscy rozmawiali o tej samej pracy, ale słowo „gotowe” znaczyło dla każdego coś innego.

Definition of Done wydobywa te oczekiwania na wierzch. Uzgodnienie jej bywa trudne, szczególnie gdy zespół jest nowy, praca różnorodna, a ludzie mają różne zawodowe doświadczenia. Uważam, że ta umowa staje się jaśniejsza, w miarę jak zespół uczy się razem. Ta nauka musi jednak zacząć się od jawnego standardu, którego ludzie mogą faktycznie używać.

Część pierwsza: rola Definition of Done

Co daje Definition of Done

Definition of Done, w skrócie DoD, opisuje wspólny standard jakości, który musi spełnić ukończona praca. W zespole produktowym pomaga ustalić, kiedy zmiana może zostać uznana za część gotowego produktu. Samo napisanie kodu może zostawić niedokończone testy, integrację albo inne niezbędne prace. [4]

Dobra definicja pomaga zespołowi na cztery praktyczne sposoby:

• Jakość staje się sprawdzalna: ludzie potrafią wyjaśnić, jak wynik został zweryfikowany.
• Pozostała praca staje się widoczna: skończona implementacja nie ukrywa niedokończonej weryfikacji ani integracji.
• Planowanie jest lepsze, bo obejmuje pracę potrzebną do osiągnięcia uzgodnionego standardu.
• Rośnie zaufanie: interesariusze wiedzą, na czym mogą polegać, gdy zespół zgłasza, że coś jest gotowe.

Sformułowania mają znaczenie, bo mgliste kryteria odtwarzają pierwotny problem. „Porządnie przetestowane” wciąż zostawia każdemu prywatną decyzję, co znaczy „porządnie”. Odwołanie do uzgodnionego zestawu sprawdzeń z dostępnymi wynikami daje zespołowi coś, co może wspólnie obejrzeć.

Miejsce DoD w Agile

Zasady Manifestu Agile podkreślają częste dostarczanie działającego oprogramowania, techniczną doskonałość, współpracę i regularne doskonalenie. Nie narzucają jednego uniwersalnego wzoru Definition of Done. Jawny standard ukończenia wspiera te zasady, bo pomaga ocenić, czy praca nazywana skończoną jest używalna i spełnia oczekiwania jakościowe. [1]

Formalna rola w Scrumie

W Scrumie Definition of Done jest zobowiązaniem związanym z Przyrostem (Increment), czyli używalnym rezultatem pracy zespołu. Opisuje warunki jakości, które ten rezultat musi spełnić.

Scrum Team tworzy odpowiednią definicję, jeśli nie zapewniają jej już standardy organizacji. Definicja organizacyjna jest minimum, a Developerzy odpowiadają za jej przestrzeganie. Zespoły pracujące razem nad jednym produktem muszą mieć wspólną definicję.

Element Product Backlogu, który nie spełnia definicji, nie może wejść do Przyrostu, zostać wydany ani pokazany na Sprint Review. Wraca do Product Backlogu, gdzie zostanie rozważony w przyszłej pracy. Samo Review nie jest bramką wydania: używalny Przyrost można dostarczyć wcześniej.

Definicja obowiązuje przez cały Sprint. Jakość nie może spadać w trakcie Sprintu. Scrum wyróżnia trzy odpowiedzialności: Product Owner, Scrum Master i Developerzy; kierownik projektu nie jest dodatkową rolą w Scrumie. Te zasady wyznaczają ramy, w których zespół wypracowuje swoją umowę. [2]

Jak „gotowe” działa w Kanbanie

Kanban Guide opisuje szerszą umowę o nazwie Definition of Workflow. Obejmuje ona elementy pracy, ich punkt startu i końca, stany przepływu, kontrolę pracy w toku (WIP), jawne zasady przesuwania pracy oraz prognozę, ile praca powinna trwać.

Definition of Done może wyrażać część tych zasad, choć Kanban nie wymaga terminologii Scruma. Ukończenie potrzebuje wyraźnej granicy: skończenie programowania i przejście przez cały przepływ to mogą być różne rzeczy. Wybrana granica decyduje też o tym, co mierzy czas cyklu (cycle time).

Na przykład przepływ kończący się na „Gotowe do wydania” opisuje inny rezultat niż przepływ kończący się na „Wydane”. Żadna z tych etykiet nie powinna zostawiać interesariuszy w niepewności, co się właściwie stało. To praktyczne zastosowanie zasady jawnego przepływu.

Kanban nie wymaga Sprintów. Zespoły mogą stosować i ulepszać swoje zasady w sposób ciągły. Gdy Kanban uzupełnia Scrum, dokłada uwagę na przepływ, a Przyrostem nadal rządzi scrumowa Definition of Done. [3]

Jeden wspólny standard i miejsce na różne wymagania

W tym miejscu zdefiniowanie „gotowe” może na początku wydawać się niemożliwe. Jak jedna definicja ma objąć nową funkcję, poprawkę błędu, zmianę w dokumentacji i analizę?

Dobrym punktem wyjścia jest rozdzielenie trzech pytań:

Umowa	Na jakie pytanie odpowiada	Przykład
Definition of Done	Jaki standard jakości musi spełnić ukończona praca nad produktem?	Zmiany są zintegrowane, a uzgodnione sprawdzenia przechodzą.
Kryteria akceptacji	Co musi osiągnąć ten konkretny element?	Eksport CSV uwzględnia wybrane filtry i uzgodnione kolumny.
Warunki ukończenia zadania	Kiedy ta konkretna czynność jest skończona?	Recenzent przejrzał proponowaną zmianę i zapisał uwagi.

Wspólna definicja powinna pozostać konkretna. Szczegóły, które się różnią, dopowiadają elementy pracy. Zmiana w dokumentacji i zmiana w kodzie mogą wymagać innych dowodów, ale obie składają się na produkt, który musi spełniać uzgodniony standard.

Podobnie ukończenie analizy może oznaczać odpowiedź na uzgodnione pytanie i zapisanie wniosków. To wartościowy wynik, ale samo zakończenie zadania badawczego nie oznacza, że powstał używalny Przyrost produktu. Precyzja co do rezultatu chroni przed tym, by wewnętrzny status zadania zawyżał postęp.

Kiedy ustalić umowę i jak jej używać

Ustalcie pierwszą używalną definicję na tyle wcześnie, żeby kierowała pracą, najlepiej przed pierwszym Sprintem, w którym zespół dostarcza produkt. Na Sprint Planning używajcie jej do rozmowy o tym, co realnie da się ukończyć, łącznie z weryfikacją, integracją i innymi wymaganymi czynnościami.

Przenoście tę umowę ze Sprintu na Sprint. Nie ma sensu pisać jej od nowa tylko dlatego, że zaczyna się nowy Sprint. Trzymajcie ją na widoku w trakcie pracy, a na Retrospektywie sprawdzajcie, gdzie jej treść, stosowanie lub wspierające ją praktyki wymagają poprawy.

Jeśli zespół zmienia definicję, wyjaśnijcie, co się zmieniło i od kiedy zmiana obowiązuje. Unikajcie odkrywania nowego oczekiwania jakościowego dopiero wtedy, gdy ktoś prosi o odbiór pracy. Tak samo unikajcie usuwania wymagań tylko po to, żeby niedokończona praca wyglądała na gotową.

Część druga: budowanie wspólnego rozumienia w dojrzewającym zespole

Przykład ze sprzątaniem pokoju

Wyobraź sobie, że prosisz dziecko o posprzątanie pokoju.

Dziecko wkłada zabawki do pudełka i robi przejście przez podłogę. Zrobiło dokładnie to, co zrozumiało z prośby. Kilka minut później ogłasza, że pokój jest posprzątany.

Wchodzisz i widzisz ubrania na krześle, książki porozrzucane po biurku i kubek przy łóżku. W twojej głowie posprzątany pokój oznaczał też ubrania w koszu na pranie, książki na półce, kubek odniesiony do kuchni i przetarte biurko.

Obie osoby miały w głowie obraz oczekiwanego wyniku. Tych obrazów nikt nigdy nie porównał.

Przed następną próbą możecie uzgodnić kilka sprawdzalnych warunków: zabawki w pudełku, ubrania w koszu, książki na półce, kubek w kuchni, biurko puste i przetarte. Możecie nawet razem obejrzeć przykład. Dziecko ma teraz dużo jaśniejszą podstawę, by ocenić, kiedy zadanie jest skończone.

To porównanie dotyczy ukrytych oczekiwań. W zawodowym zespole ludzie wnoszą do tej samej pracy różną wiedzę i różne odpowiedzialności. Każda perspektywa może odsłonić coś ważnego, czego inni jeszcze nie wzięli pod uwagę.

Dlaczego na początku tak trudno się porozumieć

Zespół, który dopiero zaczyna razem pracować, nie ma jeszcze wspólnej historii tego, co zwykle idzie nie tak. Jedna osoba uważa code review za oczywistość. Inna traktuje je jako dodatkową czynność. Ktoś, kto utrzymywał systemy produkcyjne, może oczekiwać instrukcji odtwarzania, o których nikt inny nie pomyślał.

Różnorodna praca jeszcze to utrudnia. Ogólnik w rodzaju „wykonane zgodnie z dobrym standardem” niby obejmuje wszystko, ale w niczym nie pomaga, gdy ludzie się nie zgadzają. Z drugiej strony lista kontrolna napisana wyłącznie pod kod aplikacji może nie mieć sensu dla dokumentacji czy analizy.

Presja też zniechęca do tej rozmowy. Dyskusja o jakości wymaga czasu, a nierozwiązane zależności mogą utrudniać osiągnięcie pożądanego standardu. Kusi, żeby oznaczyć element jako gotowy, a resztę zostawić na później.

Dojrzałość opisałbym tu jako zdolność zespołu do ujawniania założeń, uzgadniania dowodów i uczciwej reakcji, gdy dowodów brakuje. Same lata wspólnej pracy nie dają tej umiejętności automatycznie.

Włączcie biznes do rozmowy

Umowa musi łączyć rozumienie zespołu z oczekiwaniami ludzi, którzy zależą od jego pracy. Angażujcie Product Ownera i właściwych interesariuszy przy ustalaniu potrzeb dotyczących jakości, użyteczności i utrzymania. Jeśli kierownik projektu koordynuje zależności lub raportowanie, upewnijcie się, że rozumie, co faktycznie obiecuje status „gotowe” w zespole.

Zapytajcie klienta lub przedstawiciela biznesu, co spodziewa się móc zrobić z wynikiem. Prośba o nowy raport może dla jednej osoby znaczyć „pokaż dane na ekranie”, a dla innej „przygotuj eksport, którego finanse użyją bez ręcznych poprawek”. Ta różnica powinna trafić do wymagań elementu, zanim ktokolwiek oceni, czy jest skończony.

Jeśli potrzebna jest akceptacja, nazwijcie ją wprost: kto jej udziela i co sprawdza. Nie zostawiajcie „biznes to zatwierdzi” jako niezdefiniowanego ostatniego kroku.

Jak stworzyć pierwszą roboczą definicję

Zacząłbym od krótkich warsztatów wokół prawdziwej pracy. Poniższa kolejność daje zespołowi konkretny materiał do rozmowy.

1. Wybierzcie kilka ukończonych elementów, które potem wymagały nieoczekiwanej pracy. W miarę możliwości różnych rodzajów. Zapytajcie, co każdy uważał za skończone, a co zostało do zrobienia.
2. Oddzielcie powtarzalne oczekiwania jakościowe od wymagań pojedynczych elementów. Jeśli oczekiwanie dotyczy wielu zmian w produkcie, rozważcie je dla wspólnej definicji. Jeśli opisuje zachowanie jednej funkcji, zapiszcie je przy tym elemencie.
3. Piszcie sprawdzalne warunki. Zamiast „przetestowane” opiszcie, które sprawdzenia muszą przejść i gdzie można znaleźć wyniki. Zamiast „dokumentacja kompletna” wskażcie, jakie informacje muszą być aktualne i kto ich potrzebuje.
4. Sprawdźcie szkic na prawdziwych przykładach. Przejdźcie przez funkcję, poprawkę błędu i jakiś mniej typowy element. Omówcie, jaki dowód pokazałby, że każde kryterium jest spełnione. Warunek, którego nikt nie potrafi spójnie zinterpretować, wymaga poprawy.
5. Sprawdźcie, czy zespół jest w stanie spełnić standard. Brak dostępów, środowisk, umiejętności lub wsparcia to problemy dostarczania do rozwiązania. Pokażcie te ograniczenia zamiast chować je za statusem „gotowe”.
6. Używajcie definicji i przyglądajcie się wynikom. Zapisujcie powtarzające się nieporozumienia i nieoczekiwane poprawki. Ulepszajcie umowę, gdy te obserwacje pokażą lukę.

Krótka początkowa definicja może dobrze działać, jeśli obejmuje kluczowe potrzeby jakościowe produktu. Prostota powinna wynikać z jasnych sformułowań i świadomie wybranego zakresu, a nie z pominięcia niezbędnych sprawdzeń.

Praktyczny przykład dla zespołu programistycznego

Weźmy zespół, który dodaje eksport CSV do produktu raportowego. Kryteria akceptacji tego elementu mogą określać, że eksport uwzględnia wybrane filtry, zawiera uzgodnione kolumny i czytelnie obsługuje pusty wynik.

Obok tych wymagań zespół mógłby stosować taką wspólną Definition of Done. To przykładowy punkt wyjścia, do dopasowania do produktu i jego ryzyk:

• Uzgodnione zachowanie jest zweryfikowane, a dowody sprawdzeń są dostępne.
• Zmiana przeszła code review i jest zintegrowana z produktem.
• Uzgodnione testy regresji przechodzą, a nierozwiązane błędy nie przekraczają zdefiniowanych progów jakości produktu.
• Właściwe wymagania bezpieczeństwa, prywatności i dostępności zostały sprawdzone względem uzgodnionych standardów produktu.
• Instrukcje dla użytkowników i informacje dla utrzymania, których dotyczy zmiana, są aktualne.
• Powstały Przyrost jest używalny i można go dostarczyć bez pracy, której ta definicja jeszcze wymaga.

Konkretne zachowanie eksportu należy do tej funkcji. Wspólne oczekiwania jakościowe obowiązują także wtedy, gdy kolejną zmianą będzie poprawka błędu albo inna funkcja.

Sformułowania typu „właściwe” czy „uzgodnione sprawdzenia” wymagają doprecyzowania. Wskażcie odpowiednie standardy i zestawy testów. Określcie z góry, kiedy kryterium obowiązuje i jaki dowód jest potrzebny; zapiszcie powód, gdy nie obowiązuje. W przeciwnym razie elastyczne sformułowania staną się kolejnym źródłem prywatnych interpretacji.

Jak definicja dojrzewa razem z zespołem

Scrum Inc. opisuje Definition of Done jako umowę, która rozwija się wraz z dojrzewaniem zespołu, i ostrzega przed obniżaniem jej pod presją terminów. To wspiera ważną część argumentu o dojrzałości: standard powinien reagować na to, czego zespół się uczy. [4]

Pierwsze ulepszenia mogą dotyczyć jasności. Późniejsze mogą wynikać z większych możliwości: automatycznych sprawdzeń, bardziej niezawodnych środowisk, jaśniejszych instrukcji utrzymania albo lepszych sposobów testowania integracji.

Na przykład odkrycie, że pozornie ukończone zmiany wielokrotnie psują się po wdrożeniu, może skłonić zespół do dodania odpowiedniego testu integracyjnego i zainwestowania w środowisko, w którym da się go uruchomić. Ulepszenie wymaga zarówno oczekiwania, jak i zdolności, by je spełnić.

Postęp oceniałbym po tym, czy definicja zmniejsza liczbę niespodzianek. Szukajcie mniejszej liczby elementów otwieranych ponownie z powodu pominiętej pracy, rzadszych późnych odkryć brakujących sprawdzeń i mniej sporów o to, co obejmuje ukończony wynik. Te obserwacje to sygnały do nauki, a nie punkty do rankingu ludzi.

Dojrzała umowa może stać się bardziej wymagająca, nie stając się dużo dłuższa. Część szczegółów może żyć w wyraźnie przywołanych standardach i automatycznych sprawdzeniach. Liczy się to, czy ludzie rozumieją warunki i potrafią pokazać, że je spełnili.

„Gotowe” wciąż potrzebuje informacji zwrotnej

Produkt może spełniać standard jakości, a mimo to nie rozwiązywać problemu klienta. Poprawnie zaimplementowany eksport może być trudny do znalezienia, zawierać informacje, których nikt nie potrzebuje, albo wspierać proces, który biznes już zmienił.

Definition of Done daje zespołowi solidną podstawę do rozmowy o ukończonym wyniku. Informacja zwrotna od klientów i dowody faktycznego użycia pomagają ocenić, czy ten wynik dostarcza wartość. Obie rozmowy są ważne i żadnej nie powinno się chować w mglistym stwierdzeniu, że „klient jest zadowolony”.

Ujawniajcie oczekiwania, zanim zacznie się praca

Przykład ze sprzątaniem pokoju pokazuje, jak łatwo skończyć pracę zgodnie z oczekiwaniem, którego inni nigdy nie podzielali. Zespół może uniknąć dużej części tego zamieszania, rozmawiając o wyniku wcześnie, zapisując ważne warunki i konsekwentnie je sprawdzając.

Uważam, że dobra Definition of Done powstaje w powtarzanych rozmowach o prawdziwej pracy. Zacznijcie od umowy, której ludzie mogą używać, uczcie się z miejsc, w których zawodzi, i rozwijajcie możliwości, które pozwalają zespołowi ją spełniać.

Zanim zacznie się kolejny element, zapytajcie wszystkich zaangażowanych: „Jaki dowód przekonałby nas, że to jest gotowe?”

Źródła

1. Principles behind the Agile Manifesto (zasady Manifestu Agile)
2. The Scrum Guide 2020
3. The Kanban Guide, maj 2025
4. Scrum Inc: Definition of Done