Decision Log – czyli jak może wyglądać rejestr decyzji technicznych

Temat prowadzenia projektowego rejestru podejmowanych decyzji poruszany był już na naszym blogu w poprzednich postach (chociażby w tym na temat Hype Driven Development).

Czym jest Decision Log?

To rejestr informacji na temat podjętych decyzji, które z punktu widzenia długo falowego prowadzenia projektu są ważne. Zazwyczaj budowany w formie prostej tabeli zawierającej lub/i osobnych dokumentów zawierających szczegółowe informacje. Przydatny szczególnie gdy po kilku tygodniach czy miesiącach musimy odpowiedzieć sobie dlaczego podjęliśmy taką, a nie inna decyzję. Pamięć bywa zawodna, a wpis w dokumentacji będzie nam nakreślał kontekst oraz argumenty dlaczego postąpiliśmy w dany sposób.

Decision Log jak i samo podejmowanie decyzji może dotyczyć różnych kontekstów prowadzenia projektu informatycznego (przykładowo):

• Project Manager może decydować o kwestii powiększenia lub pomniejszenia zespołu rozwijającego oprogramowanie,
• Product Owner może zmienić wymagania względem konkretnej funkcji systemu,
• Zespół programistyczny może decydować o zastosowanych rozwiązaniach technicznych (np. dobór bibliotek, architektura aplikacji).

Są to jednak trzy, nieco niezależne od siebie kwestie. Skupię się jednak na kontekście prowadzenia Decision Log na poziomie zespołu programistycznego. Dlatego też przykłady będą dotyczyły aspektów technicznych. Oczywiście wiele z omawianych rzeczy, równie dobrze sprawdzi się w przypadku pozostałych kontekstów. Dodam, że rejestr może być prowadzony niezależnie od wybranej metodyki wytwarzania oprogramowania – będzie równie wartościowym dodatkiem gdy pracujesz w Scrumie, Kanbanie czy w modelu kaskadowym.

Zalety prowadzenia Decision Log

Samo gromadzenie decyzji nie powinno być elementem wymaganym do utrzymania porządku procesu. Aby miało ono sens, warto wiedzieć po co utrzymywać rejestr, tak aby był faktycznie pomocny.

Pracowałem w projekcie który w krótkim czasie bardzo mocno się rozrósł (pod względem ilości zaangażowanych osób), często pojawiały się pytania „dlaczego wybraliście X, a nie Y”. Wyobraź sobie, że za każdym razem musiałem opowiadać całą historię wyboru narzędzi. Gdybyśmy prowadzili rejestr decyzji – mógłbym podesłać link do niego, oszczędzając czas który można było wykorzystać w inny sposób.

Czy to jednak wszystkie zalety? Zdecydowanie nie, ponieważ Decision Log pomaga:

• wrócić do kontekstu w momencie podejmowania decyzji;
• przypomnieć sobie wymagania jakie były wtedy ważne;
• w weryfikacji argumentów popierających konkretną decyzję;
• osobom które były nieobecne w szybkim odnalezieniu się w podjętych zmianach;
• utrzymywać jeden punkt gromadzenia wiedzy, nie ma potrzeby przeszukiwania archiwum komunikatora czy skrzynki pocztowej.

Wady? To kolejny element dokumentacji wymagający pielęgnacji. Duża część grona programistycznego nie lubi pisać dokumentacji związanej z projektem (nawet tej stricte technicznej). Ja staram się ograniczać do niezbędnego minimum to co powinno być dokumentowane i właśnie w to minimum wpisuje się Decision Log. Ważne aby w jasny i konkretny sposób wskazać faktyczną wartość takiej dokumentacji.

Warto podkreślić, że rejestr decyzji nie może służy jako narzędzie do „wyciągania” brudów z przeszłości – po to aby wyciągać konsekwencje. Wszelkiego rodzaju karanie czy nagany doprowadzą do niechęci prowadzenia rejestru, a co gorsza, do podejmowania decyzji w zespole.

Kiedy należy zanotować podjętą decyzję w Decision Log?

Codziennie programista podejmuje kilkanaście, kilkadziesiąt, a może nawet kilkaset decyzji (!). W sposób bardziej lub mniej świadomy. Część z nich jest odruchowa, spowodowana jakimś doświadczeniem z przeszłości lub konsekwencją znajomości dobrych praktyk. Jednak czy wszystkie takie decyzje powinny zostać odnotowane w rejestrze? Odpowiedź jest prosta – NIE.

