niedziela, 16 grudnia 2007

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.

sobota, 8 grudnia 2007

Metody zwinne w organizacji "stabilnej" cz. 1

Ostatnimi czasy metody zwinne zarządzania projektami stają się coraz bardziej popularne. Metody te najlepiej sprawdzają się w środowiskach bardzo dynamicznych, w projektach, w których występuje duża doza niepewności. Okazuje się jednak, że duża część firm działających w bardziej stabilnych środowiskach również wdraża zarządzanie zwinne. Jakie są powody tego? Na pewno swoista „moda”, ale czy tylko? Ze względu gwałtownie narastający charakter zjawiska napiszę w kilku postach, jakie mogą być powody, dla których organizacje pracujące w środowisku stabilnym wdrażają zwinne zarządzanie projektami.

Uzasadnienia nie będą w żadnej logicznej kolejności, dlatego na pierwszy ogień pójdzie powód bardzo ważny dla większości osób zaangażowanych we wdrożenia zwinnego zarządzania projektami, choć z drugiej strony być może mniej interesujący dla kierownictwa. Otóż skutkiem wprowadzenia zwinnych metod zarządzania projektami, jest to, że zespołom realizującym projekty pracuje się... przyjemniej.

Przyjemność ta wynika z kilku czynników. O jednym pisałem już kiedyś, przy okazji omawiania tematyki zmian w projekcie – w projektach zarządzanych metodami zwinnymi zespół pracuje nad zestawem funkcjonalności, które nie mają prawa się zmienić (w danej iteracji). To powoduje duży spokój psychiczny zespołu, jako że jasno określone są reguły, na podstawie których dokonywane są zmiany i nikt nie zaskakuje członków zespołu. Wbrew pozorom stabilność (choćby w ramach jednej iteracji) jest jednym z podstawowych wymogów zachowania przyjemności z wykonywania pracy.

Kolejnym bardzo dobrze wpływającym na pracę czynnikiem jest fakt, że ze swojej natury zespoły pracujące zgodnie z metodami zwinnymi są zespołami relatywnie małymi położonymi w jednej fizycznej lokacji. Bardzo częsta komunikacja między członkami zespołu powoduje dobrą atmosferę pracy choćby dlatego, że wszelkie niezrozumienia są błyskawicznie usuwane a problemy są komunikowane przynajmniej raz dziennie podczas spotkań. Poza tym w takim zespole ze względu na charakter spotkań (zarówno codziennych jak i podsumowujących iterację) każda z osób czuje się dowartościowana, bo jej zdanie jest brane pod uwagę.

Uwaga. Powyższe jest prawdą tylko o ile osoby zajmujące się koordynacją zespołów posiadają odpowiednie umiejętności komunikacyjne!!!

Praca w projektach zwinnych jest przyjemna również dlatego, że każdy z członków zespołu ma poczucie odpowiedzialności i szybką nagrodę w postaci osiągnięcia sukcesu – działający produkt na koniec iteracji. Mała wielkość zespołu w połączeniu z krótkimi iteracjami oraz tym, że na koniec każdej iteracji trzeba dostarczyć produkt wzbogacony o konkretną wartość dodaną dla klienta powoduje, że każdy z członków zespołu jest zaangażowany w dostarczanie tej wartości. Krótki czas realizacji sprawia, że każdy widzie efekty swojej pracy podczas prezentacji dla klienta. Człowiek natomiast skonstruowany jest tak, że lubi jak mu coś wychodzi.

Jak to się ma do zarządzania firmą jako całością? Ma się, gdyż jeżeli pracownikom pracuje się przyjemniej to pomaga im to pracować efektywnie. Poza tym pracownicy, którzy mają przyjemną atmosferę w pracy zwykle rzadziej myślą o zmianie pracodawcy. Jeżeli idzie to w parze z efektywnością (a idzie) to oczywistym jest, że lepiej mieć pracownika zadowolonego niż zdegustowanego.

sobota, 1 grudnia 2007

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.

czwartek, 22 listopada 2007

Jak definiować testy?

Problem z praktyki: w jaki sposób definiować testy funkcjonalne w oprogramowaniu rozwijanym metodami zwinnymi? Żeby odpowiedzieć poprawnie najpierw przyjrzyjmy się jak to jest robione w standardowych metodach zarządzania projektami informatycznymi. Według teorii dokumentem na którym się bazuje jest definicja wymagań. Po zatwierdzeniu dokumentu definiującego wymagania przez klienta na podstawie tegoż dokumentu jednocześnie projektanci przystępują do projektowania systemu a osoby odpowiedzialne za testy piszą tzw. specyfikacje testów. Czyli ustalają co ma być testowane, w jaki sposób i w jakich ramach czasowych. Tak jest w teorii. W praktyce bywa nieco inaczej oczywiście. Głównie dlatego, że w znakomitej większości projektów dokument specyfikacji wymagań tak naprawdę zamknięty i zakończony jest dopiero w momencie zakończenia prac nad projektem. Klient przez cały czas wprowadza jakieś poprawki, które potem muszą być odzwierciedlane w testach. Dlatego po każdej zmianie specyfikacji wymagań trzeba zmienić specyfikację testów. Gratulacje dla tych, którym udaje się to utrzymać w porządku przy większych projektach.

W przypadku projektów realizowanych metodami zwinnymi jest trochę inaczej. Jak wiadomo wymagania definiowane są poprzez funkcjonalności, które muszą przynosić wartość dodaną oraz być nie większe niż jedna iteracja. Funkcjonalności mają też taką cechę, że nie mogą się zmieniać tylko i wyłącznie w ramach iteracji, w której są wykonywane. Wcześniej lub później można je dowolnie przedefiniować. W przypadku gdyby chcieć w takich warunkach pisać zwykłą specyfikację testów byłoby to niemożliwe ze względu na narzut na utrzymanie aktualnej dokumentacji. Jak sobie z tym poradzić? W najprostszy możliwy sposób. Otóż testy funkcjonalne zapisywane są i definiowane w obrębie danej funkcjonalności i do nie niezmiennie przypisane. W praktyce wygląda to tak, że funkcjonalność składa się z opisu tego co ma być zrobione oraz sposobu w jaki należy sprawdzić, czy zostało to zrobione poprawnie. Mówiąc językiem bardziej biznesowym funkcjonalność zawiera metodę upewnienia się, że faktycznie wprowadza ona wartość dodaną dla klienta.

Proste? Przede wszystkim zgodne ze zdrowym rozsądkiem. I bardzo dobre dla wszystkich stron zaangażowanych w tworzenie oprogramowania. Klient od razu wie w jaki sposób będzie sprawdzane czy funkcjonalność jest dobra, więc bardzo wcześnie można wykryć wszelkie niedomówienia w definiowaniu wymagań. Unika się w ten sposób sytuacji, kiedy wymaganie zostało inaczej zrozumiane przez zespół - "myśleliśmy, że o to Wam chodziło". Tutaj w sposób jawny definiujemy jak będziemy sprawdzać poprawność wykonania wymagania klienta. Testerzy są bardzo zadowoleni, bo zwykle mają w takim przypadku gotowe specyfikacje testów, które trzeba tylko oprogramować i wykonać. Programiści natomiast doskonale wiedzą czego się od nich oczekuje. Mogą więc na przykład postawić na TDD (Test Driven Development).

