Czego uczy Agile o… zarządzaniu ryzykiem?

751

W wywiadzie dla magazynu „Zarządzanie Projektami” (nr 1(8) /2015) wspomniałem, że metodyki zwinne pozwalają na eliminowanie wielu ryzyk projektowych:

Osobiście uważam, iż podejście zwinne znacznie podnosi jakość zarządzania ryzykiem w projekcie i to jest największą korzyścią w stosunku do tradycyjnych metodyk. Nikt z nas nie wie, co wydarzy się w przyszłości, natomiast jako kierownicy projektów powinniśmy być stale przygotowani na zmiany w otoczeniu projektowym. Należy zadać sobie pytanie, jak długo jesteśmy gotowi czekać, zanim odkryjemy, że projekt przekracza budżet, opóźnia się lub dostarczy nie takiej funkcjonalności, której chce klient. Podejście iteracyjne pozwala nam śledzić postępy projektu z bardzo duża dokładnością i daje nam możliwość zareagowania z wyprzedzeniem, co finalnie przekłada się na korzyści w różnych obszarach projektu.

Dziś omówię zarządzanie ryzykiem w Agile nieco szerzej i wskażę możliwe podejścia do tego tematu.

Chciałbym zacząć od tego, że zarządzanie ryzykiem jest niejako wpisane w filozofię Agile. Chcemy dostarczać wartość, działający software i tym samym powinniśmy eliminować wszelkie zagrożenia, które mogą mieć istotny wpływ na wynik naszej pracy (lub zwiększać szansę tych zdarzeń, które mogą pozytywnie oddziaływać na rezultaty naszych działań).

Jeśli zarządzanie ryzykiem kojarzy Ci się z czymś ciężkim, bardziej tradycyjnym, to zapewniam, że tak nie jest i można nim zarządzać naprawdę zwinnie – zapraszam do lektury.

Podejście lekkie

W zależności od skali, stopnia złożoności, doświadczenia zespołu czy innowacyjności naszego produktu, będziemy stosować podejście mniej lub bardziej aktywne. W pierwszym przypadku zakładamy po prostu, że koszty zarządzania ryzykiem są nieadekwatne do nakładów, w związku z czym potencjalne ryzyka eliminowane są w oparciu o nasze procesy, przykładowo:

  • Codzienne spotkania zespołu pozwalają zidentyfikować i eliminować typowe ryzyka związane ze sprintem
  • Retrospektywa pozwala szerzej spojrzeć na projekt oraz proces i daje szanse na wprowadzenie usprawnień oraz eliminowanie zagrożeń
  • Porządkowanie Backlogu pozwala na unikanie ryzyk związanych z błędnym rozumieniem wymagań
  • Dema z użytkownikami końcowymi pozwalają na szybką weryfikację, czy produkt dostarcza wymaganą funkcjonalność
  • Na poziomie pracy development teamu – code review w celu uniknięcia problemów z nieczytelnym kodem w przyszłości

Podejście lekkie mocno związane jest z zakresem prac, zwłaszcza na wczesnym etapie projektu, kiedy najbardziej istotne ryzyka i działania z nimi związane włączane są do naszego Backlogu. Przykładem takich działań może być sprawdzenie sensowności zastosowania danego narzędzia / technicznego podejścia w pierwszej iteracji, aby w kolejnych wybrać już właściwą drogę rozwoju produktu.

Attack risk before they become tomorrow’s problem.

W podejściu lekkim ryzyka są zatem zarządzane, choć może się zdarzyć, że nie jest to w pełni świadome działanie, zwłaszcza dla mniej doświadczonych zespołów.

Podejście aktywne

W podejściu aktywnym stosujemy mechanizmy znane z świata tradycyjnych metodyk, takich jak PRINCE2 czy PMBOK, odpowiednio dostosowując je do potrzeb naszego projektu. Oznacza to, że powinniśmy uwzględnić w naszym procesie podstawowe kroki zarządzania ryzykiem.

image001

Zanim zaczniemy

Zanim zaczniemy podejmować konkretne działania związane z ryzykami, warto ustalić kilka prostych reguł / definicji, które określą, jak będziemy zarządzać ryzykiem w projekcie. Będzie to nasz odpowiednik dla strategii zarządzania ryzykiem, który powinien zawierać takie informacje jak:

  • Przyjęta skala dla wpływu i prawdopodobieństwa występowania ryzyka
  • Sposób opisywania ryzyka (wpływ, prawdopodobieństwo, nazwa, opis itp.)

Moim zdaniem na początek to w zupełności wystarczy i w trakcie prac możemy (jeśli to będzie konieczne) ustalać kolejne elementy (sposoby zapisu ryzyk, częstotliwość spotkań itp.).

Pamiętajmy także, że taki zapis powinien się zmieniać w trakcie projektu, jeśli zajdzie taka potrzeba (na przykład przedefiniowanie skal na wartości pieniężne w momencie, gdy Product Owner i Zespół są już w stanie to zrobić).

Identyfikacja ryzyk

