wtorek, 1 maja 2007

"Zwinna" dokumentacja

Niejednokrotnie gdy rozmawiałem na temat metod zwinnych zarządzania projektami IT pojawiały się sugestie, że metody te to "wolna amerykanka" nie do zastosowania w "poważnych" sytuacjach. Jako jeden z głównych powodów podawano dokumentację. Od osób, z którymi rozmawiałem dowiadywałem się najczęściej, że metody zwinne zakładają brak dokumentacji projektu. Nic bardziej błędnego.

Metody zwinne (niektóre, żeby być całkowicie zgodnym z prawdą) zakładają brak zbędnej dokumentacji projektu. Ale żadna nie zakłada zrezygnowania całkowicie z dokumentacji. Wręcz przeciwnie, z tego co zauważyłem projekty realizowane metodami zwinnymi są dużo lepiej udokumentowane niż projekty prowadzone metodami standardowymi. Dlaczego? Hmm, żeby odpowiedzieć w pełni trzeba zacząć od zastanowienia się dlaczego dokumentacja (głównie techniczna wykonawcza) stanowi piętę achillesową wielu projektów w IT. Z mojego doświadczenia i rozmów z projektantami/programistami wynika, że wytłumaczenie braku dokumentacji lub jej szczątkowości jest następujące:
  1. Bo nam się nie chciało, co można rozbić na:
    1. Bo to jest za trudne
    2. Bo nie wiem po co to pisać
  2. Bo nie było czasu
Zastanówmy się nad przyczynami źródłowymi tych tłumaczeń i jak one wyglądają z punktu widzenia metod zwinnych.

1.1 Bo to jest za trudne. Trudne? Jakim cudem dla programisty, który pisze kod może być trudne pisanie dokumentacji do tego, co sam stworzył? To by przecież oznaczało, że nie wie co pisał??? No cóż, nie zawsze. Przyczyna może być bowiem również taka, że dokumentacja jest pisana dużo później niż sam kod. To dość częsty przypadek, kiedy kierownik projektu najpierw naciska na jak najszybsze skończenie pracy programistycznej a potem, po 6 miesiącach, kiedy software poszedł właśnie do testów i programiści nie za bardzo mają co robić rzucane jest hasło "to teraz dokumentujemy nasz kod". Faktycznie, pisanie dokumentacji do kodu pisanego 6 miesięcy wcześniej i wielokrotnie później przerabianego jest trudne. Jeżeli nie niemożliwe. W przypadku metod zwinnych kierownik projektu jest ograniczony jedną iteracją, czyli maksymalnie ośmioma tygodniami, w większości przypadków czterema. To oznacza, że programista nigdy nie będzie komentował kodu starszego niż średnio 4 tygodnie. Oczywiste jest, że będzie to dużo łatwiejsze. A w połączeniu z następnym punktem stanie się wręcz niezbędne.

1.2 Bo nie wiem po co to pisać. Duży uśmiech :-) W większości przypadków i projektów zarządzanych standardowo faktycznie programiści nie wiedzieli po co ta dokumentacja. Odgórne zarządzenie "teraz piszemy dokumentację techniczną" przychodziło zwykle w momencie kiedy system był już skończony. Co więcej przy założeniu, że to system pod konkretnego klienta i konkretne wymagania po co w takim momencie pisać dokumentację, skoro robota jest skończona? Z punktu widzenia programisty strata czasu. W przypadku metod zwinnych sprawa staje na głowie. Po pierwsze średnio co 4 tygodnie ma się ukazać gotowa wersja systemu. Łącznie z dokumentacją. Co już stanowi motywację do jej pisania. Jeszcze lepszą motywacją jest to, że w metodach zwinnych programista nie wie, co będzie realizował w kolejnej i następnych iteracjach. Skutkiem czego nigdy nie jest pewny kiedy będzie musiał wrócić do fragmentu kodu, który właśnie skończył pisać. To powoduje, że sam programista ma wielką motywację do pisania dokumentacji, dlatego że robiąc to robi dobrze sobie a nie kierownikowi czy komukolwiek innemu. Doświadczenie wskazuje, że najlepiej aby każdy z programistów na własnej skórze zobaczył co to znaczy pracować w n-tej iteracji na nieopisanym kawałku kodu stworzonym w iteracji n-3. Trochę kosztowny sposób nauki, ale skuteczność jest rewelacyjna. Po jednym takim przypadku nigdy nie będzie więcej problemów aby ten konkretny człowiek opisał to co robi.

2. Bo nie było czasu. Tu sprawa jest najbardziej skomplikowana. Co to znaczy, że nie było czasu? Projekt był źle oszacowany. Albo źle oszacowano czas trwania zadań i dokumentacja jako najmniej ważny element została pominięta w celu terminowego skończenia funkcjonalności (co ciekawe mówią tak te same osoby, które zarzucają zwinnym metodom, że są złe bo nie ma dokumentacji). Albo sytuacja jest jeszcze gorsza i w ogóle nie wzięto pod uwagę czasu potrzebnego na wykonanie dokumentacji technicznej. Metody zwinne w prosty sposób nie pomogą, ale zwykle pomagają nie-wprost. Po pierwsze są krótkie iteracje z rozbiciem na zadania. W związku z tym łatwiej jest pokazać czas przeznaczony na pisanie dokumentacji i nikt zwykle nie ma wątpliwości, że to tam powinno się znaleźć. Łatwiej jest bowiem dodawać po 2 dni na aktualizację dokumentacji do każdej z 10 iteracji, każda trwająca po 4 tygodnie niż z 10-cio miesięcznego projektu jeden miesiąc roboczy (20 dni) przeznaczyć na dokumentację. Po drugie natomiast i ważniejsze z powodów opisanych w poprzednim akapicie sami programiści, czyli osoby wykonujące zadania będą miały dużą motywację do pisania dokumentacji i sami nie pozwolą kierownikowi zapomnieć o tym aspekcie. Oczywiście działając z bardzo niskich pobudek, bo dla ułatwienia sobie pracy, ale czy to ważne?

Podsumowując metody zwinne systemowo ułatwiają pisanie dokumentacji. Nie wymuszają, ale ułatwiają. I tak za stan dokumentacji na koniec projektu odpowiada kierownik. Bez jego zdecydowanych działań, ustalenia z zespołem jasnych reguł i ich późniejszego egzekwowania rezultaty będą dużo poniżej oczekiwań. Moje doświadczenie wskazuje, że projekty realizowane zgodnie z metodami zwinnymi były najlepiej udokumentowanymi jakie widziałem. Do tego stopnia, że ostatnio jak przekazywaliśmy do innego zespołu pewien projekt (niezbyt duży, jakieś 4000 roboczogodzin) razem z dokumentacją zrealizowany czystym SCRUMem okazało się, że w okresie wsparcia (2 miesiące) nie dostaliśmy ani jednego pytania dotyczącego kodu czy też spraw wykonawczych.


PS. Cały czas w tym wpisie mowa była o tzw. technicznej dokumentacji wykonawczej i zdecydowanie uwagi powyższe nie dotyczyły np. dokumentacji użytkownika.

1 komentarz:

Kuba pisze...

Ha! Cześć, wtrącę słowo. Dokumentacja "wykonawcza" kodu jest zbędna, a zwłaszcza jej przygotowanie, jest zbędne. Całą taką dokumentację można generować automatycznie/automagicznie do dowolnego formatu. Skoro ja u siebie, na projektach realizownaych pod maską "tradycyjności" mogę to wdrożyć to na projektach "zwinnych" wspierających innowację zorganizowanie tego powinno być jeszcze łatwiejsze.