Zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM

Wstęp

Zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM nie jest prostym zadaniem. Samo podjęcie decyzji o wykorzystaniu tej metodyki nie jest łatwe. Jednym z pierwszych dylematów, jest obawa przed mierzalnością poszczególnych faz projektowych. Brak jasno wytyczonego sposobu postępowania rodzi obawy, sponsorów projektu, o wprowadzenie anarchii projektowej.

Pierwszym krokiem przy analizie problemu jak ułożyć projekt wdrożeniowy kierując się wartościami SCRUMowymi jest porównanie metodyk. Poniższy rysunek prezentuje różnicę w fazowaniu projektów w metodykach tradycyjnych (waterfall) oraz metodyk zwinnych/iteracyjnych (scrum):

Zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM

Porównanie faz projektu dla metodyk zwinnych oraz tradycyjnych

Przewagą podejścia tradycyjnego jest „domyślne” rozumienie każdej z faz przez sponsorów biznesowych. Dodatkowym plusem, jest każdorazowa próba zwymiarowania projektu w jednostkach pracochłonności po każdej z faz projektowych. Taka wycena nie jest jednak procesem trywialnym i nie każdy kierownik projektu jest w stanie sobie z nią poradzić. Daje to Komitetowi Sterującemu informację jaki jest poziom uzyskanych korzyści w stosunku do poniesionych kosztów.

Największą wadą metodyk tradycyjnych jest ich „nieczułość” na zmiany zachodzące zarówno wewnątrz jak i w otoczeniu biznesu. Kolejnym równie istotnym minusem jest niedokładność przedstawianych estymacji (wynikających z poziomu skomplikowania projektu). Biorąc pod uwagę w/w fakty łatwo wywnioskować, że analizowane w pierwszej fazie procesy na koniec wdrożenia mogą wyglądać zupełnie inaczej. Ryzyko to dodatkowo potęguje długi czas trwania wdrożenia (12 – 24 miesiące). Dlatego też wdrożenia scrumowe w odróżnieniu od tradycyjnych rzadziej kończą się totalnym niepowodzeniem. Należy mieć na względzie że najwyższą ceną za nieudane wdrożenie systemu ERP może być bankructwo przedsiębiorstwa.

Jeśli ostatecznie zdecydowaliśmy się prowadzić wdrożenie systemu ERP w sposób SCRUMowy proponuję rozważyć kilka możliwości implementacji podejścia iteracyjnego. Na początku opiszę 2 modele konserwatywne, kolejne modele będą przedstawiały hybrydy pomiędzy tradycją o iteracją.

MODEL 1 – Konserwatywny model SCRUM

Najbardziej konserwatywny model scrumowy sugerowany przez metodycznych purystów nie zakłada jakichkolwiek faz projektowych a jedynie kolejne wydania aplikacji tzw. releasy.

Zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM

Fazy projektu w modelu 1

Osobiście uważam ten model nie do zaimplementowania w realiach nowego wdrożenia systemu ERP. Aczkolwiek myślę, że sprawdzi się przy projektach serwisowych oraz rozwojowych już wdrożonego systemu.

Scrum Masterzy którzy przekonują klientów, że zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM w jego czystej postaci jak w przedstawionym modelu jest optymalne. Raczej ślepo wierzą w metodykę niż mają poparte udanymi wdrożeniami doświadczenie. A pamiętajmy i odnosi się to zarówno do metodyk zwinnych jak i tradycyjnych. Zastosowanie którejkolwiek z nich nie gwarantuje powodzenia projektu (choć zwiększa prawdopodobieństwo sukcesu).

Przy próbie implementacji (nieudanej) konserwatywnego podejścia do SCRUMa napotkałem następujące trudności:

  • Upakowanie wszystkich elementów wytworzenia produktu tj. Analizy, Wykonania, Testów oraz Implementacji. Spowoduje wydłużenie sprintu co najmniej do 4 tygodni (i tak trudno jest wykonać cały proces biznesowy przez ten czas).
  • W nowym wdrożeniu tylko system jako całość niesie wartość dla klienta zatem raczej nie spotyka się podziału na releasy.
  • Nawet jeśli mamy podział na releasy z reguły czas trwania pierwszego z nich jest bardzo długi 1 – 2 lata (pozostałe możemy potraktować jako rozwój narzędzia i wtedy SCRUM ma już sens);
  • Łatwość popadnięcia w anarchię – ze względu na wysoką złożoność wdrożeń ERP brak szkieletu w postaci przeprowadzonej analizy biznesowej powoduje poważne problemy w zarządzaniu zakresem projektu;
  • Brak wystarczającej dojrzałości organizacji, szczególnie jeśli chodzi o rolę Product Ownera, nie spotkałem się jeszcze z dobrze przygotowanym Product Backlogiem zanim rozpocząłem wdrożenie (jeśli w ogóle klient go przygotował to już był sukces);

