Własność funkcjonalności

W projektach informatycznych zdarza się bardzo często sytuacja kiedy projekty jest na tyle duży, że do poprawnego zdefiniowania wymagań potrzeba więcej niż jednej osoby. Po prostu wiedza dziedzinowa dotycząca projektu nie jest możliwa do zgromadzenia przez jedną osobę. W takim wypadku szczególnej uwagi nabiera kwestia tego, kto jest "właścicielem" poszczególnych funkcjonalności.

Przez właściciela funkcjonalności rozumie się osobę, która jest w pełni odpowiedzialna za zdefiniowanie danej funkcjonalności i zwykle będzie osobą używającą jej w przyszłości (odbiorcą korzyści biznesowej dostarczanej przez daną funkcjonalność). Zdefiniowanie takiej osoby jest niezmiernie ważne w kontekście mogących się pojawić wątpliwości dotyczących tego jak ma działać zdefiniowana funkcjonalność. Musi być ktoś, kto ma ostateczny głos w sprawie zdefiniowania pożądanego sposobu zachowania się systemu. W mniejszych systemach tą osobą jest właściciel produktu, w większych często właściciel produktu nie ma wystarczającej wiedzy aby decydować o każdej funkcjonalności i dlatego warto wyznaczać właścicieli poszczególnych funkcjonalności. Najlepiej właściciela po prostu zapisać na karcie funkcjonalności.

Powyższy system działa dobrze, do czasu kiedy nie zajdzie sytuacja w której dwie funkcjonalności zdefiniowane przez różne osoby stoją w konflikcie ze sobą. Wbrew pozorom często tak jest. Na przykład w systemach kompleksowo obsługujących przedsiębiorstwa proces sprzedaży zakłada zwykle udział działów sprzedaży, magazynu, księgowości a często także produkcji. Każdy z tych działów może mieć różną koncepcję tego jak proces sprzedaży wyglądać powinien. W takich sytuacjach osobą rozstrzygającą powinien być właściciel produktu. Niezależnie bowiem od właścicieli poszczególnych funkcjonalności musi istnieć ktoś, kto jest odpowiedzialny za całość definiowania wymagań i w związku z tym za ostateczny kształt projektowanego systemu. Tą osobą jest właśnie właściciel produktu. W przypadku dużych systemów, gdzie występuje wielu właścicieli funkcjonalności brak właściciela produktu jest bardzo często spotykanym błędem.

I na koniec: w takich sytuacjach jak opisana bardzo ważne jest, aby właściciel produktu był mocno "umocowany" w strukturze organizacji. Jest to konieczne, gdyż prędzej czy później będzie musiał on godzić wymagania różnych działów i forsować rozwiązania korzystne dla całości przedsiębiorstwa a nie dla poszczególnych kierowników. Osoba nisko stojąca w hierarchii, bez odpowiedniego autorytetu formalnego i nieformalnego nie ma szans w starciu z kierownikami "silosów". Wyznaczenie mało znaczącego właściciela produktu jest drugim bardzo często popełnianym błędem w opisywanych sytuacjach.

Księga procedur a 15 minut

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

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

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

Założenia to przekleństwo

Czasami warto jest się przyjrzeć głębiej powodom, dla których podejmowane są działania uważane przez wszystkich za oczywiste. Dla przykładu pierwsza z brzegu rzecz czyli planowanie. Wszyscy wiemy, że to jest ważne, jest podstawą pracy itd. Projekty z definicji są działaniami, które są innowacyjne, które zawierają w sobie pewien element niepewności. Dlatego też musimy je planować a nie działać automatycznie jak to się robi w przypadku procesów. Plan jest następnie realizowany, po czym, w dużej części przypadków, następuje brutalne zderzenie z rzeczywistością, które dla planu okazuje się być nie do przeżycia. Zwykle w wyniku nieprzewidzianych zdarzeń muszą nastąpić poważne zmiany w planie jak i w samych produktach projektu.

Interesujące jest co dzieje się dalej. W większości środowisk, z którymi miałem do czynienia podejmuje się natychmiastowe działania naprawcze skupiające się wokół generalnego twierdzenia "musimy lepiej planować". Przez "lepiej" w tym wypadku określa się zwykle dogłębniej, dokładniej i bardziej szczegółowo. Generalnie bardziej kosztownie. I tu pojawia się pytanie następujące. Jakie założenie stoi za twierdzeniem, że więcej zasobów poświęconych na planowanie automatycznie przekłada się na lepszą realizacje tychże planów w przyszłości?

Jak dla mnie założenia za tym twierdzeniem są następujące "planując dłużej uzyskujemy większą kontrolę nad przyszłością" oraz "dłuższe planowanie powoduje zmniejszenie liczby zmian w przyszłości". Czy te założenia są prawdziwe? Wątpię. Czy to oznacza, że planowanie jest zbędne. Oczywiście nie. Oznacza tylko, że nigdy nie możemy oczekiwać, że maksymalne wydłużenie analizy i planowania spowoduje automatyczny sukces naszego projektu. Tak się nie dzieje. Od pewnego momentu mimo przeznaczania coraz większych nakładów na planowanie "uzysk" dokładności jest minimalny. A im działanie jest bardziej innowacyjne tym to "wypłaszczenie" następuje szybciej.

Co z tym zrobić? Może zamiast brnąć w taki system oparty na błędnym założeniu skonstruować system, który dostosowuje się do rzeczywistości. Czyli zadać sobie pytanie "jak powinien wyglądać mój system realizacji projektów jeżeli założę, że zmiany na pewno nastąpią". Jeżeli uda się taki system zbudować i wprowadzić w życie to zamiast walczyć z rzeczywistością otrzymamy organizację potrafiącą w danej rzeczywistości idealnie zarządzać.

P.S. Oczywiście powyższe wywody nie dotyczą pewnej klasy systemów, np. takich gdzie gra idzie o życie ludzkie (projektowania samolotów).

Metody realizacji projektów

Poniżej moje autorskie, przygotowane w konkretnym celu i dla konkretnej okazji, o której tutaj nie będę pisał, porównanie metod realizacji projektów. Można używać do woli, pod warunkiem podania źródła.

Metoda ścieżki krytycznej + EVM
Motywacja historyczna:
W dużych projektach rządowych chciano wiedzieć, na którym ciągu zadań powinien skupiać się kierownik, aby zapewnić realizację projektu w czasie.

Typowe rezultaty wdrożenia metody:

• Projekt zobrazowany jako lista prac do wykonania na osi czasu
  
• Ustalona odpowiedzialność za zadania
• Zmniejszone ryzyko opóźnienia projektu
• Możliwość formalizacji planowania i zarządzania projektami
• Iluzja pełnej kontroli (daty rozpoczęcia i zakończenia każdego zadania)
  
• Realna możliwość oceny efektywności prac zakończonych (EVM)
  

Typowe przeszkody we wdrożeniu

• Metoda tak stara, że teoretycznie nie powinno być, ale:
• Wymusza dużą formalizację projektów
• Nie daje szybkich wygranych
• Generowane są dane a nie informacje
• Łatwo skupić się na przerzucaniu formularzy zamiast zarządzaniu projektem
  

Łańcuch krytyczny (CCPM)
Motywacja historyczna:
Dla przedsiębiorstw komercyjnych kluczowe stało się realizowanie projektów w pierwotnie planowanym terminie przy ograniczonej liczbie zasobów


Typowe rezultaty wdrożenia metody:

• Projekt zobrazowany jako sieć połączonych zadań
• Ustalona odpowiedzialność za zadania
• Minimalne choć bardzo intensywny proces nadzorowania projektów
  
• Brak przeciążenia zasobów
• Maksymalizacja prawdopodobieństwa oddania projektu na czas (do 95%)
  
• Możliwość proaktywnego nadzorowania realizacji

Typowe przeszkody we wdrożeniu

• Brak jest jasnego uzasadnienia biznesowego wdrożenia
• Wymaga zmiany kultury pracy i mierników
• Pełne wdrożenie wymaga zgody wszystkich szczebli i działów
• Metoda na tyle skomplikowana, że wymaga wdrożenia zintegrowanego systemu IT
  
• Postrzeganie jako wdrożenia tylko systemu IT
• Metoda nieodporna na zmiany sieci projektu w trakcie trwania

Metody zwinne (agile)
Motywacja historyczna:
Branża informatyczna zauważyła, że konieczność planowana całości projektu przed jego rozpoczęciem nie sprawdza się w środowisku, gdzie zmiany bardzo łatwo się wprowadza – zastosowano podejście radykalnie różne od dotychczasowych


Typowe rezultaty wdrożenia metody:

• Projekt rozpisany jako lista funkcjonalności produktu
• Szybkie dostarczanie najbardziej wartościowych funkcji
• Nowe wersje dostarczane regularnie
• Łatwe dostosowywanie produktu do zmian
• Można pracować mimo braku pełnego planu
• Zdrowe relacje w zespołach
  
  

Typowe przeszkody we wdrożeniu

• Zbyt proste – wszyscy myślą, że zrozumieli
• „Cieńka czerwona linia” między chaosem a agile
• Wyższe szczeble zarządzania chcą „ciężkich” procesów
• Kierownicy produktu nie trzymają się założeń
• Wymaga zmiany kultury pracy i mierników

Na koniec drobna uwaga:

Odpowiedzialnością każdego specjalisty, w tym kierownika projektów, jest znać jak najwięcej różnych narzędzi i stosować te, które najlepiej spełnią cele postawione w danej sytuacji. Jak to kiedyś ujął mój kolega "chroń mnie Panie przed człowiekiem, który przeczytał tylko jedną książkę".

PMO w sposób zwinny

