niedziela, 6 listopada 2011

Zarządzanie ryzykiem w agile/SCRUM

Większość literatury i metodyk opisujących agile pomija zupełnie temat zarządzania ryzykiem. Jednak ryzyko jest wpisane w projekty z samej ich definicji - jeżeli projekt jest przedsięwzięciem innowacyjnym, to muszą być z nim związane ryzyka. Aby uniknąć wątpliwości przyjmijmy definicję, że ryzyko to jakiekolwiek przyszłe, niepewne wydarzenie, które może mieć wpływ na zakres, czas, zasoby bądź jakość projektu.

Najprościej jest powiedzieć, że agile ma zarządzanie ryzykiem wbudowane w samą metodykę ze względu na krótkie iteracje, dostarczanie działających wersji produktu, stały kontakt z klientem oraz retrospekcje obejmujące zakres, technologię i procesy. Dokładając do tego możliwość poprawnego priorytetyzowania funkcjonalności (te z wysokim ryzykiem jako pierwsze) dostajemy system, który powinien "samodzielnie" poradzić sobie z ryzykiem. Jeżeli ryzyko się zmaterializuje to dzięki krótkiej iteracji będzie można szybko zmienić plan i dostosować zakres do nowej sytuacji. Dzięki wybraniu najbardziej ryzykownych funkcjonalności jako pierwszych będziemy mogli szybko sprawdzić wykonalność całego projektu, itd. (napiszę osobny post na temat tego jak działa to wbudowane w metodykę zarządzanie ryzykiem).

Działania w ramach metodyki agile mogą znacząco ograniczyć ryzyka związane z technologią i niepewnością dotyczącą zakresu produktu. Niestety nie są to jedyne ryzyka, które mogą pojawić się w trakcie realizacji projektu. W szczególności w większych organizacjach i projektach do tych dwóch kategorii ryzyk dochodzi wiele innych związanych np. z finansowaniem inwestycji, integracją z innymi elementami systemu, wdrożeniem systemu na środowiskach produkcyjnych, sytuacją rynkową organizacji czy nawet polityką wewnętrzną. Takimi ryzykami nie zarządzimy tylko dzięki krótkim iteracjom i skupianiu się na dostarczaniu wartości dla klienta. Tego typu ryzyka są zupełnie pomijane w większości literatury dotyczącej agile. Czas więc odkurzyć metody zarządzania ryzykiem rodem z PMI. Co tam znajdujemy?

Pominąwszy procesy związane z identyfikacją ryzyk czy ich jakościową oceną (ilościowa w moim odczuciu nie współgra z duchem projektów agile) pojawia się proces pod nazwą Planowanie Odpowiedzi na Ryzyka. Do każdego z ryzyk można zastosować cztery ogólne strategie: akceptacji (nic nie robię, jak się zdarzy to trudno), unikania (podejmuję aktywne działania, aby ryzyko się nie spełniło), minimalizacji skutków (czekam na ryzyko i mam gotowy plan jak ograniczyć jego skutki jak już zaistnieje) oraz przeniesienia/transferu (płacę komuś żeby się o to martwił - ubezpieczenia). Niezależnie od metody, którą prowadzimy projekt, w przypadku wybrania dla zarządzenia ryzykiem strategii innej niż akceptacja, należy dostosować plan projektu do wybranej strategii zarządzania ryzykiem. W przypadku agile również takie akcje należy podjąć. Jeżeli chcemy unikać jakiegoś ryzyka to działania prowadzące do tego unikania powinny zostać zapisane i przydzielone do realizacji w możliwie najbliższej iteracji. Dzięki temu ryzyko będzie miało mniejsze prawdopodobieństwo zaistnienia. Jeżeli wybieramy strategię minimalizacji skutków to założeniem tej strategii jest opracowanie planu co zrobić zanim ryzyko się zmaterializuje. W tym wypadku przełożenie tego na agile polega na posiadaniu "na boku" zestawu funkcjonalności/karteczek, które wejdą do realizacji jeżeli dane ryzyko się zmaterializuje. O tym czy dany zestaw działań minimalizujących zrealizować czy nie powinno się oczywiście decydować w ramach zwykłego planowania iteracji. Jeżeli natomiast wybieramy strategię transferu ryzyka to takie działanie również pociąga za sobą konieczność wykonania działań, zwykle jednak nie są to działania na poziomie zespołu projektowego.

Co ciekawe ze względu na specyfikę ryzyk, o których tutaj rozmawiamy (nie produkt i nie technologia) bardzo często plany dotyczące radzenia sobie z nimi będą w małym stopniu angażować zespół projektowy a dużo większym np. product ownera. Niemniej jednak takimi ryzykami też trzeba zarządzać w metodykach agile. Zarządzać to znaczy planować, przydzielać odpowiedzialności i później nadzorować ich realizację. Czasami może się to niestety sprowadzić do tego, że będziemy musieli mieć inny niż iteracyjny sposób zarządzania tymi zadaniami (z tego powodu, że zaangażowane osoby nie pracują w takim rygorze).

I tak na koniec: w metodyce PMI w obszarze dotyczącym zarządzania ryzykiem, pierwszy proces, który się pojawia to Zaplanuj Zarządzanie Ryzykiem. Co polecam zrobić dla wszystkich ryzyk, w każdym projekcie, w tym również w tych prowadzonych metodykami agile.


Brak komentarzy: