Kryteria Jakości

Jakie standardy jakości musi spełniać praca, by była ukończona?

Cały kod został zrecenzowany i zatwierdzony przez co najmniej jednego innego programistę.
Pokrycie testami jednostkowymi spełnia uzgodniony próg 80% lub wyższy.
Nie pozostają otwarte żadne błędy o krytycznym lub wysokim priorytecie.
Dokumentacja i Komunikacja

Co należy udokumentować lub udostępnić przed uznaniem za ukończone?

Dokumentacja dla użytkowników została zaktualizowana, aby odzwierciedlać zmianę.
Notatki o wydaniu i wpisy w dzienniku zmian są kompletne.
Dokumentacja API odzwierciedla wszelkie nowe lub zmienione punkty końcowe.
Testowanie i Walidacja

Jak weryfikujemy, że praca faktycznie działa?

Wszystkie kryteria akceptacji z historyjki użytkownika zostały spełnione.
Testy manualne ukończone w obsługiwanych przeglądarkach i na urządzeniach.
Funkcjonalność zwalidowana przez właściciela produktu przed zamknięciem.
Wdrożenie i Gotowość

Co musi być spełnione, by bezpiecznie wydać pracę?

Funkcjonalność jest wdrożona na produkcji lub ukryta za flagą funkcji.
Monitorowanie i alerty są skonfigurowane dla nowej funkcjonalności.
Plan wycofania lub odzyskiwania jest gotowy na wypadek problemów.

Czym jest Definicja Ukończenia?

Zdarzyło Ci się kiedyś wdrożyć coś, by potem odkryć, że tak naprawdę nie było to ukończone? Definicja Ukończenia (Definition of Done, DoD) wnosi jasność do jednej z najważniejszych wspólnych umów, jakie zespół może zawrzeć. Ustanawia ona klarowne, zbiorowe zrozumienie kryteriów, które muszą zostać spełnione, zanim jakikolwiek element pracy — historyjka użytkownika, funkcjonalność lub cały sprint — będzie można uznać za naprawdę ukończony. Dzięki jasnemu wyrażeniu tych oczekiwań zespoły ograniczają poprawki, podnoszą jakość i tworzą niezawodny, powtarzalny standard dostarczania. Zakorzeniona w praktykach zwinnych i Scrumie, Definicja Ukończenia działa jak lista kontrolna jakości, na którą wszyscy się zgadzają, zanim rozpocznie się praca. Eliminuje zgadywanie w rozmowach typu „czy to jest gotowe?” i pomaga zespołom uniknąć pułapki przenoszenia ukrytej pracy do kolejnych sprintów. Niezależnie od tego, czy definiujesz „ukończone” po raz pierwszy, czy też wracasz do istniejącej umowy, ta wspólna sesja zachęca każdy głos do udziału — od programistów i testerów po projektantów i właścicieli produktu — aby wynik odzwierciedlał perspektywę całego zespołu. Prowadzenie tej sesji w TeamRetro ułatwia uchwycenie, omówienie, pogrupowanie i ustalenie priorytetów kryteriów, które mają największe znaczenie dla Twojego zespołu. Rezultatem jest żywy dokument, który rozwija się wraz z dojrzałością i standardami zespołu. Efektem jest bardziej przewidywalne dostarczanie, mniej niespodzianek podczas przeglądu oraz wspólne poczucie odpowiedzialności, które podnosi jakość wszystkiego, co dostarczacie. Dowiedz się więcej o tej koncepcji z <a href="https://www.scrum.org/resources/blog/done-understanding-definition-done" target="_blank" rel="noopener noreferrer">przewodnika Scrum.org po Definicji Ukończenia</a>.

Format współpracy Definicja Ukończenia

Kryteria Jakości

Jakie standardy jakości musi spełniać praca, by była ukończona?

Ten temat obejmuje techniczne i jakościowe punkty odniesienia, które każdy element pracy powinien spełniać, zanim zostanie uznany za ukończony. Zachęć zespół do myślenia o jakości kodu, pokryciu testami, wydajności i standardach. Zadawaj pytania pogłębiające, takie jak „Co sprawiłoby, że bylibyśmy pewni, iż to nie zepsuje się na produkcji?”, aby ujawnić niejawne oczekiwania i przekształcić je w jasne, mierzalne kryteria.

Dokumentacja i Komunikacja

Co należy udokumentować lub udostępnić przed uznaniem za ukończone?

Wykorzystaj ten temat, aby ujawnić oczekiwania dotyczące dzielenia się wiedzą i dokumentacji, które utrzymują zespół w zgodzie i ograniczają przyszłe nieporozumienia. Zachęć uczestników do zastanowienia się, kto musi wiedzieć o zmianie i jakie artefakty powinny istnieć. To często najbardziej pomijana część definicji ukończenia, więc zachęć do szczerej refleksji nad wcześniejszymi brakami.

