Księga procedur a 15 minut

Dzisiaj będzie stricte o projektach IT. Kiedyś dawno temu przeczytałem, że programista pracując nad nowym kodem średnio co 15 minut podejmuje ważną decyzję technologiczną. Fakt ten przypomniał mi się w zeszłym tygodniu, kiedy zaangażowałem się w ciekawą dyskusję nad procedurami w firmie.

Ogólnie pytanie brzmi: jak dokładnie można opisać procedury, które powinien stosować pracownik. Istnieje pewna grupa przekonań, według których procedury mogą i powinny opisywać każdą istotną czynność wykonywaną przez pracownika. Założenie stojące za takimi stwierdzeniami jest takie, że można przewidzieć i opisać każdą jedną sytuację wobec której stanie pracownik. A jak już będzie to opisane to pracownikowi będzie łatwiej pracować, bo zamiast myśleć (?!) sięgnie tylko do odpowiedniej procedury. Hmm, ciekawe, ale na pewno nie w projektach IT. Być może w budownictwie, którego tradycje sięgają kilku tysięcy lat można skatalogować i opisać każdy jeden przypadek. Ale w programowaniu? Gdzie każdą rzecz można wykonać na przynajmniej kilka sposobów? Gdzie decyzje technologiczne podejmuje się co 15 minut? Nawet gdyby teoretycznie było to możliwe księga wzorców projektowych musiałaby liczyć tysiące stron. A gdzie procedury decydowania, który wzorzec użyć? Po pierwsze nikt nie byłby w stanie tego opisać, a jeżeli nawet to potem nikt nie byłby się w stanie tego nauczyć :-)

Co więc zamiast ścisłych procedur? Po pierwsze określone ramy postępowania, czyli np. pracownicy wiedzą co jest ważne w danym rozwiązaniu: elastyczność czy wydajność. Po drugie właściwi pracownicy, którzy potrafią użyć swojej inteligencji do wybrania spośród znanych im rozwiązań tego najlepszego akurat w zadanych ramach. Co 15 minut :-) Tu problem jest większy, ale cóż za to w końcu firma płaci programiście albo innemu administratorowi, żeby to ON się znał na rzeczy. Jeżeli firma uważa, że ON się nie zna, to czemu go jeszcze zatrudnia? Pracownik musi być na tyle inteligentny i proaktywny, żeby potrafić zastosować w danym momencie rozwiązanie najlepiej realizujące cel postawiony dla danego oprogramowania. Jeżeli firmie uda się zbudować taki zespół i ustalić wspierającą go strukturę zarządzania to będzie ona na pewno bardziej "agile" (zwinna) niż firmy starające się opisać każdą decyzję pracownika w opasłym tomie procedur.

Przyczyna źródłowa

Pisząc o koncepcji Jidoka napisałem tak “[pracownik ma obowiązek] znaleźć przyczynę takowego niepożądanego stanu rzeczy, wyeliminować ją i dopiero potem [podjąć z powrotem pracę]”. Po zastanowieniu dochodzę do wniosku, że to jest świetny materiał na rozważania o tym, co powinno być elementem sesji retrospekcji i co leży w obowiązku kierownika projektu, zwłaszcza realizowanego metodami agile. Chodzi o to znajdowanie i eliminowanie przyczyn źródłowych problemów.

Jak się popatrzy na obecne środowisko pracy w wielu organizacjach to jedyną reakcją na problemy stosowaną przez wyższe kierownictwo jest coraz większy nacisk na to, aby problemów nie było. Jeżeli projekt przekracza deadline’y to kierownictwo wyznacza większe bonusy za dotrzymanie deadline’ów. Jeżeli jest za dużo błędów to grozi się obcięciem pensji za ponowne wypuszczenie błędnej wersji oprogramowania. Problem w tym, że takie podejście tak naprawdę konserwuje to, co jest. Bo zakłada, że wszystko robiliśmy dobrze, tylko się nie staraliśmy wystarczająco dobrze. Więc jeżeli następnym razem się postaramy bardziej to będzie dużo lepiej. Hmm, bardzo odważne założenie. W rzeczywistości będzie zapewne tak, że jak teraz przy tych metodach które mamy trochę nam nie wyszło to jak je zastosujemy jeszcze bardziej dokładnie to jeszcze bardziej nam nie wyjdzie.

Tak naprawdę rzadko kto podejmuje się zadania proponowanego przez Japończyków (choć nie tylko ich) czyli znalezienia przyczyny źródłowej takiego a nie innego stanu rzeczy. Wysiłek ten podejmowany jest rzadko, bo nie jest to zadanie proste. Przyczyna źródłowa oznacza zadawanie pytania “dlaczego” tak długo aż dojdziemy do odpowiedzi, której już dalej nie da się podzielić. Co więcej bardzo często znajdowanie przyczyny źródłowej polega na odkrywaniu i kwestionowaniu podstawowych założeń, na których oparta jest nasza organizacja i jej sposób działania.

Jeżeli popatrzyć na metodyki agile to najodpowiedniejszym miejscem do znajdowania przyczyn źródłowych problemów wydaje się być retrospekcja. Wówczas poza zastanowieniem się co się stało warto by też zastanowić się nad przyczynami źródłowymi problemów. Ponieważ nie jest to łatwe ani proste nie można się zastanawiać nad wieloma przyczynami źródłowymi jednocześnie. Raczej spośród wielu problemów nękających projekt należałoby wybrać jeden, który najbardziej boli i skupić się na jego rozwiązaniu. Czyli najpierw znaleźć jego przyczynę źródłową a dopiero potem wdrożyć rozwiązanie.

Aha i tutaj jedna uwaga. Przyczyny źródłowe problemów w projektach mają to do siebie, że często są tzw. przyczynami systemowymi. Czyli wynikają wprost z tego jak skonstruowany jest system, w tym wypadku system zarządzania w danej organizacji. Jeżeli przyczyna jest przyczyną systemową to aby permanentnie ją wyeliminować należy zmienić system. A to niestety często jest poza zasięgiem kompetencyjnym osób pracujących w projektach. Jedyne logiczne rozwiązanie w takiej sytuacji to rzeczony przypadek udokumentować oraz przedstawić odpowiednio wysokim menedżerom w firmie. A następnie mieć nadzieję, że zależy im na tym, aby ich system zarządzania działał sprawnie.

Dwa narzędzia, które mogą pomóc w znajdywaniu przyczyn źródłowych to na przykład A3 Problem Solving Method (bazująca na rozwiązaniach Toyoty) oraz Current Reality Tree (bazująca na narzędziach myślowych teorii ograniczeń).

Dług technologiczny

Koncepcja długu technologicznego jest stara jak agile a ostatnio natknąłem się na nią przy okazji robienia czegoś zupełnie innego. Co to jest dług technologiczny? Oto jak kiedyś mi to wytłumaczono: cokolwiek co czyni Twój produkt trudnym do zmiany w przyszłości jest długiem technologicznym - możesz albo zapłacić pełną cenę technologiczną teraz (zrobić od razu rozwiązanie elastyczne) albo zaciągnąć dług i spłacić go później (zrobić rozwiązanie szybkie ale nieelastyczne a przy pierwszej konieczności zmiany mieć trudność z brakiem elastyczności). Dług ma to do siebie, że generuje odsetki. To znaczy, że jeżeli dzisiaj nie poświęcimy dwóch dni na uczynienie naszego produktu elastycznym, to w przyszłości jeżeli będziemy chcieli przeprowadzić zmiany nie będzie kosztowało to dwa dni, tylko dwa dni plus odsetki. Odsetki te niestety przyrastają zdecydowanie szybciej niż w popularnych bankach. Efektem skrajnym jest kiedy produkt staje się tak niepodatny na zmiany, że prościej jest takowy produkt zrobić od nowa niż zmienić stary (sam byłem w takiej sytuacji).