Metoda jest bardzo prosta, ale istnieją dla niej pewne zagrożenia. Jednym z nich jest to, że nagle zaczną sie pojawiać "testy luzem". To znaczy propozycje wykonania testów, które "muszą być", ale nie będą przypisane do żadnej funkcjonalności. Uwaga na takie sytuacje!!! W technikach zwinnych "testy luzem" akceptuje się tylko i wyłącznie dla wymagań niefunkcjonalnych. Zgodnie ze swoją definicją dotyczą one ogółu systemu (np. wydajność) a nie poszczególnego funkcjonalności. Jeżeli natomiast trafi się propozycja uwzględnienia funkcjonalnego "testu luzem" to najprawdopodobniej jest to błąd wynikający z jednej z dwóch przyczyn. Po pierwsze brak wymagania - sytuacja kiedy ewidentnie brakuje jakiegoś wymagania funkcjonalnego. "Funkcjonalny test luzem" nie istnieje, bo z definicji testuje jakąś funkcjonalność. Jeżeli nam się taki osierocony test przytrafi to przyczyną może być brak definicji któregoś z wymagań - trzeba je dodefiniować. Drugą przyczyną może to być "pozłacanie" (ang. gold plating) produktu - klient nie chciał, ale my mu zrobimy bo jesteśmy fajni. Nie wolno. Jeżeli klient nie chciał to za to nie płaci, dlatego nie robimy. Możemy ewentualnie zasugerować klientowi, że znaleźliśmy możliwość wprowadzenia takiej dodatkowej funkcjonalności i poczekać na jego decyzję.

wtorek, 30 października 2007

Skąd się biorą wymagania?

Pytanie nieskomplikowane, odpowiedź zwłaszcza w świetle tego, o czym pisałem wcześniej powinna być oczywista: od klienta. Niestety. Odpowiedzi oczywiste nie zawsze są prawdziwe.

Najpierw trzeba się dobrze zastanowić, kto to jest klient. Klient jest osobą, która zamawia i płaci za nasz produkt. Jeżeli działamy w ramach projektów wewnętrznych zamiast klienta jest tzw. właściciel produktu, czyli osoba, która odpowiada za stworzenie nowego produktu. Płacą zaś za niego tak naprawdę klienci docelowi, którym właściciel produkt sprzedaje. Umówmy się, że niezależnie od tych sytuacji wszystkie te osoby będę nazywał klientami.

Pytanie jest następujące: czy klient ma dobrą wiedzę o tym potrzebnych funkcjonalnościach produktu? Zdarza się, że tak. Ale w ogólnym przypadku klient nie zawsze jest tym, który produktu używa. Na przykład w dużych korporacjach software jest zwykle kupowany przez dział IT a potem wdrażany w całej firmie. Czy dział IT (klient) naprawdę wie jakie funkcjonalności powinien mieć program? Nie. O funkcjonalnościach najwięcej wie użytkownik końcowy, czyli ten, który oprogramowanie będzie używał w swojej codziennej pracy.

Co więcej często dość naturalne jest, że istnieje pewnego rodzaju różnica zdań pomiędzy spojrzeniem na wymagania od strony klienta a od strony użytkownika końcowego. Załóżmy, że tworzone jest nowe oprogramowania do zarządzania projektami w dużej firmie. Używać go będą oczywiście kierownicy projektów oraz wszyscy zaangażowani w projekty w firmie. Zamawia go (klientem jest) jednak albo centralny dział IT albo szef działu zarządzania projektami. Z ich punktu widzenia priorytet będą miały takie wymagania jak: bezpieczeństwo danych, łatwość instalacji, łatwość zdalnego zarządzania, przeglądanie sytuacji wielu projektów, raporty z pracy poszczególnych kierowników projektów, kontrolowanie zasobów firmy w kontekście wielu projektów itp. To są funkcjonalności, które oni potrzebują. Czy te wymagania stanowią jakąkolwiek wartość dodaną dla zarządzania projektami w firmie? Wątpliwą. Użytkownicy końcowi potrzebują: łatwości planowania projektów, pomocy w harmonogramowaniu, łatwości przydzielania zasobów, automatyzacji przydzielania zadań, łatwości śledzenia postępu prac (dla kierowników), prostej i szybkiej metody raportowania postępu prac (dla wykonawców), ostrzeżeń o nieprawidłowościach w projekcie. Jeszcze raz: czy system spełniający wymagania klienta ale nie implementujący wymagań użytkownika końcowego będzie miał rzeczywistą wartość dodaną dla organizacji?

Czy w związku z tym wszystkie napisane we wcześniejszych wpisach słowa o kreowaniu wartości dla klienta nie są prawdziwe? Czy nie powinno chodzić o wartość użytkownika? Nie, bo mówimy o dwóch różnych rzeczach. Nie można porównywać jabłek z gruszkami. Klient płaci za produkt, więc to on domaga się za płacone pieniądze dostarczenia wartości dodanej dla siebie. Tylko za tą wartość zapłaci. Wartość ta tworzona jest poprzez implementację funkcjonalności potrzebnej użytkownikom końcowym produktu (wartość dla użytkownika końcowego powinna przekładać się na wartość dla organizacji). Jednak to klient ma ostateczny głos za co chce płacić a za co nie. On też decyduje o tym, które elementy z jego punktu widzenia są najbardziej potrzebne a które mniej. Jeżeli klient zadecyduje, że jego wymagania mają większą wartość niż wymagania użytkowników i trzeba je zaimplementować to jest jego suwerenna decyzja. Etyka zawodowa nakazywałaby jednak poinformować go o potencjalnym konflikcie takim jak opisany wcześniej.

Tak więc jak w projektach zwinnych powinno wyglądać ustalanie co tak naprawdę produkujemy? Wymagania zbieramy od użytkowników końcowych. Priorytety ustalamy z klientem. Proste.

wtorek, 23 października 2007

Wielkość zespołu zwinnego

Temat wielokrotnie poruszany, tym razem doczeka się mojego komentarza. Zwykło sie uważać, że zespół pracujący metodami zwinnymi nie powinien mieć więcej niż 10-12 osób (maksymalna górna granica). Mało kto jednak pisze dlaczego tyle a nie więcej. Co prowadzi, do usilnych prób implementowania metod zwinnych w większych zespołach.

Historię trzeba zacząć od zasad podstawowych. Jedną z wartości zarządzania zwinnego jest "people and interactions over processes and tools", czyli "ludzie i interakcje ponad procesy i narzędzia". Czy to oznacza, że narzędzia i procesy nie są ważne? Nie. Narzędzia i procesy są ważne (zarządzanie zwinne to też proces) ale ważniejsi od nich są ludzie i interakcje miedzy nimi. Każdy kto pracował nad jakimkolwiek bardziej złożonym problemem w grupie ludzi doskonale wie, że choćby nie wiadomo jak dokładne były procesy i narzędzia zawsze zdarzają się sytuacje, kiedy lepiej pójść do kogoś do pokoju i wyjaśnić coś w 2 minuty zamiast (zgodnie z procesem) robić eskalację przez zarząd. Oczywiście mówimy tu o projektach a nie o np. produkcji leków - w przypadku produkcji leków raczej trzeba dokumentować, bo się kończy jak w Jelfie.

Interakcje między ludźmi są najszybszą znaną formą przekazywania informacji. Jakiekolwiek narzędzie spowalnia przekaz informacji, gdyż wymusza zakodowanie informacji do postaci akceptowalnej przez narzędzie (np. zapisanie) a następnie odkodowania przez osobę, która to odbiera (odczytanie). Dlatego w projekty realizowane zwinne cechują się często dużo wyższą efektywnością niż realizowane metodami tradycyjnymi. Po prostu to co jest oczywistością, czyli bezpośrednie przekazywanie informacji zostało tam wbudowane w metodykę zamiast jak to proponuje wiele innych metod udawać, że da się lepiej komunikować przy użyciu narzędzi - głównie dokumentów tworzonych tonami w niektórych projektach.