Rok temu opublikowałem tutaj posta na temat wprowadzania zmian w organizacjach metodami zwinnymi:
http://www.wlochowicz.com/blog/2008/05/zwinne-zarzdzanie-zmian-w-organizacji.html

Natomiast parę dni temu znalazłem na PM Hut posta na temat... wprowadzania PMO w organizacji własnie dzięki metodom agile. Cytat:

If you’re building a PMO and have a 3 year plan – drop it now! [...] As you’ve guessed by the article title I am going to suggest that we steal a technique from the software development industry. While I am not an agile expert by any means, there are some very successful practices that you can employ while building and growing your PMO.

Czyli da się. Jest to możliwe nawet do wprowadzania zmian tak rozległych jak PMO w organizacji.

Całość do przeczytania na PM Hut:
http://www.pmhut.com/the-agile-project-management-office-pmo

Narzędzia efektywnego zarządzania mniejszymi projektami

Tytuł tego postu to jednocześnie tytuł mojego wystąpienia na seminarium PMI we Wrocławiu 24 marca. Poniższą treść można traktować jako handout tej krótkiej prezentacji.

Na początek zdefiniujmy sobie co to jest ten “mniejszy projekt”. Metodą Alberta Einsteina mniejszy projekt to dla mnie projekt, dla zarządzania którym użycie MS Project jest zbyt skomplikowane / powoduje zbyt duży narzut zarządczy. W organizacjach takich jak je znam jest realizowanych wiele, bardzo wiele projektów, z których znacząca część to projekty małe. Ot choćby zmiana jednej czy drugiej procedury obsługi klienta, zorganizowanie spotkania dla klientów czy też wydanie nowej wersji katalogu firmowego. Tego typu aktywności często charakteryzują się wszystkimi cechami projektu, z tą właściwością, że ich złożoność jest o kilka rzędów wielkości mniejsza od złożoności projektu budowy nowego biurowca czy stworzenia systemu informatycznego. W związku z tym narzędzia informatyczne konstruowane z myślą o zarządzaniu projektami wielkości budowy biurowca nie mogą być wykorzystywane w sposób efektywny do tych mniejszych projektów. Głównie ze względu na swoje skomplikowanie, które powoduje, że narzut czynności zarządczych, które trzeba wykonać jest nieproporcjonalny do wielkości projektu.

Dla takich mniejszych projektów efektywne narzędzia wspierające zarządzanie nimi powinny być też mniejsze i zdecydowanie inaczej konstruowane. Na czym powinny się skupiać? Według PMI, i jest to niewątpliwie prawda, znacząca większość czasu pracy kierownika projektu jest poświęcona na komunikowanie się. W tym w szczególności na komunikowanie się z zespołem projektowym na temat poszczególnych zadań, ich statusów oraz postępu prac. W związku z tym jeżeli mówimy o efektywnym zarządzaniu projektami to podstawową funkcją, którą muszą wspierać narzędzia jest komunikacja.

Takimi właśnie narzędziami są pojawiające się ostatnimi czasy platformy internetowe oparte o technologi szumnie nazywane Web 2.0. Wiele z tych narzędzi było wręcz pisane jako nie-MS Project z nastawieniem na obsługę projektów mniejszych. Co ciekawe znacząca większość tych narzędzi kładzie nacisk właśnie na aspekty komunikacji w zespole i stara się rozwiązać ten problem poprzez udostępnienie wspólnej dla wszystkich interesariuszy platformy komunikacyjnej. Narzędzia te mają ze sobą wiele wspólnego. Do wspólnych cech zaliczyć należy przede wszystkim (oprócz dostępu przez internet z dowolnego miejsca na świecie a często także z dowolnego urządzenia mobilnego) nastawienie na maksymalne uproszczenie funkcjonalności i uczynienie doświadczenia użytkownika z pracy z narzędziem jak najbardziej pozytywnym. Poza tym, twórcy tych narzędzi garściami czerpią ze Steva Jobsa i zazwyczaj umieszczają w nich tylko i wyłącznie niezbędne funkcje, co czyni te narzędzia prostymi i efektywnymi w użyciu. Przykładowymi, choć istnieje o wiele więcej, narzędziami tego typu są BaseCamp i ActiveCollab.

Narzędzia te zbudowane są wokół koncepcji realizacji projektu poprzez osiąganie kolejnych kamieniu milowych, które to znowu są osiągane poprzez realizację zestawów zadań. Choć różni się to w szczegółach pomiędzy narzędziami to większość z nich pozwala na zdefiniowanie dla projektu dat osiągnięcia kamieni milowych. Następnie dla danych kamieni tworzy się listy zadań, przypisując odpowiedzialności do członków zespołów. Realizacja zadań jest wspomagana poprzez udostępnienie miejsca na dyskusje (coś w rodzaju forów internetowych), przechowywanie plików oraz inne dodatki zależne od konkretnego narzędzia. Śledzenie postępu przez kierownika odbywa się poprzez skondensowane dashboard’y prezentujące na jednym ekranie przeglądarki stan tego co dzieje się w projekcie. Jest to zwykle bardzo ciekawie zorganizowane, bo pokazuje stan komunikacji (co, kto, kiedy powiedział/wysłał/zaraportował) a nie jakiś wyimaginowany procentowy stan zaawansowania pracy. Takie podejście powoduje umieszczenie w jednym miejscu wszystkich informacji z realizacji projektu a także bardzo dobry pogląd na to, co się z tym projektem od strony wymiany tejże informacji dzieje.

Narzędzia te oczywiście mają także wady. Zaliczyć należy do nich głównie fakt, że czasami, zwłaszcza w sytuacjach kiedy bardzo zależy nam na czasie, mimo wszystkich uproszczeń ich użycie jest zbyt skomplikowane. Głownie dlatego, że mimo najnowszej technologii powiedzenie czegoś w bezpośredniej rozmowie jest nadal najbardziej efektywną formą komunikacji i nigdy chyba nie dorobimy się innej równie efektywnej. Drugą dużą wadą jest dla mnie to, że mimo wprowadzenia centralnego miejsca przechowywania informacji większość z tych narzędzi nie zapewnia kontroli wersji notatek, które tam się znajdują. To znaczy, że jeżeli ktoś wprowadzi jakąś informację to później można ją edytować i nie pozostawia to żadnego śladu. Takie zachowanie może wprowadzić szybko chaos komunikacyjny, zwłaszcza jeżeli osoby nie pracują w tej samej lokacji fizycznej. Kolejną wadą, czy też w tym przypadku raczej cechą, jest to że trzeba być bardzo świadomym wybierając to a nie inne narzędzie. Nie do każdego projektu one się nadają i realizacja nie każdego może być aż tak uproszczona. Ze względu na brak możliwości wymuszania sekwencji wykonywania zadań bardzo duża część projektów nie będzie mogła być efektywnie zarządzana.

Na koniec wypada tylko dodać, że jest to kolejna klasa narzędzi, którą warto znać. I używać wtedy i tylko wtedy kiedy ma to sens i jest właściwe dla danej sytuacji. Zdrowy rozsądek musi w pracy kierownika projektów odgrywać rolę pierwszoplanową.

Dyspozytor vs. Delegujący

Jak wiadomo instytucję szefa wymyślono między innymi po to, aby zarządzać zestawami zadań zbyt dużymi do zrealizowania przez jedną osobę. Istnieją dwie metody w ramach których szef może podzielić się swoim zadaniem. Umownie nazwijmy to byciem dyspozytorem bądź delegującym. Dyspozytor to osoba, która przekazuje konkretną instrukcję do wykonania. Rozdziela pracę rozumianą jako zadania do wykonania. To znaczy każdy z członków zespołu otrzymuje listę rzeczy do wykonania a następnie rozliczany jest z tego czy postąpił zgodnie z przekazaną instrukcją.

Delegowanie natomiast to zupełnie inne podejście. Zamiast przekazywać zadania przekazuje się odpowiedzialność. Czyli określa się pożądany cel i jego parametry jakościowe, natomiast nie przekazuje się wprost instrukcji jakie zadania i w jakiej kolejności należy wykonać, aby określony cel uzyskać. W tym podejściu zakłada się, że sposób dojścia do celu najlepiej znany jest osobom faktycznie wykonującym daną pracę a nie menedżerom. Rolą menedżera jest przekazać odpowiedzialność, zapewnić pracownikowi środowisko, w którym może wykonywać swoją pracę bez przeszkód a następnie odebrać prace sprawdzając czy założone cele zostały osiągnięte.

W metodach zwinnych zarządzania projektami tak naprawdę możliwa jest do zastosowania tylko i wyłącznie metoda druga. Próba zastosowania metody pierwszej (dyspozytora) prowadzi bardzo szybko do powstania wąskich gardeł zarządczych na poziomie kierowników. W środowiskach agile za dużo rzeczy dzieje się zbyt szybko, aby kierownik mógł panować nad nimi na poziomie zadań do wykonania. Jeżeli chcemy aby w naszym środowisku osiągać szybko rezultaty to jedyną opcją jest przekazywanie odpowiedzialności. Fakt, menedżer traci kontrolę nad sposobem wykonywania pracy i musi swoim ludziom zaufać. Ale jednocześnie zyskuje możliwość osiągnięcia końcowego rezultatu wielokrotnie szybciej niż przy użyciu bardziej tradycyjnej metody dyspozytorskiej.

Należy tylko pamiętać, aby razem z odpowiedzialnością wydelegować uprawnienia. Najgorszą sytuacją, którą można zafundować swoim podwładnym jest dać im odpowiedzialność za coś, ale bez uprawnienia do decydowania o wszystkich zasobach i środkach potrzebnych do wykonania danej pracy. Stawiamy wówczas pracowników przed koniecznością wykonania pracy na którą nie mają wpływu. Nie mogą więc sami decydować o jej sukcesie bądź porażce. Taka sytuacja prowadzi wprost do dużej i narastającej frustracji osób zaangażowanych w projekty.

