Definicja stanu „zakończone” (DoD): lista kontrolna i przykłady
Definicja zakończenia (DoD) to lista kontrolna, którą każda historia musi spełnić przed wydaniem. Przykładowe listy kontrolne, wskazówki dotyczące tworzenia własnej listy oraz różnice między definicją zakończenia a kryteriami akceptacji.
Definicja zakończenia (DoD) to krótka lista kontrolna, co do której zespół uzgadnia, że każda historia musi spełnić poniższe warunki, zanim zostanie uznana za ukończoną: zweryfikowana, przetestowana, scalona, wdrożona, zaakceptowana. Stanowi ona jeden standard obowiązujący dla całego zespołu. Kryteria akceptacji dotyczą poszczególnych historii; definicja zakończenia ma charakter ogólny. Pomieszanie tych dwóch pojęć prowadzi do sytuacji, w której „zakończone” po cichu zaczyna oznaczać „działa na moim komputerze”.
Każdy zespół doświadczył rozbieżności między stwierdzeniem „programista twierdzi, że zadanie jest ukończone” a stwierdzeniem „można to faktycznie wprowadzić do produkcji”. Definicja ukończenia pozwala tę lukę zniwelować. Wystarczy uzgodnić ją raz, a następnie egzekwować w każdym sprincie, niezależnie od tego, na czym polega dana historia użytkownika. Bez tego pojęcie „gotowe” pozostaje subiektywną opinią poszczególnych osób, a różnice ujawniają się podczas prezentacji, a w najgorszym przypadku – już w środowisku produkcyjnym.
Co oznacza pojęcie „definicja zakończenia” w metodologii Scrum
W Przewodniku po Scrumie określa się to jako „formalny opis stanu przyrostu w momencie, gdy spełnia on wymagane kryteria jakościowe dla produktu”. Mówiąc prościej, definicja zakończenia stanowi zobowiązanie związane z przyrostem, jednym z trzech artefaktów Scruma. Praca, która spełnia te kryteria, staje się częścią przyrostu. Praca, która nie spełnia tych kryteriów, nie może zostać wydana ani zaprezentowana podczas przeglądu sprintu; wraca ona do rejestru produktów.
Jeśli Państwa organizacja ustaliła już definicję „zakończonego zadania”, każdy zespół stosuje ją jako minimum i może ją uzupełniać. Jeśli nie, zespół opracowuje własną. Zasada ta nie ogranicza się wyłącznie do metodyki Scrum: zespoły stosujące metodę Kanban często sporządzają taką samą listę jako wytyczne dotyczące przenoszenia zadań do ostatniej kolumny.
Przykłady definicji stanu „zakończone”
Przykładowa lista kontrolna „Definicja zakończenia”: zespół programistów
Praktyczny punkt wyjścia dla zespołu zajmującego się wdrażaniem aplikacji internetowej:
- Kryteria akceptacji zostały spełnione i zweryfikowane.
- Kod został sprawdzony i wkomponowany do gałęzi głównej.
- Napisano i pomyślnie przeprowadzono testy automatyczne; nie pojawiły się żadne nowe testy niestabilne.
- Nie odnotowano żadnych regresji ani otwartych błędów krytycznych związanych z tym zadaniem.
- Zaktualizowano dokumentację i dziennik zmian w zakresie zmian mających wpływ na użytkowników.
- Wdrożono do środowiska testowego i przeprowadzono testy sprawdzające.
- Właściciel produktu wyraził na to zgodę.
Proszę to przejąć, a następnie dostosować do tego, co Państwa zespół faktycznie będzie egzekwował. Definicja zakończenia zawierająca punkt, którego nikt nie sprawdza, jest gorsza niż krótka definicja. Sprawia to, że zespół zaczyna traktować całą listę jako element dekoracyjny. Proszę zmieścić ją na jednym ekranie i zadbać o to, by każdy punkt dał się zweryfikować.
Przykład definicji „zakończone”: zespół, który nie wydaje kodu
Ta sama zasada ma zastosowanie w przypadku zespołów marketingowych, treściowych lub projektowych. Definicja „zakończenia zadania” dla zespołu ds. treści mogłaby brzmieć następująco:
- Spełniono kryteria akceptacji określone w briefie.
- Tekst został zredagowany przez osobę inną niż autor.
- Sprawdzono fakty, dane liczbowe i linki.
- Zastosowano podstawowe zasady dostępności: tekst alternatywny, kolejność nagłówków, odpowiedni kontrast.
- Zatwierdzono przez osobę, która o to wnioskowała.
- Opublikowane lub przekazane oraz odnotowane w miejscu dostępnym dla zespołu.
Poziomy: historia, sprint i wydanie
Metodologia Scrum wymaga ustalenia jednej definicji „zakończenia” dla przyrostu. W praktyce wiele zespołów grupuje te weryfikacje według miejsc, w których naturalnie mają one miejsce:
| Poziom | Dotyczy | Typowe pozycje |
|---|---|---|
| Opowieść | Każda pozycja z listy zadań do wykonania | Kod został sprawdzony, testy zakończyły się powodzeniem, kryteria akceptacji zostały spełnione, a właściciel produktu wyraził zgodę |
| Sprint | Całość przyrostu | Zintegrowano z gałęzią główną, zestaw testów regresyjnych zakończył się pomyślnie, wdrożono do środowiska testowego |
| Komunikat prasowy | Co dociera do klientów | Opracowano informacje o wydaniu, przeprowadzono kontrole bezpieczeństwa i wydajności oraz poinformowano dział wsparcia technicznego |
Proszę traktować poziom opisu zadania jako podstawową listę. Jeśli weryfikacja może nastąpić dopiero w momencie wydania, proszę również odnotować to na liście, aby nikt nie oznaczył zadania jako zakończonego, zakładając, że ktoś inny później wychwyci tę lukę.
Jak sformułować definicję zakończenia zadania
- Zacznijcie od tego, co wciąż umyka. Przyjrzyjcie się ostatnim sprintom: błędom wykrytym po zakończeniu sprintu, zadaniom, które zostały odrzucone, oraz zadaniom przeniesionym z poprzedniego sprintu. Każdy z tych elementów wskazuje na brakujący element.
- Opracujcie ją wspólnie z całym zespołem. Osoby wykonujące zadania uzgadniają ją podczas jednego spotkania, przy wsparciu scrum mastera i w obecności właściciela produktu. Lista narzucona z zewnątrz nie zostanie poparta przez zespół w obliczu presji terminów.
- Niech każda linia kodu podlega weryfikacji. „Przetestowane” to stan subiektywny; „napisane testy automatyczne, które przechodzą pomyślnie w ramach ciągłej integracji” to weryfikacja. Jeśli dwie osoby nie są zgodne co do tego, czy dany warunek jest spełniony, proszę go przeredagować.
- Ograniczcie to do tego, co zamierzacie obecnie egzekwować. Zaczęlibyśmy od pięciu do ośmiu punktów. Te ambitniejsze dodajcie dopiero wtedy, gdy zespół będzie w stanie je faktycznie zrealizować.
- Umieść to tam, gdzie odbywa się praca. Lista kontrolna zawarta w szablonie zgłoszenia lub w kolumnie „zrobione” na tablicy jest faktycznie wykorzystywana. Strona w wiki zostaje zapomniana.
- Proszę to sprawdzić podczas przeglądu retrospektywnego. Jeśli ta sama luka pojawi się dwukrotnie, proszę dodać wiersz. Jeśli wiersz zostanie zaznaczony bez sprawdzenia przez nikogo, proszę zapytać, czy nadal ma on rację bytu.
Różnica między definicją „zakończenia” a kryteriami akceptacji
Jest to rozróżnienie, z którym zespoły mają najwięcej problemów. Kryteria akceptacji dla historii „logowania” odnoszą się konkretnie do logowania: poprawne dane logowania przenoszą użytkownika na pulpit nawigacyjny, a trzy nieudane próby powodują zablokowanie konta. Definicja zakończenia (sprawdzone, przetestowane, wdrożone) jest identyczna dla historii „logowania”, historii „wyszukiwania” oraz historii „rozliczeń”. Kryteria mają charakter lokalny i odpowiadają na pytanie: „Czy stworzyliśmy właściwą rzecz?”. Definicja zakończenia ma charakter globalny i odpowiada na pytanie: „Czy jakakolwiek część naszej pracy nadaje się do wdrożenia?”. Historia nie jest ukończona, dopóki nie przejdzie przez obie te bramki.
Różnica między definicją „gotowości” a definicją „zakończenia”
To są elementy uzupełniające, a nie symetryczne bliźniaki. Definicja „gotowości” pozwala na włączenie zadania do sprintu: musi być wystarczająco małe, wystarczająco jasne i oszacowane. Definicja „zakończenia” pozwala na wyłączenie ukończonej pracy ze sprintu. „Gotowość” dotyczy zadania; „zakończenie” dotyczy pracy. Zespoły, które stosują tylko jeden z tych stanów, zazwyczaj skupiają się na „gotowości” (ponieważ niegotowe zadania są głośno sygnalizowane) i po cichu pozwalają, by stan „zakończone” schodził na dalszy plan – w ten sposób gromadzą się zadania przenoszone z poprzedniego sprintu oraz te „zrealizowane w 90%”.
Te trzy listy kontrolne przestaną się ze sobą zlewać, gdy tylko zorientują się Państwo, co każda z nich obejmuje:
| Definicja słowa „gotowy” | Kryteria akceptacji | Definicja stanu „zakończone” | |
|---|---|---|---|
| Zakres | Na całym świecie, każda historia | Wiadomości lokalne – ta historia | Na całym świecie, każda historia |
| Bramy | Wejście w sprint | Własny finał tej historii | Zakończenie sprintu |
| Odpowiedzi | „Czy możemy już zacząć?” | „Czy stworzyliśmy to, co trzeba?” | „Czy nadaje się do wysyłki?” |
| Własność | Zespół wraz z właścicielem produktu | Właściciel produktu wraz z zespołem | Zespół |
Kto jest odpowiedzialny za określenie kryteriów zakończenia zadania?
Zespół to opracowuje; zespół dba o jego przestrzeganie. Scrum master pełni rolę moderatora, a właściciel produktu ma wpływ na ustalenie progu akceptacji, jednak to inżynierowie decydują, jakie wymagania techniczne musi spełniać „zakończone zadanie”, ponieważ nieprecyzyjnie zdefiniowane „zakończone zadanie” stanowi dług, za który odpowiadają oni sami, a nie kierownictwo. Proszę powrócić do tego tematu podczas retrospektywy, gdy ta sama luka wciąż się powtarza; jest to sygnał, że brakuje jakiegoś elementu.
W jaki sposób definicja „zakończenia” wpływa na Państwa szacunki
Punkty fabularne określają zakres prac aż do momentu ich zakończenia, a nie do „zakończenia kodowania”. Zatem definicja zakończenia jest uwzględniona w każdym oszacowaniu. Dodanie zapisu w rodzaju „przetestowano wydajność” sprawia, że każda historia staje się nieco większa. Gdy lista ulegnie zmianie, proszę ponownie sprawdzić historie referencyjne podczas kolejnej sesji planowania, w przeciwnym razie prędkość pracy spadnie z przyczyny, której nikt nie będzie w stanie wskazać.
Co idzie nie tak
Definicja „gotowości” staje się plakatem. Jest przypięta na wiki zespołu, odczytywana podczas wdrażania nowych pracowników, a pod presją terminów ignorowana: „testy napiszemy w następnym sprincie”. Dwa sprinty później dług testowy staje się strukturalny, a definicja „gotowości” – fikcją. Kiedy pojęcie „zakończone” jest niejasne, prędkość rozwoju zawyża się: zespół zapisuje punkty za pracę, której tak naprawdę nie da się dostarczyć, a prognoza po cichu traci wszelkie znaczenie.
Rozwiązaniem nie jest dłuższa lista, lecz krótsza, przy której zespół będzie się trzymał. Definicja „zakończone” ma znaczenie tylko w takim stopniu, w jakim są Państwo gotowi nie oznaczyć danego zadania jako zakończonego, ponieważ nie spełniło ono jednego z kryteriów.
Kryteria akceptacji stanowią punkt kontrolny dla danego zadania. Definicja zakończenia stanowi punkt kontrolny dla zespołu. Proszę zadbać o to, by były one na tyle zwięzłe, aby faktycznie można je było egzekwować. Punkt kontrolny, który nie jest egzekwowany, to tylko formalność.
Najczęściej zadawane pytania
Jaka jest definicja „zakończenia” w metodologii agile?
Definicja zakończenia (DoD) to jednolita lista kontrolna, której każda historia musi spełnić, zanim zostanie uznana za ukończoną: zazwyczaj obejmuje ona przetestowanie, przegląd kodu, scalenie, udokumentowanie oraz wdrożenie do środowiska testowego. Stanowi ona jeden wspólny standard dla całego zespołu, a nie oddzielną listę dla każdej historii, i ma na celu zapewnienie, by termin „zakończone” miał zawsze to samo znaczenie, niezależnie od tego, kto go używa.
Jaka jest różnica między definicją zakończenia a kryteriami akceptacji?
Definicja zakończenia ma charakter ogólny i stanowi ten sam punkt kontrolny dla każdego zadania. Kryteria akceptacji mają charakter lokalny i odnoszą się konkretnie do jednego zadania. Kryteria akceptacji określają, jak dana funkcja powinna działać; definicja zakończenia określa natomiast, co oznacza termin „gotowe do wydania” w odniesieniu do każdego wyniku pracy zespołu. Zadanie musi spełnić oba te warunki.
Czym jest lista kontrolna „definicji zakończenia”?
Krótka, jasno sformułowana lista warunków mających zastosowanie do każdego zadania: kod został sprawdzony i wkompilowany, testy zostały napisane i zakończyły się powodzeniem, nie ma znanych regresji, dokumentacja została zaktualizowana, kod został wdrożony w środowisku testowym, a właściciel produktu wyraził zgodę. Dokładne pozycje mogą się różnić w zależności od zespołu, jednak lista powinna zmieścić się na jednym ekranie, a każdy wiersz powinien dać się zweryfikować.
Jaka jest różnica między definicją „gotowości” a definicją „zakończenia”?
Etapy „gotowości” wyznaczają moment wejścia w sprint, a próg, który zadanie musi spełnić, zanim zespół się nim zajmie. Etapy „zakończenia” wyznaczają moment wyjścia ze sprintu, a próg, który ukończona praca musi spełnić przed jej wydaniem. Gotowość oznacza, że zadanie jest prawidłowo sformułowane; zakończenie oznacza, że praca nadaje się do wydania.
Jak sporządzić definicję zakończenia zadania?
Zacznijcie od tego, co ciągle umyka: błędów, poprawek i spraw przeniesionych z ostatnich kilku sprintów. Uzgodnijcie tę listę jako cały zespół, sformułujcie każdą pozycję tak, aby można było na nią odpowiedzieć „tak” lub „nie”, ograniczcie ją do tego, co faktycznie będziecie egzekwować, i umieśćcie ją tam, gdzie odbywa się praca, na przykład w szablonie zgłoszenia. Następnie powracajcie do niej podczas retrospektywy za każdym razem, gdy coś umknie Państwa uwadze.
Kto ustala definicję „zakończenia”?
Odpowiedzialność za to spoczywa na zespole programistycznym, zazwyczaj przy wsparciu scrum mastera. Właściciel produktu ma wpływ na ustalenie progu akceptacji, jednak to osoby wykonujące pracę decydują, co technicznie oznacza „zakończone”, ponieważ to właśnie one ponoszą konsekwencje, gdy definicja ta jest zbyt ogólna.
Materiały powiązane
- Szacowanie w metodologii agile: kompletny przewodnik: tutaj znajdą Państwo wszystkie niezbędne informacje.
- Kryteria akceptacji: test na poziomie poszczególnych historii, z którym często mylona jest definicja zakończenia.
- Definicja terminu „gotowy”: brama mety znajdująca się na drugim końcu trasy sprintu.
- Błędy w planowaniu pokerowym: w jaki sposób nieprecyzyjne określenie „gotowe” zawyża wskaźnik prędkości.