DoDa kontra HLAC 

Oto kolejny z wpisów, który porusza najczęściej poruszane problemy w tworzeniu zwinnego środowiska w organizacjach. Tytuł brzmi enigmatycznie?  Jestem pewny, że Ci którzy potocznie mówiąc „siedzą” w zwinnych metodykach z łatwością go rozszyfrują. DoDa kontra HLAC – gdzie zastosujemy jedno, a gdzie drugie?

Kim jest DoDa? Czym jest HLAC?

Myli się ten, kto przypuszcza, że będę się dziś zajmował definicjami. Po pierwsze, ten blog dawno już opuścił miejsce, w którym ciągle zajmowaliśmy się podstawami. A po drugie, co już niejako wynika z pierwszego, już o tym pisaliśmy. Wystarczy rzut oka na dwa z poprzednich 240 tekstów.

Dla uporządkowania dyskusji, DoDa to oczywiście Definition of Done, inaczej zwana Definicją Ukończenia. HLAC to High Level Acceptance Criteria, czyli wysokopoziomowe kryteria akceptacji. Te ostatnie znajdziemy oczywiście we wszelkiego rodzaju wymaganiach.

Skoro nie o definicjach, to o czym jest ten tekst? Aby wszystko stało się jasne, do zestawu powyższych skrótów dołożę jeszcze jeden – US, czyli User Story. Czas zatem na postawienie właściwego pytania: jak ma się DoDa i HLAC do User Story? To pytanie tylko z pozoru jest oczywiste. Bo czy na pewno rozumiemy te pojęcia we właściwy sposób?

US w kontekście DoD i HLAC

Oba powyższe skróty odnoszą się w pewien sposób do User Story. Kryteria akceptacji są integralną częścią wymagań zapisanych w tym właśnie formacie. Każde User Story bezwzględnie musi zawierać informacje o HLAC dotyczących tego konkretnego kawałka pracy. I może warto to podkreślić – tego i żadnego innego.

Robimy to po to, aby wyznaczyć kierunek realizacji wymagań znajdujących się w naszym backlogu. Bez HLAC-ów sposób implementacji wymagania obarczony jest ryzykiem niezgodności dostarczonego przyrostu z oczekiwaniami klienta. Powiedzmy sobie wprost – nie stać nas na to.

Z DoDą jest dużo prościej. Znajdująca się na poziomie organizacji definiuje kryteria, które wymaganie musi spełniać, aby można było uznać je za ukończone. Oczywiście, DoDzie podlega każde z wymagań, a nie tylko te, które wybierzemy. A weryfikując zgodność z DoDą powinniśmy przeanalizować wszystkie z kryteriów, a nie tylko te, które pasują do analizowanego wymagania.

Z powyższej analizy jasno wynika, na którym z poziomów i czego dotyczyć powinny DoDa i HLAC. Skąd więc tyle pomyłek i błędnych interpretacji?

Najczęściej popełniane błędy

Brak kryteriów akceptacji czy brak definicji ukończenia to wierzchołek góry lodowej. To zbyt oczywiste błędy, aby w tym miejscu o nich pisać.

Kolejnym najczęściej popełnianym błędem jest ujmowanie kryteriów ukończenia jako kryteriów akceptacji wymagania i vice versa. Jako przyczyny tego stanu rzeczy w ciemno można wskazać brak wiedzy co do różnic i zastosowań obu typów kryteriów. A chyba sami musicie przyznać, że po przeczytaniu tego krótkiego tekstu jest to więcej niż jasne i oczywiste.

Do czego prowadzi pomyłka, o której mowa powyżej? Ujęcie elementów DoDy jako kryteriów akceptacji powoduje, że nie tylko rozmywa się kierunek rozwoju naszego produktu, ale elementy związane np. z wymaganiami niefunkcjonalnymi naszego rozwiązania weryfikujemy tylko wyrywkowo (tam, gdzie je dopisaliśmy). Niektóre rzeczy powinny być zawarte na poziomie definicji ukończenia. Chcemy przecież, aby każde wymaganie je spełniało. Czy jest sens powielania ich w kryteriach akceptacji wymagań?

Błędne rozumienie, czym jest HLAC, a czym elementy DoD powoduje również niemożność spełniania DoDy przez de facto skończone elementy. Innym problemem jest stosowanie kryteriów tylko do wybranych inkrementów.  A stąd już tylko krok do zaniechania jaj używania.

DoDa kontra HLAC, czyli kompletne User Story

Patrząc z punktu widzenia User Story kompletne wymaganie powinno zawierać krótką nazwę, opis w wybranym formacie, HLAC i… na poziomie User Story to będzie na tyle. Nie możemy zapomnieć jednak, że na poziomie organizacji czeka na nas jeszcze jedna, istotna lista kryteriów, którą musimy bezwzględnie przyłożyć, żeby powiedzieć „Done”.

Szukając odpowiedzi na pytanie, jaka jest wzajemna relacja DoD kontra HLAC jasno dojdziemy do wniosku, że oba te elementy wzajemnie się uzupełniają. Pierwszy z nich, DoDa, ma za zadanie obniżenie ryzyka przy jednoczesnym podniesieniu jakości dostarczanego rozwiązania. Drugi w jasny sposób wskazuje kierunek implementacji rozwiązania dbając o jego akuratność i zadowolenie interesariuszy.

Celem tego tekstu nie było wyjaśnienie pojęć, a podkreslenie różnic pomiędzy obiema listami kryteriów. Niby takie same, a jednak inne. Obie wyglądają podobnie, a jednak ich weryfikacja odbywa się na zupełnie innym poziomie i powinna dotyczyć zupełnie innych aspektów.