Last but not least wypadałoby jeszcze pamiętać o różnicach kulturowych. Ci z Was, którzy mieli przyjemność pracować z Hindusami dokładnie wiedzą, że zastosowanie znajduje tylko i wyłącznie jedna z opisywanych metod.

Przyczyna źródłowa

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

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

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

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

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

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

Jidoka

Czytając wspomnianą tutaj już książkę “Implementing Lean Software Development” jeden element wybitnie wrył mi się w pamięć jako zupełnie dla mnie nowy. W ramach przedstawiania produkcyjnego lean’u i jego zasad autorzy opisali coś, co nazywa się po japonsku jidoka a po angielsku autonomation. Po polsku będzie chyba autonomizacja (?? choć po przemyśleniach nie wydaje mi się). Koncepcja jest tak prosta i tak oczywista, że wręcz dziwię się, że nigdy nie słyszałem o jej zastosowaniu do rozwoju oprogramowania.

W przypadku produkcji jidoka polega na tym, że każde odchylenie od pożądanego standardu jest natychmiast wychwytywane na bardzo niskim poziomie zarządczym a następnie usuwa się, uwaga, przyczynę powstania problemu a dopiero później powraca się do pracy. W praktyce oznacza to, że każdy z robotników pracujących przy taśmie jeżeli zauważy jakiekolwiek odchylenie od pożądanego stanu ma prawo i obowiązek natychmiast zatrzymać całą linię produkcyjną. Następnie znaleźć przyczynę takowego niepożądanego stanu rzeczy, wyeliminować ją i dopiero potem następuje ponowny rozruch linii. Ciekawe jest to, że te działania są podejmowane przez pracowników liniowych, bądź ich bezpośrednich przełożonych bez zwracania się o radę i decyzję do wyższego kierownictwa. Stąd termin autonomizacja - elementy organizacji uzyskują autonomię pozwalającą im podejmować działania podwyższające jakość bez konieczności czekania na decyzję wyższego kierownictwa.

Genialne. Głównie dlatego, że w ten sposób unika się powstawania wąskich gardeł decyzyjnych wyżej w strukturze firmy. Managerowie nie są zasypywani dużą ilością błahych i oczywistych spraw do rozwiązania, tylko mają czas myśleć nad rzeczami strategicznymi. A o jakość dbają ci, którzy są najbliżej czyli pracownicy.

Jak to się ma do rozwoju oprogramowania? Ano tak, że zgodnie z tą koncepcją każdy członek zespołu pracującego nad nowym oprogramowaniem miałby możliwość zatrzymania produkcji jeżeli tylko zobaczyłby, że nie spełnia ona jakościowych wymagań. Następnie miałby obowiązek znaleźć przyczynę wystąpienia tego odstępstwa oraz ją usunąć. Czyli na przykład jeżeli kodując funkcjonalność X przykładowy programista zorientuje się, że funkcjonalność Y nie działa zgodnie ze specyfikacją to ma obowiązek zatrzymać prace i zbadać dlaczego tak się stało. Może brakuje jakiegoś unit testu? To trzeba go dopisać, poprawić funkcjonalność Y i dopiero potem wrócić do pracy nad X. Oprócz unikania wąskich gardeł decyzyjnych ma to też taką oczywistą zaletę, że nie pozwala na zaniedbanie starszego kodu. Ma też tą wadę, że zakłada iż wymagania jakościowe są na tyle dobrze zdefiniowane, że każdy będzie w stanie wychwycić odchyłkę od normy. A to niestety często nie jest prawda. Niestety. Podkreślić tu bowiem należy, że niezależnie od przyjętej metody zarządzania projektem informatycznym te wymagania, które już weszły do produkcji muszą być na tyle dobrze zdefiniowane aby można było sprawdzić ich jakość. No ale to już temat na osobny post, który zresztą już chyba kiedyś się tutaj pojawił.

A jidoke zastosuję przy najbliższej nadarzającej się okazji :-)

Dług technologiczny

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

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

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

Obciążenie systemu

Ludzie instynktownie rozumieją, że jeżeli obciążymy serwer do 100% jego mocy spowoduje to nagły spadek wydajności, drastyczne zwiększenie czasu oczekiwania na odpowiedź oraz ogólnie rozumiany brak stabilności. Jednocześnie tak bardzo dziwią się jak Google może utrzymać krótki czas reakcji na zmiany na rynku, bardzo dużą wydajność pracy oraz stabilność, pozwalając swoim programistom na 20% pracy na rzecz zadań nie związanych z ich aktualnymi projektami.

Przecież to jest to samo. Tak jak serwer, aby utrzymać maksymalną wydajność i krótki czas odpowiedzi nie powinien być przeładowany pracą na więcej niż 80% tak samo pracownik, aby utrzymać maksymalną wydajność i krótki czas reakcji nie powinien być przeładowany powyżej 80% swojego czasu. Co ciekawe jeżeli obciążenie serwera zaczyna w zwykłej firmie oscylować w okolicach 80% to zwykle dyrektor działu IT natychmiast występuje z wnioskiem o zakup nowego serwera. Z drugiej strony jeżeli pracownik jest obciążony na 80% to w zwykłej firmie dyrektor (nawet ten sam) zwykle... dorzuci mu jeszcze jeden projekt. A potem bardzo się będzie dziwił, że czas oczekiwania na efekt gwałtownie rośnie a wydajność spada. Gdzie tu logika?

(temat zaczerpnięty z książki “Implementing Lean Software Development”)

Budowanie dla utrzymania

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

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

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

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

Bardzo, bardzo dobra książka...

Implementing Lean Software Development - czytam i muszę powiedzieć, że jestem zaskoczony tym jak dobra jest ta książka. Stanowi ona zestaw prawd na temat zasad rządzących światem tworzenia oprogramowania. Zestaw ten poparty jest wieloma, naprawdę wieloma przykładami z doświadczenia własnego autorów.

Od dziś jest to dla mnie lektura obowiązkowa dla każdego menedżera zajmującego się rozwojem oprogramowania. Pewne koncepcje w niej zawarte na pewno przemyślę, przedyskutuję i podzielę się nimi na tym blogu.

Wdrożenia nowych metod - zadanie domowe

W środowisku osób zajmujących się wdrożeniami systemów zarządzania projektami (chodzi tu o systemy rozumiane jako zestawy procesów a nie oprogramowanie) do rangi anegdoty kultowej urosło podobno prawdziwe zdanie, wypowiedziane przez jednego z konsultantów pod koniec długiego i kosztownego projektu wdrażania nowej metody zarządzania projektami w pewnej firmie (XXX - nazwa metody zarządzania projektami):

“Jak na dziś to wszyscy już rzygają tym naszym XXX, w związku z czym wdrożenie uważam za w pełni zakończone sukcesem!!!”

Hmm. Przypadek wręcz kliniczny, który przypomniał mi się w ramach kolejnej rundy rozważań nad pewnym nieudanym wdrożeniem metod agile. Pytanie brzmi następująco. Jeżeli wdrażamy coś (cokolwiek) nowego w organizacji i jako efekt dostajemy aktywne niezaangażowanie osób do których adresowane było wdrożenie tego czegoś, to o czym to świadczy? Hipoteza jest taka, że po prostu nie odrobiliśmy pracy domowej i wdrożyliśmy rzecz, która jest absolutnie niepotrzebna z punktu widzenia osób zaangażowanych lub mimo, że rzecz jest potrzebna, to sposób jej wdrożenia jest nieadekwatny. Przez rzecz niepotrzebna rozumiem nie pozwalająca jednostkom na osiąganie lepszych rezultatów. Rezultatów mierzonych w sposób taki w jaki się je mierzy dla każdego konkretnego człowieka w tej konkretnej organizacji. Innymi słowy, mówiąc kolokwialnie z wprowadzonej przez nas zmiany człowiek “nic nie będzie miał”.

Oczywiste pytanie to czy każdy musi z tego wdrażanego rozwiązania coś mieć. Jasne, że tak! Bo skoro organizacja jako całość ma na danej nowości zyskać, to dlaczego nie mieliby zyskać poszczególni uczestnicy tej organizacji? Wszyscy uczestnicy. Z jakiego powodu tak często zakładamy, że wdrożenie czegoś nowego musi być robione przeciw ludziom a nie z ludźmi? Czy naprawdę jeżeli wdrażamy coś nowego to musi być tak, że ktoś będzie "rzygał" tym rozwiązaniem? Moja hipoteza jest taka, że absolutnie nie. Jeżeli rozwiązanie jest dobre dla całości organizacji, to musi być sposób, aby skonstruować je tak, aby było dobre dla wszystkich osób w nią zaangażowanych (odwrotnie nie działa). Powtarzam wszystkich. Tylko trzeba ten sposób znaleźć, dokładnie analizując sytuację.

Przed wdrożeniem trzeba odrobić pracę domową i zobaczyć jak zmiany proponowane przez agile mogą pomóc wszystkim innym interesariuszom projektów w organizacji. Ta pomoc musi zwłaszcza być sprawdzona w odniesieniu do miar, którymi mierzona jest efektywność pracy poszczególnych kierowników. Chodzi o to, aby tak skonstruować system zarządzania, że wprowadzenie nowych reguł spowoduje z punktu widzenia poszczególnych jednostek zmiany pozytywne. Bo na przykład będzie łatwiej osiągać właściwe cele lub choćby prezentować wyniki. Jeżeli nie zadbamy o to, aby wszystkim ważnym interesariuszom było łatwiej to osiągniemy efekt podobny do wyrażonego w przytoczonym cytacie. I osoby aktywnie niezaangażowane we wdrożenie, powodujące realne zagrożenie jego powodzenia.

