Czym jest DSDM (metoda dynamicznego rozwoju systemów)?

Discover how to deliver better software and systems in rapidly scaling environments. Join our Community

Czym jest DSDM? Metoda dynamicznego rozwoju systemów (DSDM) to zwinny model realizacji projektów, który powstał w 1994 roku i w tamtym czasie był wykorzystywany do tworzenia oprogramowania. Miała stanowić udoskonalenie szybkiego tworzenia aplikacji (RAD), które kładło nacisk na szybkie prototypowanie i iteracje oparte na opiniach użytkowników. Podobnie jak wiele zwinnych metod realizacji projektów, model zwinnych […]

Czym jest DSDM?

Metoda dynamicznego rozwoju systemów (DSDM) to zwinny model realizacji projektów, który powstał w 1994 roku i w tamtym czasie był wykorzystywany do tworzenia oprogramowania. Miała stanowić udoskonalenie szybkiego tworzenia aplikacji (RAD), które kładło nacisk na szybkie prototypowanie i iteracje oparte na opiniach użytkowników. Podobnie jak wiele zwinnych metod realizacji projektów, model zwinnych ram realizacji projektów DSDM z czasem przekształcił się z rozwiązania przeznaczonego wyłącznie do tworzenia oprogramowania w bardziej ogólne narzędzie do zarządzania projektami.

Elementy metody dynamicznego rozwoju systemów obejmują:

  • Od innych metod wyróżnia ją oparcie na solidnych podstawach i zarządzaniu
  • Przyrostowe, iteracyjne podejście do postępu 
  • Opinie użytkowników lub klientów mają kluczowe znaczenie dla ciągłego doskonalenia 
  • Opiera się na ścisłych ograniczeniach dotyczących kosztów, jakości i czasu 
  • Ustala zakres według kategorii: Musi być, Powinno być, Może być lub Nie będzie

Oprócz samej metody DSDM dała również początek konsorcjum DSDM w 1994 roku. Inżynierowie oprogramowania i inni eksperci połączyli siły, aby opracować i udoskonalić model jako prawidłową alternatywę dla powszechniejszych metodyk szybkiego tworzenia aplikacji. W tamtym czasie w grupie znajdowali się przedstawiciele między innymi British Airways, American Express, Oracle, Logica, Data Sciences i Allied Domecq. Grupa zmieniła nazwę i obecnie działa jako Agile Business Consortium.

Podręcznik DSDM został udostępniony bezpłatnie do przeglądania i używania online w 2014 roku.

Get Free Access
Get regular tech leadership wisdom for delivering better software and systems.
Get Free Access

Have an account? Log In

DSDM a RAD i Agile

Metodyka RAD cieszyła się ogromną popularnością na początku lat 90. jako metodyka rozwoju systemów wykorzystywana do tworzenia oprogramowania i realizacji innych projektów IT. W tym czasie nastąpiło przejście od tradycyjnego interfejsu użytkownika typu „zielony ekran” do graficznych interfejsów użytkownika, które stały się obecnie synonimem całej branży technologicznej. Zmiana ta oznaczała, że cykl tworzenia również mógł ulec zmianie, ponieważ nowy rodzaj wizualnego interfejsu użytkownika wykorzystywano do komunikacji, szybkiego prototypowania i iteracji. 

Metodyka RAD była dość chaotycznym zwinnym systemem tworzenia oprogramowania. Nie miała jednego uzgodnionego podejścia ani jednej definicji. Agile DSDM stanowiła bardziej uporządkowane podejście do tego typu modelu tworzenia oprogramowania. Metoda dynamicznego rozwoju systemów koncentrowała się przede wszystkim na budżetach czasowych i kosztowych poprzez ścisłe ustalanie priorytetów zakresu. Kładzie również nacisk na komunikację i wynikające z niej działania między wszystkimi interesariuszami. 

DSDM nie tylko ściśle podchodzi do terminów i budżetu, lecz także zwykle opiera się na określonej kolejności zdarzeń: fazie przedprojektowej, fazie cyklu życia projektu i fazie poprojektowej. Metodyki tworzenia oprogramowania RAD opierają się bardziej na swobodnej pracy, pozwalając, aby kreatywność i niezależność dominowały nawet kosztem wyczerpania zasobów. 

Scrum a DSDM

