Szablony definicji realizacji projektu

Czym jest szablon Definicji ukończenia (DoD)?

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

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

DoD jest tylko tak dobry, jak dyscyplina zespołu. Zanim sfinalizujesz swój szablon, zastosuj te trzy eksperckie "kontrole stanu":

1. Audyt "Niedokończonej pracy"

Audyt: Czy przenosisz historyjki do "Zrobione", odkładając dokumentację lub testy integracyjne na "następny sprint"? Naprawa: Audytuj pod kątem odroczonej jakości. Profesjonalny DoD musi zawierać testy regresyjne i aktualizację dokumentacji. Jeśli nie jest udokumentowane i przetestowane w całym systemie, nie jest "Zrobione"; to tylko "Zaimplementowane". Twój szablon powinien wyraźnie wymieniać "Brak nowego długu technicznego" jako wymóg.

2. Test "Zautomatyzowanej prawdy"

Audyt: Czy Twoja DoD opiera się na "ludzkich obietnicach" (np. "Sprawdziłem kod")? Rozwiązanie: Przeprowadź audyt pod kątem Weryfikacji binarnej. Kiedy to możliwe, zastąp ręczne kontrole automatycznymi. Zamiast "Kod jest przeglądany," użyj "Pull Request zatwierdzony przez 2 osoby." Zamiast "Przetestowano jednostkowo," użyj "Pokrycie testów jednostkowych > 80%." To eliminuje subiektywność i zapewnia, że stan "Done" jest mierzalny i niepodważalny.

3. Konflikt "Globalny vs Lokalny"

Audyt: Czy DoD jest tak rozbudowana, że zespół ignoruje połowę, żeby osiągnąć cel sprintu? Rozwiązanie: Przeprowadź audyt pod kątem realności. Zacznij od "Minimum Viable DoD" i rozbudowuj ją 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 user story. Przenieś go zamiast tego do "Definition of Release". Dzięki temu codzienne DoD pozostaje osiągalne i przestrzegane.

Ramy strategiczne: trzy poziomy "Done"

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

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

  • Zakres: Jakość kodu, przegląd zespołowy i spełnienie konkretnych kryteriów akceptacji.

  • Przykład: "Testy jednostkowe przeszły", "zatwierdzone przez PO", "Testy funkcjonalne przeszły".

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

  • Zakres: Jak funkcja współdziała z resztą aplikacji.

  • Przykład: "Brak błędów regresyjnych", "Wskaźniki wydajności stabilne", "Środowisko staging zaktualizowane".

• Poziom 3: DoD wydania (poziom rynkowy)

  • Zakres: Zgodność prawna, marketingowa i bezpieczeństwa.

  • Przykład: "Test penetracyjny bezpieczeństwa przeszedł", "Tłumaczenie ukończone", "Instrukcja użytkownika zaktualizowana".

Kluczowe elementy szablonu Definition of Done

Aby DoD działał efektywnie, musi obejmować te pięć głównych kategorii:

• Standardy programistyczne: Kod jest skomentowany, zrefaktoryzowany i zatwierdzony do głównej gałęzi.

• Testowanie i jakość: Testy jednostkowe, integracyjne i ręczne testy typu „smoke” są ukończone i przechodzą pomyślnie.

• Środowisko i DevOps: Kod jest wdrożony do środowiska stagingowego i przechodzi potok budowania.

• Przegląd i akceptacja: Przegląd przez współpracowników jest zakończony, a właściciel produktu (PO) zatwierdził(a) funkcjonalność.

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