W szczególności dług technologiczny dotyczy kodu oprogramowania. Tam jest bardzo łatwo zrobić rozwiązanie, które jest mało elastyczne ale bardzo szybkie we wdrożeniu (np. użycie nieudokumentowanych funkcji - kto z nas tego nie robił ;-)). Zdecydowanie trudniej jest napisać kod, który jest elastyczny. Co więcej często wprowadzenie zmiany sprawia, że kod staje się mniej elastyczny. Wówczas, aby nie zaciągać długu należy przeprowadzić refaktoryzację i zmienić kod tak, aby elastycznym był. Pominięcie refaktoryzacji spowoduje pogłębianie się długu, produkt będzie coraz trudniejszy do zmian. Prędzej czy później trzeba będzie za to zapłacić. Z tego punktu widzenia czas poświęcony na refaktoryzację to nie jest koszt. Jest to raczej inwestycja. Dzisiaj inwestujemy dwa dni pracy po to, aby w przyszłości nie musieć inwestować 5 dni w przeprowadzenie prostej zmiany.

Agile w sposób naturalny wspiera eliminację długu technologicznego. Poprzez iteracyjność oraz fakt, że nikt w zasadzie nie wie nad jakim kawałkiem produktu będzie pracował w przyszłej iteracji wspiera się aktywnie tworzenie rozwiązania bardzo elastycznego. W zespołach bardzo często tworzenie rozwiązań elastycznych jest przyjmowane jako jedna z głównych zasad pracy. Niestety nawet w przypadku takim jak ten, kiedy metodyka wspiera takie działania można cały ten efekt zepsuć. Najprościej dzięki mało kompetentnym kierownikom projektów, którzy nie pozwalają własnym zespołom na pracę dobrą a wymagają tylko pracy szybkiej. Jeżeli jesteście w takiej sytuacji to wytłumaczcie proszę zarządzającym koncepcję długu technologicznego i odsetek od niego. Moje ostatnie doświadczenia wskazują, że takie podejście skutkuje.

Budowanie dla utrzymania

W nawiązaniu do tego, co kiedyś napisałem o wyzwaniach związanych z tworzeniem dokumentacji wdrożeniowej i utrzymaniowej oprogramowania napiszę jeszcze o jednym pokrewnym rozwiązaniu. W znanym tekście “The New New Product Development Game”* autorzy jako jeden z głównych powodów znaczącej poprawy efektywności producentów stosujących opisywane nowe metody tworzenia produktów podali korzystanie z zespołów wielofunkcyjnych. W szczególności w skład zespołów opracowujących nowe produkty wchodziły osoby z produkcji, czyli te, które później będą odpowiedzialne na wytworzenie w setkach tysięcy sztuk pomysłów inżynierów. Idea, która za tym stała była prosta i oczywista - często to, co jest optymalne z punktu widzenia inżyniera projektującego nowy produkt, wcale nie jest optymalne z punktu widzenia osoby, która ten produkt będzie musiała wykonać w tysiącach sztuk. Celem tworzenia takich zespołów miało być projektowanie takich nowych produktów, które nie tylko będą spełniały marzenia inżynierów (i marketingowców), ale jednocześnie będą proste w produkcji. Stąd zaangażowanie osób za nią odpowiedzialnych w rozwój produktu od samego początku projektu.

Przekładając to co zostało napisane na temat produkcji na rozwój oprogramowania wydaje się, że odpowiednikiem produkcji (wytwarzania) jest tutaj (wbrew pozorom) wdrożenie/utrzymanie. Sytuacja wygląda bowiem tak, że zespół rozwoju projektuje nowy system, który później trafia do zespołów wdrożeniowych i utrzymaniowych, które muszą zadbać o to, aby produkt działał bezbłędnie u każdego z klientów firmy. Podobnie jak produkcja w fabryce, tak wdrożeniowcy wytwarzają gotowe, działające u klient produkty firmy software’owej, oczywiście na bazie produktu stworzonego przez inżynierów odpowiedzialnych za rozwój.

Ciągnąc tą analogię dalej w niektórych projektach warte zainteresowania jest włączenie osób odpowiedzialnych za wdrożenia i utrzymanie (maintenance) do zespołów wytwarzających produkt, czyli zespołów rozwijających nowe oprogramowanie. Taka koncepcja wygląda na pierwszy rzut oka dość karkołomnie, ale im dłużej się nad tym zastanawiam tym większy ma sens. Wiadomo, że włączenie tych osób do zespołu spowoduje, że system będzie inaczej zaprojektowany. Zarówno te osoby, które muszą system zainstalować u klienta jak i te, które potem muszą odpowiadać na klienckie zapytania i/lub radzić sobie z błędami zgłaszanymi przez klienta będą miały mnóstwo pomysłów na usprawnia. Oczywiście jedną ze strategii jest je po prostu zbyć, ale... Ale tak naprawdę to one wystawiają swoją głowę klientowi na ścięcie i to od efektywności ich pracy zależy postrzeganie firmy przez organizację klienta. I nawet pomijając to jaki jest cel tej gry, to jak wiadomo każdemu z nas pensje tak naprawdę płaci... klient naszej firmy.

* Tekst znany jest głównie z tego, że w nim jako w pierwszym w literaturze pojawiło się określenie SCRUM na zespół pracujący zgodnie z metodami “lekkimi” - pojęcie agile jeszcze wtedy nie istniało. Sam artykuł ukazał się w Harvard Business Review, ale jak to kogoś interesuje to można go sobie wygooglać w formie PDFa. W tytule nie ma błędu.

Dzielenie funkcjonalności raz jeszcze

Prawie dokładnie dwa lata temu napisałem post nt. wielkości funkcjonalności. Post był krótki i treściwy, ale po dwóch latach w sposób równie krótki i równie treściwy muszę dokonać pewnej modyfikacji tego, co w nim napisałem.

Otóż jak najbardziej prawdą jest, że w ramach iteracji powinniśmy realizować funkcjonalności, których wielkość jest nie większa niż jedna iteracja. Doświadczenie dwóch lat nauczyło mnie jednak, że nie jest optymalne mówienie, iż każda z tych funkcjonalności musi dostarczać wartość dodaną dla klienta. Powinno się mówić o tym, że każda z funkcjonalności (w tym takie po podziale) powinny dostarczać wartość dodaną dla właściciela produktu (Product Managera). Czy to robi różnicę? Subtelną, ale jednak robi. Różnica ta polega na tym, że właściciel produktu nie koniecznie jest klientem (aczkolwiek może nim być). Zdarzyło mi się w mojej praktyce spotkać się z przypadkami, kiedy klient końcowy jako wartość dodaną dla siebie widział tylko i wyłącznie coś, co jest efektem końcowym całego projektu. Po prostu z punktu widzenia klienta końcowego żaden z elementów pośrednich, będących efektami poszczególnych iteracji nie powoduje, że biznes klienta zacznie lepiej działać i przynosić lepsze efekty. Dlatego czasami trudno tu jest mówić o wartości dodanej poszczególnych iteracji. Z punktu widzenia klienta takowych po prostu nie ma.

