Fabryka Wyobraźcie sobie fabrykę produkującą zaawansowany technicznie produkt, niech będzie to smartphone. Konkretny model którego cechy, poprzedzone badaniami rynku i zapewne godzinami dyskusji na najwyższych szczeblach kierownictwa, czy w tym sezonie bardziej modne będą aparaty na wyspie czy nie, są skrupulatnie projektowane. Linia produkcyjna fabryki zostaje dostosowana do nowego modelu, a wszystkie pod komponenty składające się na cały łańcuch dostaw dograne co do ostatniego tranzystora. Wyobraźcie sobie dalej, że egzemplarze nowego modelu przechodzą płynnie na linii produkcyjnej od jednej maszyny do drugiej. Jednak na ostatnim etapie pakowania gotowego urządzenia do pudełek (oczywiście bez ładowarki) coś nie gra. Maszyny nie pracują, nie ma nikogo z pracowników fabryki, co więcej nikt w całej fabryce nie zauważa, że coś jest nie tak. Nikt nie zauważa, że coś jest nie w porządku do momentu gdy sklepy, już przygotowane na premierę nowego modelu, zaczynają upominać się o dostawy…. Do premiery nie dochodzi w zaplanowanym czasie, model jest opóźniony w stosunku do konkurencji która to zdążyła już wyprzedzić rzeczoną firmę we wprowadzeniu na rynek telefonów z wyspą na aparaty, tak modnej w tym sezonie. Straty idą w miliony. Historia oczywiście zupełnie nie realna i celowo przejaskrawiona. Chciałbym jednak zadać pytanie ile czasu dana funkcjonalność może przeleżeć na danym etapie naszego procesu np. na środowisku testowym lub akceptacyjnym zanim faktycznie trafi do użytkowników i nie będzie za późno? Czas Cyklu Pewnie nie ma jednoznacznej odpowiedzi na tak zdefiniowane pytanie. Niepokój powinno jednak wzbudzić spostrzeżenie, że coraz większa liczba teoretycznie ukończonych elementów backlogu spoczywa gdzieś na środowisku testowym bądź akceptacyjnym, zwiększając tzw. Czas Cyklu (ang. Cycle Time) i czekając aż ktoś się o nie upomni… Co więc jest nie tak? Odpowiedź oczywiście znajdziecie w tytule. W pierwszej kolejności należy spojrzeć w stronę Definicji ukończenia (ang. Definition of Done). I zadać sobie kilka pytań. Po pierwsze czy mamy ją w ogóle zdefiniowaną w zespole? Jeśli tak to czy wszyscy, np. nowi członkowie zespołu, są jej w pełni świadomi? Czy faktycznie przestrzegamy reguł w niej zdefiniowanych? No i wreszcie, czy jest ona aby na pewno poprawna? W tym krótkim artykule, chciałbym skupić się na poszukaniu odpowiedzi na ostatnie pytanie, a dokładanie na pytanie czy przez przypadek nie jesteśmy taką przytoczoną na wstępie fabryką która wytwarza niesamowitą wartość ale nie potrafi jej dostarczyć na półkę sklepową? Chciałbym podzielić się z Wami pewnymi konkretnymi przemyśleniami i wskazówkami w tym obszarze na bazie, zebranych wspólnie z zespołem, doświadczeń. W naszym konkretnym przypadku definicja zakładała, że ukończenie oznacza umieszczenie zadania na środowisku testowym wraz z akceptacją testera. Taka definicja ukończenia, była stosunkowo łatwa do spełnienia przez zespół developerski gdyż nie wymagała koordynacji wydań na środowiska akceptacyjne i produkcyjne. Innymi słowy, była to bardzo wygodna definicja. Ale jaki sens ma porzucenie produktu, a mówiąc w języku Scrum przyrostu, w samym środku procesu? W czym tak naprawdę mieliśmy problem? Zadaliśmy sobie takie pytanie na jednej z retrospektyw. I doszliśmy do kilku przedstawionych niżej wniosków. Koordynacja wydania na środowisko akceptacyjne jest o tyle trudna, że wymaga ustalenia jakie zadania są już dołączone do głównej gałęzi służącej jako źródło kodu na to środowisko, a następnie upewnieniu się, że funkcjonalności te stanowią integralną całość czy też mówiąc inaczej daną wersję. Dość często więc pojedyncze zadanie umieszczone na środowisku testowym i akceptacji testera, tym samym spełniające ówczesną Definicje Ukończenia, praktycznie przestawało istnieć w świadomości zespołu developerskiego, powodując zastoje jeszcze przed wydaniem na środowisko akceptacyjne. Druga przyczyna tak skromnie zdefiniowanej Definicji Ukończenia wynikała z faktu, że w naszym przypadku, znaczna część funkcjonalności jest dodatkowo weryfikowana na środowisku akceptacyjnym przez interesariuszy spoza zespołu Scrum. Skutkuje to tym, że nie mamy do końca wpływu na to kiedy dana funkcjonalność przejdzie testy akceptacyjne umożliwiając promocje na środowisko produkcyjne. I w zasadzie, można powiedzieć, że wszystko w porządku, jak nie mamy na coś wpływu to nie umieszczamy w Definicji Ukończenia. Ale czy aby na pewno nie mamy wpływu? Takie pytanie zadaliśmy sobie na retrospekcji i postanowiliśmy spróbować to zmienić. Od czego zacząć? Zaczęliśmy oczywiście od, niejako formalnej, zmiany naszej Definicji Ukończenia oraz sprawienia aby ta zmiana faktycznie zaistniała. Domyślacie się, że jak wszystko w Scrum, o ile pierwsza część jest prosta o tyle druga, wymaga trochę więcej wysiłku… Nasza Definicja ukończenia, po wprowadzonych zmianach, wygląda tak:
Spełnione kryteria akceptacyjne
Zielone testy jednostkowe
Przejście Code Review z wynikiem pozytywnym
Release na środowisko developerskie
Weryfikacja przez developera
Akceptacja UX i Testera
Release na środowisko akceptacyjne
Smoke testy
Akceptacja Product Owner'a lub klienta
Definicja Ukończenia definicją, można ją powiesić na ścianie w biurze (jak akurat nie ma na świcie pandemii i permanentnego HO), ale co tak naprawdę zmieniliśmy w naszym przypadku? Jak wspomniałem w pierwszej części, byliśmy świadomi dwóch problemów:
Koordynacji wydań na środowisko akceptacyjne
Przeciągającej się weryfikacji przez interesariuszy na środowisku akceptacyjnym
Koordynacja wydania na środowisko akceptacyjne W naszym przypadku okazało się, że głównym problemem koordynacji wydania na środowisko akceptacyjne jest brak jasnego zobrazowania czy dany element backlogu, po przetestowaniu przez testera jest już dołączony do głównej gałęzi, stanowiącej źródło kodu na środowisko akceptacyjne i później produkcyjne, czy nie. Niby prosta rzecz, łatwa do sprawdzenia, jednakże przy dziesiątkach elementów backlogu trudno nad tym zapanować. Na retrospektywie ustaliliśmy więc, że developer powinien oznaczyć, w naszym przypadku specjalną flagą w backlogu, element który został już dołączony do głównej gałęzi kodu. Tym samym zyskaliśmy cenną informacje, przez proste zobrazowanie na dashboardzie, że dany element znajdujący się ciągle na środowisku developerskim bądź testowym jest już gotowy do promocji na wyższe środowisko. Czytelność, osiągnięta poprzez uwidocznienie które elementy są gotowe do promocji na środowisko akceptacyjne, pozwala łatwo wyłapać ewentualne braki dla danej wersji produktu i zdecydowanie ułatwia zaplanowanie kolejnego wydania. Weryfikacja przez interesariuszy Zgodziliśmy się również, że naszym wspólnym obowiązkiem jako zespołu Scrum, równie ważnym jak napisanie samego kodu, jest dopilnowanie aby rzeczy były terminowo testowane na środowisku akceptacyjnym przez należyte osoby. Nie jest to coś w 100% zależne od nas, jak wspominałem wcześniej testy akceptacyjne wykonują często, w naszym przypadku, osoby spoza zespołu Scrum. Jednakże jeśli obowiązek ich informowania, przypominania czy mówiąc ogólnie komunikacji z takimi osobami przypada tylko na jedną osobę w zespole np. Scrum Mastera czy Product Ownera, należy zadać sobie pytanie czy to jest w porządku, czy nie stanowi to przez przypadek wąskiego gardła całego procesu? Warto więc zapytać, np. na retrospektywie, czy wszyscy w zespole znają interesariuszy wykonujących testy akceptacyjne, potrafią się z nimi skontaktować i czy wreszcie nie odczuwają jakiegoś rodzaju strachu przed bezpośrednim kontaktem z nimi (wiem śmieszne, ale podejrzewam, że często prawdziwe). Dojrzałość zespołu Definicja Ukończenia zależy oczywiście w dużym stopniu od dojrzałości samego zespołu jak i specyfiki danego produktu. Zachęcam jednak aby, wraz ze wzrostem wspomnianej dojrzałości, cyklicznie rewidować tą definicje i dążyć do tego aby Ukończenie w Twoim zespole oznaczało umieszczenie produktu na przysłowiowej półce sklepowej.