Jednym z problemów, z którym boryka się mój zespół, jest dług technologiczny. System tworzony jest od kilku lat, w między czasie znacząco zmienił się jego zakres (łącznie z docelowym przeznaczeniem), oryginalny skład zespołu … czyli innymi słowy sporo „legacy code’u” i „ciekawej” (czytaj pokręconej) architektury. Gdy poruszyliśmy temat długu technicznego na retrospekcji okazało się, że pierwszym krokiem w celu poprawy sytuacji powinno być w jakiś sposób monitorowanie sytuacji. Tylko jak ? Narzędzia do statycznej analizy kodu (Sonar, checkstyle, fxcop) dają jakiś taki pogląd na jakość kodu ale to nie wystarczy. Nie są w stanie zobrazować sytuacji na poziomie architektury, nie wyłapią „quickfixów” i co bardziej kreatywnych „obejść problemów”.

Wtedy wpadliśmy na pomysł Doomsday clock’u. Jest to koncepcja wymyślona w 1947 roku na Uniwersytecie Chicagowskim. Pomysł jest bardzo prosty: przy pomocy zegara przedstawić jak daleko jesteśmy od totalnej zagłady ludzkości w wyniku wojny nuklearnej. Gdy wybije północ rozpocznie się judgement day. Każde istotne wydarzenie (np. pakt rozbrojeniowy) zapisywane jest w rejestrze zegara, a jego wskazówki przesuwane są do przodu lub do tylu w zależności od tego czy skutki zdarzenia były pozytywne czy negatywne. Więcej o Doomsday clock tutaj: http://pl.wikipedia.org/wiki/Zegar_Zagłady

Pomysł więc był prosty: monitorować dług technologiczny przy pomocy naszej wersji Doomsday clock’a.

   

Dlaczego wybraliście akurat taką formę monitorowania długu technologicznego ?

Bo jest fajna :) Poważnie ! To jest bardzo istotny czynnik. Zespół dużo chętniej robi coś co sprawia mu przyjemność (nawet w odniesieniu do tak nieprzyjemnej rzeczy jak dług technologiczny)

Czy zegar przedstawia „twarde, statystyczne dane” ?

Oczywiście że nie. Zegar bazuje na intuicji zespołu. A intuicja przeważnie ma dużo więcej wspólnego z rzeczywistością niż twarde dane statystyczne :)

Czy pokazujecie zegar swojemu klientowi ?

Tak. Wytłumaczyliśmy koncepcję klientowi i zegar stanowi integralną część raportów prezentowanych Product Owner’owi. Oczywiście nie obyło się bez pytań typu ”a nie dało by się zaprezentować tego  „bardziej konkretnie” np. w postaci Story Pointów ?”

Na którą godzinę ustawić początkową wartość zegara ?

Koncepcja Doomsday clock opiera się na subiektywnej ocenie sytuacji. Nie ma tutaj jednoznacznej odpowiedzi. Im bliżej północy zaczniecie tym bardziej podkreślicie powagę sytuacji.

O ile zmieniać wskazania zegara ?

Tak jak przy odpowiedzi na poprzednie pytanie -  nie ma tutaj konkretnej zasady. Jeśli korzystacie przy estymacjach ze Story Point’ów dość łatwo do tego dojdziecie. Story Point’y określają relatywną wielkość funkcjonalności, zmiany wskazań zegara określają relatywny wpływ zdarzeń podczas sprintu na gromadzenie lub likwidowanie długu technicznego. Dla ułatwienia możecie zrobić sobie przykładowy „cennik” który posłuży wam jako punkt odniesienia.

Co to jest sprint drift ?

Podczas jednej z retrospekcji doszliśmy do wniosku, że w sytuacji, gdy podczas sprintu nie zrobiliśmy nic co wpływa na dług technologiczny (ani nic nie zepsuliśmy, ani też nie naprawiliśmy), tak naprawdę sytuacja się pogarsza. Powód: doszły nowe funkcjonalności, które trzeba utrzymać, a stary zakumulowany dług technologiczny tak jak bomba zegarową… wciąż tyka. Dlatego po zakończeniu tworzenia rejestru zegara na dany sprint dodatkowo przesuwamy wskazówkę zegara o stały interwał do przodu (w stronę północy)

Kiedy aktualizować Doomsday clock ?

Kiedy chcecie, ważne aby uczestniczył w tym wydarzeniu cały zespół. Możecie zrobić to podczas retrospekcji lub na osobnym, krótkim spotkaniu (najwygodniej umieścić je gdzieś między spotkaniami typu retrospekcja, sprint planning)

Oczywiście koncepcję zegara możecie wykorzystać również na inne sposoby. Zespoły które uczestniczą w yourdon’owskim „Marszu ku klęsce” mogą rozszerzyć zegar do wszystkich zdarzeń mających kluczowe znaczenie dla projektu. Wówczas północ oznacza FUBAR (Fucked Up Beyond All Recognition/Repair). Zegar może również posłużyć jako wskaźnik nastroju zespołu lub nawet status prac nad całym projektem (godzina 12 – projekt został ukończony).