Stąd, jak już kiedyś pisałem, jednym z większych błędów jakie można zrobić przy wdrażaniu agile jest wdrożenie samych tylko procedur. Trzeba zmienić jeszcze także inne elementy organizacji. A to jak je zmienić i na jakie, tak aby spowodować z jednej strony akceptację, a z drugiej zakładany efekt biznesowy to już jest zadanie domowe dla tych, którzy agile wdrażać będą. I gwarantuję dwie rzeczy:

1. nie jest to proste
2. nie ma gotowych rozwiązań (porównaj).

Innowacje organizacyjne

Na początek trochę teorii i rozważań "podstawowych".

Świat jest przez nas opisywany za pomocą pewnych reguł. Stałych i niezmiennych. Te reguły określają to w jaki sposób działa świat (np. masy się przyciągają). Na podstawie reguł, które naszym zdaniem opisują świat, tworzymy pewnego typu metody i procedury, które są niczym innym jak zastosowaniem tychże reguł do konkretnego środowiska (np. szklankę stawiamy na stole a nie obok stołu - bo spadnie, co wynika wprost ze wspomnianej wcześniej reguły).

Przy takim spojrzeniu na organizacje działające w świecie rzeczywistym możemy założyć, że są dwie metody wprowadzania innowacji w organizacji. Pierwszy to zmiana metod i procedur. Po prostu jak chcemy wprowadzić coś nowego to zaczynamy od tego, że zmieniamy sposób działania ze starego na nowy. Następnie sprawdzamy czy nowy sposób działa lepiej czy gorzej, oczywiście względem pewnego konkretnego wskaźnika, który powinniśmy wyznaczyć zanim cokolwiek zaczniemy zmieniać. Ten sposób nazywa się często z angielska learning-by-doing.

Jest też drugi sposób wprowadzania innowacji, który o ile dobrze kojarzę nazywa się learning-by-understanding. Ten sposób zakłada, że zanim zaczniemy zmieniać cokolwiek w metodach i procedurach powinniśmy przeanalizować reguły, które rządzą danym kawałkiem rzeczywistości. W tym zwłaszcza upewnić się, czy to co wydaje się nam regułą opisującą daną rzeczywistość na pewno nią jest. Można tu zastosować metodę naukową. Dopiero jak mamy wystarczająco dobre reguły, to na ich podstawie konstruujemy metody i procedury. Tak aby wypełniały te zidentyfikowane reguły w konkretnym środowisku.

Powyższe uwagi są uwagami ogólnymi, ale jak najbardziej stosują się do agile a tak konkretnie do wdrażania metod zwinnych w organizacjach. Wielkim błędem jest wdrażanie metod "bo tak wszyscy robią", czy z innych tego typu powodów. A tak niestety często się dzieje. Niestety. To jest typowe podejście zmiany procedur i metod oraz później modlenia się o rezultaty. Stosując nielubiane przez mnie porównania wojskowe jest to podobne do radzieckiego "rozpoznania bojem". Ze względu na historycznie przetestowany poziom strat własnych podejście jest bardzo niezalecane. Zalecane jest za to sprawdzenie jakie reguły obowiązują w danym wycinku rzeczywistości, w którym porusza się dana organizacja. Dopiero na tej podstawie można skonstruować zestaw metod i procedur, które wdrożone przyniosą dokładnie taki efekt jak spodziewany.

To, co opisałem powyżej jest jedną z przyczyn dla której nie słyszałem o udanym wdrożeniu metod zwinnych, które było przeprowadzone ściśle według książki. Po prostu książki opisują pewną wiedzę ogólną a każda z organizacji działa w trochę innym otoczeniu, więc zestaw praktyk i metod musi być inny (choć reguły mogą, ale nie muszą, być takie same). I stąd właśnie do wdrożenia metod zwinnych często firmy potrzebują pomocy z zewnątrz - aby ktoś bezstronny "obejrzał" daną organizację i pomógł zdefiniować właściwe działania.

User Acceptance Tests

Ostatnio prowadziłem szkolenie z agile, podczas którego padło bardzo logiczne pytanie: „a co z User Acceptance Tests (UAT – testy akceptacyjne)? kiedy je się wykonuje i jak zapewnia się, że podczas ich trwania ma się dostęp do grupy wykonawczej, aby ewentualnie naprawić zgłoszone przez użytkowników błędy?”. Pytanie jak najbardziej logiczne, dobre i odpowiedź powinna gdzieś być do znalezienia. Niestety po przeszukaniu dostępnej w mojej biblioteczce literatury okazało się, że odpowiedzi na to pytanie nie ma w posiadanej przeze mnie literaturze agile. Dlatego napiszę co ja na ten temat sądzę i jak ta sprawa była rozwiązywana w firmach, w których widziałem duże wdrożenia metod zwinnych. I przy okazji: jak ktoś gdzieś ma opis w literaturze takiego lub podobnego rozwiązania to bardzo proszę o podanie mi źródła.

„Problem” z User Acceptance Tests wynika z faktu, że według procesów agile grupa wykonawcza, pracująca nad projektem powinna cały czas w ramach iteracji dostarczać kolejne działające inkarnacje produktu. Tymczasem w tzw. świecie realnym, w którymś momencie przychodzi moment, kiedy taki działający produkt należy pokazać klientowi, który to klient powinien się zdecydować czy produkt spełnia jego wymagania czy nie. Ta właśnie procedura nazywa się testami akceptacyjnymi (UAT) i zwykle trwa jakiś czas- na pewno nie jeden czy nawet dwa dni. Co więcej z punktu widzenia firmy produkującej oprogramowanie jest to czas, który jest krytyczny. W trakcie testów akceptacyjnych musi być stały dostęp do zespołu, który wytworzył dany produkt aby bardzo szybko reagować na ewentualne błędy (pamiętajmy, że testuje to już klient – użytkownik ostateczny). Jak to więc zrobić, aby mieć dostęp do grupy wykonawczej w środowisku agile?

Ano bardzo prosto. Tylko trzeba się wznieść na „poziom wyżej”. Tak jak już kiedyś pisałem poziom iteracji i poziom wersji rządzi się trochę innymi prawami jeżeli chodzi o planowanie. Przypomnę tylko, że w ramach jednej wersji może być kilka iteracji. Wersja natomiast oznacza wersję produkcyjną, która zostaje zainstalowana u klienta ostatecznego w jego środowisku produkcyjnym. W ramach danej wersji następujące po sobie iteracje stanowią pewną całość i odbywają się jedna po drugiej, bez przerw. Nikt jednak nie powiedział, że tak samo musi być z wersjami. Często jest to w ten sposób rysowane w różnej literaturze (prace nad kolejną wersją rozpoczynają sie natychmiast po zakończeniu prac nad poprzednią), ale praktyka często weryfikuje takie podejście. W praktyce jest tak, że po zakończeniu pracy nad jedną wersja produkcyjną danego produktu następuje jej wypuszczenie i wdrożenie (deployment) w środowisku klienta. Natomiast prace nad kolejną wersją tego samego produktu zaczynają się zwykle z pewnym opóźnieniem (na przykład 2-4 tygodnie). W trakcie tego „opóźnienia” odbywają się dwie rzeczy. Po pierwsze klient przeprowadza UAT wersji, którą dostał. Jako, że w tym czasie nie ma prac rozwojowych nad wersją kolejną to w przypadku jakiejkolwiek awarii zespół wykonawczy jest w stanie bardzo szybko zareagować na ewentualne problemy. Jednak zespół wykonawczy nie przeznacza tego czasu tylko na bycie w gotowości. Oprócz tego, ten czas przeznaczany jest na przygotowanie do rozpoczęcia prac nad kolejną wersją. Zwykle oznacza to w praktyce przejrzenie z kierownikami produktu wszystkich funkcjonalności mających wejść w skład następnej wersji, nadanie im priorytetów oraz przeprowadzenie wstępnej estymacji. I nie jest to wbrew zasadom agile – wręcz przeciwnie, powtórzę po raz kolejny, że agile to nie chaos i kierownicy produktu powinni na początku prac nad wersją wiedzieć co chcą w jej ramach dostać. Zwłaszcza jeżeli chodzi o funkcjonalności o wysokich priorytetach, które wejdą do produkcji w pierwszych iteracjach pracy nad nową wersją.

Na koniec podsumowując w jednym zdaniu: praktyka wskazuje, że User Acceptance Tests w projektach agile przeprowadza się w „przerwie” pomiędzy pracą nad kolejnymi wersjami produktu.

Metoda Uwe K.

Jakiś czas temu pracowałem dla naszych sąsiadów zza Odry i Nysy Łużyckiej a moim szefem był niejaki Uwe K. Miał on bardzo ciekawą metodę zarządzania zadaniami. Otóż dzwonił codziennie o godzinie 16.15 do mnie, jako do swojego pracownika i przekazywał ustnie zadania do wykonania. Następnego dnia często dzwonił o godzinie 8.00 z pytaniem gdzie może obejrzeć rezultaty mojej pracy. Najwięcej zadań oczywiście było przekazywane w piątek o 16.15, tylko po to, aby oczekiwać, że będą zrealizowane do poniedziałku do 8.00. Bardzo ciekawa metoda zarządzania to była. Szczególnie w kontekście tego, że życie nie składa sie jedynie z pracy. Jak się zapewne domyślacie dość szybko zacząłem aktywnie działać w kierunku zwolnienia Uwe K. z funkcji mojego szefa...