Natomiast wartość dodana z punktu widzenia właściciela produktu może być trochę inną wartością dodaną niż z punktu widzenia klienta. Na przykład posiadanie części rozwiązania może być dla właściciela produktu wartością, bo wie, że jest bliżej całości rozwiązania. Natomiast z punktu widzenia klienta to nie ma żadnego znaczenia, bo jemu wartość przynosi tylko i wyłącznie rozwiązanie w całości.

Nauka z tego taka, że w planowaniu zwinnym jeżeli istnieje ktoś taki jak właściciel produktu to planowanie odbywa się z oparciu o jego definicję wartości i on odpowiada za definiowanie funkcjonalności. I to właściciel produktu odpowiedzialny jest za to, aby koniec końców produkt dostarczał wartość dla klienta ostatecznego.

Uwaga!!! Klient i właściciel produktu w niektórych przypadkach to może być jedna i ta sama osoba, wtedy oczywiście cały ten post i tłumaczenie ma mały sens.

I na koniec jeszcze jedno spostrzeżenie. Gdyby nie praktyczna próba zastosowania agile nigdy nie spotkałbym się z taką sytuacją i nigdy nie przypuszczałbym, że wartość dodana dla klienta może w pewnych wypadkach być tak trudna do zastosowania. Ale od czego jesteśmy zwinni (agile). W sposób agilowy dostosowaliśmy się do panujących warunków. Zastanawiam się tylko jak by się w takiej sytuacji zachowali reprezentanci nurtu "agile ortodoksyjny"?

Kiedy nie stosować metod zwinnych

Na Controlling Chaos pojawił się przydługi wywiad z Jerrym Manasem. Trwa półtorej godziny i gdzieś w środku pojawił się jeden wątek, który z oczywistych względów mnie zainteresował. Otóż rozważane było czy stosować podejście procesowe czy elastyczne (org. flexible). Zeszło na Agile Project Management i po chwili padły tam trzy kryteria/sytuacje, których zaistnienie wyklucza użycie metod zwinnych (agile) do zarządzania projektem:

1. Bezpieczeństwo
2. Wymaganie dokładności
3. Standardy prawne

Moje komentarze do tych sytuacji:

Ad.1. Chodzi o sytuację kiedy mamy projekt od którego będzie zależało życie ludzkie: oprogramowanie nawigacyjne samolotu, projekty wojskowe czy np. oprogramowanie tomografu komputerowego. Sytuacja wyjątkowa. Takimi projektami zarządza się zupełnie inaczej niż czymkolwiek innym.
Ad. 2. Ta sytuacja zachodzi wtedy, kiedy z góry wiemy, że są ściśle zdefiniowane parametry produktu końcowego, które chcemy uzyskać. W wywiadzie był podany przykład budownictwa: tam jest wszystko opisane jak co powinno wyglądać (w projekcie) i nie ma miejsce na zwinność. Po prostu trzeba zrobić. To jest bardzo logiczne. Jeżeli parametry wyrobu są podane wcześniej i wymagane jest dokładne spełnienie tychże kryteriów to logiczniejszym wyjściem jest zaplanowanie całości w celu uzyskania tychże kryteriów niż dochodzenie do nich w sposób iteracyjny. Z drugiej strony problem może się pojawić jak nie mamy pojęcia w jaki sposób osiągnąć wymagane parametry. Wtedy rozważyłbym, czy jednak metody zwinne nie byłyby przydatne.
Ad. 3. Projekt dotyczy wdrożenia standardów prawnych (org. regulatory standards). Sytuacja jest prosta: standard istnieje i mamy go wdrożyć. Standard ze swojej definicji jest dokładnie określony i nie ma tam miejsca na zwinność. I jedna tylko drobna uwaga. Chodzi tylko i wyłącznie o standardy prawne. Jeżeli projekt dotyczy standardów innego typu, np. wewnątrzfirmowych to już rozważenie metod zwinnych jest jak najbardziej wskazane. Jak to było wspomniane w wywiadzie należy pamiętać, że standardy wewnątrzfirmowe są narzędziem a nie celem samym w sobie. Ich interpretacja jest jak najbardziej uzasadniona jeżeli gwarantuje osiągnięcie celów, dla których zostały stworzone.

Moja opinia:
Zgadzam się w całości z tym, co usłyszałem w wywiadzie. Oznacza to, że dla bardzo znaczącej większości projektów użycie metod zwinnych nie jest wykluczone.

Wieloprojektowość

Wyobraźcie sobie szpital, w którym operuje się chorych. Teraz kierownictwo tego szpitala, jako że chce skutecznie i szybko leczyć swoich pacjentów nakazuje aby natychmiast jak tylko pojawi się pacjent kierować go na potrzebną mu operację. Pomyślcie co się zaczyna dziać na salach operacyjnych. Jak jest jeden czy dwóch pacjentów to jest jeszcze dobrze, potem zaczyna być ich coraz więcej (kierowani są na operacje od razu jak tylko się pojawią). W końcu jest ich więcej niż zespołów lekarzy chirurgów i sal operacyjnych. Co w tym momencie robi kierownictwo szpitala? Nakazuje, żeby jeden zespół lekarzy wykorzystujący jedną salę operacyjną jednocześnie robił kilka operacji. Przecież Ci lekarze to świetni specjaliści, na pewno jakoś dadzą radę. Tak więc zaczyna się dzielenie czasu. Nad jednym pacjentem godzina, potem godzina dla drugiego. W miarę jak rośnie ich liczba zaczyna się problem z dostępnością sal operacyjnych. Anestezjologów zresztą też brakuje. W związku z tym tworzymy listy dostępności sali wraz ze ścisłym harmonogramem, który chirurg kiedy operuje którego pacjenta a który anestezjolog gdzie asystuje. Sale są dokładnie na godziny, więc nie można się spóźniać. Problem w tym co chirurdzy mają robić w czasie, gdy nie mogą operować swojego pacjenta, bo sala jest zajęta. Najchętniej by poczekali, ale szefostwo szpitala nie chce marnować drogocennego czasu chirurgów. Przecież to są świetni specjaliści i nie mogą w pracy spędzać "nieproduktywnych" godzin. W związku z tym szefostwo nakazuje chirurgom robić obchody w czasie jak ich (już "rozpoczęty") pacjent czeka na wolną salę. Skutek jest taki, że przestają zdążać na swój czas w harmonogramie dostępności sali, bo nie mogą się oderwać od obchodów. A jak już przyjdą i zaczną operować to jak tylko się dobrze "wdrożą" w danego pacjenta okazuje się, ze muszą go zostawić, bo w harmonogramie skończył się czas dostępności dla nich sali operacyjnej. Anestezjolodzy mają podobny problem.

Jesteście oburzeni takim podejściem? Kto by się chciał tam leczyć?

Teraz proszę podstawicie sobie w powyższym przykładzie zamiast "pacjent" to "projekt", zamiast "chirurg" to "programista" a zamiast "sala operacyjna" to "serwerownia" (czy dowolny inny zasób, który jest wystarczający rzadki w Waszym środowisku). Brzmi znajomo? Nikt nie zadaje pytania "kto by kupił projekt od takiej organizacji"?

