Kiedy warto skorzystać z metody Agile – DSDM?

14 grudnia, 2020

Agile to cały wachlarz metodyk zwinnych służących do wypuszczenia gotowego kawałka oprogramowania lub po prostu gotowego produktu/usługi. Chociaż oficjalnie mówi się o tym, że Agile „powstał” w 2001 roku w formie Manifestu, spisany przez kilkanaście osób ze świata IT, to praktyki zwinne stosowano już wcześniej. Jedną z tych praktyk było RAD – Rapid Application Development. RAD nie zyskał uznania, więc opracowano metodę DSDM – Dynamic Software Development Method. Kiedy skorzystać z metody Agile DSDM? odpowiedź znajdziecie w tym artykule!

Czym jest metoda Agile DSDM?

Agile DSDM jest to metoda wytwarzania produktów lub usług w duchu filozofii / sposobu myślenia Agile, która oferuje sprawdzone rozwiązania, jeśli ogranicza nas sztywny termin oraz określony budżet, przy jednoczesnym zachowaniu jakości wytwarzania programowania. Dokładnie określa role i związane z nimi obowiązki – każda rola jest odpowiedzialna, rozliczana lub jest kontrybutorem (osobą mającą głos w określonej sprawie) elementów (produktów zarządczych) wytwarzanych podczas realizacji projektu. 

Te elementy dzielą się na produkty ewolucyjne, które – jak nazwa wskazuje – ewoluują w czasie, oraz produkty-kamienie milowe, które stanowią podsumowanie danego etapu i pozwalają na kolejny krok w cyklu życia projektu. 

Cykl życia projektu w Agile DSDM

Cykl życia projektu w DSDM dzieli się na 6 faz. Nie będziemy wchodzić w szczegóły ich omawiania, ale co jest ważne – każda faza kończy się ustaleniem konkretnych założeń i podsumowań, które decydują o tym czy projekt może przejść do kolejnej fazy realizacji mając na uwadze pytanie: czy ten projekt przyniesie zwrot z inwestycji?

Kiedy warto skorzystać z metody Agile

Dużym plusem DSDM jest nieustanna weryfikacja celów biznesowych, nad którymi czuwa tzw. Wizjoner Biznesowy. To przyczynia się do zwiększania konkurencyjności produktu lub usługi. Stale weryfikowane założenia ujęte są w 2-4 tygodniach ramach czasowych – Timeboxów. Założenia zatem mogą ulec zmianie i jest to całkowicie normalnie  – ba! Zmiana jest mile widziana. W ten sposób mamy pewność, że wytwarzany produkt lub usługa jest nie tylko konkurencyjna, ale również mamy większą kontrolę nad całym procesem.

Zakończeniem Timeboxa jest retrospektywa (podsumowanie) podczas której dokonuje się rewizji pracy – jest to ważny moment w którym otrzymujemy informację zwrotną od Biznesu i zadajemy pytania:

  • czy projekt spełnił nasze wymagania?
  • co udało się osiągnąć w tej iteracji / czego nie udało się osiągnąć i dlaczego?

Wytwarzaniu produktu towarzyszy całe spektrum przyjaznych Agile form testów np. testy Continuous Integration ) zapewniające kompatybilność z utworzonymi wcześniej kawałkami oprogramowania.

Co wyróżnia podejście DSDM

To, co stanowi trzon podejścia DSDM w porównaniu do waterfalla to tzw. zespół zmiennych, które są ustalane „na sztywno”. W podejściu tradycyjnym są to cechy, natomiast czas, budżet, a zatem też koszty w przypadku częstych zmian, są często naciągane i wymagają  “gimnastyki” ze strony software house’u,aby mieć nad kontrolę nad projektem. 

Mówiąc wprost – w takiej sytuacji wyprodukowanie produktu lub usługi odpowiadającej w 100% założeniom klienta jest karkołomnym wyczynem. Biorąc pod uwagę długoterminowe projekty, nie jest czymś niezwykłym, że założenia się zmieniają. Motywacje mogą być różne: zmienił się cel projektu, po przeprowadzeniu badań okazało się, że należy się skupić na innym aspekcie oprogramowania lub zwyczajnie zmieniliśmy zdanie na temat wyglądu produktu. 

W tym wypadku podejście DSDM oferuje skupienie się na jakości, czasie i budżecie – cechy produktu mogą się zmienić, tak jak zmieniają się priorytety klientów – i jest to w zupełności ok!