Dobrze, więc skoro jest tak dobrze się komunikować bezpośrednio to skąd ograniczenie na wielkość zespołu? Jak to w życiu bywa wszystko w nadmiarze szkodzi. Utrzymywanie efektywnego zespołu polegającego na komunikacji interpersonalnej oznacza w skrócie, że członkowie zespołu muszą mieć możliwość swobodnego rozmawiania każdy z każdym i wymiany informacji. Problem w tym, że ilość kanałów komunikacyjnych w zespole rośnie wykładniczo w stosunku do liczby osób w tym zespole. I tak dla zespołu 5 osobowego mamy 10 kanałów komunikacyjnych, dla 8 osób kanałów jest 28, dla 10 osób 45, dla 12 osób 66 kanałów. I tu jest granica, której przekraczać nie należy. Przy 15 osobowym zespole jest już ponad 100 kanałów komunikacyjnych - ponad dwukrotny wzrost w stosunku do 10 osobowego zespołu. Czas poświęcony na dogadywanie się pomiędzy członkami zespołu zaczyna przewyższać wszelkie zyski z wykorzystania szybkich metod komunikacyjnych.

Do wszystkiego należy podchodzić w sposób zgodny z rosądkiem. Ostatnio słyszałem o przypadku firmy X, gdzie wdrożono zwinne zarządzanie projektami a zespoły "po optymalizacji" liczą 20 osób (190 kanałów komunikacyjnych w zespole). Wydaje mi się, że to będzie jeden z tych nielicznych przypadków, kiedy na koniec stwierdzone zostanie, że metody tradycyjne były lepsze. A może to nie stare metody były lepsze, tylko wprowadzenie nowych nieprofesjonalne?

niedziela, 14 października 2007

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.

niedziela, 30 września 2007

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

niedziela, 23 września 2007

Metody zwinne a struktura organizacyjna

Czy struktura organizacji może mieć wpływ na zdolność do działania z wykorzystaniem metod zwinnych? Mogłoby się wydawać, że nie bo co ma struktura organizacji do metod wykorzystywanych w konkretnym projekcie. A jednak...

Dla uproszczenia przyjmijmy, ze mamy cztery podstawowe struktury organizacyjne:
  • Liniowa - organizacja dzieli się na działy, które realizują poszczególne elementy projektu. Każdy dział dostaje do realizacji ten kawałek projektu który odpowiada jego specjalizacji. Cała władza skupia się w rękach kierowników liniowych.
  • Macierzowa słaba - do organizacji liniowej wprowadza się koordynatorów projektów, którzy koordynują pracę osób w poszczególnych działach. Ich zadaniem jest jednak jedynie koordynacja prac, bez możliwości realnego wpływania na pracowników. Bezpośrednimi przełożonymi pracowników są kierownicy liniowi.
  • Macierzowa silna - różni się od macierzowej słabej tym, że pojawia się pełnowartościowy kierownik projektu, który ma odpowiedzialność za projekt ale również uprawnienia do władzy na członkami zespołu projektowego. Kierownicy liniowy pełnią funkcje pomocnicze dbając o zapewnienie personelu, bieżące zarządzanie kompetencjami, sprawy formalne itp.
  • Projektowa - organizacja całkowicie projektowa nie posiada struktur liniowych a tylko pulę pracowników, z których wybiera się członków zespołów projektowych. Kierownik projektu ma pełną odpowiedzialność i uprawnienia do zwierzchnictwa nad członkami zespołu projektowego.
Którą należałoby wybrać dla realizacji projektów metodami zwinnymi? Zanim się na to pytanie odpowie najpierw kilka słów o tym czym powinien charakteryzować się zespół pracujący nad projektem metodami zwinnymi. Poniżej tylko cechy właściwe dla tej dyskusji:
  1. Zespół jest interdyscyplinarny - skupia ludzi o różnych umiejętnościach ale jednocześnie każdy członek zespołu może wchodzić w różne role
  2. Zespół ponosi pełną odpowiedzialność za wykonywaną pracę
  3. Zespół ma wszelkie uprawnienia potrzebne do wykonywania zadanej pracy
  4. Kluczowy członkowie zespołu pracują tylko i wyłącznie nad jednym projektem
W przypadku organizacji o strukturze liniowej żadna z tych cech nie mogłaby być spełniona. Nie ma interdyscyplinarności - w ramach jednego zespołu linowego osoby posiadają prawie identyczne umiejętności. Zespół nie może ponosić pełnej odpowiedzialności za całość prac, bo z definicji wykonuje tylko ten jej kawałek za który odpowiada komórka organizacyjna w której pracuje. Zespół nie ma uprawnień do wykonywania całej pracy a jedynie tego kawałka, który dotyczy ich części organizacji. Ponieważ organizacja jest liniowa a nie projektowa najczęściej pracuje "nad zagadnieniem", które jest w wielu projektach. Cecha czwarta też nie jest spełniona. W takich warunkach nie można prowadzić projektu metodami zwinnymi!!!

W przypadku organizacji macierzowej słabej cecha pierwsza ma się trochę lepiej. Zespół pochodzi z różnych działów, więc jest interdyscyplinarny. Cecha druga jednak nie jest już spełniona, gdyż nadal zespół nie posiada odpowiedzialności - posiadają ją kierownicy liniowi. Podobnie z uprawnieniami - mimo iż jest zespół projektowy to nie ma on możliwości podejmowania decyzji, która leży w gestii kierowników liniowych. Co do cechy czwartej to w tej strukturze organizacyjnej często jest możliwe osiągnięcie stanu kiedy członkowie zespołu projektowego pracują nad jednym i tylko jednym projektem.

Wszystkie cechy zespołu zwinnego są możliwe do osiągnięcia tylko w organizacjach projektowych i macierzowych silnych. Macierzowe silne muszą być na tyle silne, aby rola kierowników liniowych faktycznie ograniczała się tylko do spraw administracyjnych. Trzeba mieć możliwość traktować ich jako wsparcie administracyjno-logistyczne. Jeżeli w rękach kierowników liniowych pozostanie możliwość podejmowania (blokowania) decyzji to okaże się, że zespół zwinny nie będzie miał ani uprawnień ani odpowiedzialności za projekt.

Co z tego wszystkiego wynika? Otóż jeżeli jakaś organizacja będzie chciała wdrożyć zwinne zarządzanie projektami to musi się też zastanowić nad tym, czy jednocześnie nie należy zmienić struktury organizacyjnej. Bardzo często może to powodować spięcia. Przejście z organizacji liniowych czy macierzowych słabych do bardziej zorientowanych projektowo oznacza bowiem, że kierownicy liniowi tracą część swojej władzy. To zaś zawsze jest dla ludzi trudne...

niedziela, 16 września 2007

Poziomy planowania

Dzisiaj krótko o poziomach planowania. Ostatnio musiałem tą koncepcję kilka razy tłumaczyć, co znaczy jest zapotrzebowanie na ten temat. Od razu mówię, że nie jest to kompletne omówienie tematu a raczej jego zasygnalizowanie. Kompletne omówienie zajmuje całą książkę :-)

Z bliżej nieznanych przyczyn część osób, które gdzieś tam tylko usłyszały o "agile" uważa, że w zwinnym zarządzaniu całe planowanie polega tylko i wyłącznie na zaplanowaniu tego co zostanie zrealizowane w następnej iteracji. Z tego powodu pojawia się od razu zarzut, że jest to planowanie zbyt mało dokładne i nie nadające się do "poważnych" zastosowań. Nic bardziej błędnego. Planowanie w technikach zwinnych odbywa się na kilku poziomach, z których poziom iteracji jest owszem najczęściej opisywany, ale na pewno nie jest jedyny. Poniżej skrótowy opis wybranych poziomów planowania, które muszą być zastosowane w każdym projekcie prowadzonym technikami zwinnymi (są jeszcze dwa poziomy nazwijmy je "opcjonalne").