Ciekawe jest, że branża medyczna, jakkolwiek niedoskonała, już od dawna potrafi sobie radzić z taką sytuacją. W prosty sposób: dedykowane zespoły, priorytetyzacja wykorzystania kluczowych zasobów (najpierw ten co ma życie zagrożone a potem ten co operacja plastyczna), kolejkowanie pacjentów zamiast współbieżności. Śmiem twierdzić, że nawet w Polsce statystyki sukcesów są dużo lepsze dla operacji medycznych niż dla projektów, w tym zwłaszcza projektów innowacyjnych. Znaczy, że takie rozwiązania działają. Teraz wypadałoby podpatrzyć czy u nas nei da się tak samo. I tutaj niespodzianka. Zarządzanie zwinne bardzo podobnie podchodzi do portfolio projektów jak szpital do operacji. To znaczy: zespół jest dedykowany do jednego projektu (nie wolno pożyczać ludzi), projekty robi się jeden po drugim a nie współbieżnie, a priorytety zapewnia właściciel produktu. Czyli podobnie. Ciekawe, dlaczego skoro w branży medycznej te zasady uznajemy za taką oczywistość w projektach już nie.

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ą.

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.

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.

Metody zwinne w organizacji "stabilnej" cz. 2

Wracamy do tematu wdrażania metod zwinnych w organizacji stabilnej. Jak już pisałem wcześniej (tutaj) jest to obecnie pewna moda, ale są też realne powody dla których taka decyzja może być podjęta. Dzisiaj o aspekcie biznesowo-technicznym a mianowicie o uzyskiwaniu informacji zwrotnej od klienta.

Metody zwinne prowadzenia projektów zakładają podejście iteracyjne do tworzenia produktu. Każda z krótkich iteracji zakończona jest przedstawieniem klientowi działającej wersji produktu, która jest wzbogacona o konkretną wartość biznesową w porównaniu z wersją dostępną na początku iteracji. Klient uczestniczy w prezentacji funkcjonalności stworzonej podczas iteracji i/lub dostaje niewykończony produkt do testów. To, że klient widzi działający produkt powoduje natychmiastową reakcję klienta i dostarczenie zespołowi informacji zwrotnej (feedback) na temat produktu. Najważniejsze w tym opisie jest to, że w odróżnieniu od innych metod zarządzania w metodach zwinnych obowiązkowo informacje zwrotną klient przekazuje po każdej iteracji, czyli bardzo często. Dla każdej organizacji nastawionej na dostarczanie wartości dodanej dla klienta częsta informacja zwrotna jest kluczowym czynnikiem sukcesu. Pozwala ona bardzo często dokonywać sprawdzenia, czy rozwijany produkt faktycznie spełnia oczekiwania klienta, będzie mu przydatny i ogólnie czy będzie sukcesem (z punktu widzenia stopnia zadowolenia klienta). Dla tych graczy na rynku, którzy faktycznie żywią się sukcesem swoich klientów jest to zaleta nie do przecenienia.

Dla tych samych graczy kluczowy jest także drugi aspekt zbierania informacji zwrotnej od klientów w projektach zarządzanych zwinnie. Otóż informacja ta jest w 100% zbierana na podstawie stworzonej i działającej wersji produktu ostatecznego. W innych metodach bardzo często zdarza się, że informacja zwrotna zbierana jest na podstawie analizy dokumentów. Problem w tym jest taki, że każdy dokument ma pewien stopień swobody interpretacyjnej. Co więcej im mniej jest tej swobody tym dokument droższy do stworzenia. Zwykle następuje więc kompromis pomiędzy stopniem swobody a kosztami wytworzenia dokumentacji. Efekt jest taki, że choć obie strony przeczytają dokument i według nich będzie on dobry, obie zrozumieją go inaczej i klient dostanie nie to, co sobie zinterpretował z dokumentu. Porażka i negocjacje dotyczące trybu wprowadzenia poprawek są w takiej sytuacji gwarantowane. Metody zwinne pozwalają zbierać informację zwrotną już na podstawie stworzonego produktu. Klient namacalnie może stwierdzić, czy to jest zgodne z jego oczekiwaniami. Nie ma tu już możliwości interpretacji, bo ogląda działający produkt. W ten sposób przekazywana informacja zwrotna jest nie tylko częsta i szybka, ale także dokładna. Dla firm „upolitycznionych” żyjących z tego jak dobrych mają prawników może to być duża wada, ale dla większości firm, które dostają faktury za spełnienie oczekiwań swoich klientów może być to kluczowa element budowania dobrej marki.

Warto wspomnieć o dwóch biznesowych skutkach częstego zbierania dokładnej informacji zwrotnej. Po pierwsze dramatycznie zmniejszają się koszty poprawek. Choć na początku projektu klient może zgłaszać ich dużo to po praktyka wskazuje, że po pewnym okresie (kilka iteracji) jest ich już znacząco mniej, bo zespół uczy się na czym zależy klientowi. Taka sytuacja powoduje, że jest możliwe wprowadzenie kluczowych poprawek w momencie, kiedy produkt jest jeszcze stosunkowo mały (1-3 iteracja). Jest to zdecydowanie tańsze niż wprowadzanie tej samej poprawki w momencie, kiedy produkt już się rozrósł. Po drugie zbieranie szybkiej informacji zwrotnej od klienta pozwala bardzo szybko zlikwidować nieudane projekty. W każdej organizacji zdarza się tak, że czasami któryś projekt nie jest udany i nie ma szans na sukces. Problem, który się zwykle pojawia, to że okazuje się to kiedy organizacja zainwestowała już w projekt bardzo dużo środków. Wówczas podjęcie decyzji o zamknięciu takiego projektu jest bardzo trudne, bo ciężko jest się przyznać do tak dużego błędu. Metody zwinne pozwalają oceniać projekt po każdej iteracji przez tych, którzy będą go używać. Z tego względu jeżeli projekt jest nietrafione często da się to wykryć już po drugiej/trzeciej iteracji i zlikwidować go przy dużo niższych kosztach niż w tradycyjnych metodach. Jest to kluczowe zwłaszcza dla firm działających w sferze wysoce innowacyjnej lub przy bardzo szybko zmieniającym się rynku.

Zarządzanie innowacjami jest łatwe!!!

A konkretnie: zarządzanie projektami innowacyjnymi nie jest trudniejsze od projektów nie-innowacyjnych. Taki długi tytuł nie zmieściłby się na stronie. Przechodząc do konkretów:
Zupełnie nie rozumiem, dlaczego przyjęło się, że zarządzanie projektem wysoce innowacyjnym jest dużo trudniejsze niż zarządzanie projektem „standardowym”. Fakty przeczą takiemu twierdzeniu i jedyne, co można powiedzieć to, że zarządzanie jest „inne”, ale na pewno nie „trudniejsze”.

W zarządzaniu projektami innowacyjnymi główną „innością” jest występująca duża niepewność, co do podejmowanych działań. Z jednej strony tradycyjna metodyka zarządzania projektem zwykle wymaga, żebyśmy już na początku wiedzieli, co dokładnie mamy zrobić, w jakiej kolejności i ile to potrwa. Z drugiej strony samo pojęcie innowacyjności sugeruje coś dokładnie odwrotnego: nie wiemy co dokładnie mamy zrobić, nie wiemy dokładnie jaki będzie rezultat, ani tym bardziej nie wiemy ile dokładnie przeznaczymy na to czasu. Z takich dwóch stanowisk rodzi się konflikt, którego rozwiązanie nie wydaje się być proste. Wtłoczeni w ten konflikt kierownicy projektów rozrywani między dwie strony twierdzą później, że zarządzanie projektami innowacyjnymi to koszmar.

Tymczasem ten konflikt można rozwiązać w dość prosty sposób: zmieniając założenia dotyczące zarządzania projektami. Metody tradycyjne, wymagające bardzo dokładnego planowania po prostu są tutaj złym narzędziem. To tak, jakby ktoś próbował użyć siekiery do obierania ziemniaków i narzekał, że to frustrujące. Wystarczy natomiast zmienić narzędzie (na nóż) i natychmiast przestaniemy się frustrować.

Ogólnie można wyróżnić dwa „trudne” przypadki w zarządzaniu projektami innowacyjnymi: albo wiemy co mamy zrobić (poszczególne zadania) ale nie wiemy ile będą trwały, bo są one innowacyjne, albo wiemy tylko co chcemy osiągnąć, ale nie mamy sprecyzowanej drogi dojścia do celu.

W drugim wypadku, gdy znamy tylko cel a nie znamy metody dojścia do celu ani nie możemy jej zaplanować w ekonomicznie uzasadnionym czasie pozostaje użycie narzędzia stworzonego do takich przypadków: zwinnego zarządzania projektami. Jak już wielokrotnie tu było pisane metody zwinne pozwalają na dokładne planowanie tylko krótkich iteracji zbliżających cały projekt do wcześniej określonego celu (wizji). Jednocześnie częste interakcje z klientem pozwalają na weryfikację czy nasza innowacja stanowi wartość dodaną dla klienta. W ten sposób możemy bardzo szybko wycofać się z chybionych inwestycji. Czy zarządzanie projektem innowacyjnym w oparciu o takie procesy to koszmar? Nie, to czysta przyjemność. Pod warunkiem oczywiście, że procesy będą wspierane przez wszystkich w organizacji a nie tylko przez kierownika projektów.

Innym przypadkiem jest pierwszy z przypadków opisanych wcześniej. Czyli sytuacja, kiedy wiemy, jakie zadania należy wykonać w projekcie, ale innowacyjność przedsięwzięcia uniemożliwia stworzenie poprawnych oszacowań czasu trwania poszczególnych zadań. Jest to interesujące, bo problem ten dotyczy także innych projektów, niekoniecznie innowacyjnych – często z wielu przyczyn nie możemy określić dokładnie czasu trwania poszczególnych zadań lub ten czas trwania z założenia jest określony z dość małym stopniem prawdopodobieństwa. Znów użycie tradycyjnych metod zarządzania projektami w takim przypadku bardzo szybko prowadzi do frustracji kierownika projektu i całego zespołu. Należy bowiem zdać sobie sprawę, że np. szeroko stosowana metoda ścieżki krytycznej zakłada, że czasy trwania poszczególnych zadań są oszacowany poprawnie. Jeżeli pojawią się różnice w realnym czasie wykonania zadań w stosunku do planu wówczas ścieżka krytyczna może się zmieniać praktycznie codziennie doprowadzając osobę próbującą nią zarządzać na stan załamania nerwowego. Czy tak musi być? Nie. Istnieją odpowiednie metody zarządzania projektami, które skonstruowane zostały właśnie po to, aby radzić sobie z niedokładnością oszacowań. Taką metodą jest metoda łańcucha krytycznego (łańcuch a ścieżka to dwa różne pojęcia). W metodzie łańcucha krytycznego zakłada się skonstruowanie modelu projektu w taki sposób, aby ochronić datę zakończenia projektu przed zmianami. Jednocześnie jednym z założeń tej metody jest niedokładność oszacowań czasu trwania poszczególnych zadań. Niemożliwe? A jednak. Możliwe i wykorzystywane.

Znów dochodzimy do tego, od czego ten post się zaczął. Zarządzanie projektami innowacyjnymi jest łatwe. Pod warunkiem, że użyje się odpowiedniego narzędzia. Niestety część osób próbuje używać tego samego zestawu narzędzi do zarządzania stabilnym projektem budowy domku jednorodzinnego jak i do zarządzania wysoce innowacyjnym projektem z dziedziny IT. Oczywiście można próbować, tylko jaki będzie efekt? Etyka zawodowa kierownika projektów powinna nakazywać poznanie więcej niż jednej metody zarządzania projektami. Każdy kierownik powinien posiadać wiedzę o wielu narzędziach i wykorzystywać je w zależności od potrzeb. Jeżeli będzie próbował zawsze i wszędzie stosować jedno i to samo narzędzie to niestety skutki będą znane: frustracje, porażki i tłumaczenia, że to jest „trudne i skomplikowane”. Fakt, obieranie ziemniaka przy użyciu siekiery jest trudne i skomplikowane.

Szacowanie przy użyciu prędkości

Pytanie, które pojawia się dość często jest następujące: jak oszacować kiedy zakończy się projekt (rozumiany w sensie dostępnej kolejnej wersji produktu)? Jak wszystkie inne problemy w sztuce zwinnego zarządzania projektami jest to proste, choć niekoniecznie zgodne z tym czego oczekiwaliby specjaliści od tradycyjnych metod zarządzania projektami.

Podstawą szacowania jest tzw. prędkość pracy zespołu. Prędkość ta określa ile jednostek funkcjonalności zespół jest w stanie ukończyć w trakcie jednej iteracji. To ile "warta" jest każda z funkcjonalności jest określane zgrubnie przez zespół na etapie planowania wersji. Później jest to doprecyzowane przy poszczególnych etapach planowania i/lub retrospekcji. W każdym razie po etapie planowania wersji powinno być dostępne oszacowanie ile jednostek funkcjonalności liczy cała zaplanowana wersja. Później sprawa jest już wybitnie prosta. Otóż po wykonaniu kilku (zwykle trzech) iteracji można z dużą dozą prawdopodobieństwa powiedzieć ile jednostek funkcjonalności produkuje zespół w jednej iteracji - tzw. prędkość zespołu. Następnie należy podzielić ilość jednostek, które zostały do zrealizowania przez prędkość zespołu i otrzymujemy ile iteracji pozostało do końca. Uwaga, iteracji a nie dni czy miesięcy. W zwinnym zarządzaniu projektami iteracja jest najmniejszą niepodzielną jednostką, więc to jej będziemy używać do określania ile jeszcze pozostało do końca. Przeliczenie iteracji na konkretne daty może już być zadaniem dla kogoś spoza zespołu projektowego.

Proste? Tak, pojawia się jednak pewne "ale". Co zrobić, jeżeli z jakichś powodów koniecznie musimy mieć oszacowanie przed pierwszą iteracją i nie możemy czekać do trzeciej iteracji aby określić prędkość zespołu? Cóż - po pierwsze trzeba spróbować wytłumaczyć tej osobie, która "nie może" czekać, żeby jednak zaczekała. Argumentacja jest prosta: czy lepsze są dane rzeczywiste dostępne za trzy iteracje czy dane wysoce niepewne (a.k.a. wróżenie z fusów) dostępne dzisiaj? Jeżeli nie uda się wyperswadować to też można sobie poradzić, choć jest to utrudnione. W takim wypadku należy jedną, dwie lub trzy iteracje po prostu bardzo dokładnie zaplanować. Rozbić na zadania i razem z zespołem dokładnie zaplanować co ile czasu zajmie. Na postawie planowania podaje się przybliżoną prędkość zespołu a potem liczy się już tak jak we wcześniejszym akapicie.

