Dziś publikuję artykuł z serii "symbioza RUP i PRINCE2" Wszystkie artykuły z cyklu można znaleźć na IT CREW BLOG

Już od ponad dwóch lat jest najnowsza edycja PRINCE2 (wersji 2009, polskie wydanie 2010). Zmiany, które zostały wprowadzone w 2009 roku, dążą w kierunku „odciążenia” tej metodyki. Pewne elementy zostały uproszczone, inne zaś uporządkowane. Między innymi w PRINCE2:2009 zostało opisane 7 principiów — uniwersalnych zasad, które tak naprawdę występują w tej czy innej postaci również w innych metodykach. Poza tym zostało zredukowane dotychczasowe 8 procesów do 7. Natomiast dotychczasowe 8 komponentów zostało zmienione na 7 tematów. Podsumowując, w PRINCE2:2009, mamy super kumulację: 777.

Mówiąc zupełnie poważnie, w najnowszej edycji, PRINCE2 oferuje sporo uporządkowanych ale poważnie złagodzonych metod zarządczych. Dokumenty nie muszą już występować w postaci sformalizowanej. Chociaż postać sformalizowana często ma niewątpliwe zalety, to w najnowsze edycji mówi się o tym, że produkty zarządcze (dokumenty) powinny zawierać określone zestawy informacji, które są wykorzystywane w procesach PRINCE2 w celu umożliwienia określonym rolom podjęcia działań i/lub decyzji. Ostatecznie produkt zarządczy może przyjąć dowolną formę: wydrukowanego dokumentu, e-maila lub też krótkiej rozmowy w windzie.

Historycznie PRINCE2 wywodzi się z projektów informatycznych. Z biegiem czasu, z metodyki zniknęły wszystkie odniesienia do informatyki. Obecnie jest to uniwersalna metodyka dla dowolnych projektów biznesowych. W związku z tym, jak to zwykle bywa w przypadku ogólnych metodyk zarządzania, pojawiła się w niej pewna celowa luka. PRINCE2 nie określa technicznych szczegółów implementacji, również nie daje szczegółowych wskazówek jak podchodzić do rzeczy typowo technicznych. Daje za to konkretne i bardzo precyzyjne wskazówki, jak należy podchodzić do projektów od strony biznesowej.

RUP z kolei dobrze określa co należy zrobić i w jakiej kolejności dla projektów, które mają na celu wytworzenie systemu informatycznego. Jednakże RUP nie do końca dobrze określa co ma się dziać tuż przed projektem, ani co tuż po zakończeniu projektu. RUP również nie daje zbyt dużo narzędzi, które mogłyby określić czy system informatyczny będzie przynosił korzyści biznesowe i zyski czy nie. Nie daje też zbyt wiele wskazówek jak należy przeprowadzić przekazanie produktu finalnym użytkowników, ani w jaki sposób dobrać uczestników projektu. Za to to wszystko dobrze określa PRINCE2.

Zatem powstaje dosyć oczywiste dążenie połączenia typowo biznesowego podejścia w PRINCE2 z typowo informatycznym dobrym ogarnięciem tematów systemowych w RUP. Czy taka symbioza ma szanse się powieść czy nie? Czy różnice modeli cyklu życia projektu, typowy wodospad w PRINCE2 i spiralny iteracyjno-przyrostowy w RUP dadzą się pogodzić czy nie? W poprzednich wersjach PRINCE2 był z tym spory problem. Jednak w edycji 2009 dokonano wiele uproszczeń i udogodnień, które spowodowały, że taka symbioza stałą się możliwa.

7 pryncypiów kontra 6 najlepszych praktyk

PRINCE2:2009 przedstawia 7 principiów w sposób bardzo zbliżony do 6 najlepszych praktyk w RUP. Oto te principia:

#Ciągła zasadność biznesowa
#Korzystanie z doświadczeń
#Zdefiniowane role i obowiązki
#Zarządzanie etapowe
#Zarządzanie z wykorzystaniem tolerancji
#Koncentracja na produktach
#Dostosowanie się do warunków projektu
Natomiast RUP podaje 6 najlepszych praktyk. Oto one:

#Zarządzanie wymaganiami
#Architektura oparta na komponentach
#Wizualne modelowanie
#Zarządzanie zmianami
#Iteracyjne wytwarzanie oprogramowania
#Systematyczna weryfikacja jakości

Niektóre principia PRINCE2 izomorficznie łączą się z najlepszymi praktykami RUP. Tak na przykład zarządzanie etapowe łączy się z iteracyjnym wytwarzaniem oprogramowania, koncentracja na produktach z architekturą opartą na komponentach, zarządzanie z wykorzystaniem tolerancji z zarządzaniem zmianami, dostosowanie się do warunków projektu z zarządzaniem wymaganiami. Poza tym, tak naprawdę wizualne modelowanie bardzo blisko łączy się z koncentracją na produktach. Natomiast systematyczna weryfikacja jakości łączy się z tematem „Jakość” w PRINCE2. Natomiast zasada zdefiniowanych roli i obowiązków łączy się pośrednio z koncepcją artefaktów i delegacji odpowiedzialności w RUP. Korzystanie z doświadczeń w PRINCE2 łączy się cyklem Le Chateliera, który niejawnie jest wpisany w cykl wytwarzania oprogramowania.

To, czego brakuje w RUP, to ciągła zasadność biznesowa. Pomimo istnienia dokumentu wizji biznesowej, RUP nie przywiązuje zbytniej uwagi do zasadności prowadzenia projektu i ma dosyć bierne podejście do zasadności biznesowej. W sumie, jako metodyka najlepiej pasująca do dostawcy, nie musi się skupiać na rzeczach biznesowych, a jedynie na zmanufaktoryzowaniu procesu dostarczenia produktów informatycznych. I tu z pomocą przychodzi PRINCE2.

Jednym ze sztandarowych pytań „powakacyjnych” PRINCE2, jest pytanie, czy warto kontynuować projekt, który stracił zasadność biznesową? Szczególnie w przypadku, gdy np. projekt jest wart $2’000’000, a do zakończenia projektu zostało $50’000? PRINCE2 mówi, że nie warto. Dlaczego organizacja ma stracić kolejne $50’000, a na dodatek produkt końcowy nie przyniesie zwrotu kosztów inwestycji i zakładanych (oczekiwanych) przychodów? RUP niestety nic na ten temat nie mówi. Dlatego PRINCE2:2009 i RUP, w przypadku projektów informatycznych, wydają się być komplementarne.

Aleksander Olszewski