No dobrze, ale co będzie, gdy te osoby odejdą z pracy? Gdyby była dokumentacja, strata ta nie byłaby tak bolesna.

Jeśli odejdą osoby kluczowe dla projektu, to i tak na dobrą sprawę można zaczynać od początku. Żadna dokumentacja nam tu nie pomoże. Co więcej, poleganie na niej sprawia, że menedżerowie projektów informatycznych przestają dbać o swoich ludzi, wydaje im się, że można ich łatwo wymienić. A to tylko złudzenia.

Generalnie w adaptacyjnym zarządzaniu projektami inna musi być rola menedżera. Większość decyzji - zarówno projektowych, jak i wykonawczych - powinna być przeniesiona na zespół. Kierownik projektu ma nie tyle kierować jego realizacją, ile dbać o to, żeby w zespole "dobrze się działo". Wspólne działanie może odbywać się nawet na granicy chaosu. Pracownicy, którzy czują, że na nich scedowano odpowiedzialność, potrafią się bardzo starać. Chociażby jednym z podstawowych efektów programowania ekstremalnego jest to, że dwie osoby pracujące nad tym samym fragmentem kodu przy tym samym komputerze, właśnie wobec siebie będą chciały wykazać się dobrą robotą.

Czy jednak takie porzucenie formalizmów nie sprawia, że trudno trzymać się standardów, stanowiących przecież jeden z fundamentów informatyki?

Standardy są bardzo potrzebne, ale jedynie w kilku kluczowych sprawach. Niewiele standardów, lecz za to bardzo ścisłe ich przestrzeganie - to przecież chyba zdecydowanie lepiej niż gdyby sytuacja miałaby być odwrotna.

Łatwo i przyjemnie odrzucić rygory reżimu czasu i pieniędzy. Jak więc jednak sprawić, żeby projekty kończyły się w założonym czasie i budżecie?

Często narzucanie ostrych ograniczeń czasowych to forma tyranii, pod rządami której pracownicy pracują po godzinach. Spędziłem wiele lat, zarządzając projektami szybkiego prototypowania (RAD), by dojść do wniosku, że nakreślanie ram czasowych wcale nie ma na celu ograniczenia czasu realizacji projektu. To jedynie narzędzie do wyboru tego, co można zrobić, na czym należy się skupić. Oczywiście, zawsze czas jest potrzebny jako periodyczny bodziec sygnalizujący, że poszczególne elementy powinny być już skończone.

W technikach adaptacyjnych podstawowy cykl, którego efektem mają być konkretne funkcje tworzonego systemu przedstawiane użytkownikowi, powinien trwać nie więcej niż 4-8 ty- godni. Celem jest jak najszybsze stworzenie fragmentu działającego kodu. Nie ma więc mowy o tym, że użytkownik zobaczy system za rok, a może i nawet później. Użytkownik musi widzieć produkt w trakcie jego tworzenia. Kluczem do sukcesu metod adaptacyj nych jest ciągłe testowanie i weryfikacja "namacalnych" rezultatów prac przez klienta. To nie abstrakcyjna specyfi- kacja, lecz fragment aplikacji, który może on przetestować.

Na początku może się okazać, że trzeba zmienić wszystkie założenia projektowe. Nic nie szkodzi! Taka pierwsza iteracja pozwoli przecież wypracować relacje pomiędzy klientem a wykonawcą systemu.

To zakłada dobrą współpracę z użytkownikiem. Czy wszyscy użytkownicy są gotowi do takiej współpracy?

Oczywiście nie. Są tacy użytkownicy, którzy chcieliby system możliwie szybko zamówić, poczekać i odebrać gotowy za ileś tam miesięcy. Ale nie ma sensu zajmować się takimi użytkownikami, bo przy takim podejściu projekt nigdy nie ma szansy się udać.

--------------------------------------------------------------------------------

Jim Highsmith przebywał w Polsce na zaproszenie firmy InfoViDE. Prowadził warsztaty szkoleniowe dla pracowników tej firmy, dotyczące zasad adaptacyjnego tworzenia oprogramowania.