poniedziałek, 30 lipca 2007

Dostosowywanie metodyk

Alistair Cockburn we wspomnianej już książce ""Agile Software Development" zawarł bardzo ciekawy rozdział na temat metodyk jako takich: co to jest metodyka, jakie są jej wymiary, jakimi parametrami można ją opisać itp. Jednym z ciekawszych spostrzeżeń jest to, że warunkiem aby zastosowany zbiór metod/zasad został uznany za metodykę jest pozytywna odpowiedź na pytanie "czy jakbyś teraz robił coś nowego to zrobiłbyś to w ten sam sposób?". Pozytywna odpowiedź na to pytanie oznacza, że w ramach danej dziedziny został uzyskany stan wiedzy, który pozwolił na stworzenie uniwersalnego zbiory metod i zasad pracy. Zbiór ten jest uniwersalny oczywiście w pewnym zakresie zastosowań - zwykle dość wąskim. Tym niemniej ważne jest, że zasady te są na tyle uniwersalne, że da się je zastosować po raz drugi w podobnym problemie i jednocześnie na tyle dobre, że chce się je zastosować po raz drugi. Oczywiste jest, że dopracowanie się takiego zestawy zasad nie jest możliwe za pierwszym razem. Zbiór metod i zasad zwykle musi być parę razy poprawiony zanim osiągnie na tyle wysoką jakość aby móc być stosowanym bez modyfikacji do różnych zastosowań.

I tutaj dochodzimy do zwinnego zarządzania projektami. Aspektem bardzo często podkreślanym w kontekście zwinnego zarządzania projektami jest to, że ta metodyka pozwala na inkrementacyjne dostosowywanie produktu do wymogów klienta. Mniej oczywistą konsekwencją stosowania krótkich iteracji jest możliwość dostosowania stosowanych metod i reguł do środowiska w którym jest realizowany projekt. Oraz ich bardzo szybkiej modyfikacji w celu osiągania coraz to lepszych wyników. Metody są na wysokim poziomie utrzymywane przez ramy zwinnego zarządzania projektem, ale oprócz tego w każdej organizacji występuje masę reguł działania właściwych tylko i wyłącznie dla danego miejsca. Mowa tu zarówno o procesach organizacyjnych (jak rezerwujemy sale konferencyjne, czy i gdzie możemy powiesić na ścianie raporty prac) jak i regułach zachowania się w danej kulturze firmy (w jakiej formie mamy się kontaktować z klientem, jak często kierownik musi raportować, kto o czym ma być informowany, etc.). Dotarcie się takich reguł zajmuje chwilę. Przy dużych projektach, długich cyklach produkcyjnych raz popełniony błąd można poprawić zwykle przy następnym projekcie, czyli za około kilka miesięcy. W przypadku projektów zwinnych następna okazja do poprawki będzie za kilka tygodni najdalej. W ten sposób szybciej zarówno zespół projektowy jak i cała firma może nauczyć się współpracować w środowisku projektowym. Możliwe jest też znacząco szybsze wejście na "wysokie obroty" i dostarczanie wartości dla klienta bez zaprzątania sobie głowy niedostosowanymi do realiów zasadami pracy.

Warunek do osiągnięcia tego jest jeden: porządnie zrobione retrospekcje po każdej iteracji zarówno pod kątem produktu jak i organizacji pracy.

niedziela, 22 lipca 2007

"Pożyczanie" ludzi... tylko na 2 godzinki

W nawiązaniu do ostatniego wpisu na temat przerywania iteracji tym razem sprawa powiązana. Występująca w praktyce nawet częściej niż dylematy z tamtego wpisu. Sytuacja najczęściej zdarza się w środku iteracji i w skrócie polega na tym, że do kierownika projektu przychodzi inny kierownik i prosi (żąda?), żeby jedna z osób zaangażowanych w nasz projekt "na chwilę" pomogła/poprawiła coś w projekcie tego człowieka, bo tam "się pali". Zwykle taka prośba jest dodatkowo okraszona zapewnieniami, że to tylko na chwilkę, maksymalnie dwie godziny.

