Wsparcie narzędziowe zarządzania ryzykiem w projektach Spotkanie 2 Zbigniew Misiak (BOC IT Consulting)
Czym się będziemy zajmować? Podsumowanie spotkania 1 PrzeŜyjmy to jeszcze raz czyli jak tradycyjnie podchodzi się do ryzyk w projekcie Agile nowe sposoby radzenia sobie z wymagającymi projektami Czynnik ludzki Jak ustalić czego potrzebuje Klient
Podsumowanie spotkania 1 Wishlist: -więcej na temat ryzyka w PRINCE2 oraz PMBOK -ryzyko, a testowanie -więcej na temat oprogramowania -praktyczne przykłady zarządzania ryzykami -najczęstsze ryzyka i sposoby postępowania z nimi -definiowanie ryzyk -ITIL -PRINCE2 -lekkie metodyki i narzędzia wspomagające -jaśniejsze omówienie róŝnic w metodykach, przykłady -jak rozmawiać z klientem po analizie ryzyka -a gdzie ludzie -ryzyko a intuicja, przeczucie i nos -pamiętnik Tompkinsa
Czemu projekty się nie udają? Główne ryzyka dla projektów IT: 1) Problemy z harmonogramem 2) Inflacja wymagań 3) Utrata pracowników 4) Niepełne i niespójne specyfikacje 5) Niska produktywność Źródło: Tom DeMarco, Timothy Lister Waltzing with Bears: Managing Risk on Software Projects
PRINCE2 Krótkie podsumowanie: Uniwersalna Ramy do realizacji projektu oparte na dobrych praktykach Nacisk na uzasadnienie biznesowe projektu Planowanie produktowe, a nie działaniowe Wspiera zarządzanie ryzykiem Skupia w komitecie sterującym 3 strony: inwestora, uŝytkownika oraz wykonawcę, którzy odpowiadają za decycje strategiczne (zarządzanie przez wyjątki). BieŜącym zarządzaniem zajmuje się Kierownik Projektu. Zapewnia definicję ról i ich obowiązków
PRINCE2 Korzyści: Sprawdzona metodologia Brak opłat licencyjnych Łatwy dostęp do wiedzy Znaczna uniwersalność Zapewnia wspólny język dla wszystkich stron MoŜna łączyć np. z PMBOK Ale: Niewłaściwie stosowana prowadzi do znacznej biurokracji Jest nastawiona na raczej spokojne środowiska
PRINCE2 jak to działa? Co jest potrzebne: Uzasadnienie biznesowe Ustalony zestaw oczekiwanych produktów Ustalony zestaw działań, które pozwolą wytworzyć produkty Zasoby do realizacji działań (w określonym czasie trwania) Dopasowanie organizacyjne
PRINCE2 techniki Planowanie produktowe: Struktura produktowa czego potrzebuje Klient Następstwa produktów Plan działań Harmonogram Sterowanie zmianami: Decyzje odnośnie zmian są podejmowane przez właściwe osoby i naleŝycie dokumentowane, a ich wpływ na projekt jest analizowany Przeglądy jakości: Czy produkt spełnia załoŝenia z opisu produktu?
PRINCE2 komponenty Uzasadnienie biznesowe (po co jest projekt -> podstawa do decyzji o kontynuacji) Struktura organizacyjne Plany Elementy sterowania Zarządzanie ryzykiem Jakość w środowisku projektowym Zarządzanie konfiguracją Sterowanie zmianami
PRINCE2 struktura Role: Komitet Sterujący (biznes, uŝytkownik, wykonawca) Kierownik Projektu (PM) Kierownicy Zespołów (wykonawczych) Wsparcie Projektu Nadzór Projektu
PRINCE2 procesy Strategiczne zarządzanie projektem Przygotowanie załoŝeń projektu Inicjowanie Projektu Sterowanie Etapem Zarządzanie wytwarzaniem produktów Zarządzanie zakresem etapu Zamykanie projektu Planowanie Fazy Ŝycia projektu:
PRINCE2 dokumentacja PRINCE2 zaleca stosowanie systemu dokumentacji projektu. Dokumentacja jest porządkowana w teczki: projektu (np. uzasadnienie biznesowe, rejestr ryzyk), etapu, jakości oraz teczkę merytoryczną (np. konfiguracja) Analogicznie dokumentowane są wszystkie wymienione wcześniej elementy sterowania: Inicjowanie projektu Raporty o waŝnych wydarzeniach Raporty o istotnych odchyleniach Ocena odchyleń Ocena końcowa etapu Zamknięcie projektu Tolerancja
PRINCE2 dokumentacja PRINCE2 zakłada, Ŝe członkowie Komitetu Sterującego nie muszą się angaŝować w codzienne Ŝycie projektu. Podejmują decyzję wyłączenie w wypadku znaczących odstępstw od planu. Obawa o status projektu jest minimalizowana dzięki zapewnieniu im informacji o zdarzeniach wymagających ich uwagi oraz regularnym informacjom (w ramach sterowania etapem)
PRINCE2 ryzyko Źródło: Managing successful projects with Prince2 (2005)
PRINCE2 ryzyko Ocena zdrowia projektu ryzyka: Czy istnieje rejestr ryzyk? Czy jest aktualizowany? Czy dla kaŝdego planu identyfikuje się i analizuje ryzyka oraz odpowiednio działa? Czy jest uŝywana formalna procedura zarządzania ryzykiem? Czy ocena ryzyka jest częścią kaŝdego zakończenia etapu? Czy główne ryzyka były ujęte w uzasadnieniu biznesowym? Czy zostali zidentyfikowani właściciele ryzyk? Czy ryzyka są monitorowane wystarczająco regularnie? Czy ocena ryzyka następuje przy okazji analizowania kaŝdego wniosku o znaczącą zmianę? Czy oceniono prawdopodobieństwo i skutki ryzyk? Czy podjęto odpowiednie działania w celu przeciwstawienia się ryzykom tam, gdzie to konieczne? Czy przygotowano plany awaryjne? Czy objęto wszystkie oczywiste ryzyka? Czy ryzyka i przeciwdziałanie im zostały omówione z Komitetem Sterującym? Czy podjęto odpowiednie działania, gdy było to konieczne? Czy przy zmianie planów dokonano ponownej analizy ryzyk? Źródło: Managing successful projects with Prince2 (2005)
Czemu projekty się nie udają?
RóŜnica podejście do zmian Źródło: PMBOK (2004)
RóŜnice w podejściach do PM Tradycyjne PM Wiemy co i jak chcemy zrobić oraz jaki będzie czas i budŝet. Działamy w oparciu o plan przygotowany na początku. Adaptacyjne Wiemy mniej więcej co mamy zrobić, ale metody nie muszą być jasne. Czas i budŝet są znane. W miarę jak odkrywamy nowe elementy trzeba modyfikować plany Ekstremalne Brak pewności co do celu, metod oraz czasu i budŝetu. Odkrywamy na bieŝąco. Źródło: Tradycyjne zarządzanie projektami a podejście adaptacyjne i extremalne, Chomicz, Spica
RóŜnice w podejściach do PM Tradycyjne PM Zdefiniowane wymagania Planowanie zadań Planowanie i kontrola pracy Postęp projektu mierzony w zadaniach wykonanych Produkt zgodny z planem Agile Definiowanie wymagań w miarę jak się pojawiają Planowanie funkcjonalności Samokontrola Postęp projektu określa funkcjonalność Produkt zaspokajający potrzeby Klienta Źródło: Tradycyjne zarządzanie projektami a podejście adaptacyjne i extremalne, Chomicz, Spica
RóŜnice w podejściach do PM Tradycyjne metodyki skupiają się na zapewnieniu zgodności z pierwotnie stworzonym planem Armia zawsze przygotowuje się do poprzedniej wojny Metodyki z nurtu Agile zakładają, Ŝe wymagania się zmienią i dlatego teŝ zapewniają środowisko w którym łatwo jest wprowadzać zmiany w odpowiedzi na zmieniające się priorytety Klienta
Agile We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the item on the right, we value the items on the left more. Źródło: http://agilemanifesto.org/
Agile Warto zauwaŝyć, Ŝe nie oznacza to całkowitego odrzucenia narzędzi i technik tradycyjnego zarządzania projektami. Narzędzia te (np. metody zarządzania ryzykiem, system dokumentacji decyzji) mogą być wykorzystywane nadal, ale w innym środowisku projektowym i w oparciu o analizę potrzeb. Kluczowe staje się budowanie zespołu projektowego. Proces zarządzania projektem nie ma być powtarzalny, ale rzetelny. Uwaga poboczna de facto Klienta interesują rezultaty, a nie metodyka. Chce dostać rezultaty i czuć się bezpiecznie w procesie.
Zasady na przykładzie APM Wytwarzanie produktu: Wytwarzanie iteracyjne oparte na elementach funkcjonalności Doskonałość techniczna Dostarczenie Klientowi wartości Styl zarządzania przywódczo-współpracujący: Budowa adaptacyjnych zespołów Upraszczanie Zachęcanie do eksploracji Źródło: APM: Agile Project Management, Highsmith
Zasady na przykładzie APM Struktura procesu APM: Źródło: APM: Agile Project Management, Highsmith
Scrum Scrum: 1986 Nonaka i Takeuchi The New New Product Development Game (HBR) Początek lat 90-tych Ken Schwaber, Jeff Sutherland
Scrum - role Role: Właściciel produktu (zapewnia priorytety dla funkcjonalności zebranych w listę zaległości produktu) Scrum Master (coaching oraz zapewnianie, Ŝe zespół ma najlepsze moŝliwe warunki do pracy) Zespół (5-9 osób; ustalenie podziału pracy) Grafiki: www.sxc.hu
Scrum Jak to działa?
Scrum - proces Lista zaległości baza funkcjonalności uporządkowana wg. wagi dla Klienta Zaległości sprintu najwaŝniejsze elementy z listy zaległości produktu wybrane do implementacji w sprincie Codzienne spotkanie Scrum usuwanie problemów zespołu: co zrobiłem wczoraj, co zrobię dziś, co mi przeszkadza Demonstracja funkcjonalności wytworzonych w ramach sprintu
Czemu ludzie są istotni? Dobierz sobie odpowiednich ludzi, a wtedy niezaleŝnie od tego jaki popełnisz błąd, ci ludzie cię uratują Wymienność ludzi? Tom DeMarco: 1) Najlepszy programista 10 razy lepszy od najgorszego 2) Najlepszy programista 2,5 raza lepszy niŝ mediana 3) Górna połowa 2 razy lepsza od dolnej połowy
Czynnik ludzki Najlepsi przywódcy to tacy, których istnienia ludzie nie dostrzegają. Stopień niŝej to tacy, których ludzie cenią i szanują. Potem tacy, których się boją; wreszcie tacy, których nienawidzą. Kiedy najlepszy z przywódców skończy swą pracę ludzie mówią: 'zrobiliśmy to sami'. Lao-tse Zadaniem menedŝera nie jest zmuszanie ludzi do pracy, a stwarzanie im warunków do pracy Tom DeMarco
Czynnik ludzki Jak zrujnować zespół (Tom DeMarco): 1. defensywne zarządzanie 2. biurokracja 3. fizyczne oddalenie 4. rozdrabnianie obowiązków pracowników 5. praca nad produktem z którego nie moŝna być dumnym z powodu kiepskiej jakości 6. "lipny" - nierealny termin projektu ( 9 kobiet ) 7. przeciwdziałanie powstawaniu klik 8. nachalne motywowanie 9. praca w nadgodzinach
Czynnik ludzki Jak stworzyć warunki do ukształtowania się zespołu (Tom DeMarco): 1. kult jakości 2. zapewnić ludziom świadomość swoich dokonań 3. atmosfera elitarności 4. dopuszczać i promować róŝnorodność 5. utrzymywać i chronić sprawdzone zespoły 6. wyznaczać kierunki strategiczne, a nie taktyczne
Specyfikacja Klasyczne podejście: Przypadki uŝycia + use case diagrams Ale moŝna teŝ inaczej: user stories + prototypy + testy Przykład praktyczny
Podsumowanie Ewaluacja Materiały do wykładu: http://ryzyko.wordpress.com/
Podsumowanie Dziękuję