• Nie Znaleziono Wyników

AgilePM (Dynamic System Development Method)

ZWINNYCH METODYK ZARZĄDZANIA PROJEKTAMI

1) Modelowanie obiektów domeny (ang. domain object modeling) – praktyka polegająca na dokładnym rozpoznaniu i opisaniu rozpatrywanego problemu poprzez

2.9. AgilePM (Dynamic System Development Method)

DeCarlo zawarł w XPM silnie idealistyczną, humanistyczną i osobistą diagnozę skrajnie trudnych warunków realizacji projektów, jednakże proponowane zalecenia mają charak-ter ogólny, a co za tym idzie: uniwersalistyczny i zawsze aktualny.

Filozofia DSDM sformułowana została w formie właściwej wizji zarządczej. Mówi ona, iż „najlepsza wartość biznesowa wyłania się, gdy projekty są powiązane z jasnymi celami biznesowymi, dostarczają często, a także angażują do współpracy ludzi zmotywo-wanych i odpowiednio umocozmotywo-wanych”178. Takie hasło i swoisty „manifest” przyświeca autorom metodyki i powinien towarzyszyć także zespołom pracującym zgodnie z zale-ceniami metody.

Nakreślonej wizji towarzyszą określone pryncypia uszczegóławiające ją do postaci ośmiu kierunkowych zaleceń, będących de facto regułami heurystycznymi:

1) Koncentruj się na potrzebie biznesowej.

2) Dostarczaj na czas.

3) Współpracuj.

4) Nigdy nie idź na kompromis w kwestii jakości.

5) Buduj przyrostowo od solidnych podstaw.

6) Rozwijaj iteracyjnie.

7) Komunikuj się ciągle i jasno.

8) Demonstruj kontrolę179.

Podobnie jak w przypadku np. pryncypiów PRINCE2 zalecenia te mają sugerować postawy, kulturę, zachowania zespołu. Mimo ogólnego nakreślenia stanowią one istotny i niepomijalny element metodyki.

Z perspektywy „mechaniki” prezentowanego rozwiązania, kluczowe znaczenie mają w nim zalecenia dotyczące procesu DSDM. W tym zakresie metodyka proponuje szersze podejście niż większość innych metodyk zwinnych, gdyż obejmuje ona swoim zasięgiem cały cykl życia projektu: począwszy od jego zainicjowania, przez planowanie i organiza-cję, budowanie rozwiązania, po wdrożenie oraz fazę po projektową. Metodyka zachowuje przy tym elastyczność i swój iteracyjny charakter oraz może być dość swobodnie konfi-gurowana w zależności od rozmiaru, zmienności rozwiązania oraz wymagań względem częstotliwości i zakresu kolejnych wydań.

Faza „przed-projektem” (ang. pre-project) związana jest przede wszystkim z podej-mowaniem decyzji związanych z uruchomieniem projektu, odniesieniem go do strategii oraz identyfikacją celów i problemów, które ma rozwiązać. W tej fazie powołuje się rów-nież osoby pełniące role sponsora biznesowego oraz wizjonera biznesowego. Faza ta ma zapewnić, iż realizujemy właściwe i dobrze zorganizowane projektu. Na tym etapie two-rzone są również tzw. warunki odniesienia (ang. terms of reference) określające kontekst biznesowy, cele projektu oraz zakres i uzasadnienie kolejnej fazy wykonalności180. Zgod-nie z zaleceniami autorów metodyki „przed projektem” powinno trwać relatywZgod-nie krótko.

178 Agile Business Consortium, Agile PM…, s. 16.

179 Ibid., s. 20–21.

180 Ibid., s. 39.

Rysunek 29. Model procesu DSDM

Rozwój ewolucyjny

Preprojekt

Wykonalność

Podstawy

Wdrożenie

Postprojekt Budowa

Przegląd

Wdrożenie

Źródło: opracowanie własne na podst. Agile Business Consortium, Agile PM. Agile Project Management Handbook v2. Wydanie pol-skie, Agile Business Consortium, Ashford 2019, s. 10.

Faza „wykonalność” (ang. feasibility) określona została w celu zweryfikowania zasad-ności i szans zbudowania pożądanego rozwiązania (wykonalność techniczna oraz uzasad-nienie biznesowe). W tej fazie opracowuje się także zarys podejścia do realizacji projektu, jak również jego organizację, zarządzanie oraz wstępne szacunki projektu.

