Ta strona została przetłumaczona automatycznie. Aby poprawić komfort czytania, przełącz się na język angielski.

Przełącz na język angielski
Zaktualizowano (opublikowano )

Definition of Done: Przykład, lista kontrolna i warsztat w Scrum

Pewnego dnia przygotowywałem warsztaty razem z kolegą. Szybko uzgodniliśmy treść, brakowało tylko odpowiedniej prezentacji PowerPoint. Aby móc pracować nad prezentacją tak efektywnie, jak to tylko możliwe, podzieliliśmy ją tematycznie. Kiedy usiedliśmy, by przedyskutować gotowy projekt, pojawił się duży problem: mieliśmy bardzo różne pomysły na to, co właściwie charakteryzuje “gotowy projekt”. 

Problem ten może pojawić się również w zwinnych zespołach Scrum. Po dwóch tygodniach zespół osiąga koniec sprintu, ale nie ma zgody co do tego, czy przyrost produktu jest już ukończony i może zostać przeniesiony z “w toku” do “ukończony”. Ta różnica zdań prowadzi do dyskusji, które z kolei negatywnie wpływają na klimat w zespole. Aby zapobiec takim dyskusjom i chronić efektywną pracę zespołową, w świecie Scrum istnieje artefakt o nazwie “Definicja ukończenia” (DoD). 

Czym jest Definition of Done w Scrum?

Definition of Done to wspólne porozumienie jakościowe zespołu Scrum. Opisuje, jakie warunki muszą zostać spełnione, aby przyrost można było uznać za ukończony i użyteczny. Nie jest to osobista lista zadań ani dodatkowa akceptacja przez jedną rolę, lecz przejrzysty standard dla całego zespołu.

Dosłownie, Definition of Done oznacza “definicję ukończenia”. Oznacza to, że zespół uzgadnia, co należy zrobić, aby dana funkcja została uznana za ukończoną. W praktyce definicja ukończenia może być reprezentowana jako rodzaj listy kontrolnej, która jest używana podczas sprintu, a zwłaszcza na końcu, aby sprawdzić, czy zostały spełnione określone kryteria ukończenia. W przypadku zespołów programistycznych kryteria te mogą być na przykład następujące: 

Przykład Definition of Done: lista kontrolna dla zespołów Scrum

Praktyczna Definition of Done dla produktu software’owego może na przykład zawierać następujące kryteria:

  • Kryteria akceptacji i wymagania merytoryczne są spełnione.
  • Dokumentacja została przygotowana.
  • Kod jest w pełni zaimplementowany i skomentowany.
  • Przeprowadzono przegląd kodu.
  • Automatyczne testy przechodzą pomyślnie; istotne błędy i ryzyka bezpieczeństwa zostały obsłużone.
  • Zmiana jest zintegrowana i może zostać sprawdzona w środowisku zbliżonym do produkcyjnego.
  • Uwzględniono monitoring, logowanie oraz ewentualnie notatki wydania.
  • Przyrost jest użyteczny i spełnia standard jakości produktu.

Ta lista jest przykładem, a nie uniwersalnym wzorcem. Dobra DoD chroni jakość, pozostaje dla zespołu stosowalna w każdym Sprincie i jest dostosowywana, gdy zmieniają się produkt, ryzyka lub warunki techniczne.

Definition of Done to nie to samo co wpływ produktu

Definition of Done odpowiada na ważne pytanie: czy przyrost spełnia uzgodniony standard jakości i czy jest użyteczny? Nie odpowiada jednak automatycznie, czy zmiana na rynku lub u klienta przyniosła pożądany efekt.

W praktyce pomaga więc rozróżnienie trzech poziomów:

  • Done: Przyrost spełnia Definition of Done i może być używany.
  • Done-Done: Zmiana jest zintegrowana, dostarczona i możliwa do obserwacji w działaniu.
  • Wpływ produktu: Rzeczywiste opinie klientów pokazują, czy zmiana rozwiązuje istotny problem i zwiększa wartość produktu.

John Cutler opisuje oprogramowanie dlatego jako stale rozwijany system usług: funkcje nie są ostatecznymi budynkami, lecz tymczasowymi środkami służącymi do tworzenia korzyści dla klienta. Przeczytaj jego perspektywę w The Work Is Never Done.

Gil Zilberfeld rozróżnia ponadto różne znaczenia słowa „Done” – na przykład wtedy, gdy rozwój, testy, wdrożenie lub opinie klientów oznaczają kolejny stopień ukończenia. Jego ujęcie znajdziesz w The Definition of Done, Done-Done and Really Done.