Podsumowując zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM w MODELU 1 jest problematyczne. Jego użycie widzę bardziej w zarządzaniu:

  1. Pracami rozwojowymi nad narzędziem. Dodawania obsługi kolejnych wspierających procesów biznesowych (zakładam że procesy główne wdrożyliśmy we wdrożeniu właściwym), optymalizację / automatyzację procesów biznesowych głównych etc.
  2. NIENADAJE się natomiast do nowych wdrożeń od podstaw lub migracji z mniejszego systemu ERP do bardziej kompleksowego rozwiązania.

MODEL 2 – Tradycja z elementami SCRUM

Model 2 jest poniekąd odwróceniem podejścia z modelu 1 tj. jest to model najbardziej zbliżony do metodyk waterfallowych / tradycyjnych. Puryści SCRUMowi raczej odrzucą go na wstępie. Jednak należy wziąć pod uwagę, że kreowanie tradycyjnego podejścia do zarządzania projektami jest kształtowane od lat 90’. Oznacza to, że w wielu organizacjach nomenklatura oraz sposób myślenia o projekcie zgodnie z waterfollowym podejściem jest głęboko zakorzeniony. Szczególnie że zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM jest dziedziną nową. Podstawowym pytaniem jest czy na pewno chcemy rezygnować ze wszystkiego co organizacji w tej materii udało się wypracować? Oraz czy zgadzamy się na podjęcie ryzyka jakim jest zmiana podejścia oraz przyzwyczajeń zespołu projektowego oraz kadry zarządzającej? Osobiście jestem zdania, że rewolucja fundowana projektowy czy całej firmie nie obywają się bez ofiar. Dlatego jestem zwolennikiem ewolucyjnego modelu zmiany. A model 2 jest takim kolejnym krokiem w zmianie podejścia projektowego.

Drugi model fazowania projektu opiera się na koncepcji zachowania waterfollowych faz projektowych, czyli:

  1. DIAGNOZY (faza opcjonalna);
  2. ANALIZY
  3. WYKONANIA
  4. TESTÓW ODBIOROWYCH
  5. URUCHOMIENIA / STABILIZACJI ROZWIĄZANIA

Jednak prace prowadzone w ramach tych faz rządzą się prawami zaczerpniętymi ze scruma, rysunek poniżej prezentuje poglądowo organizację pracy.

Zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM

Fazy projektu w modelu 2

W modelu tym tworzymy BackLog (zakres prac) dla każdej z faz z osobna. Naturalnym jest, że w ramach fazy poprzedniej tworzony jest zakres prac dla fazy kolejnej. Co do zasady nie powinniśmy przechodzić do kolejnej fazy bez zakończenia fazy poprzedniej. W większości projektów po każdej z faz następuje rewizja harmonogramu, budżetu oraz postępu prac projektowych.

Wad tego modelu jest bardzo wiele, poniżej przedstawiono kilka z nich. Jedną z pierwszych jest nieczułość na zmiany otoczenia biznesowego w trakcie trwania projektu, ze względu na stały / wcześniej uzgodniony zakres w ramach fazy diagnozy oraz analizy. Oczywiście w ramach projektu określamy procedurę zgłaszania zmian, ale z doświadczenia wiem, że klienci niechętnie z niej korzystają. Dla klienta wiąże się to z dodatkowymi wycenami zakresu. Dla firmy wdrożeniowej jest o tyle kłopotliwe, że rzutuje na rzetelność fazy analizy. Kolejnym minusem jest to że nie pozwala wyjść klientowi oraz dostawcy z fazy negocjacji. W konsekwencji trwa ona przez cały projekt. Co skutecznie odciąga uwagę zarządzających oraz zespołu projektowego od głównego celu projektowego jakim jest uruchomienie systemu. Często obie strony „konfliktu” orientują się w bezcelowości sporu / negocjacji kiedy jest już za późno i wdrożenie należy „ratować”.

Podsumowując oprócz organizacji w których tradycyjne metodyki zarządzania projektami zostały udanie wdrożone dla projektów IT, Modelu 2 nie polecam. Jeśli mamy traktować nasz projekt jako krok organizacji w kierunku scruma zastanowiłbym się od razu nad implementacją modelu 3. Odradzam również w/w model dla konstrukcji projektu: klient – dostawca. Uważam, że częstotliwość informowania klienta o zmianach budżetu oraz harmonogramu jest niewystarczająca.

MODEL 3 – Analiza + Sprinty developerskie

Model 3 jest pierwszym z tu przedstawianych modeli hybrydowych z przewagą zastosowania metodyki tradycyjnej. Opiera się na podziale projektu wdrożeniowego na dwie fazy:

  1. Diagnoza i analiza
  2. Wykonanie, testy, implementacja

Zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM w modelu 3 charakteryzuje się przede wszystkim scrumowym porządkiem. Według którego fazy dzielimy na sprinty o długości nie przekraczającej 4 tygodni, wykonujemy codzienne daily scrum etc.

Zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM

Fazy projektu w modelu 3

W pierwszej fazie budujemy szczegółowy product backlog. Po zakończeniu prac jest on na tyle dokładny, że możemy na jego podstawie z marszu zbudować sprint backlog. Na podstawie przeprowadzonej analizy obok opisu funkcjonalności standardowych, precyzyjnie zamodelowano modyfikacje systemu. Tak przygotowana lista stanowi zaczątek do powstania listy zadań. Każde z zadań posiada swoją wycenę złożoności np. w story pointach oraz szacunkową pracochłonność. Na podstawie odpowiednio zwymiarowanej listy powstaje harmonogram oraz budżet wdrożenia.