Proste? Wiem, że nie do końca. Ten temat jest akurat takim tematem, który rewelacyjnie tłumaczy się przy użyciu kartki papieru i dwóch, trzech wykresów. Niestety blog takich możliwości interakcji nie daje. W przypadku, gdyby ktoś był bardzo zainteresowany zapraszam do kontaktu.

Iteracja zero

Pojęcie iteracji zero nie jest popularne w świecie zwinnego zarządzania projektami a według mnie jest to jedno z bardziej przydatnych narzędzi, które powinno być częściej wykorzystywane.

Jak wiadomo jedną z podstawowych zasad zwinnego zarządzania projektami jest to, że każda iteracja ma dostarczyć produkt o zwiększonej wartości biznesowej dla klienta, czyli ze zrealizowanymi dodatkowymi funkcjonalnościami. Każda iteracja zakończona jest pokazem dla klienta, podczas którego ma on możliwość przetestowania dostępnej nowej funkcjonalności. Iteracja zero różni się tym, że nie dostarcza żadnej wartości dodanej dla klienta. Dostarcza ona natomiast wartość dodaną dla zespołu realizującego projekt.

Iteracja zero jeżeli jest stosowana musi być pierwszą z iteracji w projekcie. Stosuje się ją, gdy zespół z jakichś względów nie może rozpocząć od razu pracy nad merytoryczną częścią projektu. Jej celem jest przygotowanie wszystkiego co jest niezbędne, aby zacząć projekt. Mogą to być takie rzeczy jak zdobycie nowej wiedzy, przygotowanie środowisk pracy, nabycie materiałów niezbędnych do rozpoczęcia prac, decyzje strategiczne dotyczące architektury przyszłego rozwiązania itp. Ze względu na swój szczególny charakter iteracja ta może mieć długość inną niż pozostałe. Ważne jest, aby iterację zero zaplanować. Należy bardzo dokładnie określić co jest jej celem i jak oceni się, że została ona zakończona. Tu postępuje się podobnie jak w każdej innej iteracji. Podobnie po iteracji przeprowadza się spotkanie kończące na którym przedstawiana jest wartość dodana, którą zespół uzyskał po zakończeniu iteracji. Uwaga, iteracja zero może być jedna i tylko jedna. To znaczy, trzeba ją zaplanować tak dokładnie aby nigdy więcej w ramach projektu zespół nie musiał zatrzymywać się - należy w tej pierwszej iteracji zero zatroszczyć się o wszystko co jest koniecznie do prowadzenia prac.

Podstawowym błędem popełnianym przy używaniu tego narzędzia jest próba użycia go w celu "przemycenia" starych nawyków z podejścia kaskadowego. Syndromem jest tutaj poświęcenie całej iteracji zero na "zaplanowanie" albo "przeanalizowanie" sposobu realizacji wymagań. To nie jest celem iteracji zero. Planowanie i analizowanie wymagań użytkownika odbywa się w ramach normalnego procesu iteracyjnego w zwinnym zarządzaniu projektem. Dla porównania iterację zero powinno się zastosować, jeżeli na przykład nikt z zespołu nie zna przepisów, w ramach których musi pracować nasz produkt. To drugie jest warunkiem koniecznym do startu prac zespołu to pierwsze jest próbą powrotu z metod iteracyjnych do kaskadowych.

Niepewność wymagań

Niepewność wymagań została wywołana dwukrotnie w ciągu ostatnich dwóch tygodni, w tym raz publicznie w komentarzach na blogu Alexa. Dlatego dzisiaj o niepewności wymagań.

W świecie IT (choć nie tylko) bardzo często dochodzi do sytuacji, kiedy w momencie w którym projekt powinien się rozpocząć zespół wykonawczy nie jest w stanie spisać wszystkich wymagań klienta. Według standardowych metod w takim wypadku należy powołać zespół analityków i być może projektantów, którzy siądą z użytkownikami końcowymi (lub klientem, choć to bardziej ryzykowne) i spiszą wymagania. Brzmi bardzo rozsądnie. Problem pojawia się w momencie kiedy klient nie wie czego by chciał. To wbrew pozorom zdarza się dosyć często. Tzn. klient wie do czego ma służyć system, wie jakie mają być główne jego funkcje, ale na przykład wymyślenie szczegółowych raportów, które powinien generować system jest poza możliwościami klienta. Głównie dlatego, że system nie istnieje jeszcze w rzeczywistości a człowiek często ma trudności w operowaniu bytami wirtualnymi. Co więcej jest pewna gama projektów, w których nie ma możliwości określić wszystkich wymagań na początku trwania projektu. Przykładami jest większość projektów internetowych. Na przykład www.flickr.com powstał jako narzędzie do dzielenia się zdjęciami. Kto w momencie powstawania tego serwisu zdefiniowałby takie funkcjonalności jak geotagging czy tworzenie fizycznych gadżetów ze zdjęciami?

Wracając jednak do niepewności wymagań: należy założyć, że istnieją projekty w których ta niepewność po prostu jest. Są też projekty, w których tej niepewności być nie powinno. Na przykład projekty realizowane w ramach zamówień publicznych - tam wszystkie wymagania powinny być określone w SIWZ. Błędem często popełnianym przez kierowników projektów jest próba użycia metodyk doskonale sprawdzających się w projektach ze stałymi wymaganiami do projektów w których występuje duża niepewność wymagań. Oczywiście gwoździe można wbijać trzonkiem noża zamiast młotkiem ale skutki mogą być opłakane.

Narzędziem do radzenia sobie z projektami o dużej niepewności wymagań są właśnie metody zwinne zarządzania projektami. Metody zwinne oferują kilka narzędzi/technik, które pomagają radzić sobie z takimi problemami. Najważniejsze:

• Klient szybko dostaje wartość dodaną - krótkie powodują, że klient dostaje regularnie system wzbogacony o nowe funkcjonalności do testowania, co powoduje że jest w stanie na żywo sprawdzić czy jego wymagania zostały spełnione i wygenerować/uszczegółowić nowe
• Planuje i rozlicza sie funkcjonalności - całe planowanie oparte jest o kolejne funkcjonalności a nie o zadania do wykonania. Z tego względu klient i zarząd dokładnie wie co (jaką wartość) otrzyma po każdej iteracji. Konieczność zdefiniowania tego powoduje, że musi doprecyzowywać wymagania na bieżąco - do realizacji nie wchodzą wymagania "niepewne".
  
• Można planować na różnych poziomach - Ze względu na poziomy planowania tylko najbliższa iteracja lub iteracje muszą być zaplanowane dokładnie. Kolejne wersje mogą być zaplanowane mniej dokładnie, co wprost implementuje naturalną dla człowieka zdolność do dokładniejszego planowania tego co jest bliżej a mniej dokładnego tego co jest dalej. Dodatkowo w sposób naturalny obejmuje to wszelkie niepewności co do wymagań odnośnie szczegółów projektu.
  