Warto natomiast zapisywać decyzje dotyczące:

• wykorzystania narzędzi mających znaczący wpływ na tworzone oprogramowanie – baza danych, framework, środowisko uruchomieniowe, wykorzystywane protokoły komunikacji pomiędzy aplikacjami,
• tematów często dyskutowanych – nazewnictwa zmiennych, metod, struktury testów automatycznych,
• elementów które mogą być niezrozumiałe – skomplikowany proces przetwarzania danych lub ich ekstrakcji,
• szeroko pojętych zmian, wpływających na długofalowy projekt – zmiana procesu budowania aplikacji, pipeline procesu,
• rozważań pomiędzy rozwiązaniami realizującymi nasze założenia – wybór jednego rozwiązania z dwóch i więcej możliwych,
• wpływu na pracę innych zespołów – forma przeprowadzania Code Review czy zapewniania Continous Integration,
• konsensusu w różnicy oczekiwanych rezultatów – zespół X oczekuje, że zespół Y będzie przesyłać dane jako XML, natomiast zespół Y może zapewnić przesyłanie danych w formacie JSON.

Oczywiście powyższa lista nie jest zamknięta, obrazuje jednak jaka forma decyzji warta jest odnotowania.

Gdzie prowadzić Decision Log?

Najlepiej w miejscu gdzie gromadzona jest wiedza na temat projektu czyli np. dodatkowa przestrzeń w dokumentacji projektowej (np. w Confluence, GitHub Wikis itp.). Tak aby nie rozpraszać informacji dotyczących projektu po kilku miejscach. Centralizacja takich danych jest równie ważna co ich utrzymanie z aktualnym stanem rzeczy.

Kto powinien być odpowiedzialny za Decision Log?

Każda osoba w zespole powinna czuć się odpowiedzialna za zapisywanie podjętych decyzji. Można zastosować prostą zasadę:

inicjator decyzji = skryba

Czyli każdy kto wychodzi z inicjatywą podjęcia decyzji, odpowiada za jej udokumentowanie. Podczas przeglądu sprintu można weryfikować czy dostarczone zadania nie wymagały czasem podjęcia na tyle ważnej decyzji, że należało ją umieścić w rejestrze.

Jak może wyglądać Decision Log?

Forma przechowywania informacji na temat decyzji powinna być dopasowana do Twoich oczekiwań. Poniżej umieszczam listę elementów z których może składać się wpis w rejestrze. To forma od której można zacząć budowanie swojego Decision Log:

Status – na jakim etapie jest podejmowana decyzja (np. In Progress, Done)

Tytuł – Jednozdaniowy opis podejmowanej decyzji.

Data – Kiedy została podjęta decyzja.

Założenia:

• Opis problemu – kilkuzdaniowy (lub w formie podpunktów) opis problemu który rozwiązujemy.
• Definicja oczekiwań – czyli to na co należy zwrócić uwagę podczas podejmowania decyzji np. oczekiwania względem klasy rozwiązania (Open Source, Enterprise itp.).

Decyzja:

• Opis – opisanie wyboru, od kiedy obowiązuje.
• Argumenty – przemawiające za wyborem konkretnego rozwiązania.

Identyfikator zadania – Link do zadania w JIRA lub innym Issue Tracker (o ile istnieje, pole nieobowiązkowe)

Kto podejmował decyzje – Tak aby w razie pytań można było dopytać konkretną osobę.

Impakt na inne zespoły – Czy podjęcie decyzji ma wpływ na inne zespoły pracujące nad projektem? Jeśli tak to na które konkretnie.

Podsumowanie

Wprawdzie koleje dokumentowanie pewnych aspektów projektowych może wydawać się czasochłonne. Jednak ile decyzji wartych umieszczenia w Decision Log pojawia się w ciągu tygodnia? Parę, może kilka gdy dopiero rozpoczynamy pracę nad nowym projektem. Czy kilka minut na zanotowanie najważniejszych aspektów jest stratą czasu?

Unikajcie pochopnych decyzji, abyście na pytanie „Dlaczego wybraliście bazę danych X” nie musieli odpowiadać „Eeee… Bo ktoś za bardzo wkręcił się w Hype Driven Development” 🙂

Jakie jest wasze zdanie? Utrzymujecie rejestr decyzji w swoich projektach? A może zamierzacie go wprowadzić po niniejszej lekturze? Zapraszam do podzielenia się opiniami w komentarzu.