Ważne: „wpływ produktu” nie powinien być po prostu formułowany jako dodatkowe kryterium DoD. Zespół Scrum musi dostarczyć użyteczny przyrost; czy osiąga on pożądany efekt, staje się widoczne dopiero później poprzez Sprint Review, korzystanie z produktu i kolejne pętle uczenia się. Właśnie to rozróżnienie chroni Definition of Done przed przekształceniem się w nieosiągalną listę zbiorczą.

Jak Definition of Done współgra z innymi skutecznymi praktykami Scrum, pokazujemy w naszym artykule Scrum Best Practices 2026.

Dlaczego definicja Done jest ważna?

To, że wyznaczanie celów ma ogromne znaczenie dla wydajności, nie jest nowym spostrzeżeniem. Wyznaczanie celów jest często badanym tematem w psychologii (por. Locke & Latham, 2006). Wykazano, że wydajność jest najwyższa, gdy cele są tak konkretne i wymagające, jak to tylko możliwe, ale nie wydają się nieosiągalne. Definition of Done nie jest jednak metodą wyznaczania celów (ale jeśli ma być stosowana, jest metodą wyznaczania celów). Wsparcie w wyznaczaniu celów Jeśli potrzebujesz pomocy, chętnie Ci pomożemy); jest to raczej kwestia kryteriów, które należy spełnić, aby osiągnąć cel. 

Kryteria te są ważne dla stworzenia wspólnego zrozumienia w zespole. Zrozumienie tego, co każdy członek zespołu musi osiągnąć, aby osiągnąć wspólny cel. Chodzi więc o indywidualne wyniki, które ostatecznie składają się na wyniki zespołu.

Jeśli spojrzymy na kwestię DoD z punktu widzenia właściciela produktu, ujawnią się zupełnie inne problemy. Jeśli nie jest jasno określone, kiedy przyrost produktu jest uważany za ukończony, może to prowadzić do nieporozumień z klientem, gdy produkt jest mu prezentowany. Jeśli tak się stanie i zostanie zaprezentowany niedokończony produkt, możliwość uzyskania informacji zwrotnej od klienta zostanie zablokowana. 

Ciągłe doskonalenie

Ponieważ definicja ukończenia nie jest koncepcją statyczną i może i powinna stale ewoluować lub zmieniać się, oferuje ona również zespołowi możliwość uczenia się. Jeśli pod koniec sprintu zespół zda sobie sprawę, że nie mógł spełnić kryteriów definicji ukończenia, członkowie zespołu mogą albo dostosować definicję ukończenia do rzeczywistej wydajności, albo zespół wyciąga wnioski na następny sprint i zmienia swój własny sposób pracy.

Wypróbuj Echometer za darmo już teraz i zdobądź nowe inspiracje do swoich retrospektyw!

Przetestuj Echometer bezpłatnie

Refleksje na temat Definicji Wykonania powinny być przeprowadzane przez zespół podczas retrospektywy. Możliwe Elementy EchometerPytania, które można zadać w ramach przygotowań to 

Mamy jasne definicje wykonania dla naszych wymagań.

Zwykle wiem, na czym stoimy w osiąganiu naszych wspólnych celów.

Cele: Moje cele są zbieżne z celami moich kolegów.

Zespół posiada wszystkie umiejętności potrzebne do osiągnięcia naszego celu.

Kwestionują oni nie tylko to, czy w zespole w ogóle istnieje definicja Done, ale także przejrzystość, autonomię i jasność ról w zespole.

Możesz znaleźć pełną pulę przedmiotów w naszym Narzędzie retro.

Jak nasz zespół może zdefiniować to, co zostało zrobione? Przykład warsztatu

Pokazaliśmy Ci, czym jest Definicja Wykonania i dlaczego są one ważne dla efektywnej współpracy w zespołach Scrum. Ale jeśli twój zespół nie stworzył jeszcze DoD, prawdopodobnie zastanawiasz się, jak to działa. 

Zasadniczo ważne jest, aby zespół nie spieszył się z przygotowaniem dokumentu. Ostatecznie powinien powstać dokument, z którym każdy członek zespołu może się identyfikować i który nie jest postrzegany jedynie jako zło konieczne. W związku z tym zalecamy format przypominający warsztaty z Scrum Masterem w roli moderatora. Każdy członek zespołu powinien zastanowić się, które kryteria są ważne dla ukończenia produktu, a zespół może następnie podsumować te przemyślenia. Analogicznie, opracowaliśmy format warsztatów dla ustalania celów. Rzuć okiemaby uzyskać pomysły na warsztaty Definition of Done! 