Historia powyższa przypomniała mi się gdy rozmawiałem w zeszłym tygodniu z pewną osobą, której nie udało się wdrożenie zwinnych metod zarządzania w średniej wielkości polskiej firmie informatycznej. Teoretycznie firma była idealna do wdrożenia. Produkty cechujące się dużą niepewnością funkcjonalności, bardzo duża możliwość testowania niepełnego produktu przez klientów ostatecznych, projekty na tyle małe, że można je robić jednym zespołem, więc odpadają wszelkie typowe problemy ze skalowaniem metod zwinnych. Niestety wdrożenie zostało wyłożone. Co się stało? Zacznijmy od tego, że wdrożenie agile project management zostało umotywowany tym, że "firma zbyt wolno reaguje na potrzeby klienta". Celem było więc stworzenie systemu, który pozwoli szybko reagować na zgłaszaną przez klienta informację zwrotną o produktach firmy. O ile osoby zajmujące się programowaniem dość szybko zrozumiały o co chodzi w nowym systemie pracy, to zrozumienie metod zwinnych po stronie osób zarządzających produktem (product managerów) było cokolwiek powierzchowne. Doprowadzono do sytuacji, w której dano product managerom pełną dowolność zmian funkcjonalności produktu bez liczenia się z opinią kierowników projektów realizacyjnych. Bardzo szybko spowodowało to pojawienie się syndromu opisanego powyżej. Objawiało się to wpisywaniem przez menedżerów produktu na listę funkcjonalności niezdefiniowanych rzeczy podczas spotkań planujących iterację. Realizatorzy prosili o uszczegółowienie takich wymagań, co następowało zwykle na trzy dni przed końcem iteracji. Na innym poziomie było wrzucanie do ostatniej iteracji przed wypuszczeniem wersji zmian fundamentalnych, wymagających zmian w architekturze - oczywiście tłumaczone nagłą potrzebą klienta. A także inne kwiatki, których nie mogę opublikować. Jak się domyślacie oczekiwanie było, że na koniec każdej iteracji będzie dostępny działający produkt. A już wersja to koniecznie musiała być, bo przecież obiecana klientowi. Jakiekolwiek tłumaczenie od strony realizatorów, że taka praca jest nieoptymalna menedżerowie produktów kwitowali krótko: "no jak to, czy to znaczy, że nie jesteście wystarczająco agile?". Dość szybko ludzie z zespołów realizacyjnych zaczęli myśleć dokładnie to, co ja myślałem o moim szefie.

Nauka z tego taka, że zwinność zwinnością, ale i tak zawsze trzeba pamiętać, że istnieje gdzieś niepisana cienka linia, której przekroczenie spowoduje zabicie metody. Najpierw na poziomie elementarnego poziomu i trzymania się zasad. Chwilę potem na poziomie ludzkich relacji i chęci dalszej współpracy. Napiszę jeszcze raz to, co już tu wielokrotnie wprowadzałem: agile to wprowadzanie porządku w chaos. Agile to nie jest zarządzanie bez reguł.

I na koniec taka refleksja. Nie wiem dlaczego, ale zaczyna u mnie dominować przekonanie, że wdrożenia metod agile są najbardziej zagrożone nie od strony realizacji, ale od strony zarządzania produktem. Właśnie ze względu na błędne zrozumienie, że agile oznacza "wszystko nam wolno". A co ciekawe firmy praktycznie nigdy nie chcą aby im szkolić menedżerów produktów...

Dokumentacja wdrożeniowa i administracyjna

Ostatnio pojawiło się bardzo dużo, bardzo ciekawej pracy. Stąd przerwy w pisaniu na blogu. Będę próbował się poprawiać :-)

Wracając do tematu, spotkałem się z bardzo ciekawym człowiekiem, który pisze pracę magisterską z dziedziny agile. Konkretne na temat dokumentacji w projektach realizowanych metodami zwinnymi. Ja już kiedyś swoje zdanie na ten temat wyraziłem (tutaj). W trakcie rozmowy wyniknął jednak jeden ciekawy problem.

Kto bowiem w zespole pracującym zgodnie z metodami zwinnymi jest odpowiedzialny za pisanie dokumentacji wdrożeniowej i administracyjnej? Na początek ustalmy pojęcia. Dokumentacja wdrożeniowa obejmuje opis procesu, który trzeba zastosować, aby system został uruchomiony w środowisku klienta i poprawnie funkcjonował z innymi systemami wcześniej tam obecnymi. Dokumentacja administracyjna obejmuje opis procedur, które muszą być stosowane przez osoby obsługujące systemy (bardzo często są to pracownicy naszego klienta) aby zapewnić utrzymanie systemu. Często dokumentacja administracyjna obejmuje też instrukcję radzenia sobie z najczęstszymi problemami.

W przypadku dokumentacji technicznej oraz dokumentacji użytkownika sprawa jest dość prosta. Odpowiadają za nią członkowie zespołu, którzy jednocześnie piszą kod bądź testują oprogramowanie. Z dokumentacją wdrożeniową, a już zwłaszcza administracyjną, jest jednak inaczej. Otóż w najczęściej spotykanych przypadkach jest tak, że osoby zajmujące się wdrożeniami systemu (czy też integracją systemów) nie są bezpośrednio członkami zespołów agilowych. Wynika to z faktu, że w większość znanych mi firm (nie mówię tu o sytuacji super-idealnej wziętej z książki któregoś z guru) osoby zajmujące się rozwojem produktu oraz osoby zajmujące się jego wdrożeniem i później ewentualnie administracją pracują w różnych działach, często nie mających ze sobą nic wspólnego. Dlatego w znanych mi zespołach nie było osób z kwalifikacjami potrzebnymi do napisania tego typu dokumentacji.

Jak więc sobie z tym poradzić? Długo się zastanawiałem i wymyśliłem dwa sposoby. Pierwszy jest „ortodoksyjny”. To znaczy zespół agilowy jest odpowiedzialny za stworzenie i tej dokumentacji. Przy czym oznacza to wprowadzenie do zespołu osoby, która się na tym zna. Oznacza to, niestety, że zespół się rozrośnie, bo tak jak to wspomniałem wcześniej rzadko zdarza się, żeby osoby pracujące nad rozwojem produktu miały wiedzę i umiejętności potrzebne do napisania takiej właśnie dokumentacji. Drugim rozwiązaniem, bardziej praktycznym, jest… odpuszczenie sobie tej dokumentacji na poziomie prac wykonywanych w poszczególnych iteracjach. Dokumentacja wdrożeniowa i administracyjna powinna pojawiać się wówczas jako element wypuszczanej wersji a nie produkt iteracji (o różnicach w planowaniu wersji i iteracji pisałem tutaj). Wówczas będzie działać to tak, że zanim wersja zostanie uznana za gotową do wypuszczenia do klientów jako warunek konieczny pojawi się „dostępna dokumentacja wdrożeniowa i administracyjna”. Pracę tą można wykonać na przykład podczas iteracji synchronizującej (tutaj). Ma to też sens patrząc się ze strony działów wdrożeń, których pracownicy będą się musieli uczyć zmian w systemie raz na wersję a nie raz na iterację. Z ich punktu widzenia to akurat bardzo duże ułatwienie.

Dzielenie funkcjonalności raz jeszcze

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

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

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

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

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

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

Jak upowszechnić ideę, czyli dlaczego zostanie tylko SCRUM

Witam po dłuższej przerwie wakacyjnej. W każdym razie żyję i teraz już postaram się wrócić do zwykłej częstotliwości pisania.

Na początek temat tylko z pozoru odległy od głównej tematyki tego bloga. W trakcie wakacji kilkukrotnie powróciło do mnie zagadnie czynienia nowej idei popularną. Chodzi o sytuację, kiedy mamy nową (innowacyjną) ideę i chcemy ją upowszechnić. Niektórzy puryści powiedzą w tym momencie, że to nic trudnego, po prostu trzeba tą ideę sprzedać używając „zwykłych” metod marketingu i sprzedaży, postępując podobnie jak z każdym innym produktem. Być może mają rację. A nawet mają ja na pewno. Ale ja się zacząłem zastanawiać nad czymś innym. Jaka powinna być konstrukcja systemu, w którym krąży rzeczona idea, aby tenże system był w stanie w sposób najbardziej skuteczny upowszechnić tą właśnie ideę wśród firm (uwaga to ważne: mówimy o upowszechnieniu wśród organizacji komercyjnych).

Czyli sytuacja wyjściowa jest następująca: mamy nową, dobrą ideę, czyli na przykład agile project management i chcemy, żeby koncepcja ta przedostała się do świata firm i była tam używana. Jaki system zbudować, aby to było możliwe?

Jeden z modeli takowego systemu, który służy upowszechnianiu idei został mi zasugerowany przez Marka Kowalczyka. Po drobnych zmianach system ten, nazwany przeze mnie „modelem guru”, wygląda mniej więcej tak:

