Do przeczytania kolejny artykuł z serii Agile Zrób To Sam. Tak jak poprzednio publikuje treść artykułu mojego autorstwa zamieszczonego w najnowszym numerze kwartalnika Quale. Zapraszam do lektury i pozostawiania komentarzy….
Kiedy możesz być pewny, że praca nad wymaganiami, którą wykonuje zespół developerski, została skończona bądź jest na etapie pozwalającym uznać ją za zamkniętą?
Każdy członek zespołu jest inny i zapewne kieruje się odmiennymi kryteriami w kontekście ukończenia pracy. Jeden developer może pominąć kwestię, która dla drugiego będzie kluczowa. Wobec powyższego widać wyraźnie, że bez ogólnodostępnej, jasnej i przede wszystkim wspólnie stworzonej definicji ukończenia pracy każda funkcjonalność staje się zagrożona i niewykluczone, że nie zostanie dostarczona na koniec trwania iteracji. W takim przypadku konsekwencje mogą być poważne, np. nie otrzymamy od klienta części zakontraktowanej płatności.
Idea kryjąca się pod pojęciem listy DoD umożliwia wspólne zrozumienie terminu Done (pol. zrobione, ukończone). Definicja ukończenia dostarcza zespołowi niezbędnych informacji, swoistej referencji służącej efektywnej pracy, a co za tym idzie, pozwala na właściwą synchronizację informacji podczas codziennych spotkań. Informacja o statusie ukończonego elementu Rejestru Produktu zawsze niesie za sobą ten sam przekaz. Jak widać na poniższej ilustracji (rys.1), element zakresu, który spełnił definicję ukończenia, oczekuje tylko na przegląd sprintu.

Poziomy DoD

W zależności od chęci, możliwości i dojrzałości zespołu można definiować ukończenie na wielu poziomach. W artykule skupię się na dwóch najpopularniejszych, choć osobiście uważam, że najważniejsza jest definicja ukończenia dla wydania, ponieważ wówczas nowy inkrement produktu trafia w ręce klienta i/lub użytkownika końcowego. Należą do nich: pojedyńczy element Rejestru Produktu (user story) oraz wydanie
Przykład DoD dla pojedynczego elementu Rejestru Produktu:
– Wszystkie kryteria akceptacji zostały spełnione
– Kod jest przejrzysty, odpowiednio sformatowany, napisany zgodnie ze standardami programowania.
– Kod przetestowany jednostkowo.
– Kod poddano analizie statycznej.- Nowo utworzony kod przejrzała doświadczona osoba niebędąca jego autorem.-  Funkcjonalność przetestowana systemowo i eksploracyjnie.- Narzędzie Continuous Integration nie zwraca błędów integracji.
Przykład DoD dla wydania produktu:
– Przygotowano prezentację nowych funkcjonalności dla interesariuszy projektu.
– Kod przeszedł pomyślnie testy regresji (manualne i automatyczne).
– Kod zapisano w postaci taga i brancha w repozytorium kodu SVN.
– Przygotowano informacje o wydaniu, np. główne zmiany funkcjonalne.- Dług techniczny nie został powiększony.- Uzupełniono i zaktualizowano dokumentację funkcjonalną oraz techniczną.- Kod jest potencjalnie wdrażalny na produkcję.
Jak widać część elementów listy DoD dla pojedynczego elementu może być wykorzystana z powodzeniem całościowo dla wydania produktu.

Czy lista może się zmieniać??

Definicja ukończenia nie jest statyczną listą tworzoną jednorazowo na początku trwania projektu. Ewoluuje z czasem wraz ze wzrostem umiejętności zespołu i wydajnością organizacji. Podczas trwania iteracji naturalnym momentem, aby dokonać przeglądu aktualnego zakresu listy i przedyskutować ewentualne poprawki, jest retrospektywa.
Należy przy tym podkreślić, że nie można ingerować w treść definicji w trakcie trwania sprintu.

Czy reguły DoD różnią się pomiędzy zespołami?

Oczywiście tak, jeśli organizacja nie ustali własnego minimalnego zestawu reguł, definicja reguł DoD zależy od produktu i formułuje ją zespół. Gdy powstaje ona „od zera”, zazwyczaj początkowo zawiera kilka najistotniejszych punktów, a następnie – nie częściej niż na koniec każdej iteracji – team stopniowo powinien ją ulepszać. Zespół budując definicję ukończenia od zera, zazwyczaj zaczyna od bardzo prostej definicji kilku najważniejszych punktów, aby później nie częściej niż na koniec każdej iteracji ją ulepszać. Bardzo istotne jest, aby ustalone reguły były zawsze ogólnodostępne i – co niezwykle ważne – właściwie rozumiane przez cały zespół. Nikt nie może mieć wątpliwości, co i jak powinien zrobić. Ta zasada jest silnie powiązana z jednym z trzech filarów framework Scrum, a mianowicie przejrzystością.

Kilka zespołów pracujących nad jednym produktem

Jeżeli produkt jest złożony i pracuje nad nim wiele zespołów, z praktyki wiem, że często zespoły są dystrybuowane geograficznie, wszystkie teamy muszą koniecznie ustalić wspólną definicję ukończenia, która będzie zapewniała minimalny akceptowalny poziom jakości zintegrowanego rozwiązania.
Oczywiście nic nie stoi później na przeszkodzie, aby poszczególne ekipy stworzyły własne, bardziej wysublimowane DoD dla dostarczanych modułów, komponentów systemu.

Podsumowanie

Odpowiedzmy sobie, zatem na stwierdzenie, dlaczego DoD można traktować, jako bramkę jakości we frameworku Scrum? Otóż utworzenie dedykowanej, dopasowanej do realnych możliwości zespołu i akceptowalnej jakości produktu listy DoD, jest wysoce rekomendowanym rozwiązaniem podczas implementacji dowolnych produktów w podejściu Scrum. To standard, bez którego implementacja zostaje obarczona dużym ryzykiem niepowodzenia. Pierwsza definicja ukończenia jest swoistą bramką jakości, niezmiennym standardem wykonania dla pojedynczych funkcjonalności ale przede wszystkim przyrostu produktu jako całości.
Ponadto wskazuje developerom rzeczy ważne w procesie wytwórczym, a stara się eliminować straty. Chcemy, aby nasz zespół oraz ich proces wytwórczy był z iteracji na iterację maksymalnie wydajny, aby zawsze niósł za sobą wartość i zakładany poziom jakości. Nie chcemy pozostawiać tego przypadkowi. Możemy to osiągnąć wyłącznie poprzez współpracę pomiędzy zespołem developerskim a właścicielem produktu głównie w ramach definicji ukończenia i zrozumienia konkretnych praktyk w niej zawartych, które z czasem powinny być ulepszane i wzmacniane. 
Wówczas członkowie teamu nie będą błądzić, marnotrawiąc cenny czas na tzw. gold platting, czyli próbę ulepszania czegoś, co już jest wystarczająco dobre i mogło być dostarczone bez przekraczania estymacji. Nie popełniajcie tego błędu i jeśli jeszcze nie dysponujecie własną listą, opracujcie ją uwzględniając możliwości swoich zespołów, a następnie zacznijcie ją ulepszać.