środa, 19 marca 2008

Przejrzystość – przykład

W nawiązaniu do posta o przejrzystości.

Znany mi jest przypadek projektu, w którym kierownik wyższego szczebla miał zwyczaj idąc po kawę wchodzić do pokoju projektowego, patrzyć się na ścianę na której były te wszystkie informacje po czym bez słowa wychodzić z pokoju. Takie „nawiedzenia” zdarzały się mniej więcej co dwa dni. Co z tego? Otóż jednocześnie ten sam kierownik (który był jednocześnie sponsorem – płacił za projekt) nigdy nie pytał kierownika projektu o status. Nauczył się sam go odczytywać i te dwie minuty raz na dwa dni mu starczały. Z kierownikiem projektu spotykali się tylko podczas demonstracji na koniec iteracji. Obaj: kierownik projektu i sponsor byli z tego bardzo zadowoleni. Pierwszy miał święty spokój a drugi czuł się najlepiej poinformowanym sponsorem w firmie. Wniosek: radiatory informacji się sprawdzają.

wtorek, 11 marca 2008

Iteracje synchronizujące

Kiedyś pisałem o tym, że nie każda iteracja musi być „zwykłą” iteracją. Wtedy podawałem przykład tzw. iteracji 0, których cechą jest dostarczanie wartości dodanej dla zespołu projektowego nie dla klienta. Osobom wyznającym „agile ortodoksyjny” na pewno się to nie spodoba, ale ja dopuszczam poza iteracją 0 także inne „specjalne” iteracje. Ważne tylko jest, aby każda z tych iteracji dostarczała realną wartość dodaną dla klienta. Nie dopuszczam sytuacji, kiedy iteracja inna niż 0 nie wytwarza rzeczywistej wartości dodanej.

Szczególnym przykładem takiej specjalnej iteracji jest coś, co popularnie nazywa się iteracjami synchronizującymi. Takie iteracje występują w sytuacji, kiedy na jeden produkt składa się więcej niż jeden element wytwarzany metodami zwinnymi w jednym czasie. Wówczas w którymś momencie musi nastąpić połączenie poszczególnych elementów w jeden produkt, czyli integracja komponentów. „Agile ortodoksyjne” zakłada, że takie komponenty są integrowane cały czas wykorzystując mechanizmy ciągłej integracji. W praktyce często zdarza się jednak, że z różnych powodów nie jest możliwe przeprowadzanie ciągłej integracji. Wówczas dość często stosuje się tak zwane iteracje synchronizujące. Polega to na tym, że dana wersja produktu jest rozwijana w ramach poszczególnych komponentów (czyli normalnie). Ostatnia iteracja w rozwoju danej wersji przeznaczona jest na poskładanie w całość wszystkich komponentów. Z punktu widzenia przepływu wartość dla klienta wygląda to tak, że do przedostatnie iteracji klient dostaje komponenty o zwiększonej funkcjonalności, natomiast zwiększoną wartością ostatniej iteracji jest działanie systemu (zamiast sumy komponentów). Takie działania integracyjne w ramach ściśle określonej iteracji dają w większości przypadków bardzo pozytywne efekty. Należy jedynie pamiętać, aby tą akurat iterację zaplanować od strony czasowej bardzo konserwatywnie. Powód jest bardzo prosty. Bez włączonych mechanizmów ciągłej integracji okazuje się, że sama integracja wykazuje wiele błędów w poszczególnych komponentach. Dlatego dodatkowy czas musi być przeznaczony na ewentualne poprawki znalezionych błędów. Cóż: coś za coś – brak „problemów” ciągłej integracji skutkuje zwiększonymi kosztami poprawiania błędów.

Na koniec dwie uwagi do powyższego tematu. Po pierwsze mimo braku zaimplementowanych mechanizmów ciągłej integracji pod żadnym pozorem nie wolno doprowadzić do rozjechania się interfejsów poszczególnych komponentów. Zadanie zsynchronizowania poszczególnych części jest w takiej konfiguracji szczególnie ważne i powinno zostać powierzone osobie odpowiedzialnej za całość przedsięwzięcia (uwaga, to też nie jest zgodne z „agile ortodoksyjnym”).

Druga uwaga, to dość oczywisty, ale często zapominany fakt, że problemy z integracją komponentów w największym stopniu można ograniczyć poprzez inteligentny i przemyślany podział na całości systemu na części. Do takich przemyśleń można wykorzystać na przykład czas iteracji 0. Jak konkretnie to zrobić to byłby już temat na osobny post.

poniedziałek, 3 marca 2008