W centrum tego modelu stoi „guru” – osoba, która jest niekwestionowanym autorytetem jeżeli chodzi o daną koncepcję, czy też ideę, najczęściej jej twórca. Osoba ta najczęściej przekazuje swoje idee poprzez książkę swojego autorstwa, która zawiera jedynie właściwą wykładnię tego, co jest treścią idei. Książka najczęściej nie jest jedna, tylko robi się z tego cykl, każda następna prezentująca kolejną odsłonę idei. Książka jest głównym nośnikiem marketingowym, pozwalając dotrzeć do masowego odbiorcy za bardzo sensowne pieniądze (dla odbiorcy). Te osoby, które po przeczytaniu książki zainteresuje idea są następnie zachęcane do odbywania spotkań z „guru” lub osobami przez niego wskazanymi, na których to spotkaniach można zgłębić kolejne tajniki wiedzy. Całą tą machinę aktywnie wspiera sieć społeczna zbudowana wokół idei. Sieć taka zwykle opiera się o jakąś formę portalu webowego lub sieć stowarzyszeń/klubów w których spotykają się osoby zainteresowane tą właśnie ideą. Sieć ta ma zwykle jakiś sposób na wyróżnienie swoich członków spośród innych ludzi. Takim sposobem są na przykład wszystkiego typu gadżety reprezentujące idee: teczki, koszulki, kubki, zakładki do książek, etc. Zwykle sprzedawane po cenach absurdalnie wysokich.

Model powyższy został w praktyce zaimplementowany i sprawdza się znakomicie w pewnych przypadkach. Przykładami „guru” i stojących za nimi idei rozpowszechnianych w takim modelu są między innymi: Stephen Covey (7 nawyków skutecznego działania), Robert Kiyosaki (Bogaty Ojciec), Anthony Robbins (The Power Within) czy w końcu David Allen (GTD). Wymienione przykłady dowodzą, że model ten działa i w oparciu o niego można skonstruować sprawnie działający mechanizm szerzenia idei i (przy okazji) zarabiania pieniędzy.

Wymieniony model ma jednak dość znaczącą wadę. Otóż nigdzie nie ma dowodów na to, że pozwala on w sposób efektywny sprzedawać idee do firm. Wszystkie wymienione koncepcje są nakierowane na sprzedaż dla jednostek a nie dla organizacji. Mimo, że może nawet wystąpić sytuacja kiedy to firma płaci za seminarium GTD czy dowolne inne to nadal cały czas ta idea jest sprzedawana poszczególnym osobom w ramach organizacji. Czy ktoś kiedyś słyszał, żeby firma działała według 7 nawyków, aby według GTD albo czegoś podobnego? Nie. Firmy działają według Lean, CMMI, SixSigma, ISO, PMI czy Prince2 . W tym momencie mnie tknęło. Następnym logicznym pytaniem jest bowiem: czy te wszystkie koncepcje też mają wspólny model wokół którego się obracają? Analiza wykazała: mają.

„Model standardu” jest drugim modelem upowszechniania idei, który sporządziłem próbując dokonać reverse engineeringu na koncepcjach odnoszących największe sukcesy w firmach. Takich, które zostały już wielokrotnie wdrożone i które są znane większości osób zaangażowanych w daną działkę przemysłu. „Model standardu” prezentuje się w sposób następujący:

Zgodnie z nazwą w centrum modelu jest standard. Koniecznie spisany, dostępny albo za darmo, albo (częściej) w postaci płatnego wydawnictwa. Standard ten jest oficjalnie opracowany i utrzymywany przez pewną organizację, która jest zwykle pomysłodawcą idei. Ta sama organizacja zajmuje się certyfikacją, która jest kolejnym elementem modelu. Organizacja, która wymyśliła ideę rości sobie prawo do oceniania i certyfikowania z zakresu propagowanej idei. Odbywa się to zwykle dwutorowo. Po pierwsze organizacja może przetestować i certyfikować poszczególne osoby/organizacje pod kąte tego jak dobrze znają one dany standard. W ten sposób powstają wszystkie dyplomy, certyfikaty, stopnie dojrzałości itp. Drugi zakres działania organizacji certyfikującej jest jeszcze ciekawszy: dotyczy certyfikacji organizacji, które mogą propagować standard dalej. Czy organizacja, która wymyśliła pierwotną ideę, daje swoistą licencję innym organizacjom na propagowanie tej właśnie idei. Zauważyłem zresztą, że bardzo rzadko ta organizacja, która wymyśliła ideę sama dostarcza np. wiedzę z jej zakresu. Ona wynajmuje do tego „niezależnych”, certyfikowanych dostawców. Cudzysłów jest dlatego, że ci dostawcy są w 100% zależni od organizacji certyfikującej, gdyż brak ich uznania, cofnięcie certyfikatu w większości wypadków skutkowałby natychmiastowym wypadnięciem z rynku. Na koniec jako element propagowania idei jest jeszcze coś takiego jak sieć kontrahentów. Chodzi tu o to, że organizacje certyfikujące poprzez swoich „niezależnych” dostawców często wymuszają na przedsiębiorstwach, że w momencie implementacji standardu będą „namawiać” swoich partnerów do przyjęcia tego samego standardu. „Właśnie wdrożyliśmy ISO i aby utrzymać wymaganą jakość oczekujemy, że za 6 miesięcy wszyscy nasi dostawcy też wdrożą ISO”. Działa rewelacyjnie, zwłaszcza jak pierwszym podmiotem, który tak mówi jest organizacja rządowa udzielająca zleceń (przypadek PMI, Prince2 czy CMMI).

Jaki jest powód tego, że „model standard” jest znacznie skuteczniejszy w sprzedawaniu idei do firm niż „model guru”? Według mnie klucz leży w modelu potrzeb Maslowa a konkretnie w drugiej kluczowej potrzebie każdego człowieka, czyli potrzebie bezpieczeństwa. W tym wypadku bezpieczeństwa zawodowego menedżera, który podejmuje decyzje o wdrożeniu danej idei. W przypadku „modelu guru” idea taka nie jest dla niego bezpieczna, gdyż opiera się o konkretnego, jednego człowieka. Czy jakikolwiek wysoki szczeblem menedżer pozwoli, żeby jego firma opierała się o idee jednej jednostki, jednego człowieka? Nie. Zupełnie inaczej natomiast wygląda sytuacja, kiedy mamy wdrożyć znany na rynku standard wspierany przez „niezależną” instytucję certyfikującą i „niezależnych” dostawców wiedzy. Zresztą tych dostawców jest wielu w odróżnieniu od „modelu guru”, gdzie zwykle dostawca jest jeden (firma założona przez twórcę idei).

I tak na koniec. Dlaczego piszę o tym na tym właśnie blogu? Otóż próbowałem przeanalizować sobie w jaki sposób próbuje się upowszechniać koncepcje agile project management. Wydaje mi się, że do tej pory wszystkie koncepcje agile były upowszechniane w sposób przypominający „model guru”. Dwa najbardziej jaskrawe przypadki to Alistair Cockburn z jego metodami Crystal oraz Ken Schwaber i SCRUM. Upowszechnianie idei w ten sposób jakoś szło. Ken Schwaber, Mike Cohn oraz Esther Derby, jako jedyni spośród „guru” agilowych, zdecydowali się jednak powołać Scrum Alliance. „Niezależną” organizację trzymającą pieczę nad standardem oraz certyfikującą „niezależnych” dostawców. Jeżeli moje rozważania są poprawne oznacza to, że prędzej czy później, ale raczej prędzej SCRUM upowszechni się jako jedyna słuszna metoda zwinnego zarządzania projektami.

Zespoły - na co zwrócić uwagę

Projekty realizowane metodami agile/zwinnymi wymagają zupełnie innych zespołów niż takie realizowane metodami tradycyjnymi. Jak wiadomo zespół powinien być maksymalnie 10-12 osobowy, idealnie przebywać w jednym miejscu fizycznym, sam się zarządzać + parę innych cech, bardzo często wymienianych w literaturze. Ja natomiast dzisiaj napiszę o tych czynnikach, które mogą być potencjalnym zagrożeniem dla sprawnego działania zespołu realizującego projekt przy użyciu metod zwinnych. Na te czynniki powinno się zwrócić szczególną uwagę podejmując decyzję o realizowaniu projektu metodami zwinnymi.

Po pierwsze należy to jasno powiedzieć, choć może nie jest to twierdzenie politycznie poprawne: skuteczność zespołu pracującego metodami zwinnymi zależy w dużym stopniu od kultury miejsca pracy. Chodzi tu zarówno o kulturę organizacyjną jak i kulturę państwa/narodu, którego przedstawicielami są osoby uczestniczące w projekcie. Kultura musi wspierać prace grupowe i jednocześnie deprymować lansowanie się jednostek kosztem grupy. Praca metodami zwinnymi jest pracą grupową i na to poradzić nic nie można. I tak jak z innymi zajęciami grupowymi (na przykład sport) często zdecydowanie lepszy jest zespół składający się z osób o przeciętnych zdolnościach, ale zdolnych do współpracy od zespołu składającego się z geniuszy, którzy nie potrafią ze sobą porozmawiać, bo każdy chce tylko udowodnić swoją wyższość. To jaki charakter pracy jest uprawiany w danej organizacji zależy właśnie od kultury organizacji. I niestety zmiana tego jest bardzo trudna.

Po drugie zespoły pracujące metodami zwinnymi powinny w czasie trwania projektu móc pracować tylko i wyłącznie nad tym projektem. To niestety jest bardzo trudne do zrobienia w przypadku organizacji posiadających silną strukturę macierzową. Taka struktura zakłada bowiem, że w każdy członek zespołu projektowego ma jeszcze swojego przełożonego "liniowego", który w znaczącej większości przypadków decyduje o takich rzeczach jak awanse czy podwyżki. To oznacza, że praktycznie w każdej sytuacji niejasnej pracownicy będą słuchać swojego przełożonego liniowego a nie osób z projektu. W tradycyjnie zarządzanych projektach powoduje to duże problemy i jest m.in. jedną z przyczyn notorycznych opóźnień. W projektach zarządzanych metodami zwinnymi takie podejście jest całkowicie destrukcyjne i projekty praktycznie nie mogą się toczyć. Projekt zwinny bardzo podobny jest do wspomnianego już kiedyś przypadku operacji w szpitalu. Na czas operacji cały zespół ma być tylko i wyłącznie na sali operacyjnej. Przecież nikt nie wyobraża sobie, że nagle anestezjolog wyjdzie z sali i zajmie się sporządzaniem raportu, którego akurat bardzo potrzebuje jego przełożony "liniowy". Ciekawe, że w projektach, takie zachowanie jest uważane za coś normalnego.