Ukończone DoD można wykorzystać w retrospektywach, na przykład w formie sygnalizacji świetlnej Definition-of-Done:  

  1. Zapisz kryteria dla definicji Done poniżej siebie.
  2. Narysuj czerwony, żółty i zielony kwadrat obok każdego z nich.
  3. Dla każdego elementu w Definicji Wykonania każdy członek zespołu zaznacza, czy został on wdrożony dobrze, umiarkowanie dobrze czy słabo w ostatnim sprincie. 
  4. Omów trzy najczęściej wymieniane w czerwonym obszarze.
  5. W razie potrzeby dostosuj swoją definicję gotowości.

Podsumowanie – Ukończone?

Kilka słów na zakończenie: w środowisku zwinnym nie ma czegoś takiego jak “gotowe”. Gotowe oznacza jedynie, że coś jest tymczasowo ukończone, ale dalsze poprawki i ulepszenia mogą i powinny nastąpić w dowolnym momencie. Jest to jeden z wielu pięknych aspektów pracy zwinnej: ciągłe doskonalenie. 

Szczególnie ekscytujące: czasami punkty są “zrobione”, dopóki klient nie zgłosi się i nie zakwestionuje całego rozwiązania, wstrząsając w ten sposób twoimi założeniami dotyczącymi potrzeb klienta. W takich sytuacjach staje się jasne, czy zespół rzeczywiście przedkłada korzyści klienta nad postępy w systemie zgłoszeń.

Jasna definicja wykonanej pracy pozwala uniknąć konfliktów i zwiększyć twoją wydajność. Jeśli interesuje Cię więcej sposobów na osiągnięcie tego celu, powinieneś również zapoznać się z naszym artykułem o niesamowitej prawdzie kryjącej się za zwinnym sposobem myślenia spójrz. Możesz też wzbogacić swoje retrospektywy, biorąc pod uwagę najnowsze odkrycia naukowe w dziedzinie psychologii.

Dokładnie z tą obietnicą opracowaliśmy nasze narzędzie retro Echometer. Jeśli jesteś zainteresowany tym, jak (i czy) działa Echometer, przeczytaj raport z doświadczeń Holgera z naszym narzędziem:

Chcesz przenieść swój zespół na nowy poziom wydajności? Nasze narzędzie Retro może Ci w tym pomóc. Oto doświadczenia Holgera z tym narzędziem:

Raport z doświadczeń Holgera na temat Remote Retro Tool

Najczęstsze pytania dotyczące Definition of Done

Co powinno znaleźć się w Definition of Done?

Do Definition of Done należą wszystkie kryteria jakościowe, które przyrost musi spełniać, aby był użyteczny. Typowe przykłady to spełnione kryteria akceptacji, code review, testy, kontrola bezpieczeństwa, dokumentacja oraz techniczna możliwość dostarczenia. O tym, które punkty obowiązują, decyduje zespół w swoim kontekście produktowym.

Kto tworzy Definition of Done w Scrum?

Zespół Scrum wspólnie opracowuje i utrzymuje Definition of Done. Nie powinna ona być narzucona przez jedną rolę jako lista kontrolna. Organizacje mogą ustalać minimalne standardy, ale zespół musi je rozumieć i być w stanie stosować je na co dzień.

Jaka jest różnica między Definition of Done a Definition of Ready?

Definicja ukończenia opisuje, kiedy inkrement jest gotowy i użyteczny. Definicja gotowości może natomiast zawierać kryteria przygotowania elementu pracy, ale nie jest oficjalnym artefaktem Scruma i nie może służyć do przenoszenia odpowiedzialności ani pętli informacji zwrotnej.

Przykład z praktyki: Nasza wewnętrzna definicja ukończenia w Echometer

Definicja ukończenia nie musi kończyć się na kodzie i testach. Echometer stosuje wewnętrznie bardziej kompleksowy standard, który obok funkcjonalności uwzględnia także UX, łatwość utrzymania, obserwowalność oraz przygotowanie wydania. Poniższy przykład pokazuje, jak zespół może konkretnie i sprawdzalnie określić własne kryteria jakości:

Obszar Przykładowe kryteria
Funkcjonalność Określona funkcja działa, typowe przypadki brzegowe zostały sprawdzone, nie ma znanych błędów, niedokończone funkcje są chronione przez Feature Flag, a istotne dane o użyciu są rejestrowane.
UX Uwzględniono stany puste, stany ładowania, uprawnienia, obsługę błędów, lokalizację i responsywny wygląd.
Utrzymywalność Przestrzegano Coding Guidelines i odpowiednich konwencji, uniknięto zbędnego kodu i celowo pozostawionego długu technicznego, a także dostępne są ważne informacje do monitoringu i debugowania.
Wdrożenie Zmiana została wdrożona na produkcję albo świadomie przygotowana za pomocą Feature Flag, uzupełniono Release Notes, a zainteresowane strony są w razie potrzeby informowane.

Ten przykład nie jest oczywiście uniwersalnym szablonem. Możecie jednak wykorzystać go jako podstawę, wzbogacić o własne definicje, regularnie weryfikować i rozwijać jako żywy dokument.

Źródła

Locke, E. A., & Latham, G. P. (2006). New Directions in Goal-Setting Theory. Current Directions in Psychological Science, 15(5), 265–268. https://doi.org/10.1111/j.1467-8721.2006.00449.x

Kategoria bloga

Więcej artykułów na temat „Praca zespołowa”

Zobacz wszystkie artykuły z tej kategorii
10 prostych podstawowych zasad zwinnej retrospektywy

10 prostych podstawowych zasad zwinnej retrospektywy

Retrospektywy Agile: 10 prostych zasad efektywnej pracy zespołowej. Stwórz bezpieczne środowisko, promuj szczerość i skup się na rozwiązaniach.

Jak poprawić komunikację w zdalnym zespole programistów?

Jak poprawić komunikację w zdalnym zespole programistów?

Popraw komunikację w zdalnych zespołach programistycznych! Odkryj skuteczne środki dla zwinnego tworzenia oprogramowania, od spotkań 1 na 1 po retrospektywy.

Retro zmęczenie: „Retro jest zbędne” – 7 wskazówek, jak reagować

Retro zmęczenie: „Retro jest zbędne” – 7 wskazówek, jak reagować

Żaden lider ani Scrum Master nie lubi słyszeć, gdy zespoły kwestionują retrospektywę lub określają ją jako zbędną. Jest to częsty objaw zmęczenia retro. Dlaczego tak się dzieje, mimo że mówi się, ż...

Lista kontrolna: 21 nawyków dla menedżerów (PDF)

Lista kontrolna: 21 nawyków dla menedżerów (PDF)

Popraw swoje umiejętności przywódcze dzięki naszej liście kontrolnej dla menedżerów personalnych! Odkryj 21 nawyków skutecznych liderów i pobierz szablon PDF.

4 wskazówki dotyczące budowania zespołu w rozproszonych zespołach zdalnych

4 wskazówki dotyczące budowania zespołu w rozproszonych zespołach zdalnych

Skuteczny team building w zespołach zdalnych: 4 wskazówki dotyczące lepszej komunikacji, rutyny i zaufania. Tak zespoły rozproszone rozwijają swój potencjał.

Pierwsze kroki w pracy zwinnej - Agile Explorers

Pierwsze kroki w pracy zwinnej - Agile Explorers

Agile zarządzanie projektami z łatwością: Odkryj, jak zespoły wdrażają zwinność w codziennej pracy. Czynniki sukcesu, takie jak komunikacja, kultura akceptacji błędów i bliskość klienta w centrum uwagi.

Motywowanie zespołów - Małe ABC zaangażowanych zespołów (część 1)

Motywowanie zespołów - Małe ABC zaangażowanych zespołów (część 1)

Motywowanie zespołów: Odkryj podstawy angażowania zespołów w zwinnym tworzeniu oprogramowania! Unikaj próżniactwa społecznego i rozproszenia odpowiedzialności dzięki tym wskazówkom.

Co sprawia, że zespół jest naprawdę dobry

Co sprawia, że zespół jest naprawdę dobry

Co tworzy dobry zespół? Cele, komunikacja i atmosfera są kluczowe. Wskazówki dotyczące budowania zespołu, atmosfery w zespole i zwinnych retrospektyw dla B2B.

Bezpieczeństwo psychologiczne w zwinnych zespołach

Bezpieczeństwo psychologiczne w zwinnych zespołach

Dowiedz się, dlaczego bezpieczeństwo psychologiczne jest tak ważne w zespołach Agile. ✓ Definicja ✓ Korzyści ✓ Pomiar ✓ Wskazówki dotyczące poprawy dla Scrum Masterów.

Newsletter Echometer

Nie przegap aktualizacji Echometer i czerp inspirację do zwinnej pracy