Mówiąc o metodykach Agile, nie można nie wspomnieć o największej różnicy – iteracyjnym (powtarzający się, zapętlony, charakteryzujący się większą liczbą krótszych etapów) i inkrementalnym (dodatkowy, dodający) podejściu do wytwarzania oprogramowania. W DSDM również stosuje się te praktyki. 

Jakość zapewnia więc nadawanie priorytetów jak również krótkie ramy czasowe (Timeboxy) dla rozwoju działającej części oprogramowania. To oznacza, jak wspomniałam wcześniej, że Biznes może udzielać nam nieustającego feedbacku nakierowującego nas na właściwy tor przy realizacji projektów. Takie wytworzenie oprogramowania daje sporo korzyści: nawet jeśli zespół rozwoju rozwiązania nie poradził sobie ze spełnieniem celów danego Timeboxa, to nie ucierpi na tym budżet w takim stopniu, jak w przypadku projektu, gdzie feedback od klienta jest zbierany po kilku miesiąca, gdy będzie już za późno na zmiany, ponieważ będą one zbyt kosztowne. Timeboxy zapewniają również przez to komfort pracy dla zespołu.

Tworzenie dokumentacji

Istnieje pewien mit dotyczący wytwarzania oprogramowania w duchu Agile dotyczący tworzenia dokumentacji. Klasycznie, w podejściu tradycyjnym, dokumentacje, specyfikacje techniczne, architektury informacji czy inne dokumenty są tworzone przed realizacją projektu. Szczegółowo omawia się zakres prac, tworzy rozwiązania. Takie podejście jest słuszne przy projektach, które realizowaliśmy już kilkukrotnie i chcemy uporządkować nasz system pracy czy spisać procesy, żeby ułatwić i zautomatyzować pracę np. przy projektowaniu strony dla tego samego klienta, które spełnia podobne założenia lub projektowaniu prostych Landing Page’ów czy mailingach. DSDM w porównaniu do niektórych metodyk Agile, zakłada tworzenie dokumentacji na takim poziomie, na jakim jest to wystarczające dla nas – co nie oznacza, że mamy zrezygnować z dokumentacji zupełnie.

Kolejnym mitem jest przeświadczenie, że w Agile jak również w DSDM, nie ma planowania projektu, nie ma harmonogramu. W DSDM jest wręcz przeciwnie – planuje się ciągle i nieustanne zewzględu na zmieniające się założenia. Zmienia się jedynie sposób – w przypadku projektów tradycyjnych szczegółowy harmonogram opracowuje się i dostarcza na początku projektu. DSDM oferuje metodę „Enough Design Up Front” [EDUP] – szczegółowo planuje się najbliższe iteracje, do kolejnych nakreśla się jedynie szkic / plan. 

Przyświeca temu idea, że nie ma potrzeby planować prac z detalami na wiele miesiące lub lata do przodu – może się okazać, że poprzednie zadania rozwiązały lub wygenerowały nowe problemy, które trzeba ująć w harmonogramie lub może się okazać, że niektóre funkcjonalności nie są nam już potrzebne, ponieważ nie są już tak konkurencyjne.

 

Kiedy warto skorzystać z metody Agile DSDM

Badanie potrzeb i spisywanie założeń przed projektowaniem rozwiązań w przypadku projektów, które niosą ze sobą dużą niepewność i liczbę niewiadomych jest ryzykownym podejściem. DSDM bada potrzeby klientów nieustannie – zapewniają to odpowiednie wyznaczone role Biznesu: Ambasador Biznesowy, Wizjoner Biznesowy oraz Analityk Biznesowy i Koordynator Techniczny oraz zbieranie informacji zwrotnej po każdym ukończonym Timeboxie.

Twórcy Airbnb nie planowali wdrożenia aplikacji i działań globalnych od samego początku bez sprawdzenia czy rzeczywiście ich pomysł odpowie na potrzeby ludzi. Ich inicjatywa wyłoniła się z potrzeby i luki na rynku – Brian i Joe, po przeprowadzce do Nowego Jorku nie mogli znaleźć mieszkania, zauważyli, że w tym czasie wszystkie hotele zostały zarezerwowane. Gdy udało im się wreszcie znaleźć miejsce, postanowili zaoferować innym podróżującym „kawałek” podłogi. Pomysł został przetestowany i sprawdził się – postanowili zatem zacząć oferować swoje usługi na szerszą skalę.

