Szablony definicji ukończenia

Czym jest szablon Definition of Done (DoD)?

Szablon Definition of Done (DoD) to kompleksowa lista kontrolna kryteriów technicznych i funkcjonalnych, które historyjka użytkownika lub zadanie muszą spełnić, zanim zostaną uznane za "Ukończone". W przeciwieństwie do "kryteriów akceptacji" (które są unikalne dla każdej historyjki), DoD jest globalnym standardem stosowanym do każdej pracy. Zapobiega "długowi technicznemu", zapewniając, że testy, dokumentacja i zgodność nigdy nie są pomijane na rzecz szybkości.

Audyt "Jakości": 3 sposoby na egzekwowanie standardów "gotowych do wydania"

DoD jest tyle warte, ile dyscyplina zespołu. Zanim sfinalizujesz swój szablon, zastosuj te trzy eksperckie "kontrole":

1. Audyt "Niedokończonej pracy"

Audyt: Przenosisz historie do "Done", zostawiając dokumentację lub testy integracyjne na "następny sprint"? Rozwiązanie: Sprawdź pod kątem odroczonej jakości. Profesjonalny DoD musi zawierać testy regresyjne oraz aktualizację dokumentacji. Jeśli coś nie jest udokumentowane i przetestowane w całym systemie, nie jest "Done"; to tylko "Developed". Twój szablon powinien wyraźnie wymieniać "Brak nowego długu technicznego" jako wymóg.

2. Test "Automated Truth"

Audyt: Czy Twój DoD opiera się na "ludzkich obietnicach" (np. "Sprawdziłem kod")? Rozwiązanie: Audytuj pod kątem Weryfikacji binarnej. Kiedy tylko to możliwe, zastąp ręczne kontrole automatycznymi. Zamiast "Code is reviewed," użyj "Pull Request zatwierdzony przez 2 recenzentów." Zamiast "Unit tested," użyj "Pokrycie testów jednostkowych > 80%." To eliminuje subiektywność i sprawia, że stan "Gotowe" jest mierzalny i niepodważalny.

3. Konflikt "Globalne vs. Lokalne"

Audyt: Czy twój DoD jest tak długi, że zespół ignoruje połowę, żeby osiągnąć cel sprintu? Rozwiązanie: Audyt pod kątem realności. Zacznij od "Minimum Viable DoD" i rozbudowuj go w miarę dojrzewania zespołu. Jeśli zespół nie jest w stanie realistycznie przeprowadzać pełnego audytu bezpieczeństwa w każdym sprincie, nie umieszczaj go w DoD na poziomie historyjki. Zamiast tego przenieś go do "Definition of Release". Dzięki temu codzienny DoD pozostaje osiągalny i przestrzegany.

Ramy strategiczne: trzy poziomy "Ukończenia"

Profesjonalna organizacja często używa trzech odrębnych szablonów do zarządzania różnymi etapami ukończenia:

• Poziom 1: DoD dla historyjki użytkownika (poziom sprintu)

  • Skupienie: jakość kodu, przegląd kodu i spełnienie konkretnych kryteriów akceptacji.

  • Przykład: "Testy jednostkowe przeszły pomyślnie," "Zatwierdzone przez PO," "Testy funkcjonalne przeszły pomyślnie."

• Poziom 2: DoD sprintu/funkcji (poziom integracji)

  • Skupienie: jak funkcja współdziała z resztą aplikacji.

  • Przykład: "Brak błędów regresyjnych," "Stabilne wskaźniki wydajności," "Zaktualizowano środowisko testowe."

• Poziom 3: DoD wydania (poziom rynkowy)

  • Skupienie: wymogi prawne, marketingowe i bezpieczeństwa.

  • Przykład: "Test penetracyjny bezpieczeństwa zakończony pomyślnie," "Tłumaczenie ukończone," "Zaktualizowano instrukcję użytkownika."

Kluczowe elementy szablonu DoD

Skuteczny DoD wymaga tych pięciu podstawowych kategorii:

• Standardy tworzenia oprogramowania: Kod jest skomentowany, poddany refaktoryzacji i włączony do głównej gałęzi.

• Testy & Jakość: Testy jednostkowe, integracyjne oraz ręczne testy dymne są ukończone i przechodzą pomyślnie.

• Środowisko & DevOps: Kod jest wdrożony na środowisko staging i pomyślnie przechodzi proces budowania.

• Przegląd & Zatwierdzenie: Przeprowadzono przegląd peer review, a Właściciel produktu (PO) zatwierdził funkcjonalność.

• Wymagania niefunkcjonalne: Funkcja spełnia określone kryteria wydajności, dostępności i bezpieczeństwa.