• Istnieje pewność realizacji spójnego projektu - poziom planowania produktu czy też wizji w projektach zwinnych zapewnia, że cały czas będziemy realizować jeden projekt z jedną wizją i spójnym produktem końcowym. Pozwala to błyskawicznie wykryć sytuację kiedy okaże się, że wymagania tak się zmieniły, że robimy co innego niż pierwotnie zakładane.
  
• Zespół pracuje w środowisku stabilnym - na czas iteracji. A to już spojrzenie "z drugiej strony". Programiści i inni zaangażowani w projekt realizowany metodami zwinnymi są szczęśliwi, bo mają pewność że wymagania są zamrażane na czas jednej iteracji. Mają pewność, że nikt nie przerwie im pracy i nie zmieni gwałtownie tego co robią przez całą iterację. Ta pewność w morzu niepewności jest przez członków zespołów szczególnie ceniona.
  

Oczywiście na koniec słowo o kontraktach. Kiedyś już to było poruszane na tym blogu. W skrócie jeżeli klient nie wie co chce to w jaki sposób może oczekiwać, że my wiemy jak to wycenić? W przypadku projektów o dużej niepewności wymagań podawanie stałej ceny za zrealizowanie takiego kontraktu to chodzenie po bardzo cienkiej linie.

Wielkość funkcjonalności

Dzisiaj będzie krótko ale treściwie. Dość często zespoły wdrażające zwinne zarządzanie projektami stają przed problem wielkości funkcjonalności. Brzmi to trochę abstrakcyjnie, ale w praktyce objawia sie w prosty sposób. Otóż osoby wytwarzające nasz produkt mówią kierownikowi, że funkcjonalność, która jest przewidziana do realizacji w iteracji jest zbyt duża żeby ją skończyć w ramach jednej iteracji. Co wtedy? Odpowiedź prawidłowa jest tylko jedna: należy podzielić tą funkcjonalność na mniejsze. Zawsze po iteracji ma być dostarczona nowa wartość dodana dla klienta. Dlatego funkcjonalność, której nie można zrobić w okresie jednej iteracji (znaczy: na koniec iteracji nie będzie działała) nie spełnia wymogów dostarczenia nowej wartości dodanej. Funkcjonalność zbyt dużą do wykonania w jednej iteracji trzeba podzielić tak, aby w każdej z iteracji dostarczać coś działającego, co będzie miało realną wartość dla klienta. Klient będzie mógł to obejrzeć i dać nam informacje zwrotne jak mu się podoba.

Zarządzanie zwinne najlepiej działa jeżeli różnica między najmniejszą a największą funkcjonalnością jaką operujemy to mniej więcej rząd wielkości. Czyli największa jest około 10 razy większa od najmniejszej. Przy takim doborze wielkości najlepiej działają wszystkie metody szacowania dla projektów zwinnych. Jeżeli funkcjonalności w naszym projekcie po pierwszej identyfikacji nie mieszczą się w tych granicach to należy je dostosować: to co jest za małe połączyć, to co jest za duże podzielić. Operacje dostosowywania wielkości funkcjonalności powinny się odbywać na poziomie planowania wersji (zobacz: poziomy planowania).

FBS

Ostatnio napisałem o planowaniu dla wartości klienta. Jednym z narzędzi, które wydatnie w tym pomagają jest FBS. Z angielska jest to Feature Breakdown Structure, czyli struktura podziału funkcjonalności. W planowaniu zwinnym jest to odpowiednik znanej z tradycyjnego planowania struktury podziału pracy, czyli tzw. WBS. Różnica miedzy FBS a WBS tkwi w ideologii stojącej za tworzeniem jednego i drugiego.

W przypadku WBS ideologia mówi, że zakończenie projektu jest równe zakończeniu wszystkich działań podejmowanych w ramach tego projektu. Te działania mają na koniec zapewnić osiągnięcie celów założonych przy planowaniu. Dlatego tworząc strukturę podziału prac uwaga skupiona jest na czynnościach, które mają doprowadzać do stworzenia całości. Projekt jest dzielony na zadania do wykonania. Zakłada się, że wykonanie działań powoduje dojście do wyznaczonych celów. Zgodnie z tzw. zasadą 100%, która jest jedną z zasad tworzenia poprawnego WBSa określa się, że jeżeli wykonanie wszystkich działań na poziomie n WBS jest jednoznaczne ze 100% uzyskaniem elementu zdefiniowanego na poziomie n+1. I jeszcze raz: skupienie jest tu na działaniach i ich ukończeniu. Ukończenie działań, wszystkich działań, ma być gwarancją osiągnięcia efektu.

Zarządzanie zwinne proponuje podejście odmienne. Ze względu na to, że projekty zwinne są sterowane poprzez dostarczanie wartości dla klienta planowanie odbywa się nie poprzez podzielenie produktu końcowego na funkcjonalności, które mogą być dostarczane klientowi w kolejnych iteracjach. Struktura podziału dotyczy więc nie wykonywanych zadań a dostarczanych funkcjonalności. Podział większej funkcjonalności na mniejsze musi się odbywać w taki sposób, aby zidentyfikować funkcjonalności jednostkowe, które zawsze muszą mieć następujące dwie cechy (plus kilka innych, mniej ważnych z omawianego punktu widzenia):

• funkcjonalność musi mieć realną wartość dodaną dla klienta
• funkcjonalność musi być jednoznacznie testowalna

Pierwsza cecha gwarantuje, że podzielimy produkt na takie części jednostkowe, które na pewno wnoszą coś dla naszego klienta, co w ostateczności oznacza, że klient będzie za nie w stanie zapłacić. Po co bowiem klient miałby płacić za coś czego nie potrzebuje? To najprostszy sposób, żeby uniknąć tworzenie czegoś, co jest zbędne. Jednocześnie takie podejście w wielu przypadkach ułatwia szybkie dostarczenie produktu przynoszącego realną wartość. Pamiętać tu bowiem trzeba o zasadzie Pareto, która w tym konkretnym przypadku powie, że 20% funkcjonalności przyniesie 80% wartości dodanej. Konieczność zastanowienia się nad konkretną wartością dodaną przy każdej funkcjonalności ułatwia określenie o które 20% tak naprawdę rozgrywa się gra. Na koniec tego akapitu jeszcze raz dla podkreślenia: o tym co ma jaką wartość zawsze decyduje klient.

Drugą cechą każdej z funkcjonalności jednostkowych powinna być jednoznaczna testowalność. To znaczy już na etapie określania co jest jednostkową funkcjonalnością należy jednocześnie określić jak będzie można przetestować czy dana funkcjonalność została zrealizowana poprawnie i czy faktycznie przynosi wartość dodaną. Oczywiście chodzi tu o to, aby z punktu dostawcy jednoznacznie wiedzieć jakie są kryteria dla klienta. Kiedy klient wie, że dany kawałek produktu faktycznie jest dla niego przydatny. Jeżeli nie ma możliwości określenia tego zwykle coś jest nie tak ze zdefiniowaniem samej funkcjonalności. Z doświadczeń z rozmów z klientami wynika jednak, że w znakomitej większości przypadków doskonale wiedzą oni po co tak naprawdę jest mi potrzebna dana funkcjonalność i jak sprawdzić, czy działa ona tak jakby chcieli. Jeżeli pojawiają sie z tym problemy to zwykle w sytuacjach kiedy rozmawiamy nie z faktycznym ostatecznym użytkownikiem produktu a z jego reprezentacją wewnątrz firmy, czyli właścicielem produktu.