Po trzecie i ostatnie (na dzisiaj) należy sobie zdawać sprawę, że zupełnie inna jest rola kierownika projektu w projekcie zarządzanym metodami tradycyjnymi a zupełnie inna jest ta rola w projektach zarządzanych metodami zwinnymi. Do tego stopnia, że niektórzy puryści zajmujący sie agile twierdzą wręcz, że w tych metodach stanowisko kierownika projektu istnieć nie powinno i nazywają je inaczej (np. SCRUM Master). Tak naprawdę nie ważne jak się ono nazwa, ważne jest, że osoba wyznaczona do kierowania powinna mieć zupełnie inne umiejętności i na co innego zwracać uwagę niż w projektach tradycyjnych. Typowym przykładem jest kwestia rozdziału zadań i podejmowania decyzji. W metodach tradycyjnych zwyczajowo to kierownik projektu podejmuje wszystkie decyzje sam, podobnie on rozdziela zadania do wykonania. Takie podejście jest zaprzeczeniem metod zwinnych. Tutaj zadaniem kierownika jest tak pokierować (przewodzić) pracy zespołu, aby decyzje były podjęte wspólnie a zadania rozdzielone na zasadzie swobodnego wyboru przez członków zespołu. To oznacza również, że kierownik stosujący zwinne metody zarządzania musi być ekspertem w dziedzinie, której dotyczy projekt. W odróżnieniu od tradycyjnego podejścia, gdzie parafrazując pewną bardzo znaną książkę "nawet pielęgniarka może poprowadzić projekt budowlany, byleby miała dobrze zdefiniowany system zarządzania projektami". W metodach zwinnych takie podejście gwarantuje porażkę.

Kiedy nie stosować metod zwinnych

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

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

Moje komentarze do tych sytuacji:

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

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

Wieloprojektowość

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

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

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

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

Zwinne zarządzanie zmianą w organizacji

Parę tygodni temu obyłem inspirującą rozmowę z pewnym ciekawym człowiekiem. Rozmawialiśmy na temat projektu wprowadzenia zmian organizacyjnych w bardzo dużej firmie. Zmiany miały być na wielką skalę. Na tyle wielką, że projekt musiał być realizowany w etapach. Na sam koniec rozmowy poprzez tematykę etapów zeszło na metody skutecznego zarządzania takim projektem. Jedną z rozważanych hipotez stało się użycie metod zwinnych do zarządzania tymże projektem.

Na pierwszy rzut oka pomysł wydaje się być totalnie pozbawiony sensu. Podstawowym założeniem wszystkich metod zwinnych (wszystkiego co nazywa się agile) jest iteracyjne dostarczanie działającego produktu. Działającego produktu. A my mówimy o projekcie wprowadzenia zmian organizacyjnych. Więc nie spełniamy podstawowego założenia. Drugim założeniem bardzo ważnym dla metod zwinnych jest koncentracja na przepływie wartości dodanej dla klienta, której emanacją są definicje funkcjonalności. Dlatego w projektach zwinnych nie definiuje się struktury podziału pracy tylko strukturę podziału funkcjonalności produktu końcowego. Bo to ukończona funkcjonalność niesie wartość dodaną a nie praca wykonana. Znowu więc na pierwszy rzut oka nijak ma się to do wprowadzania zmian organizacyjnych w firmach. A na drugi rzut oka?

Załóżmy przez chwilę, że organizację jako całość traktujemy jako produkt. Klientem na ten produkt jest właściciel organizacji lub jego przedstawiciel (zarząd). Tenże produkt przynosi właścicielowi korzyści biznesowe (zwykle wyrażone dość konkretnie w pieniądzach). Aby te korzyści przynosić tenże produkt posiada zestaw funkcjonalności, pewnych działań realizowanych przez organizację, które to działania, każde z nich, ma pewną wartość dla klienta. Jeżeli by tej wartości nie miało to klient (właściciel) już dawno wyrzuciłby to działanie ze swojego produktu (organizacji).

Przy takim spojrzeniu nie ma przeszkód, aby zarządzać projektem zmian organizacyjnych przy użyciu metod zwinnych. Klient (właściciel) definiuje jakie nowe funkcjonalności powinien mieć produkt (organizacja). Na przykład organizacja powinna mieć dedykowany dział wsparcia klienta albo organizacja powinna zarządzać projektami według metod zwinnych. To jest funkcjonalność, której brakuje a która z punktu widzenia właściciela przyniosłaby realny wzrost wartości całej organizacji. Teraz taką funkcjonalność można potraktować tak jak w projektach zwinnych: rozbić na mniejsze, nadać priorytety i wspólnie z klientem zastanowić się co wdrażamy najpierw. A następnie powołany zespół projektowy ds. zmian organizacyjnych zacząłby takie zmiany wdrażać. Produktem dostawy po każdej iteracji byłaby cała organizacja, która wykazywałaby działające kolejne elementy zdefiniowanej funkcjonalności.

Takie podejście do tematu zmian organizacyjnych po krótkim zastanowieniu wydaje się być obiecujące. Nie dość, że wydaje się być możliwe do wdrożenia to ma jeszcze dwie ważne cechy. Po pierwsze traktując organizację jako produkt z określonymi funkcjonalnościami spowodujemy, że definiując co trzeba zmienić będziemy się patrzeć na funkcjonalności właśnie a nie działania, które mamy przeprowadzić. Podobnie jak w przypadku zwinnych projektów przestajemy rozmawiać o działaniach a zaczynamy się skupiać na efektach, które te działania mają przynieść. Dzieje się tak, gdyż właściciel podobnie jak klient chce efektów a nie działań. Druga ważna sprawa wynika wprost z poprzedniej. Skupienie się na efektach oznacza, że będziemy musieli rozważać wartość biznesową każdego z nich. (każdej nowej funkcjonalności, którą będzie miała mieć organizacja). A analiza wartości biznesowej wprowadzanych zmian jest czymś, co w przypadku tradycyjnie zarządzanych projektów zmian organizacyjnych rzadko się zdarza. Potencjalnie uzyskujemy bardzo dużo.

Powyższe to czysta spekulacja, ale czy to zadziała? Zgodnie z duchem zasad projektów zwinnych teoretyczna negacja jest zabroniona. Trzeba by przeprowadzić eksperyment. Szukam chętnych. Adres email w informacji o mnie po prawej stronie.

Kontrakty na projekty zwinne

Ostatnie kilka tygodni spędziłem bardzo pracowicie spotykając się z wieloma bardzo interesującymi ludźmi. Stąd dłuższy brak postów na blogu. Z drugiej strony spotkania te były niezwykle interesujące i dostarczyły bardzo ciekawych spostrzeżeń.

Przykład, który mnie najbardziej zadziwił to omawiany już tu kiedyś (tutaj) „problem” kontraktów na projekty zwinne. Generalnie podczas każdej prezentacji, szkolenia czy nawet rozmowy na temat zwinnych metod zarządzania projektami prędzej czy później któryś z obecnych kierowników projektów podnosi „problem” kontraktów. Najczęściej przybiera to formę pytania „a co ja mam powiedzieć mojemu klientowi jak on zapyta ile będzie kosztował cały system”. Zwykle w takich przypadkach tłumaczę, że kontrakty na projekty realizowane zwinnie powinny być płacone inkrementalnie za wykonaną pracę, tak jak jest dostarczana funkcjonalność. Odpowiedź kierowników jest zwykle jedna: „moi klienci się na to nigdy nie zgodzą, oni chcą wiedzieć ile będzie kosztowała całość”. Dyskusja trwa długo.

Otóż tak się składa, że rozmawiałem ostatnio z kilkoma osobami, na co dzień kupującymi oprogramowanie, w tym oprogramowanie tworzone na zamówienie. Jako, że metody zwinne moim konikiem są, prędzej czy później schodziło na tą tematykę. Z wielkim zdziwieniem stwierdzałem, że idea zwinnego rozwoju oprogramowania, w tym płacenia inkrementalnego... bardzo im się (wszystkim) podobała. Jako, że byli to ludzie odpowiedzialni za pieniądze natychmiast (wszyscy) reagowali tak samo: to jest idealny sposób ograniczania ryzyka. Jeden z nich wprost od razu zapytał gdzie może znaleźć firmę, która zgodzi się na rozwój oprogramowania w taki właśnie sposób: płacenia za krótkie, ściśle zdefiniowane iteracje. Czy przeszkadza im to, że nie wiedzą ile będzie kosztowała całość? W zasadzie nie. Ewentualne kontrowersje natychmiast znikały gdy dowiadywali się, że będą mogli zmieniać definicję „całości” w dowolnym momencie, ze skutkiem z końcem kolejnej iteracji. To jest racjonalne, bo przecież zwykle oprogramowanie kupuje się nie po to, aby było „całością”, tylko po to, aby realizowało potrzeby biznesowe. Co ciekawe ludzie, którzy zlecają tworzenie oprogramowania rewelacyjnie to rozumieją. Dla nich rachunek jest prosty: kwota jaką zapłaciłem za oprogramowanie musi być (zdecydowanie) mniejsza niż korzyść wyrażona finansowo, którą ono (szybko) wygeneruje. Dlatego możliwość dynamicznego dostosowywania się do zmieniających się potrzeb i w ten sposób możliwość szybszego generowania większej korzyści jest bardzo, ale to bardzo dużą realną wartością. Więc ja się pytam o jakim „problemie” kontraktów na projekty zwinne mówią kierownicy projektów? Zadanie domowe dla nich: przy następnej rozmowie z klientem zapytajcie się czy nie zgodziliby się na kontrakt oparty o metody zwinne zarządzania projektami.