I co zrobić w takiej sytuacji? Nie zgadzać się. Powodów jest kilka. Po pierwsze logika wskazuje, że takie sprawy nigdy nie kończą się na dwóch godzinach. Osoba z naszego zespołu musi przerwać pracę, przypomnieć sobie co robiła wtedy, dotrzeć do dokumentów czy też plików na których wtedy pracowała, intelektualnie "wdrożyć" się w problem, rozwiązać go i wytłumaczyć drugiemu zespołowi co się stało, jakie było rozwiązanie i dlaczego tak. Później musi pozamykać tamte sprawy i po raz kolejny mentalnie przestawić się na nasz projekt. W dwie godziny to jest niewykonalne. Zajmuje minimum jeden dzień roboczy, a w większości przypadków dwa: pierwszy dzień na przestawienie się na tamten projekt i wykonanie zadania, drugi dzień na odpowiadanie na pytania tamtego zespołu i intelektualny powrót do naszego projektu. Dwa dni mentalnej nieobecności członka zespołu w czasie iteracji to 10% jej efektywnego czasu pracy (zakładając, że iteracja trwa 4 tygodnie). Takich strat się zwykle nie odrobi. Jak przyjdzie to Was jakiś kierownik z taką prośbą to grzecznie spytajcie się go czy on pożyczyłby Wam jedną z jego osób na 10% czasu trwania projektu. Aby kogoś zrozumieć należy bowiem często najpierw wejść w jego buty.

Powyższe uzasadnienie jest czysto praktyczne i zdroworozsądkowe. Jest też uzasadnienie z punktu widzenia metodyki. Otóż zespół pracujący nad projektem zwinnym powinien być widziany z zewnątrz jako jedna jednostka. Zespół pracujący w środowisku samoorganizujacym się nie może być dzielony na mniejsze kawałki. To zespół zobowiązuje się przed klientem do wykonania pewnego zakresu prac, zespół je realizuje i zespół jest z tego rozliczany. Nie można wyjąć kawałka tego zespołu i oczekiwać że reszta dostarczy to co obiecała. To tak jakby facetowi grającemu na pianinie powiedzieć, że lewą ręką ma robić coś innego (np. liczyć na kalkulatorze) i nadal oczekiwać, że będzie grał tak samo dobrze. Nie da rady. W takich przypadkach rolą kierownika projektu zwinnego jest aby po pierwsze jasno komunikować na zewnątrz, że zespół ma być widziany jako całość a po drugie jak tylko można chronić zespół przed pomysłami typu wypożyczanie ludzi "na chwilkę".

Mając oba powyższe na uwadze co w związku z tym zrobić jeżeli faktycznie okazuje się, że osoba pracująca w naszym zespole ma tak unikalne umiejętności, że "musi" popracować przy innym projekcie? Cóż, w takim razie należy odwołać się do wyższego kierownictwa. Na tyle wysokiego, aby miało zwierzchnictwo i nad Waszym projektem i nad tymi aktywnościami, które tak nagle potrzebują Waszych zasobów. Niech ona/on zadecyduje co z biznesowego punktu widzenia jest ważniejsze. Jeżeli naprawdę inne aktywności są biznesowo ważniejsze od Waszego projektu to należy się z tym pogodzić, oddać osoby i wygasić aktualną iterację waszego projektu. Wygasić dlatego, że na podstawie decyzji zewnętrznych czynników (odpowiednio wysoko postawiony menedżer) dostaliście informację, że z punktu widzenia firmy znikło uzasadnienie biznesowe Waszej iteracji - coś innego jest ważniejsze. Wygasić trzeba również dlatego, że zespół który zobowiązał się dostarczyć coś nie jest już tym samym zespołem, który miałby dokończyć pracę. Od decyzji sponsorów będzie też zależało co z Waszym projektem dalej będzie: kończymy zupełnie czy rozpoczynamy nową iterację ze zmienionym zespołem.

Czy to oznacza, że nigdy nie należy pomagać? Owszem jak najbardziej należy. Pomoc można zaplanować na czas następnej iteracji. A w przypadku "malutkich" próśb o pomoc moja zasada brzmi: jeżeli można to załatwić przez telefon w czasie mniejszym niż 15 minut to ok, w innych przypadkach niestety nie.