1. Poziom produktu
Podobno chińskie przysłowie mówi, że jak nie wiesz dokąd chcesz iść to nigdy tam nie dojdziesz. Tak samo jest z projektami. Planowanie na poziomie produktu pozwala określić co tak naprawdę projekt ma przynieść. Jakie cele mają być zrealizowane. W odróżnieniu od technik tradycyjnych w technikach zwinnych na tym poziomie nie stosuje się dokładnego planowania a raczej pojęcie i koncepcję wizji produktu końcowego. Wizja ta jest realizowana w sposób zwinny - stąd nie może istnieć dokładny plan na tym poziomie. Jeżeli by istniał, to po co nam zwinność? Istnieją specjalne narzędzia wspomagające planowanie na tym poziomie.

2. Poziom wersji
Po angielsku "release". Jak już wiadomo jest co ma być oczekiwanym rezultatem końcowym produktu/projektu trzeba zaplanować kiedy kolejna wersja produktu trafi na rynek. Wersja jest to coś co jest sprzedawane komercyjnie. I tu uwaga, bo można się pomylić z iteracją. Produktem iteracji też jest działający produkt, ale niekoniecznie jest to wersja do komercyjnej sprzedaży. Natomiast produktem wersji jest zawsze produkt (wersja produktu) idący do sprzedaży i komercyjnego wdrożenia. Na etapie planowania wersji identyfikuje się funkcjonalności, które powinny się w niej znaleźć oraz określa się ile iteracji będzie potrzebnych do wyprodukowania wersji produktu zawierającego zakładane funkcjonalności. Zwykle powinno być to przynajmniej kilka (5-10) iteracji. Można, choć nie trzeba, na tym etapie przypisać wstępnie która funkcjonalność jest do zrealizowania w której iteracji - z założeniem, że to się może pozmieniać. Choć powyższe może brzmi banalnie trzeba mieć świadomość, że aby choć wstępnie określić jakie funkcjonalności przypisać do których iteracji, trzeba mieć wstępną wycenę pracochłonności poszczególnych funkcjonalności. Co czyni planowanie na tym poziomie wcale nie takim prostym jak to się wydaje na pierwszy rzut oka.

3. Poziom iteracji
Najczęściej wspominany w literaturze. Na tym poziomie należy podjąć decyzję na dwóch pod-poziomach. Zespół musi się zobowiązać które funkcjonalności zrealizuje w ramach danej iteracji oraz rozbić te funkcjonalności na zadania do wykonania. Te decyzje zwykle podejmuje sie iteracyjnie, gdyż często aby się zobowiązać do zrobienia czegoś trzeba to lepiej poznać przez rozbicie na zadania. Z drugiej strony powinno się rozbijać na zadania tylko te funkcjonalności, które mają szanse znaleźć się w najbliższej iteracji. Oczywiście przy podejmowaniu decyzji o wyborze funkcjonalności należy kierować się ogólnie przyjętymi zasadami wyboru funkcjonalności, co w praktyce często oznacza, że będzie w to zaangażowany klient lub właściciel produktu. Pamiętać należy, że plan iteracji z punktu widzenia obserwatora spoza zespołu, zgodnie z duchem zarządzania zwinnego powinien być oparty i jasno pokazywać wartość dodaną, która zostanie wytworzona w danej iteracji. Z drugiej strony na tym poziomie planowania poprzez rozbicie na zadania powstaje plan operacyjny dla zespołu pracującego nad projektem. Plan operacyjny oznacza zidentyfikowane zadania do wykonania.

4. Poziom dnia
Na poziomie dnia planuje się i kontroluje operacyjnie działanie grupy. Najgłośniejszą metodą są tu dzienne spotkania zespołu podczas których tak naprawdę jest kontrolowany status poszczególnych zadań. To pozwala porównywać wykonywane zadania z zadeklarowanymi na poziomie planowania iteracji. Daje to kierownikowi projektu natychmiastową informację zwrotną jeżeli tylko cokolwiek idzie nie tak, są odstępstwa od planu. Podkreślenia wymaga fakt, że dziennie również odbywa się planowanie. Jak to się bowiem zwykle dzieje w środowisku projektowym plan traci aktualność z chwilą jego wytworzenia. Planowanie codzienne pozwala mieć bardzo częste aktualizacje informacji o stanie rzeczywistym wykonywanych działań. W przypadku kiedy stan rzeczywisty nie odzwierciedla planu (wcześniejszego przewidywania) należy podjąć działania. W "tradycyjnej" książce czy szkoleniu byłoby w tym miejscu napisane, że działania mają mieć na celu przywrócenie projektu do zgodności z planem. Ponieważ tekst dotyczy metod zwinnych to trzeba przyjąć inną strategię: podjęte działania mają zmaksymalizować ilość dostarczanej wartości dodanej dla klienta przy zachowaniu wartości związanych ze zwinnym zarządzaniem projektami. Mówiąc po ludzku: projekt trzeba zaadoptować do zaistniałej sytuacji.

niedziela, 9 września 2007

Testowanie w projektach zwinnych

W ciągu ostatnich trzech tygodni byłem trzy razy pytany o to jak testować oprogramowanie powstające z wykorzystaniem procesów zwinnych. Pytały trzy różne, niezależne osoby. Oznacza to, że temat jest ciekawy. To co poniżej napiszę to tylko wstęp, ale na początek powinien wystarczyć.

Opiszę jak w podejściu zwinnym odbywa się (powinno się odbywać) testowanie na poziomach testowania jak zdefiniowanych tutaj.

Testowanie komponentów
To jest najprostsze. Testowanie komponentów musi odbywać się obowiązkowo w każdym projekcie realizowanym z użyciem metod zwinnych. Testowanie komponentów zawsze powinno być automatyczne. W zależności od tego w jaki sposób zespół jest przyzwyczajony pracować absolutnym minimum jest napisanie testów automatycznych pokrywających 100% napisanego kodu. Sytuacją dającą najlepsze rezultaty jest programowanie z nastawieniem "najpierw testy" oraz używanie środowiska ciągłej integracji. Chodzi mniej więcej o to, aby w sposób automatyczny wykonywały się testy całości do tej pory zaimplementowanej funkcjonalności. Po każdej zmianie kodu całość powinna być rekompilowana i testy powinny wykonywać się automatycznie. Najlepiej aby raporty z wykonania tych testów były w jakiś sposób publikowane, tak aby każdy mógł je zobaczyć. Na przykład na jakiejś stronie intranetowej.

Takie podejście jest absolutnie konieczne ze względu na dużą zmienność występującą w systemach wytwarzanych metodami zwinnymi. Jeżeli zaniedba się testy automatyczne to po kilku iteracjach w kodzie zapanuje chaos i nie będzie wiadomo co działa a co nie. Gwarantowane.

Testowanie integracji
Uwaga! Poniższe dotyczy testów integracji komponentów. Nie odnosi sie to testowania integracji systemów.

Testy integracyjne należy również zautomatyzować na ile tylko się da. Podstawowe testy integracyjne powinny być wykonywane w środowisku ciągłej integracji, czyli tak często jak się da. Najrzadziej co noc. Problem pojawia się wtedy kiedy mamy się integrować z niestabilnymi komponentami, na przykład tworzonymi równolegle przez zespoły pracujące metodami zwinnymi. Będzie to problematyczne, ale też należałoby tutaj zautomatyzować takie testy do granic, gdzie się da. Zwykle będzie to wymagało dokładnego dogadania się z innymi zespołami na temat wykorzystywanych interfejsów. Brzmi trudno, ale w praktyce powinno być tak, że mniej więcej w połowie iteracji zespoły powinny znać szczegóły interfejsów zewnętrznych swojego komponentu. To powinno zaś umożliwić zautomatyzowanie testów. Trzeba tylko uważać na ewentualne zależności w funkcjonalności poszczególnych komponentów. Takie zależności powinny być rozwiązywane na poziomie zarządzania zwinnego projektem a dokładnie na poziomie zarządzania wieloma zespołami. Przykładem techniki, która to umożliwia jest na przykład "scrum of scrums" - temat na osobny wpis/kilka wpisów.