Scrum i DSDM mają wiele podobieństw, ale różnią się także w kilku istotnych kwestiach. Niektóre różnice dotyczą jedynie terminologii — na przykład DSDM dzieli pracę na „działania inżynieryjne” (czyli fazę tworzenia) oraz „wyłaniające się rozwiązanie” (czyli wynik). W Scrumie wynik jest natomiast znany jako „przyrost potencjalnie możliwy do wydania”. 

Obie metody obejmują listy zadań podrzędnych, które są realizowane zgodnie z rygorystycznymi terminami. Obie metodyki zmierzają również do ukończenia projektu, co w Scrumie jest sygnalizowane, gdy projekt osiąga „Definicję ukończenia”. Nie istnieje jednak określony moment w projekcie, w którym ta „Definicja ukończenia” jest uzgadniana. To kluczowa różnica między Scrumem a DSDM. 

W DSDM istnieje określona faza, w której uzgadnia się definicję pracy (oraz ukończonej pracy): faza podstaw projektu. Następuje ona stosunkowo wcześnie, co czasami oznacza, że niepotwierdzone jeszcze założenia wpływają na proces planowania. Aby temu zaradzić, definicja „ukończonej” pracy jest okresowo weryfikowana w całym cyklu życia projektu. Kolejną kwestią jest to, że liderzy zespołów powinni unikać projektowania całości z wyprzedzeniem (BDUF), które jest bardziej charakterystyczne dla metodyk kaskadowych niż dla Agile. 

Zasady DSDM

Zasady zwinnego DSDM stanowią siłę przewodnią każdego projektu. Łącznie jest ich 8.

  1. Koncentruj się na potrzebach biznesowych
  2. Dostarczaj na czas
  3. Współpracuj
  4. Nigdy nie idź na kompromis w kwestii jakości
  5. Buduj przyrostowo na solidnych podstawach
  6. Rozwijaj iteracyjnie
  7. Komunikuj się stale i jasno
  8. Wykazuj kontrolę

Techniki i praktyki DSDM

Tym, co wyróżnia DSDM na tle innych metod tworzenia systemów, są następujące techniki i praktyki. 

Ograniczanie czasu: DSDM przestrzega rygorystycznych terminów. W tym celu cały projekt należy podzielić na mniejsze elementy, z których każdy ma określony budżet i harmonogram. Aby sprawnie zarządzać tym procesem, wymagania są ustalane według priorytetów. Jeśli kończy się czas lub pieniądze, wymagania o najniższym priorytecie są usuwane. Gotowy projekt składa się więc wyłącznie z najważniejszych elementów wymagań. 

MoSCoW: Są to grupy priorytetów używane do uszeregowania elementów od najważniejszych do najmniej ważnych. Grupy priorytetów to: Musi mieć, Powinien mieć, Może mieć oraz Nie będzie mieć. Zarządzanie konfiguracją pomaga radzić sobie ze wszystkimi tymi konkurującymi elementami do dostarczenia, które często są opracowywane jednocześnie.

Modelowanie i rozwój iteracyjny: Modelowanie pomaga wizualizować różne aspekty projektu w miarę postępów prac. Ułatwia przedstawienie każdego opracowywanego elementu oraz umożliwia iteracyjny rozwój dzięki regularnemu zbieraniu opinii i wdrażaniu usprawnień. 

Prototypowanie: Podobnie jak w przypadku wielu metodyk zwinnych, prototypowanie jest niezbędne do przetestowania projektu na jego wczesnym, koncepcyjnym etapie. Jest to sposób na rozplanowanie podstawowych funkcji, wykrycie rażących słabości oraz umożliwienie użytkownikom przetestowania oprogramowania. 

Warsztaty: Użytkownicy i interesariusze spotykają się, aby omawiać wymagania, problemy, wyniki i testy. DSDM od samego początku opiera się na wysokim poziomie interakcji z użytkownikami. Testowanie ma ogromne znaczenie dla DSDM, ponieważ zapewnia wysoką jakość rezultatów. 

More Articles

Role w DSDM

Każdy zwinny proces tworzenia systemów obejmuje listę ról, które należy obsadzić. W DSDM jest tak samo. Zgodnie z podręcznikiem DSDM są to najważniejsze role w każdym środowisku DSDM. 