PS. Dla lubiących myśleć: przeanalizujcie sytuację, gdy nagle okazuje się, że jeden z Waszych ludzi "musi" się znaleźć gdzie indziej aby tam ratować sytuację z punktu widzenia Celu nr 2

niedziela, 15 lipca 2007

Przerwanie iteracji

Kilka osób pytało się jakie jest moje zdanie na temat przerywania iteracji w projekcie zarządzanym metodami zwinnymi. Zgodnie z pierwsza zasadą konsultanta prawidłowa odpowiedź powinna brzmieć "to zależy". I tak jest w rzeczywistości. Podjęcie decyzji o przerwaniu iteracji jest wynikiem działania czynników środowiska w którym przebiega dany projekt i trudno dać tu odpowiedź zawsze prawdziwą. Tym niemniej mogę podzielić się paroma wskazówkami.

Podjęcie decyzji o przerwaniu iteracji powinno być działaniem ostatecznym podejmowanym tylko wtedy jeżeli żadna inna technika zarządcza nie przyniesie lepszych biznesowo skutków. Podejście iteracyjne jest jedną z podstawowych zasad zarządzania zwinnego i jako taka nie może być w dowolny sposób łamana. Złamanie tej zasady musi mieć mocną podstawę biznesową i za każdym razem powinno być zatwierdzane przez najwyższe władze danego projektu (sponsora lub komitet sterujący). W interesie kierownika projektu jest jednak, aby takie decyzje nie były podejmowane. Podjęcie ich i złamanie tym samym umowy zawartej na początku iteracji może bowiem bardzo szybko doprowadzić do chaosu w projekcie. Jeżeli bowiem raz zapadnie zgoda na przerwanie iteracji to później powołując się na ten precedens bardzo łatwo będzie podjąć tego typu decyzje po raz kolejny. Dlatego kierownikowi projektu dla jego własnego przyszłego spokoju powinno zależeć na dotrzymaniu umów i nie przerywaniu iteracji.

Prześledźmy w jakich przypadkach najczęściej pojawia się pokusa przerwania iteracji i jakie są opcje w tych przypadkach.

Przypadek pierwszy i najczęstszy to sytuacja, kiedy w czasie trwania iteracji nagle okazuje się, że klient już nie chce produkowanej przez nas aktualnie funkcjonalności. W takim przypadku przerwanie iteracji nie powinno nastąpić. Iteracje w projektach zwinnych są dość krótkie (maksimum 8 tygodni), więc sytuacja kiedy w czasie trwania iteracji klient nagle przekonuje się, że pewna funkcjonalność na którą sam się zgodził kilka tygodni temu nie jest mu potrzebna nie powinna się wydarzyć. Jeżeli się zaś wydarzy to, choć to trudne, umów trzeba dotrzymywać. Na początku iteracji wszystkie strony zgadzają sie co do zakresu danej iteracji i podobnie jak klient oczekuje od zespołu, że nie wycofa się z podjętego zobowiązania tak samo zespół ma prawo oczekiwać, że nie wycofa się klient. Dodatkowo przerwanie iteracji z taką motywacją spowodowałoby, że w produkcie pozostałyby pewne ślady już wykonanej a nie dokończonej pracy. To mogłoby mieć negatywny wpływ na przyszłą stabilność i jakość produktu. Dlatego prace należy dokończyć. Sporne funkcjonalności mają być wykonane z pełną jakością a w produkcie końcowym mogą być na przykład zakomentowane czy w inny sposób ukryte. Ewentualne nowe funkcjonalności trzeba zrealizować zgodnie z procesem w następnej iteracji. Przed następną iteracją należy się tylko zastanowić, czy w związku z nagłymi zmianami zakresu nie należałoby zmodyfikować (skrócić) czasu trwania iteracji. Taka decyzja musi być podjęta w gronie kierownictwa projektu i nie może być pochopna.