Na koniec jedna uwaga: klienci z którymi rozmawiałem są osobami wydającymi pieniądze, że które ponoszą pełną odpowiedzialność (w części są to ich własne pieniądze). Podkreślam to, bo w korporacjach, gdzie wydaje się pieniądze „budżetowe” sprawa może wyglądać zdecydowanie inaczej.

Co to jest to Agile Project Management?

Jak w największym skrócie wytłumaczyć czym jest zwinne zarządzanie projektami (Agile Project Management)? Odpowiedź w szczegółach będzie inna w zależności od tego do kogo ma być skierowana. W jednym zdaniu powiedziałbym tak:

Dla organizacji, działających w warunkach, w których istnieje niepewność dotycząca technologii bądź wymagań klienta, Agile Project Management jest klasą metod zarządzania projektami pozwalającą,w odróżnieniu od innych, na natychmiastowe rozpoczęcie, uporządkowane poprowadzenie i zakończenie z sukcesem projektów kierując sie cały czas przepływem wartości dodanej dla odbiorcy produktów projektu.*

Miejscem, gdzie metody zwinne znajdują najlepsze zastosowanie są te środowiska, w których występuje niepewność. Na przykład wszelkiego typu projekty innowacyjne lub projekty dla bardzo szybko zmieniających się rynków (internet, „nowe media”). W takich wypadkach nie ma możliwości dokładnego zaplanowania całości projektu w sensownym czasie. Mamy więc klasyczny dylemat: albo planujemy dokładnie (bo tak jest bezpiecznej) i odkładamy start projektu w nieskończoność albo zaczynamy działać szybko (bo tak wymaga rynek) w oparciu o niepełne plany. Metody zwinne rozwiązują ten potencjalny konflikt dając zestaw narzędzi pozwalający na rozpoczęcie projektów w nie będąc pewnym całego planu osiągnięcia celów projektu. Co więcej dają możliwość usystematyzowania prac nad takim projektem w sposób, który gwarantuje, że zespół mimo braku posiadania pełnego planu pozostanie na właściwej drodze i będzie wykonywał właściwe zadania.

Metody zwinnego zarządzania projektami są tak skonstruowane, że mimo braku pewności co do dróg osiągnięcia celów projektu jeden parametr jest cały czas w punkcie skupienia zarówno kierownictwa projektu jak i każdego członka zespołu. Tym parametrem jest przepływ dodanej wartości biznesowej dla odbiorcy produktów projektu (klienta). Ta jedna cecha stanowi, że w połączeniu z elastycznością tego rozwiązania projekty realizowane metodami zwinnymi mają zdecydowanie większe szanse zakończyć się sukcesem. Klient jest zaangażowany w cały proces decyzyjny w projekcie zwinnym. Zespół projektowy realizując projekt ściśle odpowiada na potrzeby klienta dostarczając mu dokładnie te elementy, które stanowią realną wartość dodaną dla klienta. Takie podejście powoduje, że z jednej strony zespół projektowy uczy się co ma a co nie ma wartości w danym projekcie, z drugiej odbiorca produktu (klient) doskonale wie, że będzie dostawał dokładnie to, co dla niego jest wartościowe a nie to co wartościowe jest dla zespołu projektowego.

Na koniec rzecz wcale nie najmniej ważna, którą zawsze lubię podkreślać. Zarządzanie zwinne projektami, poprawnie zaimplementowane, oprócz opisanych wcześniej realnych zalet biznesowych ma jedną niepowtarzalną zaletę ludzką: zespoły projektowe po prostu lubią pracować tą metodą. Jakie są tego powody tłumaczyłem tutaj. A możliwe implikacje biznesowe przedstawiałem nie swoimi słowami tutaj.

*Dodatkowy warunek konieczny: produkty projektu można dostarczać w postaci inkrementacyjnej. To oznacza, że funkcjonalność, którą spodziewamy się dostać w ramach całego projektu powinna być możliwa do podzielenia na tak małe części, aby każdą z nich dało się wykonać w ramach jednej, dość krótkiej (2-6 tygodni), iteracji.

Metody zwinne w organizacji "stabilnej" cz. 4

Dzisiaj po raz ostatni napiszę o tym dlaczego stabilne organizacje przechodzą na zwinne zarządzanie projektami. Powód, który zostawiłem na koniec jest dość kontrowersyjny, choć jednocześnie jest dość często wymieniany przez managerów z firm, które wdrożyły zarządzanie zwinne projektami.

Powodem, dla którego przechodzi się na zarządzanie zwinne jest często chęć przestawienia organizacji z nastawienia czysto technicznego na nastawienie biznesowe. Tradycyjny paradygmat zarządzania przyłożony do organizacji produkujących bardzo zaawansowane technicznie produkty takie jak na przykład oprogramowanie powoduje bowiem, że wewnątrz organizacja zaczyna skupiać się na technice podczas gdy na zewnątrz powinna skupiać się na zaspokajaniu biznesowych potrzeb klienta. Inżynierowie pracujący w organizacjach zarządzanych tradycyjnie przez większość swojego czasu zastanawiają się jak rozwiązać problem techniczny a nie problem biznesowy klienta. Wbrew pozorom to nie to samo. W niektórych firmach powstają wręcz specjalne działy analityków, których jedynym zajęciem jest przekładanie wymagań biznesowych na wymagania techniczne. Założenia za tym stojące są takie, że inżynierowie nie mogą zrozumieć wymagań biznesowych a z drugiej strony, że klient nie jest w stanie pojąć techniki. O ile to drugie być może jest prawdziwe to zarządzanie zwinne projektami całkowicie odrzuca założenie pierwsze.

Całe proces zarządzania zwinnego został tak stworzony by na każdym etapie dbać o klienta. Inżynier pracujący nad projektem głównie rozwiązuje problemy klienta i spełnia jego wymagania. Każde działanie zespołu projektowego jest podporządkowane wypełnieniu wymagania funkcjonalnego klienta. Wymagania funkcjonalne zaś są reprezentacją wartości dodanej dla klienta, czyli tego, za co firma realizująca projekt dostaje pieniądze. Takie podejście pomaga inżynierom skupić się na rozwiązywaniu realnych problemów klientów a nie problemów technicznych, które często są ciekawe i interesujące ale w żadnym razie nie przyczyniają się do znacznej poprawy funkcjonalności produktu.

Kolejną cechą pomagającą zespołowi projektowemu nastawić się na rozwiązywanie potrzeb klienta jest sposób zapisywania wymagań i idący za tym stały kontakt z klientem. W projektach zwinnych zakłada się, że wymagania pierwotnie spisywane są na dość dużym poziomie ogólności. Następnie są one uszczegółowiane podczas bieżących kontaktów z przedstawicielami klienta. Jak już kiedyś wspominałem rozwiązuje to problem kodowania i dekodowania informacji – osoby implementujące wymagania na bieżąco i bezpośrednio od klienta dostają informację o tym jak będzie wykorzystywana zlecona funkcjonalność. Otrzymywanie tych informacji bezpośrednio od klienta z pominięciem zespołu analityków oznacza lepszy kontakt z rzeczywistym światem klienta i zdecydowanie lepszą komunikację. Doświadczenie projektów prowadzonych metodami zwinnymi wskazuje, że ilość niepoprawnie (z punktu widzenia klienta) działających funkcji produktu jest nieistotnie mała. Oczywiście wszystko to pod warunkiem, że klient zgodzi się poświęcić swój czas na intensywną komunikację z zespołem projektowym – zwykle nie ma z tym jednak problemu, gdyż w zamian uzyskuje zdecydowaną korzyść w postaci lepiej przemyślanego produktu.

Dużą rolę w skupieniu na kliencie odgrywają przeprowadzane po każdej iteracji prezentacje działającego produktu. Podczas tych prezentacji klient może i powinien sam używać produktu wytworzonego do tej pory w projekcie. Najłatwiej jest to zrobić w przypadku oprogramowania komputerowego, gdzie po prostu klient dostaje do ręki klawiaturę i myszkę. Może w pełni korzystać ze wszystkich funkcji, które miały być wyprodukowane we właśnie zakończonej iteracji. NA tym samym spotkaniu obecni są także członkowie zespołu projektowego, którzy na żywo widzą, w jaki sposób klient używa ich produktu. Takie spotkania bardo pomagają ustawić właściwą perspektywę biznesową wśród zespołu. Szczególnie, że odbywają się relatywnie często. Zdarzało się wielokrotnie, że zespół widząc jak ich klient używa produktu proponował rewolucyjne zmiany w produkcie wielokrotnie upraszczające sposób użycia i w efekcie pozwalające klientowi pracować dużo bardziej efektywnie.

Na koniec mała uwaga: w żaden sposób nie chcę tutaj dowieść, że tradycyjnie zarządzane projekty nie są nastawione pro-kliencko. Twierdzę jedynie, że metody zwinne wydatnie pomagają skupić się na rozwiązywaniu faktycznych problemów klienta, komunikacji z klientem oraz na sposobie, w jaki faktycznie będzie wykorzystywany produkt końcowy.

Przejrzystość – przykład

W nawiązaniu do posta o przejrzystości.

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

Iteracje synchronizujące

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

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

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

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

Metody zwinne w organizacji "stabilnej" cz. 3

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

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

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

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

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