1. Sponsor wykonawczy („Mistrz projektu”) - Organizacja użytkownika i/lub klient wyznacza osobę do pełnienia tej roli. Jest ona również uprawniona do przydzielania, w razie potrzeby, funduszy i zasobów. Ma „ostateczne słowo” w kwestiach decyzyjnych.

2. Wizjoner - Dysponując konkretnymi celami i znajomością działalności użytkownika, wizjoner rozpoczyna projekt, koncentrując się od samego początku na wymaganiach o najwyższym priorytecie i kierując na tej podstawie zespołem. 

3. Użytkownik-ambasador - Idealny „użytkownik testowy”, który wnosi do projektu punkt widzenia społeczności użytkowników. Przez cały proces jest kluczowym źródłem opinii. 

4. Użytkownik-doradca - Kolejny rodzaj użytkownika, który powinien wnosić do danego projektu istotne spostrzeżenia. Może mieć wyjątkową wiedzę lub inne kompetencje, dzięki którym jest idealnym kandydatem. 

5. Kierownik projektu - Kierownik projektu to osoba zarządzająca całym projektem. 

6. Koordynator techniczny - Projektuje architekturę systemu i odpowiada za kontrolę jakości wszystkich elementów technicznych. 

7. Lider zespołu - Lider zespołu odpowiada za koordynację i ułatwianie współpracy. 

8. Deweloper rozwiązania - Analizuje wymagania systemowe, modeluje system, tworzy kod do dostarczenia oraz opracowuje prototypy.

9. Tester rozwiązania - Testuje produkt i w razie wystąpienia błędów przekazuje uwagi oraz dokumentację. Po wdrożeniu poprawek ponownie przeprowadza testy. 

10. Sekretarz - Dokumentuje wymagania, uzgodnienia, decyzje i wszelkie inne przydatne informacje dotyczące postępów projektu. 

11. Facylitator - Odpowiada za motywowanie uczestników i przygotowanie warsztatów, aby postępy były spójne i systematyczne. Musi być świetnym komunikatorem oraz dbać o to, by wszyscy podążali zgodnie z planem. 

12. Role specjalistyczne - Są to role pełnione przez specjalistów w danej dziedzinie lub branży, zapewniających dodatkowe wsparcie zależnie od potrzeb projektu. Mogą różnić się w zależności od projektu i zespołu. Do takich ról mogą należeć architekt biznesowy, kierownik ds. jakości, integrator systemu i inne. 

Wskazówki dotyczące zarządzania projektami DSDM

Te wskazówki mogą pomóc maksymalnie wykorzystać projekt DSDM, choć wszystkie systemy zwinne również mogą skorzystać z części tej wiedzy. 

1. Kadra kierownicza wyższego szczebla i wszyscy pracownicy muszą rozumieć wybraną dla projektu metodykę i ją popierać. 

2. Zespół kierujący projektem musi zobowiązać się do przeprowadzania testów z użytkownikami, zbierania opinii i angażowania użytkowników w całym procesie — od koncepcji po uruchomienie.

3. Musi istnieć stabilny i umocowany zespół projektowy. Członkowie zespołu muszą mieć uprawnienia do podejmowania decyzji, aby proces nie ugrzązł w niepotrzebnie zawiłych procedurach składania i zatwierdzania wniosków. Zespół musi również dysponować wszystkim, czego potrzebuje do działania, na przykład odpowiednią technologią, zdrowym środowiskiem programistycznym, narzędziami do zarządzania projektami i nie tylko. 

4. Musi istnieć wspierająca i proaktywna relacja między klientem a dostawcą, niezależnie od tego, czy projekty są opracowywane wewnętrznie, czy zlecane na zewnątrz. 

5. Zespół musi wykazywać się odwagą, jeśli chodzi o uczciwe ustalanie priorytetów potrzeb projektu i, w razie potrzeby, rezygnowanie z elementów o niskim priorytecie. Dzięki temu prace pozostają realizowane terminowo i w ramach budżetu. 

Jason Boog
Over his 15-year career, Jason Boog has worked as a QA tester, QA analyst, and Senior QA Analyst on video games, commercial sites, and interactive web applications. He spent more than a decade building out the QA team and process as Director of Quality & Client Support at a full-service digital agency.
Follow the author:

You may also like