Faza „podstawy” (ang. foundations) służy dogłębnemu zrozumieniu czekającej zespół pracy. Zrozumienie to powinno uwzględniać zarówno wymiar techniczny budowanego rozwiązania (definicja architektury rozwiązania, definicja podejścia do rozwoju), jak rów-nież zarządczy (plan dostarczania oraz definicja podejścia do zarządzania) oraz biznesowy (szczegółowe uzasadnienie biznesowe, lista wymagań z priorytetami). Celem tej fazy jest zbudowanie wysokopoziomowych, ale solidnych podstaw jego realizacji.

Faza „rozwój ewolucyjny” (ang. evolutionary development) polega na bieżącej pracy zespołu nad budowaniem przyrostów rozwiązania w modelu ewolucyjnym i przyrosto-wym. Metodyka rekomenduje w tym zakresie liczne techniki pomocne w pracy zespo-łu, m.in.: MoSCoW, timeboxy, warsztaty facylitowane, modelowanie i rozwój iteracyjny.

Faza „wdrożenie” (ang. deployment) zakłada, że budowane rozwiązanie powinno zo-stać przekazane do tzw. biznesu, wprowadzone do użytku i uruchomione operacyjnie.

Metodyka zaleca stosowanie kolejnych wydań rozwiązania wdrażanych, aż do osiągnie-cia pożądanego kształtu końcowego.

Ostatnią fazą projektu zgodnie z DSDM jest „po projekcie” (ang. post-project). Roz-poczyna się po ostatnim wydaniu rozwiązania. Jej celem jest ocena przedsięwzięcia

z perspektywy dostarczonej wartości biznesowej, a w szczególności założeń opisanych w uzasadnieniu biznesowym. Według autorów metody zwykle ma to miejsce między 3. a 6. miesiącem od zakończenia projektu181.

Istotą proponowanego przez DSDM modelu jest układ powyższych faz oparty na ite-racyjności. O ile uruchomienie projektu i przejście od „przed-projektem”, przez „wykonal-ność” do „podstaw” i „rozwoju ewolucyjnego”, a w konsekwencji do „wdrożenia” będzie przebiegać naturalnie i w sposób sekwencyjny, o tyle metoda wskazuje także możliwości powrotu od „wdrożenia” do „podstaw” lub „rozwoju ewolucyjnego”. W efekcie metody-ka oferuje kierownikowi projektu i organizacji elementy składowe cyklu („klocki”), na-tomiast pozostawia dużą swobodę w ich sekwencjonowaniu. Fazy te można w rezultacie ułożyć liniowo, w zasadzie wracając do modelu kaskadowego, jak też skrócić i zdynamizo-wać, tworząc wysoce iteracyjne i zwinne środowiska zarządcze. Taki duży uniwersalizm metodyki stanowi jej istotną zaletę.

Oprócz ciekawego modelu cyklu życia metodyka prezentuje również rozbudowaną strukturę ról zaangażowanych w realizowany projekt (tabela 9). Układ proponowanych ról oddaje złożoność środowiska zarządzania projektem i dalece wykracza poza np. za-lecenia w tym względzie metodyki SCRUM. AgilePM proponuje bowiem, aż 13 (!) ról w zespole DSDM. Role te uwzględniają różne poziomy zarządzania projektem oraz re-prezentowane interesy.

Tabela 9. Kategorie ról w metodyce Agile PM

Reprezentowane interesy Poziom roli

Biznesowe Techniczne Zarządzania Procesu

Poziom projektu sponsor biznesowy, wizjoner biznesowy, analityk biznesowy

koordynator

techniczny kierownik projektu

Poziom zespołu

rozwoju rozwiązania ambasador biznesowy, analityk projektu

twórca rozwiązania, tester rozwiązania, analityk projektu

lider zespołu

Poziom wspierający doradca biznesowy doradca techniczny facylitator warsztatów, coach DSDM

Źródło: opracowanie własne na podst. Agile Business Consortium, Agile PM…, s. 10.

Kompleksowość metodyki odnajdziemy również w zaleceniach dotyczących dokumen-towania projektu. Dostarcza ona w tym zakresie 14 elementów, tzw. produktów DSDM.

Należy jednocześnie podkreślić, iż zdaniem autorów „nie wszystkie produkty

wymaga-181 DSDM Consortium, Agile Project Management Handbook. Version 1.2, DSDM Consortium 2013.

ne są w każdym projekcie, a formalizm łączący się z każdym produktem będzie zmieniał się w zależności od projektu i organizacji”182. Wśród produktów DSDM znajdziemy183:

1) warunki odniesienia (ang. terms of reference), 2) uzasadnienie biznesowe (ang. business case),

3) listę wymagań z priorytetami (ang. prioritised requirements list),