Inny klasyczny przypadek to sytuacja kiedy w trakcie pracy nad funkcjonalnością w ramach iteracji zespół zorientował się, że nie ma możliwości technicznego stworzenia zakładanej funkcjonalności. Przypadek dużo trudniejszy od poprzedniego. Przede wszystkim jeżeli taka sytuacja nastąpiła należy rozważyć możliwość wykonania zakładanej funkcjonalności w technicznie inny sposób niż to było planowane na początku. Drugą opcją jest modyfikacja funkcjonalności w taki sposób, aby była ona wykonalna. Obie te decyzje muszą być skonsultowane ze wszystkimi zainteresowanymi w tym przede wszystkim z klientem / właścicielem produktu. To do niego bowiem należą wszystkie decyzje produktowe w projekcie i będzie on miał ostatnie zdanie w kwestii rozwiązania takiego problemu. Jeżeli nie ma możliwości wykonania danej funkcjonalności w inny technicznie sposób ani klient nie jest chętny zmienić funkcjonalności tak aby była wykonalna to są znowu dwie opcje. Albo zakańczamy iterację i przygotowujemy nową, albo w ramach danej iteracji zespół zobowiązuje się wykonać inną funkcjonalność. Zależy to od wielu czynników (z których najważniejszym jest czas jaki pozostał do końca danej iteracji), lecz w celu zapewnienia spójności zarządzania projektem w większości znanych przypadków lepiej zastosować podejście drugie.

Jedyny znany mi przypadek kiedy bez żadnych obiekcji należy wygasić (ale nie raptownie zakończyć) iterację to sytuacja kiedy znikło uzasadnienie biznesowe dla realizowanego projektu. Projekty są realizowane po to aby organizacje osiągnęły mierzalne rezultaty. Jeżeli nie ma możliwości osiągnięcia tychże rezultatów to kontynuowanie prac nad projektem i dalsze generowanie kosztów przestaje mieć sens. Jeżeli taka sytuacja zaistnieje to projekt należy poprawnie zamknąć, czyli dokończyć rozpoczęte prace, udokumentować wykonane prace, zarchiwizować dane, stworzyć "lessons learned" z projektu itp. Pod żadnym pozorem nie może to być rzucenie wszystkiego i odejście od biurek. Sygnał do podjęcia takich działań musi wyjść od sponsora projektu i być potwierdzona przez właściciela produktu/klienta.

Podsumowując: zwinne zarządzanie projektami rządzi się relatywnie małą ilością zasad. Zasady te powinny być jednak rygorystycznie przestrzegane, bo bardzo łatwo jest znaleźć się po drugiej stronie cienkiej linii, gdzie już rządzi czysty chaos. Iteracyjność jest jedną z tych podstawowych zasad i nie wolno jej łamać bez posiadania twardych, biznesowych dowodów na słuszność takiej decyzji.

niedziela, 8 lipca 2007

Twoja (być może) konkurencja

Miałem ostatnio okazję porozmawiać z kierownikiem biura projektów w dużej firmie informatycznej. Dyskusja bardzo ciekawa i otworzyła przede mną wiele nowych horyzontów. W czasie dyskusji zszedłem dość płynnie na znane mi dobrze metody zwinne zarządzania projektem. Mój partner wcale się nie zdziwił. Okazało się, że jego firma działa w pełni w oparciu od metody agile (a konkretnie SCRUM) już od dwóch lat. Pominąwszy wiele innych ciekawostek usłyszałem dwa najważniejsze jego zdaniem powody, dla których nie ma odwrotu od metodyk zwinnych.

Powód pierwszy: programiści, testerzy, architekci i inni to lubią. A który z szefów nie chciał by mieć grupy pracowników, która lubi to co robi? Pracowników jest kilkuset, nad projektem pracuje zwykle około 100 osób.

Powód drugi: posługując się tymi metodami firma jest w stanie dostarczać nową, w pełni stabilną i działają wersję systemu co 30 dni, co powoduje, że 90% pilnych zmian klienckich są w stanie wbudować w stabilną wersję w ciągu mniej niż 60 dni. Dodam tylko, że firma produkuje m.in. systemy typu mission-critical. Godzina awarii takiego systemu jest przez klientów tej firmy wyceniania na ok. 10 mln EUR.

Powstający co 30 dni stabilny system pisany przez ludzi, którzy w całości lubią to co robią. Hmmm... Czy chciałbyś, żeby ta firma była Twoim konkurentem?

niedziela, 1 lipca 2007

Cel gry

Czytam aktutanie (po raz kolejny) książkę "Agile Software Development" Alistair'a Cockburn'a. Odkrywam za każdym razem coś nowego :-) Tym razem zaciekawił mnie fragment na wysokim poziomie abstrakcji dotyczący pojmowania procesu tworzenia oprogramowania jako gry. Dokładnie jako "zorientowanej na współpracę, ograniczonej zasobami gry inwencji i komunikacji". Gra ta ma charakteryzuje się oczywiście cechami, które mają wielki wpływ na to jaki jest najbardziej efektywny model "grania" w tą grę (po szczegóły odsyłam do książki). Ciekawsze jest to, że Alistair Cockburn zdefiniował cele gry. Dwa:

  1. Dostarczenie użytecznego, działającego oprogramowania (oczywistość)
  2. Zapewnienie najlepszego możliwego startu w kolejnej grze

Cel pierwszy jest chyba oczywisty. O co chodzi zaś z celem drugim? Kolejna gra to kolejny cykl rozwoju oprogramowania. Następna wersja, kolejna zmiana, kolejne dostosowanie do potrzeb klienta, ewentualnie nawet kolejne zadanie podejmowane przez firmę lub ten sam zespół ludzi. Celem jest takie przeprowadzenia aktualnej gry aby oprócz tego, że dostarczymy klientowi oprogramowanie jednocześnie możliwie najlepiej przygotować się do tworzenia kolejnej wersji tego samego lub innego produktu. Czy to nie jest oczywiste jak się o tym dłużej pomyśli? Przecież w znakomitej większości przypadków organizacja tworząca oprogramowanie nie istnieje tylko i wyłącznie w celu stworzenia tej jednej wersji produktu. Czas życia organizacji jest dużo dłuższy. W związku z tym jeżeli na dłuższą metę organizacja chce zapewnić sobie dobre perspektywy koniecznością staje się myślenie w kategoriach najlepszego przygotowania do przyszłych działań. Oczywiste, choć z moich obserwacji wynika, że w większości przypadków cel drugi nie jest brany w ogóle pod uwagę w realizacji projektów informatycznych.

Świadomość celu drugiego praktycznie rzutuje na większość decyzji podejmowanych w ramach zespołu projektowego. Patrząc się przez pryzmat obu celów zmienia się punkt optimum. To, co wydaje się optymalne z punktu widzenia dostarczenia szybko oprogramowania klientowi może stać w oczywistej sprzeczności z celem drugim. Na przykład użycie zamkniętej architektury. Na przykład zmuszenie programistów do pracy w nadgodzinach przez trzy miesiące z rzędu. Na przykład zaniechanie tworzenia dokumentacji, bo to strata czasu. Na przykład brak automatycznych testów, bo to się szybciej zrobi ręcznie. Takie decyzje może i sprawią, że nadgonimy z aktualnym projektem, ale czy na pewno zapewnią dobry start w kolejnym? Świadomość obu celów powinna spowodować odejście od szukania optimów lokalnych dla danego projektu a przenieść uwagę na optima globalne dla organizacji. To byłaby jakościowa zmiana dla wielu osób i zespołów. Czy wchodząc w projekt nie chcielibyście mieć wszystkiego przygotowanego na Wasze potrzeby? Każdy by chciał. A to przygotowanie jest zapewnione przez realizację celu drugiego.

Jedyny problem jaki widzę z praktycznym zastosowaniem tych zasad to mała mierzalność celu drugiego. Cel pierwszy da się zmierzyć bardzo prosto. Cel drugi nie ma zaś jasnych mierników, co może powodować, że w organizacjach nie znajdą zrozumienia decyzje podejmowane z perspektywy celu drugiego. Zostaną one zagłuszone przez żądania szybkiego dostarczenia efektu w postaci wypełnienia zobowiązań celu pierwszego (zdarzyło się Wam kiedyś dyskutować z działem sprzedaży?). To zaś będzie prowadzić do decyzji, które choć dzisiaj będą bardzo skuteczne mogą obniżyć konkurencyjność i możliwość "najlepszego startu" jutro.