Podzielenie projektu na części za pomocą FBS niesie za sobą oczywiście konsekwencje w dziedzinie planowania a później zarządzania postępami prac. W projektach zwinnych w znakomitej większości przypadków śledzi się właśnie wykonanie konkretnych funkcjonalności dla klienta. Wykonanie funkcjonalności potwierdza się za pomocą ustalonych wcześniej kryteriów testów podczas gdy wykonanie tradycyjnych zadań uważa się za zakończone wtedy, kiedy wykonujący je ludzie uznają je za zakończone. To znów kwestia podejścia. W zarządzaniu zwinnym nie jest ważne jakie prace są wykonywane tylko jaka wartość dodana została stworzona. Zauważcie, że wykonanie zadań w tradycyjnych metodach z założenia może nie prowadzić do stworzenia wartości dodanej - tam wartość może pojawić się dopiero po wykonaniu 100% zadań. W zarządzaniu zwinnym kwestią dogmatyczną jest, że najlepszym raportem ze statusu projektu jest pójście do klienta i powiedzenie mu "w ostatnim miesiącu wydaliśmy EUR 10 000 i wykonaliśmy funkcjonalności F1, F2 i F3 - zostały przetestowane zgodnie z ustaleniami". Tymczasem "tradycyjny" raport postępów prac dla klienta o ile się w ogóle pojawia wygląda najczęściej tak: "w ostatnim miesiącu wydaliśmy EUR 10 000 i wykonaliśmy zadania Z1 i Z2 aktualnie mam 50% wykonania zadania Z3".

Postawcie się w pozycji klienta i zastanówcie się który raport chcielibyście usłyszeć.

I tak na koniec: planowanie za pomocą FBS ma też swoje wady. Największą z nich jest to, że aby wykonać w całości daną funkcjonalność najczęściej trzeba wykonać prace w wielu miejscach produktu na raz. To prowadzi do sytuacji, że i tak na bardzo niskim poziomie, w ramach jednej iteracji, trzeba planować zadania dla poszczególnych osób/zespołów. Drugi duży problem to wymagania niefunkcjonalne. Jak sama nazwa wskazuje nie mogą być częścią FBS a muszą być zaimplementowane. Do ich śledzenia używa się tzw. kart ograniczeń projektu. Ale o tym to już innym razem.

Planowanie a wartość dla klienta

Pamiętam jak dziś, że kiedy mój znajomy objawił mi prawdę o tym kto płaci mi pensję dość długo nie mogłem wyjść z szoku. W każdej komercyjnej firmie jest bowiem tak, że koniec końców pensję płaci pracownikowi płaci nie firma, w której jest on zatrudniony, ale klient tej firmy. Żadna firma na świecie (oprócz mennicy państwowej) nie ma maszynki do produkcji pieniędzy, każda z nich pieniądze bierze od swoich klientów. Dlatego niezależnie od zajmowanego w firmie stanowiska każdy pracownik powinien dążyć do tego, aby jego firma produkowała wartość dodaną dla klientów. Jeżeli bowiem tej wartości nie będzie to wkrótce nie będzie też ani klientów ani pracy.

Ta zdroworozsądkowa zasada została wbudowana w podejście zwinne do zarządzania projektami. Jedną z wartości zwinnego zarządzania jest "działający produkt ponad kompleksową dokumentację". Po prostu nie ma na świecie klienta, który zapłaciłby realne pieniądze za dokumentację rewelacyjnego systemu, który ma tylko tą jedną wadę, że nie istnieje. Dużo więcej klientów jest w stanie zapłacić za działający system, nawet jeżeli nie byłby tak rewelacyjny a jedynie w dobry sposób spełniał podstawową potrzebę. Pojęcie wartości dla klienta przewija się przez procesy zwinnego zarządzania w wielu miejscach: wybór funkcjonalności do iteracji, prezentacja wykonanej funkcjonalności, określanie wizji, spekulacja na temat osiągnięcia wizji - wszystkie te czynności są oparte o ideę dostarczania klientowi wartości dodanej.

Jednym ze szczególnych elementów związanych z zarządzaniem projektem jest planowanie podziału dużego projektu na mniejsze, ściśle określone części, które zespół projektowy będzie wykonywał a zarządzający projektem będą nadzorować śledząc tym samym postęp prac. W tradycyjnych metodach zarządzania projektami stosuje się do tego tzw. WBS, czyli strukturę podziału pracy (Work Breakdown Structure). W zarządzaniu zwinnym do tego samego służy FBS, czyli struktura podziału funkcjonalności (Feature Breakdown Structure). Jaka jest różnica? Otóż taka, że elementem końcowym w WBS jest zwykle pewna czynność do zrobienia. W FBS jest to pewna testowalna funkcjonalność. Już widzicie różnicę? W tym drugim przypadku ponieważ mowa o pewnej funkcjonalności zawsze jednocześnie można powiedzieć o pewnej zwiększonej wartości dodanej dla klienta. W procesach zwinnych dzieli się i śledzi postępy w dostarczaniu wartości dodanej dla klienta. W procesach tradycyjnych śledzi się postęp w wykonaniu prac. Niby mała różnica a jednak.

Przekonałem się o tym parę dni temu, kiedy oglądałem plan pewnego potężnego projektu. Zrobiony w miarę poprawnie WBS obejmował lekko ponad 2000 (dwa tysiące) zadań atomowych. Przejrzałem je wszystkie. Pominąwszy oczywiste i pozostawione bez odpowiedzi pytanie jak zarządzać 2000 zadań atomowych rzuciło mi się w oczy jeszcze jedno. Otóż zadania te były tak skonstruowane, że w ogóle nie wynikało w którym momencie powstawała jakakolwiek wartość dodana dla klienta. Próbowałem znaleźć w tym WBSie zadania, po skończeniu których mógłbym powiedzieć że w tym momencie wartość systemu dla klienta wzrosła. Niestety takich zadań nie było. Jedynym miejscem był kamień milowy "produkt działa u klienta" - to w miarę oczywiste. Niesamowite jest dla mnie to jak można zarządzać dostarczaniem systemu podzielonego na 2000 zadań, razem ponad 20000 godzin pracy inżynierów różnych specjalności i podczas całego tego czasu wiedzieć tylko ile pracy zostało wykonanej. A nie wiedzieć jaka wartość została dostarczona dla klienta. Oczywiście próbowano to robić przy użyciu analizy EVA, ale moim zdaniem to nie wystarczało. W jaki sposób wiedza ile trwało i czy skończyło się zadanie "analiza technologii X"przekłada się na wiedzę ile wartości dostarczyliśmy dla klienta? W przypadku posługiwania się FBS taka wiedza byłaby dostępna natychmiast. O samym FBS napiszę więcej następnym razem - dzisiaj już się za długo rozpisałem.

Weźcie kiedyś jakiś dostępny dla Was plan projektu i prześledźcie go. Zobaczcie czy z poszczególnych elementów planu wynika że projekt dostarcza wartość dodaną dla klienta. Czy możecie kontrolować proces dostarczania tej wartości? Czy możecie mierzyć postępy dostarczania wartości dla klienta? Analizując ten plan ani na moment nie zapominajcie kto tak naprawdę płaci Wam pensję.