4) definicję architektury rozwiązania (ang. solution architecture definitione), 5) definicję podejścia do rozwoju (ang. development approach definitione), 6) plan dostarczania (ang. deliverty plan),

7) definicję podejścia do zarządzania (ang. management approach definitione), 8) ocenę wykonalności (ang. feasibility assessment),

9) podsumowanie podstaw (ang. foudation summary), 10) ewoluujące rozwiązanie (ang. evolving solution), 11) plan timeboxa (ang. timebox plan),

12) zapis przeglądu timeboxa (ang. timebox review record), 13) raport z przeglądu projektu (ang. project review report), 14) ocenę korzyści (ang. benefits assessment).

W obrębie metodyki każdy z powyższych produktów przypisany został do określonej fazy projektu; oprócz szczegółowego opisu treści i przeznaczenia wskazano również ma-cierze RACI przypisujące poszczególnym produktom związane z ich stosowaniem role.

Kompleksowość metody odnajdziemy również w obszernym zestawie tzw. praktyk DSDM pomagających kierownikom projektów zwinnie realizować prowadzone przez siebie przed-sięwzięcia. Będą to: priorytetyzacja MoSCoW, stosowanie timeboxów, warsztaty facylito-wane, modelowanie oraz rozwój iteracyjny184. W podręczniku dużo miejsca poświęcono także na zapewnienie efektywnej współpracy w zespole projektowym, definiowaniu wy-magań i historii użytkownika oraz szacowaniu w projekcie. Dodatkowo poruszono w nim zagadnienia związane z planowaniem projektów w cyklu życia, zapewnienia jakości, za-rządzania ryzykiem, a także dopasowania metodyki do potrzeb organizacji.

2.9.2.

Podsumowanie

Metodyka DSDM/Agile PM jest rozwiązaniem, które relatywnie rzadko spotyka-ne jest w dzisiejszych przedsiębiorstwach185. Nie uzyskało ono takiej popularności jak np. SCRUM czy XP. Warto jednakże pamiętać o niewątpliwych mocnych stronach tego

182 Agile Business Consortium, Agile PM…, s. 38.

183 Ibid., s. 39–40.

184 Ibid., s. 49–64.

185 D. West et al., Agile development: Mainstream adoption has changed agility, “Forrester Research” 2020, vol. 2, no. 1;

A. Komus et al., Study Status Quo (Scaled) Agile 2019/20, https://www.hs-koblenz.de/en/bpm-labor/status-qu-o-scaled-agile-2020 (dostęp: 14.06.2021).

rozwiązania. Przede wszystkim jest to metodyka o niewątpliwie kompleksowym charakte-rze, w której w centrum uwagi pozostaje projekt oraz odpowiedzialny za niego kierownik.

Jest to znaczna przewaga, gdyż większość innych rozwiązań kładzie nacisk albo na prace stricte programistyczne (np. XP, TDD, FDD, Lean), albo na poziom zespołu projektowego i kierowania jego pracą (np. SCRUM, LeanStartup, Kanban). Poza zakresem tych metodyk pozostają istotne przecież w praktyce działania przedsiębiorstwa zagadnienia dotyczące zainicjowania projektu, oceny korzyści, uzasadnienia jego realizacji czy planowania prze-biegu – nie tylko z perspektywy kolejnych iteracji wytwórczych, ale i całego cyklu życia projektu. Metodyka AgilePM pozostaje w nurcie zwinności, spełniając wszystkie kryte-ria dla tej rodziny rozwiązań. Jednocześnie jednak stanowi znaczące ich uzupełnienie o kontekst zarządczy. Jest również metodyką opracowaną z punktu widzenia kierowni-ka projektu i jako narzędzie w jego rękierowni-kach. Wieloletnie doświadczenia praktycznego sto-sowania metod zwinnych pokazały bowiem, że mimo początkowych prób usunięcia tej roli z zespołów projektowych czy rozbicia zadań między inne osoby, to nadal kierownik projektu pozostaje istotnym stanowiskiem, mającym określone zadania w środowisku przedsiębiorstwa i projektu zwinnego. Zastanawiający jest przy tym fakt, iż współcześnie potrzeby o charakterze biznesowym i organizacyjnym częściej zaspokajane są poprzez wdrażanie metod skalowania, takich jak np. SAFe, a nie przez DSDM/AgilePM, który nie zdobyła takiej popularności. Nie zmienia to faktu, iż metodyka ta pozostaje nadal aktual-nym i cenaktual-nym zbiorem zaleceń co do realizacji projektów zwinnych.

2.10. Agile PMI – Software Extension to the PMBOK