Fazę wykonania sprowadzamy do czystego SCRUMa. Precyzyjnie zbudowany product backlog pozwala dosyć szybko i gładko przejść z jednej fazy do drugiej.

Najpoważniejszą wadą tego podejścia, jest pokusa zamrożenia ceny zgodnie z budżetem stworzonym w ramach fazy analizy. Co w przypadku jakiejkolwiek zmiany (np. wzrostu skomplikowania funkcjonalności już opisanej w ramach analizy) prowadzi do nieustannych negocjacji budżetu wdrożenia. Natomiast sytuacja w tym modelu jest o tyle lepsza, że umożliwia zastosowanie umów hybrydowych o których mowa w artykule … .

Zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM w modelu 3 wiąże się z ryzykiem przeciągania w nieskończoność faza analizy. Powiedzenie papier wszystko przyjmie w odniesieniu do tego modelu nabiera realnego wymiaru. W swojej praktyce widziałem w/w model, w którym faza analizy trwała 12 miesięcy. Przez ten czas można by wyprodukować około 45% całego wdrożenia. Ale obie strony uparcie kontynuowały pracę i żadna z nich nie chciała przyznać że analiza dalszych szczegółów jest bezcelowa.

Czasami wdrożenie takiego modelu jest jedyną możliwością wykorzystania filozofii SCRUMa. A to za sprawą możliwości wdrożenia w/w podejścia do umów podpisanych z myślą o metodykach tradycyjnych. Kwestia przycięcia faz do 2 i mamy „prawie” Scruma w umowie tradycyjnej.

MODEL 4 – Kaskadowe sprinty

Zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM w modelu 4 zakłada brak faz oraz dostarczenie wysokiej jakości product backlogu. Co prawda w mojej praktyce jeszcze nigdy mi się to nie przytrafiło. Znacznie częściej wykorzystywałem pierwsze 2 miesiące na stworzenie product backlogu przez konsultantów. W tym czasie programiści rozpoczynają migrację danych. Dzięki takiemu podziałowi cały zespół developerski ma co robić. Ponadto klient pracuje w trakcie wdrożenia na „własnych danych” co stanowi ogromne ułatwienie.

Jak wspomniałem na wstępie, aby model przyniósł odpowiednie korzyści faza diagnozy powinna być maksymalnie krótka optymalnie do 2 miesięcy. W ramach budowy product backloga identyfikujemy procesy biznesowego oraz kroki procesów z których się składają. To pozwala product ownerowi zarządzać wdrożeniem na poziomie wykonywania procesów biznesowych.

Samo wykonanie poszczególnych procesów przebiega z 1 sprintowym opóźnieniem tzw. lagiem.

Zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM

Fazy projektu w modelu 4

Oznacza to że w ramach sprint planningu, product owner wybiera procesy biznesowe którymi zespół projektowy zajmie się w pierwszej kolejności. W ramach pierwszego sprintu powstają opisy poszczególnych funkcjonalności oraz opisy prac do wykonania dla programistów (modyfikacje). Zakończenie prac określone jest przez definition of done oraz definition of ready. Tak przygotowane zadania wchodzą jako product backlog do sprint planningu następnego sprintu.

Zespół projektowy w ramach planowania nadaje każdemu z zadań odpowiednią liczbę story pointów. Zadania następnie są rozdzielane pomiędzy każdego z developerów i tak przystępujemy do wykonania kolejnego sprintu. Do mierzenia postępów prac w ramach pojedynczego sprintu zalecam używanie tablicy kanbanowej (czy to w wersji elektronicznej czy tradycyjnej).

Zadania wykonane w ramach sprintu są prezentowane w ramach sprint review. Testy wykonanych zadań są planowane w ramach kolejnego sprintu. Zespół testerów po zakończeniu testów albo wraca z zadaniem do backloga albo kończy wykonanie pojedynczego procesu.

Podsumowanie
Zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM

Jak wspomniano na wstępie zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM nie jest proste. Przedstawione tu 4 modele organizacji projektu w połączeniu z odpowiednią budową zespołu wdrożeniowego (patrz: Budowa Zespołu Projektowego) stanowią prostą receptę na osiągnięcie tego celu. Wszystkie opisane tu modele są z powodzeniem wykorzystywane w mojej praktyce. Czy którąś z nich mogę polecić? Osobiście nie, bo sam stosuję je naprzemiennie (wady zapisałem nie po to żeby odradzać któryś z modeli a po to żeby od razy wystrzegać się błędów przy ich stosowaniu). Każdą z metodyk należy odpowiednio dobrać do projektu: jego rozmiaru, stopnia świadomości klienta, kultury organizacyjnej etc. W odrębnym artykule postaram się zebrać garść porad na co zwrócić uwagę przy wyborze modelu. A na pytanie czy zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM jest możliwe? Odpowiadam TAK i dodaję spróbuj bo naprawdę warto.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

fourteen − 6 =