Szczególną uwagę należy zwrócić na testy wydajnościowe. Ja zaliczam je do testów integracyjnych, gdyż poszczególny test wydajnościowy zwykle dotyczy tak naprawdę testowania współdziałania jednego bądź dwóch modułów systemu, rzadko kiedy całego systemu. Jeżeli komuś to nie pasuje to może uznać je za testy systemowe. W obu wypadkach podtrzymuję to co zaraz napiszę. Testy wydajnościowe powinny być wykonywane co najmniej raz na iterację. Powinny być wykonywane względem celu wydajnościowego ustalonego dla końcowego systemu w karcie ograniczeń produktu. Powinny obejmować wszystkie te funkcjonalności które są dostępne w danej iteracji. Powód takiego działania jest dość prosty. Otóż ze względu na iteracyjność tworzenia oprogramowania w sposób naturalny architektura rozwiązania może się zmieniać. W związku z tym powinno nam zależeć na jak najszybszym dowiedzeniu się czy aktualna architektura aby na pewno odpowiada wymaganiom stawianym przed systemem. Stąd testy wydajnościowe należy przeprowadzać z celami dla całego systemu przynajmniej raz na iterację, żeby było wiadome czy aktualna architektura i wykonanie systemu realizują założone cele.

Testowanie systemu
To najciekawszy poziom testowania z punktu widzenia metod zwinnych zarządzania projektami. Szczególnie ciekawy jest w przypadkach kiedy kilka zespołów pracuje nad kilkoma modułami stanowiącymi jeden system. Pytanie brzmi kiedy i jak testować całość systemu. Oczywiście odpowiedź brzmi, że w świecie idealnym powinno się to robić co iterację. Świat rzeczywisty wygląda jednak często tak, że nie ma na to czasu. Testy systemowe zwłaszcza dużych systemów potrafią trwać zbyt długo, aby można było sobie pozwolić na robienie ich w ramach jednej iteracji. Często głównym powodem jest tutaj fakt, że testy te wymagają dużej aktywności użytkownika końcowego i po prostu nie starczyłoby czasu. W związku z tym dla dużych systemów dopuszcza się dokonywanie testów systemu raz na każdą wersję (release) oprogramowania.