Największą zaletą DSDM jest ciągłe dbanie o konkurencyjność produktu – zatem DSDM sprawdzi się przy projektach o wielu zmiennych i niewiadomych, projektach innowacyjnych, dużych i długoterminowych. Często uważamy, że mamy jasno określoną wizję projektu, nadajemy sobie cel i jedynie do czego musimy dążyć to terminowa realizacja w budżecie. W przypadku projektów, w których istnieje duża konkurencja lub w przypadku usług na szeroką skalę, należy na bieżąco odpowiadać na potrzeby rynku. Projekt, który wydawał się innowacyjny jeszcze 3 lata temu, teraz może być już mocno zdezaktualizowany. Jednak nie musi chodzić o wyburzenie fundamentów projektów, a np. kilka dodatkowych funkcji w istniejącym już oprogramowaniu.

Przy realizacji dużych, długoterminowych projektów i gdy możemy skompletować zespół od 9 do 15 osób, z tym, że Zespół Rozwoju Rozwiązania może mieć max. 9 osób. Ważne jest, aby obsadzić odpowiednie role na poziomach Biznesu, Rozwoju Rozwiązania oraz role wspomagające/doradcze.

 

Jak należy się przygotować do DSDM

Nie zawsze jest jednak tak różowo i chociaż metodyki z parasola Agile, jak i samo DSDM wydają się idealnym lekarstwem na cały ból związany z realizacją projektów i wytwarzaniem oprogramowania, to te podejście nie sprawdzi zawsze i wszędzie. Do największych zagrożeń przy realizacji projektów w podejściu DSDM zalicza się nieprzygotowany do zwinnego sposobu myślenia zespół i osoby po stronie Biznesu. Agile wymaga większego zaangażowania i nieustannej kooperacji między agencją/twórcami usług/produktów, a klientami. 

Uczestnicy procesu muszą znać i spełniać swoje role oraz muszą zostać umocowani do podejmowania decyzji w zakresie swoich działań. Samozarządzający i samoorganizujący się zespół to podstawa. Co nie oznacza, że w DSDM nie ma miejsca na rolę Kierownika Projektu. To prawda, że zespół sam organizuje swoją pracę i proponuje rozwiązania, jednak rolą PM-a jest dopilnowanie, aby każdy tą rolę wypełnił w czasie i estymacji na którą się zobowiązał.

Różnice między SCRUMem, a DSDM

Na koniec chciałabym poruszyć kilka różnic między jedną z metodyk Agile – SCRUM, a DSDM. Często mówiąc o Agile mamy na myśli SCRUM-a. Jednak SCRUM jest to tylko jedna z metod, służąca głównie do realizacji produktów. Natomiast sam w sobie mówi więcej o samym procesie wytwarzania produktu niż o całym procesie realizacji projektu. SCRUM sprawdza się świetnie w projektach, gdzie wytwarza się oprogramowanie, aplikacje, strony o skomplikowanych funkcjonalnościach. W procesie biorą udział tylko 3 role:

  • Product Owner odpowiedzialny za wizję produktu oraz kierunek, odpowiada za historyjki użytkownika, czyli opracowanie funkcjonalności dla produktu jak również nadaje priorytety.
  • Scrum Master to osoba odpowiedzialna za pilnowanie procesu, dlatego również jest to osoba, która odpowiada za usuwanie przeszkód stojących na drodze programistom w realizacji zadania.
  • Oraz samoorganizujący się zespół złożony z osób „T”.

W DSDM role są znacznie poszerzone, każda rola posiada jasno wyznaczone obowiązki. Role podzielone są na trzy poziomy:

  • biznesu – czyli osoby odpowiedzialne za wizję produktu, ukierunkowanie strategiczne, dopilnowywanie aby produkt był opłacalny
  • rozwiązania – role odpowiedzialne za dostarczenie rozwiązania zgodnego z kierunkiem rozwoju
  • doradcy – osoby, które są odpowiedzialne za wspieranie ról rozwiązania w podejmowaniu decyzji, jak ich facilitatorzy oraz coachowie dsdm odpowiedzialni za dobrą pracę w zespole i rozumienie procesu.

Dużą różnicą jest również obecność kierownika projektu – w SCRUMIe to PO odpowiada za dostarczenie produktu, w DSDM – zespół rozwoju rozwiązania oraz kierownik projektu, który jest odpowiedzialny za harmonogram, budżet i pilnowanie aby każdy wykonał swoją pracę.

Sharing is caring!