Definicja Ukończenia: Prosta, a jednak złożona

Definition of Done (DoD) jest ważnym narzędziem agile, które pomaga zespołom planować i wykonywać pracę. W zasadzie Definition of Done to tylko zestaw kryteriów, które produkt musi spełniać, aby zostać uznany za gotowy. Choć jednak koncepcja jest tak prosta, wdrożenie jej w rzeczywistości nie jest tak łatwe. Kontekst i możliwości interpretacji tworzą bowiem szarą strefę.

Kontekst i kryteria akceptacji

Pierwsza warstwa złożoności polega na tym, że Definition of Done musi być zawsze postrzegana w kontekście środowiska, co odnosi się do technicznej i funkcjonalnej kompletności oraz akceptacji przez Product Ownera. Fakt, że Product Owner akceptuje produkt, jest reprezentatywny dla wartości produktu. Kryteria akceptacji – bez względu na to, jak się je nazywa – odzwierciedlają, czy kod może rozwiązać określony problem biznesowy, zdefiniowany przez User Story lub wymaganie. Kryteria akceptacji mają potwierdzić, że Story naprawdę robi to, do czego była przeznaczona, i mogą być wykorzystane do tworzenia testów akceptacyjnych.

Formalnie rzecz biorąc, Definition of Done jest często odzwierciedleniem technicznych i procesowych standardów organizacji. Na przykład organizacje często mają standardy dotyczące pisania kodu i testów jednostkowych, a zatem Definition of Done może zawierać wymagania dotyczące struktury kodu, dokumentacji i testowania. Może również zawierać komponenty związane z funkcjonalnością. Funkcjonalność jest jednak zasadniczo zawarta w Definition przez kryteria akceptacji itp. W niektórych przypadkach widziałem już stwierdzenia w Definition of Done, które wskazują, że kryteria akceptacji muszą być spełnione. Po przezwyciężeniu podwójnej bariery Definition of Done i kryteriów akceptacji, Product Owner musi dokonać oceny dostarczonej wartości rozwiązania. Następnie następuje ostateczna ocena, w której akceptuje lub odrzuca rozwiązanie. Wynik tego procesu opisywany jest również jako done-done lub nawet done-done-done.

Bariery i ważne pytania przy DoD

Aby solidnie wdrożyć koncepcję „Done", trzeba pokonać trzy bariery: kryteria Definition of Done, kryteria akceptacji (jako część User Story) oraz akceptację przez Product Ownera. Obejmuje to również rozważenie kilku pytań, które nieco utrudniają skądinąd stosunkowo prosty proces. Należą do nich:

1. Kto decyduje, co oznacza Done?
   W wielu organizacjach kryteria Done są często pozostawiane poszczególnym zespołom. Dzieje się to zazwyczaj w granicach technicznych i procesowych standardów zdefiniowanych przez organizację. Kilka lat temu zostałem na przykład zapytany przez zespół deweloperski z rygorystycznymi standardami kodowania i testów jednostkowych, czy mogliby pominąć wymagania dotyczące testów jednostkowych dla swojego kodu. Testy jednostkowe były kryterium w ich Definition of Done. Ich uzasadnienie było takie, że testerzy później w procesie odkryją, czy to działa, i że Product Owner nie lubi testów programistów. Jednak zespół musiał przestrzegać standardów narzuconych przez organizację i pomijanie wymagań dotyczących testów jednostkowych nie podlegało dyskusji.

2. Czy dopuszczalne jest niespełnienie kryteriów w pełni?
   Każdy zespół, z którym kiedykolwiek pracowałem, wcześniej czy później zadawał sobie pytanie, czy byłoby w porządku interpretować Definition of Done inaczej i ją obejść. Często odpowiedź brzmi „Tak". Oznacza to jednak zazwyczaj dyskusję o szarej strefie, akceptowaniu długu technicznego i o tym, kiedy ten dług ma zostać spłacony.

3. Czy potrzeby organizacji mogą być ważniejsze niż potrzeby Product Ownera?
   To jest alter ego poprzedniego pytania. Każdy w zespole, łącznie z Product Ownerem, musi wiedzieć, kiedy i gdzie standardy i/lub potrzeby organizacji są ważniejsze niż akceptacja przez Product Ownera. Presja dostarczenia może skłaniać zespoły i Product Ownerów do przyspieszania kodu, aby go później poprawiać w kolejnych Sprintach, co doprowadza standardy i architekturę do granic. Większość bardziej dojrzałych organizacji wyznacza jasne granice, tak aby każdy wiedział, kiedy należy respektować potrzeby i standardy organizacji.

Podsumowanie Definition of Done (DoD)

Wszystkie definicje słowa „Done" zawierają pewien stopień ostateczności i kompletności. W wytwarzaniu, ulepszaniu i utrzymaniu oprogramowania koncepcja Done może być bardzo wielowarstwowa. Każda z tych warstw może mieć własne niuanse techniczne, funkcjonalne i wartościowe. Zespoły szybko się uczą, że praca musi być naprawdę done, done i done, aby być naprawdę skończoną.

Niniejszy tekst pochodzi z bloga SPaMCAST i został przez nas przetłumaczony na język polski.