Ryzyka mogą występować na wielu poziomach, dlatego bardzo ważne jest zaangażowanie każdej osoby mającej wpływ na projekt (Product Owner, Development Team, Sponsorzy, Klienci, Użytkownicy Końcowi itp.). Jeśli to możliwe, powinniśmy włączyć w proces identyfikowania ryzyk każdego, kto może coś wnieść wartościowego do tego procesu.

if we have no involvement, we have no commitment.

Być może będzie to także lider innego projektu i jego doświadczenia, mogą to być lessons learned z poprzednich projektów, rejestry ryzyk, profile i wszelkie inne źródła danych na temat ryzyk, które mogą wystąpić w naszym projekcie. Jeśli nie wiemy, od czego zacząć, to można skorzystać z dostępnych publicznie list ryzyk.

Zwykle zaangażowanie wszystkich stron wymaga sporo wysiłku, niemniej warto przynajmniej raz, przy starcie projektu, takie spotkanie poświęcone identyfikacji (i najlepiej także ocenie) ryzyk zorganizować. Następnie zespół projektowy może regularnie już sam pracować dalej z stworzonym zapisem dotyczącym ryzyk.

Ocena ryzyk

Ryzyko możemy wyrażać poprzez iloczyn prawdopodobieństwa (jak pewne jest wystąpienie danego ryzyka) oraz wpływu (jakie konsekwencje poniesiemy, jeśli ryzyko się zmaterializuje).

Ekspozycja na ryzyko = Pradwopodobieństwo x Wpływ

Jedną z możliwych do zastosowania implementacji jest przyjęcie skali uproszczonej, opisanej wartościami 1, 2 lub 3. Pozwala to na szybką ocenę i priorytetyzację ryzyk. Przykładowy uproszczony rejestr ryzyk po uszeregowaniu wg wartości.

Risk Name Probability Impact Severity
Driver performance 2 3 6
Legacy module performance 3 2 6
Access to external API 2 2 4
Server patches 1 1 1
Total Risk Severity (Exposure)     17

 

Planowanie działań

Zespół może przeznaczyć część planowania na działania związane z ryzykami, może także organizować dedykowane spotkanie, na przykład co dwa tygodnie. Tutaj w dużej mierze zależy to od tego, jak bardzo ryzyka wpływają na projekt i zespół musi sam znaleźć równowagę i ocenić jaki koszt zajmowania się ryzykiem będzie odpowiedni.

Dodatkowo można zastanowić się na nad mechanizmem aktualizowania informacji na temat ryzyk od pozostałych osób mających wpływ na projekt, np. użytkownicy końcowi korzystający z narzędzia typu bug tracker do zgłaszania potencjalnych ryzyk, którymi zespół może się zająć.

Działanie

Jednym ze sposobów na włączenie działań związanych z ryzykiem do prac zespołu jest wydzielenie odpowiedniego czasu na ryzyka w iteracji.

Można także stosować inne podejście poprzez tworzenie dodatkowych user stories (lub innej formy zapisu wymagań). Zapisujemy ryzyka jako dodatkowe user stories i traktujemy ja analogicznie do wszystkich standardowych wymagań (ustalamy ich wartość oraz priorytet). Przykład takiego procesu doboru działań związanych z reakcjami na ryzyko i włączanie ich do backlogu produktu.

risk

Monitorowanie

W zależności od przyjętego sposobu zapisu i działań związanych z ryzykiem, ryzyko monitorowane może być w trybie ciągłym bądź w wybranych momentach czasu. Idealnie, jeśli przynajmniej kluczowe ryzyka są widoczne dla całego zespołu przez cały czas, dzięki czemu zapewniamy ciągły i mało nas kosztujący mechanizm monitoringu. Na przykład rejestr ryzyk w formie tablicy umieszczony w pokoju zespołu.

image005

Innym rozwiązaniem może być aktualizowanie po każdym sprincie rejestru ryzyk w formie tabeli.

Risk Name / Month June July August September October
Driver performance 6 0 0 0 0
Legacy module performance 6 3 0 0 0
Access to external API 4 4 0 0 0
Server patches 1 1 1 1 0
Product Owner Absence 3 0
Total 17 8 1 4 0

 

Można także zobrazować zmiany poprzez risk burndown chart.

image006

Kolejny widok, obrazujący status i trend kluczowych ryzyk, można uzyskać poprzez cumulative project risk profile.

image008

Podsumowanie

Moim zdaniem ryzykami w Agile należy zarządzać aktywnie, w oparciu o bardzo proste i skuteczne mechanizmy, które te działania ułatwiają. Agile Risk Management to:

  • Mniej formalizmów niż w podejściu zalecanym przez PMBOK czy PRINCE2
  • Odpowiedzialność całego zespołu za zarządzanie ryzykami
  • Pełna ciągłość, aktualność informacji na temat ryzyk
  • Zorientowanie na działanie
  • Pełna kontrola przez cały projekt
  • Ryzyka biznesowe także widoczne dla zespołudeweloperskiego
  • Ryzyka techniczne widoczne dla biznesu

Na koniec jeszcze mała niespodzianka – zarządzanie ryzykiem w zwinnym projekcie w wersji mini.

image010

 

 

 

Komentarze
This site is using the Seo Wizard plugin created by http://seo.uk.net/