Metody zwinne w organizacji "stabilnej" cz. 3

Dzisiaj kolejny powód, dla którego organizacje stabilne wdrażają zwinne metody zarządzania projektami. Powodem tym jest przejrzystość prac, którą zapewniają metody zwinne.

Przejrzystość prac jest widoczna na dwóch ogólnych poziomach. Po pierwsze przejrzyste jest to co kto robi i jaki jest stopień zaawansowania prac. Podczas codziennych spotkań zespołu uczestnicy projektu opowiadają nad czym pracowali wczoraj i co będą robić dzisiaj, co skutkuje bardzo szybkim rozpowszechnianiem się informacji. Prowadzi to do jasnej sytuacji na temat tego, jakie jest aktualne zajęcie wszystkich członków zespołu. Innym, jeszcze ciekawszym narzędziem są wszelkiego typu „radiatory informacji” wykorzystywane przez zespoły do graficznej prezentacji zaawansowania prac. To temat na osobny post, ale w skrócie narzędzia te są „analogowe” (np. tablica z żółtymi karteczkami) a nie elektroniczne i mogą zawierać najważniejsze informacje zarządcze dotyczące projektu: co zostało zrobione, co jest robione, co będzie robione, a także informacje o tym jak aktualny status ma się do planu. Wszystko to jest przedstawione wizualnie. To narzędzie jest genialne w swojej prostocie a jednocześnie przekazuje zadziwiająco dużo informacji.

Drugim poziomem przejrzystości jest przejrzystość w stosunku do klienta. W tradycyjnych metodach zarządzania projektami często jest tak, że klient nie ma najmniejszej wiedzy, co się dzieje w projekcie, za który przecież płaci, aż do dnia ostatecznego odbioru produktu. Techniki zwinne zakładają inne podejście. Po pierwsze klient musi być zaangażowany cały czas. W każdej chwili zespół pracujący nad projektem ma prawo zapytać się klienta o uszczegółowienie wymagań lub potwierdzić, że wymagania zostały zaimplementowane poprawnie. Takie zaangażowanie samo w sobie daje klientowi wgląd w to, nad czym aktualnie pracuje zespół projektowy i wystarcza, aby klient nie miał pretensji, co do stopnia informowania go o stanie projektu. Jednak techniki zwinne mają jeszcze jedno potężne narzędzie: krótkie iteracje zakańczane działającą wersją produktu. Po każdej z iteracji klient może wypróbować nowe funkcjonalność stworzone podczas tej iteracji. W związku z tym klient ma cały czas poczucie, że wie, za co płaci. Wie też, kiedy pojawią się kolejne funkcjonalności do przetestowania (na koniec aktualnej iteracji). To z punktu widzenia klienta zapewnia pełną przejrzystość i pozwala na utrzymanie bardzo dobrych relacji z dostawcą. Uwaga!!! Trzeba być jednak świadomym, że taka sytuacja nie powstanie od razu i jej wypracowanie będzie wymagało włożenia odpowiednio dużej ilości czasu w ustalanie zasad współpracy z klientem.

Inną stroną przejrzystości prac jest to, o czym wspomniał jakiś czas temu w komentarzach Marcin (tutaj). Przejrzystość może być bowiem bardzo niewygodna dla tych, którzy mówiąc delikatnie „nie lubią” pracować. Częste sprawdzanie postępu prac i konieczność wyraźnego informowania o tym co się zrobiło powoduje, że nie ma mowy o ukrywaniu się przez kilka dni nic nie robiąc. Poza ewidentnym pokazaniem szefom, że taki pracownik jest zbędny w środowiskach pracujących według metod zwinnych pojawia się bardzo silna presja ze strony grupy. Podczas wspomnianych codziennych spotkań wszyscy współpracownicy słyszą i widzą kto pracuje mało. Doświadczenie wskazuje też, że da się wyczuć kto po prostu się obija a kto rzeczywiście tworzy mało bo ma jakieś problemy. Osoby ewidentnie się obijające są pod bardzo dużą presją grupy aby zabrać się do pracy.

I w ten sposób ujawnia się jeszcze jedna duża zaleta metod zwinnych: znacząco wzrasta wydajność zespołów pracujących przy użyciu tych metod w porównaniu do zespołów stosujących metody tradycyjne. Rzecz nie do przecenienia w biznesowym świecie nastawionym na efektywność prac. Co więcej wzrost tej efektywności nie ma żadnego negatywnego wpływu na atmosferę prac. Wręcz przeciwnie ma wpływ pozytywny.