Wersja oprogramowania pojawia się w procesach zwinnych co kilka iteracji. Każda z iteracji ma na celu dostarczenie działającej wersji, potencjalnie mogącej być wysłaną do użytkownika ("potentially shipable product increment" - tak to jest w języku Shakespeare'a). Co kilka iteracji powstaje zaś "wersja" oprogramowania, która jest po prostu komercyjnym produktem mogącym iść na sprzedaż bądź być wdrożonym u klienta. Oczywiście zdarzają się przypadki, kiedy wersja powstaje w każdej iteracji, lecz doświadczenie wskazuje, że są to wtedy raczej mniejsze systemy. Systemy większe, takie które będą miały konieczność dokonania testowania systemu zwykle będą planowane na obu poziomach: wersji i iteracji. Dlaczego o tym piszę? Otóż w takich przypadkach zwykle ostatnia iteracja w wersji jest przeznaczana na testy systemowe. Zakłada się, że wartością dodaną w takiej iteracji jest dostarczenie w pełni zintegrowanego systemu. Oczywiście testy systemowe niekoniecznie muszą zajmować całą iterację. Ale na pewno przyczynią się do zmniejszenia ilości zaimplementowanej nowej funkcjonalności.

Testy akceptacyjne
Tutaj sprawa jest prosta: testy akceptacyjne wykonuje klient po przekazaniu mu każdej jednej wersji do testów. Ze względu na bliskie zaangażowanie klienta możliwe jest przekazywanie produktu nie mającego zaimplementowanych wszystkich funkcjonalności i otrzymywanie natychmiastowej informacji zwrotnej o postępach prac. W przypadku bardzo dobrej współpracy między klientem a dostawcą możliwe jest nawet przekazywanie klientowi zawierającego błędy oprogramowania w środku iteracji - po to, aby sprawdził czy koncepcja zaimplementowania którejś z funkcjonalności odpowiada jego potrzebom.

niedziela, 2 września 2007

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.

niedziela, 19 sierpnia 2007

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

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.

poniedziałek, 28 maja 2007

Innowacje a system

Dzisiaj trochę o tym dlaczego w ogóle w dużych, dobrze zarządzanych systemach innowacja może być problemem. Temat jest bardzo szeroki. Zacznijmy jednak od początku, czyli od pojęcia systemantyki. To pseudo-nauka, której celem jest opisanie w jaki sposób działają (czy też raczej nie działają) duże systemy. Choć w swej istocie i źródłach jest nacechowana dużą dozą ironii czy wręcz krytykanctwa to po głębszym zastanowieniu z większością tez trudno się nie zgodzić. Pisało o tym wielu różnych autorów, w sieci najlepszy tekst opublikował Bart Stewart, dostępny jest tutaj (http://www.draftymanor.com/bart/systems2.htm).

Jako, że mowa będzie o systemach trzeba mieć system, który można będzie zanalizować. Proponuję, żeby każdy wybrał sobie dowolny znany mu system tworzenia/wspierania innowacji. Może to być system wewnątrz korporacji/firmy czy też którykolwiek z rządowych (lub szerzej: publicznych) systemów tego typu. Zobaczmy jak takie systemy innowacji mają się do dwóch wybranych zasad systemantyki. (moje wolne tłumaczenie poszczególny zasad - po oryginały zapraszam do linku powyżej).

I.7 Systemy zwiększając swoją złożoność mają tendencję do przeciwstawiania się celowi dla którego zostały stworzone

Wydaje się bez sensu? A jednak. Najprostszy i najbardziej trafiający do umysłu przykład: system Urzędów Pracy, którego celem powinno być wyeliminowanie bezrobocia. Co się jednak stanie z tym systemem jeżeli nie będzie już bezrobotnych? Czy w interesie systemu jest wypełnienie celu dla którego go stworzono?

Jak to się ma do innowacji? Jeżeli celem stworzenia systemu jest zwiększenie innowacyjności to tak naprawdę rzadko ten system działa dla tego właśnie celu. Cele prawdziwe systemu są zupełnie inne. Zwykle to wsparcie jest wyrażone jakąś metryką, na przykład ilością pomysłów wygenerowanych albo ilością firm, którym udzielono wsparcie. Spełnienie celów opisanych daną metryką jest tym z czego będą rozliczani zarządzający systemem. I teraz czy aby na pewno spełnienie tych celów jest najprostsze poprzez wsparcie innowacyjności? Doświadczenie uczy, że w dużej części przypadków nie. Najprościej dla systemu i dla spełnienia jego prawdziwych celów jest wybrać coś nieszczególnie innowacyjnego. Dlaczego? Bo innowacja to ryzyko a system nie chce ryzykować, tylko spełnić wymagane od niego cele. A w cele i metryki w znakomitej większości przypadków nie uwzględniają ryzyka. Najprostsza więc droga do spełnienia celów postawionych przed systemem wiedzie przez ominięcie ryzyka i innowacyjności!!! Czyli system zaczyna działać przeciw celowi do którego go powołano. Oczywiście nie jest tak we wszystkich przypadkach i są chwalebne wyjątki.

Jaki z tego wniosek: konstruując system, który ma wspomagać innowacyjność postawcie dobre cele. Dobre to znaczy takie, które spełniają kryteria innowacyjności, w tym szczególnie wspomagają podejmowanie działań wysoce ryzykownych. Z drugiej strony jeżeli przystępujecie czy też chcecie skorzystać z tego typu systemu dokładnie sprawdźcie jakie są rzeczywiste (a nie deklarowane) cele takiego systemu i przemyślcie czy z punktu widzenia systemu droga do osiągnięcia celów aby na pewno wiedzie przez działania innowacyjne.

II.2 Elementy systemu nie robią tego, co system twierdzi, że robi
Trochę zagmatwane, ale w skrócie chodzi o to, że żaden z elementów działających w systemie mającym w swoim celu innowacyjność nie zajmuje się innowacyjnością. Ludzie pracujący w takich systemach zajmują się wszystkim innym, tylko nie tworzeniem innowacji. Tworzą raporty, oceniają idee, robią konferencje itp. ale na pewno nie tworzą innowacji samych w sobie. Najlepiej to widać na przykładzie wszelkich publicznych systemów czynienia gospodarki bardziej innowacyjną. Ich rezultatami prawie zawsze są stosy publikacji, konferencje, wykłady, raporty, analizy. Czy widzieliście gdzieś listę innowacji, które faktycznie zostały stworzone za pieniądze z takich programów? Jak ta suma pieniędzy ma się do sumy przeznaczonej na raporty, publikacje i konferencje? Podobnie w firmach dobrze jest sprawdzić jaka jest tak naprawdę efektywność wszelkiego typu programów innowacyjności. Ja osobiście jeszcze nie widziałem takiego systemu, który w sposób przejrzysty zapewniałby takie dane.

Wniosek jest taki, że jeżeli już koniecznie mamy skonstruować system to trzeba bardzo uważać na to aby faktycznie robił on to co powinien. Osobiście jestem zwolennikiem czystago rozliczania po efektach. Czyli na przykład sprawdźmy ile kosztuje rocznie utrzymywanie tej części Urzędów Pracy, która ma znajdować bezrobotnym pracę, po czym podzielmy to przez ilość bezrobotnych, która dzięki tym urzędom pracę znalazła. Zobaczymy jaka jest efektywność. Ta miara pozwoli stwierdzić jaka część naszego systemu tak naprawdę zajmuje się produkcją celów sysemu a jaka część przeznaczana jest na "działania wspierające i koordynujące".

Więcej przemyśleń na podanej stronie. Zachęcam do krytycznego przeczytania i porównania ze znanymi Wam systemami, zwłaszcza pobudzającymi innowacyjność.

I tak na koniec. Sam osobiście słyszałem jak jeden z prezesów pewnej miliardowej korporacji powiedział, że na polu innowacyjności on nie boi się żadnej innej wielomiliardowej korporacji - prawdziwym zagrożeniem dla jego firmy jest dwóch zapalonych młodzieńców w garażu. I to niech będzie morał dysputy o tym jak się mają duże systemy do innowacji.

czwartek, 10 maja 2007

Kontrakty na projekty zwinne - wg. PMI

To tylko zalążek bardzo ciekawego tematu. Prędzej czy później każda osoba, która ma do czynienia z projektami zwinnymi stanie przed pytaniem jak skonstruować kontrakt na taki projekt. Pełna odpowiedź na to pytanie jest zdecydowanie dłuższa niż ten post. Tutaj zajmę się tylko małą ciekawostką, którą znalazłem w książce "PMP Exam Prep" by Rita Mulcahy. Jak tytuł wskazuje książka omawia zarządzanie projektami według standardów PMI. W rozdziale o kontraktach (zarządzanie dostawcami) napisane jest tak (moje wolne tłumaczenie):

"Kontrakty gwarantujące zwrot poniesionych kosztów - [...] Ten typ kontraktów jest stosowany kiedy kupujący potrafi tylko opisać co jest wymagane a nie potrafi opisać co trzeba zrobić (p. kiedy kompletny zakres projektu nie jest znany, tak jak w sytuacjach kiedy kupujemy unikalną wiedzę)[...]
Kontrakty przewidujące stałą kwotę - [...] Ten typ kontraktów jest najbardziej odpowiedni kiedy kupujący potrafi dokładnie opisać zakres kontraktu [...]"
I jeszcze w innym miejscu w tym samym rozdziale:
"Zestawienie zakresu prac kontraktu:
- dla kontraktów gwarantujących zwrot poniesionych kosztów - w tym przypadku zakres prac opisuje tylko wymagania, gdyż kupujemy wiedzę ekseprcką "jak to zrobić". Kupujący może nie wiedzieć dokładnie co i jak trzeba wykonać.[...]
- dla kontraktów przewidujących stałą kwotę - zakres prac musi być całkowicie wyczerpujący, gdyż kupujemy "zrób to" a nie "jak to zrobić". Aby kupujący mógł ustalić cenę musi wiedzieć zawczasu o całym zakresie swojej pracy"
Z powyższego jasno wynika, że nawet tak szacowna i konserwatywna w swoim podejściu do zarządzania projektami instytucja jak PMI uznaje, że jak nie wiadomo jak dokładnie wykonać pracę i kupujemy unikalną wiedzę na ten temat to kontrakty typu fixed-price nie mają sensu. Rewelacja. Od dzisiaj na pytanie o to jakie kontrakty stosować w przypadku projektów zwinnych będę odpowiadał, że zgodnie ze standardami PMI w każdym przypadku kiedy kupujemy wiedzę ekspercką o tym jak wykonać pewną rzecz stosujemy kontrakty typu "zwrot kosztów" a nie "stała cena".

PS. I tak żeby wszystkim uzmysłowić. W przypadku oprogramowania nawet najdokładniejsza specyfikacja wymagań dostarczona przez klienta wcale nie jest "jak to zrobić" tylko nadal "co zrobić". Aby stosować (wg. powyższej definicji PMI) kontrakty "stała cena" w świecie IT trzeba by aby wykonawca dostawał od zleceniodawcy projekt techniczny. Tak robi się na przykład w budowlance. Jak wynajmujecie ekipę, żeby wybudowała dom, to robi ona wycenę na podstawie projektu architektonicznego a nie specyfikacji wymagań typu "chcę cztery okna, dwa pokoje a w kuchni ma być jasno".

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.

SHITS

W nawiązaniu do opublikowanych wcześniej powodów dla których dobrzy managerowie nienawidzą innowacji znalazłem jeszcze jedną ciekawostkę. Tym razem nie jest to powód a taktyka działania. Opisana przez Guy'a Kawasaki w jego książce "Art of Start". SHITS to akronim od:
Show
High
Interest
Then
Stall

Czyli okaż duże zainteresowanie a potem zastopuj. Po chwili zastanowienia można dojść do wniosku, że takie zachowanie jest prostym skutkiem powodów o których pisał Leadbeater. Zacznijmy od tego, że każdy manager wie, że innowacje są potrzebne. Bo taka jest moda, bo tak piszą w książkach, etc. Jednocześnie każdy stara się wykonywać to co od niego oczekują i od czego zależy jego premia. Jak wiadomo premia managerów zależy w znakomitej większości przypadków od bieżących zysków firmy. Aby zaś dbać o bieżące zyski firmy należy dbać o aktualne operacje/bieżące potrzeby. Każde działanie, które nie jest poświęcone zarabianiu pieniędzy teraz jest działaniem, które potencjalnie obniża premię managera. Jakie więc jest poparcie dla takich działań?

Nakładając na siebie dwie odmienne postawy: świadomość tego, że innowacje są potrzebne "na przyszłość" oraz fakt, że wynagrodzenie zależy w większości wypadków wyłącznie od bieżącej zyskowności co się stanie jeżeli jakiś pracownik przyjdzie do dobrego managera z innowacyjną ideą? Otóż na pewno wyrażone zostanie duże nią zainteresowanie. Zainteresowanie wynika z faktu, że przecież innowacje są wpisane w strategię firmy, wszyscy wiedzą że są potrzebne itp. Zainteresowanie ma też jeszcze jedną zaletę: nie kosztuje. Kosztują natomiast następne etapy: eksploracji i rozwoju idei, przekształcania jej w produkt lub usługę. Czy dobry manager pozwoli sobie na przesunięcie części zasobów pracujących na bieżący zysk firmy do takich działań? W większości przypadków nie od razu - chce mieć pewność, że nikt nie będzie miał pretensji do tego, że jego zyski w krótkim terminie mogą zacząć spadać. Zacznie się więc szukanie sponsorów u wyższego managementu, czekanie na kolejny cykl planowania, odwoływanie się do działów centralnych z prośbą o dodatkowe zasoby, sprawdzanie zgodności pomysłu ze strategią firmy. Jednym słowem stopowanie innowatora, który jest już bardzo podekscytowany wyrażonym wcześniej zainteresowaniem. SHITS w czystym wydaniu.

Ciekawe, czy którykolwiek z tych dobrych managerów zastanowił się czasami jak czuje sie taki innowator, któremu najpierw okazano duże zainteresowanie a potem zrzucono na barki tysiące powodów dla których na wdrożenie idei trzeba "poczekać". Ile razy wytrzyma taki cykl zanim dojdzie do wniosku, że lepiej się nie stresować i nie przychodzić z ideami? Ile może stracić firma na utraconych korzyściach.

I na koniec pytanie do wszystkich wyższych managerów w organizacjach komercyjnych: w jakim stopniu Wasze systemy motywacyjne i zarządzania wspierają zarabianie przez Waszą firmę pieniędzy dzisiaj i w przyszłości?

środa, 18 kwietnia 2007

Zwinne zmiany

Nawiązując jeszcze do wspomnianego już tematu zmian w projektach chcę obalić jeden mit związany ze zmianami, tym razem w projektach zarządzanych technikami zwinnymi. Ale od początku.

Oprócz tzw. "standardowych" czy też "tradycyjnych" metod zarządzania projektami istnieje też bardzo bliska mi klasa metod zarządzania projektami określana wspólnym mianem "Agile Project Management" czy też po naszemu zwinnym zarządzaniem projektami. Nadaje się rewelacyjnie do zarządzania projektami o wysokiej niepewności, czyli projektami zwinnymi. Jedną z fundamentalnych wartości zwinnego zarządzania projektami jest:

Responding to change over following the plan.

Czy odpowiadanie na zmianę jest bardziej wartościowe od trzymania się planu. Trzymanie się planu oczywiście też jest wartościowe, odpowiadanie na zmianę jest jednak bardziej wartościowe. O innych wartościach (są 4) zwinnego zarządzania projektami możecie przeczytać tutaj.

Teraz uwaga! Wiele osób błędnie interpretuje wspomniane zwinne podejście jako zachętę do wprowadzania dowolnych zmian, w dowolnych chwilach i generalnie wyrzucenia planu (i planowania) do kosza. To mit i duże nieporozumienie. Zwinne nie znaczy chaotyczne. Odrzucenie planowania i niekontrolowane zmiany prowadziłoby w prosty sposób do chaosu. A zwinne zarządzanie projektami rządzi się ścisłymi zasadami, których łamać nie można. Podobnie jak nie można ich łamać w tradycyjnym zarządzaniu. Łamanie zasad zawsze prowadzi do chaosu, niezależnie od techniki zarządzania.

Aby wyjaśnić temat zmian w zwinnym zarządzaniu należy jednak zacząć od czegoś bardziej fundamentalnego. Projekty zarządzane technikami zwinnymi zawsze realizowane są w iteracjach. Każda z iteracji dostarcza w pełni kompletny, ściśle określony podzbiór ostatecznej funkcjonalności produktu końcowego. Mówiąc prościej: każda iteracja dostarcza wartość dla klienta w postaci działającej wersji produktu. W związku z tym w dowolnym punkcie projektu funkcjonalności produktu końcowego można podzielić na trzy grupy: te, które zostały już zrealizowane, te które są realizowane w bieżącej iteracji oraz te które są do zrealizowania w przyszłych iteracjach. Jedną z najważniejszych zasad zwinnego zarządzania projektami jest: nie wolno wprowadzać zmian do funkcjonalności realizowanej w bieżącej iteracji. Funkcjonalności, które już zostały zrealizowane wolno zmieniać, trafiają one wtedy na listę do realizacji. Funkcjonalności z listy do zrobienia można oczywiście modyfikować bez żadnych warunków. Jeżeli istnieje dobrze uzasadniona potrzeba zmiany funkcjonalności realizowanej w ramach bieżącej iteracji to taką funkcjonalność wprowadza się jako nową na listę funkcjonalności do zrealizowania w przyszłości.

Jaki jest tego skutek? Otóż zespół projektowy w dowolnym momencie trwania projektu zarządzanego technikami zwinnymi pracuje nad niezmiennym zestawem funkcjonalności. Do czasu zakończenia danej iteracji ten zestaw wymagań nie może ulec zmianie. Ewentualnie zmiany pojawią się jako nowe funkcjonalności do zrealizowania w następnej iteracji. W ramach bieżącej zestaw wymagań zawsze jest stały i zawsze ma być ukończony na koniec iteracji. Zwinne oznacza stabilne. Zespół projektowy w każdej chwili zna minimalny zakres czasowy stabilności wymagań: do końca danej iteracji. Odpowiadanie na zmiany jest wyrażane w przyszłych działaniach a nie w natychmiastowej zmianie zakresu pracy dla grupy realizującej projekt. Złamanie tej zasady prowadzi do chaosu. Jest to zupełnie inna sytuacja niż w przypadku projektów zarządzanych tradycyjnie, gdzie zmiana może nastąpić w dowolnej chwili, jak tylko odpowiednie ciało zarządzające zmianami je zatwierdzi.

Wbrew pozorom doświadczenie wskazuje, że członkowie projektów (programiści - z tej branży mam doświadczenia) wolą pracować w stabilnym środowisku zwinnym niż w tradycyjnym projekcie, w którym zmiany spadają nie wiadomo w której chwili i to zwykle z klauzulą "do zrobienia jak najszybciej". Również wbrew temu co mogłoby się wydawać zmiany dotyczące już dostarczonej funkcjonalności po pewnym czasie zaczynają występować bardzo rzadko i projekt zwinny uzyskuje dużą stabilność. Dzieje się tak ze względu na mechanizm wyboru funkcjonalności do realizacji i jego wpływ na decyzje klienta. Ale to już temat na inną historię.

poniedziałek, 16 kwietnia 2007

Dlaczego dobrzy mangerownie nienawidzą innowacji

Prezentację pod takim intrygującym tytułem znalazłem nie tak dawno w sieci. A że zostałem przywołany do głosu na blogu Alexa to podzielę się swoimi spostrzeżeniami wcześniej niż miałem zaplanowane i trochę na szybko.

Prezentację znalazłem na stronach Charles'a Leadbeater'a. Bezpośredni link do prezentacji tutaj. Powody dla których dobrzy managerowie nienawidzą innowacji:
  • Innowatorzy wspierają przyszłość, podczas gdy skuteczne firmy lubią wzmacniać stare sukcesy
  • Innowacje wymagają wolnych mocy przerobowych, podczas gdy managerowie chcą by organizacje były produktywne, żadnego marnowania
  • Trzeba się oduczyć, żeby stworzyć miejsce na coś nowego, podczas gdy tożsamość managerów pochodzi z przeszłości
  • Innowacja to twórczość i wolne wyzwania, podczas gdy bycie managerem oznacza branie odpowiedzialności
  • Innowacja zaczyna się od przyznania się do niewiedzy, podczas gdy bycie managerem oznacza znanie odpowiedzi
  • Innowacja oznacza zapożyczanie i pokorę, podczas gdy managerowie nienawidzą przyznawać się, że ktoś jest lepszy
  • Innowacja rodzi się na styku środowisk, podczas gdy managerowie pozostają w swoich biurach
  • Innowatorzy mają historie do opowiedzenia, podczas gdy managerowie mają plany, liczby i udziały w rynkach
Prezentację i powody te powinien znać każdy, kto w jakiejkolwiek organizacji chce zabrać się za proponowanie lub wdrażanie innowacji. Bardzo często zdarza się, że wprowadzanie jakiejkolwiek zmiany w firmie a w szczególności zmiany innowacyjnej to "droga przez mękę". Najczęściej pierwsze na co człowiek trafia to mur czegoś, co zwykle uważa się za niechęć czy wręcz awersję. Nieumiejętne podejście do tego może zostawić wrażenie, że organizacja składa się z postępowych innowatorów i nic nie rozumiejących managerów. Tymczasem jest inaczej.

Mimo treści, która może być odebrana jako agresywna powyższe tezy warte są uwagi i spokojnego przemyślenia. Największą zaletą wynikającą z przemyślenia tych tez może być zrozumienie różnicy w światopoglądzie (angielskie mind-set, nie wiem jak to lepiej przetłumaczyć) innowatora i managera "organizacji funkcyjnej", do którego taki innowator zwykle musi zwrócić się o akceptację pomysłu i/lub przyznanie środków na jego realizację.

Kiedyś pewien mądry człowiek przekonywał mnie, że każdy człowiek ma rację... ze swojego punktu widzenia. Zawarte powyżej tezy dobrze naświetlają punkt widzenia managera organizacji. Znajomość tego punktu widzenia i jasne porównanie go do "innowacyjnego" punktu odniesienia pomoże znaleźć argumenty, które przekonają drugą stronę do naszych pomysłów. Poznanie potrzeb i światopoglądu pozwoli w prostszy sposób dojść do sytuacji typu wygrana-wygrana, w której szanowane i zaspokajane będą potrzeby obu stron. To znów lepiej na przyszłość ułoży stosunki między obiema stronami i znacznie zwiększy szanse powodzenia projektu.

Wszystkim zaś managerom liniowym/funkcyjnym w organizacjach bardzo polecam zapoznanie się z całością prezentacji a zwłaszcza z radami, które tam występują. O ile oczywiście zależy Wam na tym, aby Wasza organizacja była innowacyjna. I na tym, aby lepiej zrozumieć tych dziwnych ludzi, którzy przychodzą do Was i coś chcą zmieniać.

Kierownik projektu a zmiany

Czytam właśnie znaną i uznaną książkę na temat zarządzania projektami. Polecana przez dużą część znanych mi kierowników projektów. Wszystko z tą książką było dobrze do czasu aż nie doszedłem to rozdziału pt. "Zarządzanie zmianą w projekcie". Zaczął się całkiem interesująco, ale gdzieś tak w czwartym-piątym akapicie natrafiłem na takie zdanie i to jeszcze wytłuszczone:

"Zadaniem kierownika projektu jest unikanie zmian."

Przeczytałem raz, drugi, trzeci. Zdanie nie znikło. Więcej jego parafrazy pojawiały się odtąd regularnie w całym rozdziale. Ciekawe spojrzenie na rolę kierownika projektu. Zdecydowanie odległe od mojego.

Umówmy się: dzisiejszy świat zwariował. A wydatnie pomogły w tym techniki komunikacyjne. W tym świecie dzieje się za dużo, żeby ktokolwiek mógł to opanować i co więcej o wszystkim tym jesteśmy informowani czy tego chcemy czy nie. W związku z tym nie ma praktycznie możliwości, aby jakikolwiek plan odpowiadał rzeczywistości. Proces tworzenia planu musi się bowiem opierać o pewne dane, które trzeba "zamrozić" na czas tworzenia planu, co często trwa dość spory kawałek czasu. W tym samym czasie zmienia się rzeczywistość i założenia na podstawie których plan został stworzony. Dlatego każdy plan jest przestarzały w chwili kiedy skończymy go opracowywać. To w sposób oczywisty wcześniej lub później prowadzi do sytuacji, kiedy zauważamy, że to co robimy w sposób nieoptymalny odpowiada rzeczywistości. Kluczowe pytanie polega na tym jak w takiej sytuacji zareagować?

Są dwa podejścia: trzymamy sie planu ("zadaniem jest unikanie zmian") albo odpowiadamy na zmianę. Które podejście jest lepsze? Zapytam inaczej: jako ostateczny użytkownik/klient produktu wytwarzanego w ramach projektu jak byście chcieli żeby zachował się kierownik projektu?

Żeby się przekonać zobaczmy to na przykładach. Z dziedziny jak najbardziej odległej od bliskiego mi wytwarzania oprogramowania. Zwykle mówi się, że w software to wszystko jest proste, bo koszty zmian są niewielkie. Za to na przykład w takim budownictwie, to już wszystko musi być na pewno w zgodzie z planem, bo tam koszty zmian i w ogóle się nie da. No to posłuchajcie.

Wrocław, pewna duża działka w bezpośrednim sąsiedztwie Obwodnicy Śródmiejskiej, bardzo ładnie położona blisko parku z rewelacyjnym dojazdem, niecałe 4 km od ścisłego centrum. Kupiła ją firma inwestycyjna i zaplanowała postawienie tam parterowego supermarketu z potężnym parkingiem. Uzyskanie pozwoleń, projektu itp. zajęło im (na ich szczęście jak się później okazało) około 3-4 lat. W tym czasie średnia cena metra kwadratowego mieszkania skoczyła we Wrocławiu z około 2000 PLN do około 8000 PLN. Działka blisko centrum, w pobliżu parku, zielono, spokojnie... Obecnie trwa tam budowa zespołu kilkupiętrowych apartamentowców z cenami niektórych mieszkań sięgającymi 10000 PLN za metr kwadratowy. Ile kosztowałoby firmę (w sensie utraconych korzyści) gdyby kierownik i sponsor projektu potraktowali na poważnie zasadę unikania zmian?

Drugi przypadek jeszcze bardziej ekstremalny. Budowa drogi w okolicach Wrocławia, rok zdaje się 1999. Budowa już trwała ale jednemu z bardziej doświadczonych ludzi w ekipie coś przestało pasować. Przyjrzano się powtórnie dokumentacji i okazało się, że projekt techniczny został sporządzony na podstawie planów geodezyjnych sprzed 1997 czyli sprzed powodzi. Tymczasem powódź coś tam pozmieniała w glebie (co dokładnie nie wiem, nie jestem geologiem, ale zdaje się gęstość gleby). Sytuacja była taka, że drogę, a zwłaszcza występujący w jej ciągu wiadukt, dało się co prawda zbudować według oryginalnego planu, ale takie wykonanie nie gwarantowało, że droga przetrwa pierwszy rok eskploatacji - zapadłaby się. Czy w takiej sytuacji zadaniem kierownika projektu też miało być unikanie zmian? Z tego co się orientuję po dość długich negocjacjach z inwestorem projekt został zmieniony, droga spełnia wszelkie normy i służy do dzisiaj.

Naprawdę nie czułbym się komfortowo jako klient firmy, która pozostaje głucha na zmiany.

Podsumowując, po mojemu będzie więc tak:

"Zadaniem kierownika projektu jest odpowiadanie na zmiany."