Testowanie i Walidacja

Jak weryfikujemy, że praca faktycznie działa?

Ten temat koncentruje się na krokach weryfikacyjnych, które potwierdzają, że praca spełnia wymagania i zachowuje się zgodnie z oczekiwaniami. Poprowadź zespół tak, aby myślał poza testami automatycznymi, uwzględniając testy manualne, eksploracyjne i akceptacyjne. Zachęć do określenia, kto waliduje pracę i w jakim środowisku.

Wdrożenie i Gotowość

Co musi być spełnione, by bezpiecznie wydać pracę?

Tutaj zespół definiuje, co oznacza gotowość pracy do wydania i udostępnienia użytkownikom. Pobudź dyskusję wokół wdrożenia, monitorowania, planów wycofania i gotowości operacyjnej. Pomaga to zespołom uniknąć częstej luki między „kod gotowy” a „faktycznym dostarczeniem wartości”.

Kiedy należy skorzystać z tej retrospektywy

  • Gdy nowy zespół się formuje i od początku potrzebuje ustalić wspólne standardy jakości.
  • Gdy praca jest często wznawiana lub błędy przedostają się na produkcję, co sygnalizuje niejasne kryteria ukończenia.
  • Przed rozpoczęciem nowego projektu lub sprintu, aby wszyscy zgadzali się co do tego, jak wygląda ukończenie.
  • Podczas wdrażania nowych członków, którzy muszą zrozumieć oczekiwania zespołu dotyczące jakości.
  • Podczas retrospektywy, gdy zespół zauważa niespójność w sposobie uznawania pracy za ukończoną.

Proponowane pytania lodołamacze

  • Gdyby „ukończone” miało osobowość, jakie by było — perfekcjonista, pragmatyk czy bohater ostatniej chwili?
  • Jaka była najbardziej zaskakująca rzecz, o której kiedyś odkryłeś, że NIE była tak naprawdę skończona?

Pomysły i wskazówki dotyczące spotkania retrospektywnego

  • Twórzcie Definicję Ukończenia wspólnie z całym zespołem, aby każdy czuł się jej współwłaścicielem — unikajcie sytuacji, w której jedna osoba dyktuje standardy.
  • Utrzymujcie kryteria realistyczne i osiągalne; zbyt ambitna DoD, której nigdy się nie spełnia, podważa swój cel.
  • Spraw, aby każde kryterium było konkretne i weryfikowalne, by nie było wątpliwości, czy zostało spełnione.
  • Traktujcie Definicję Ukończenia jako żywy dokument i wracajcie do niej okresowo wraz z rozwojem standardów i narzędzi zespołu.
  • Zachęcaj cichszych członków zespołu do udziału, dając każdemu czas na samodzielne dodanie pomysłów przed dyskusją grupową.
  • Rozróżniajcie Definicję Ukończenia od kryteriów akceptacji — DoD dotyczy całej pracy, podczas gdy kryteria akceptacji są specyficzne dla danej historyjki.

Najczęściej zadawane pytania

Czym jest Definicja Ukończenia w agile?
Definicja Ukończenia to wspólny, jawny zestaw kryteriów, które element pracy musi spełnić, zanim zostanie uznany za ukończony. Tworzy spójny standard jakości w całym zespole i ogranicza niejasności dotyczące tego, co oznacza „skończone”.
Czym Definicja Ukończenia różni się od kryteriów akceptacji?
Definicja Ukończenia odnosi się do wszystkich elementów pracy jako uniwersalna lista kontrolna jakości, podczas gdy kryteria akceptacji są specyficzne dla pojedynczej historyjki użytkownika i opisują jej unikalne wymagania. Aby praca była naprawdę ukończona, należy spełnić oba.
Kto powinien być zaangażowany w tworzenie Definicji Ukończenia?
Cały zespół powinien współpracować, w tym programiści, testerzy, projektanci i właściciel produktu. Wspólna odpowiedzialność zapewnia, że kryteria są realistyczne, kompleksowe i przestrzegane przez wszystkich.
Jak często powinniśmy aktualizować naszą Definicję Ukończenia?
Traktujcie ją jako żywy dokument i przeglądajcie okresowo — na przykład podczas retrospektyw lub wraz z dojrzewaniem narzędzi, umiejętności i standardów jakości. Wiele zespołów wraca do niej co kilka sprintów.
Ile czasu zajmuje stworzenie Definicji Ukończenia?
Początkowa sesja zwykle trwa od 45 do 90 minut, w zależności od wielkości zespołu i tego, jak duża jest już zgodność. Kolejne przeglądy są zazwyczaj znacznie krótsze.

Nie mają Państwo doświadczenia w prowadzeniu retrospektyw? Zapraszamy do zapoznania się z naszym przewodnikiem dotyczącym tego, jak przeprowadzić retrospektywę →