Dynamic Systems Development Method
Dynamic System Development Method (DSDM) – metodyka zarządzania projektami, która powstała w 1995 r. i jest uważana za najstarszą zwinną metodykę projektową.
We wczesnych latach dziewięćdziesiątych powstało określenie „Rapid Application Development” (RAD). Oznacza ono „szybkie tworzenie aplikacji”. Ta ideologia i technika polega zarazem na zapewnieniu programistom dużych ilości gotowych komponentów i dużych możliwości prototypowania. Dzięki temu otrzymuje się możliwość uzyskania efektów w początkowych fazach etapu programowania. Na bazie RAD powstała metodyka Dynamic System Development Method.
Podstawowe założenia DSDM opierają się na tym, że zadania, które należy wykonać w celu wykonania danego systemu, zawsze podlegają zmianom.
Pierwsza wersja DSDM była udostępniona w 1995 roku. Krótko po jej wydaniu powstała odświeżona wersja V2, która wprowadzała drobne poprawki. Wersja V3 została opublikowana w 1997 roku, V4 w 2002, a kolejne rozszerzenia do wersji V4, V4.1 oraz V4.2 były dostępne online dla członków konsorcjum DSDM. Jedną z najbardziej rozpoznawalnych wersji była V5 opublikowana w czerwcu 2008 roku, zwana szerzej jako DSDM Atern. Obecna, najnowsza wersja metodyki DSDM została opublikowana w 2014 roku. Jest to wersja 6 metodyki, która nazywana jest AgilePF – Agile Project Framework.
Role projektowe
DSDM wyróżnia 13 ról w procesie tworzenia oprogramowania. Zgrupowane w trzech grupach: poziomu Zarządu Projektu, poziomu Zespołu Rozwoju Rozwiązania oraz poziomu wsparcia Zespołu Rozwoju Rozwiązania. Role te, szczególnie dla mniejszych projektów, mogą być łączone przez jedną osobę np.: Kierownik projektu, może być jednocześnie Kierownikiem Zespołu:
Poziom Zarządu Projektu:
- Business Sponsor (Sponsor Biznesowy) – rola, mająca możliwość i uprawnienia do zatwierdzania zmian w projekcie oraz do pozyskiwania wymaganych zasobów i materiałów; ma decydujący głos w dyskusjach; sponsor projektu.
- Business Visionary (Wizjoner Biznesowy) – osoba odpowiedzialna za to, aby w miarę wcześnie sprecyzować wymagania, posiada najlepsze rozeznanie w dziedzinie zastosowań produkowanego systemu, nadaje projektowi kierunek rozwoju, często pomysłodawca systemu.
- Technical Coordinator (Koordynator Techniczny) – osoba odpowiedzialna za architekturę systemu, kontrolę realizacji oraz techniczną jakość projektu, odpowiedzialny za architekturę i jakość produktu, zarządza zmianami w projekcie.
- Project Manager (Kierownik Projektu) – odpowiedzialny za synchronizację pracy zespołów.
- Business Analyst (Analityk Biznesowy) – osoba ułatwiająca kontakt pomiędzy ludźmi finansów a osobami technicznymi oraz pomiędzy zespołem zarządczym projektu a zespołem rozwoju rozwiązania. Pracuje na styku, dwóch poziomów: Poziomu Zarządu Projektu i Poziomu Zespołu Rozwoju Rozwiązania, stanowi pomost pomiędzy tymi dwoma poziomami.
Poziom Zespołu Rozwoju Rozwiązania:
- Business Ambassador (Ambasador Biznesowy) – odpowiedzialny za przekazanie wiedzy od klienta, odpowiedzialny jest za całokształt projektu, zapewnia sprzężenie zwrotne programistom podczas implementacji.
- Solution Developer (Twórca Rozwiązania, Programista) – implementuje system, interpretuje wymagania systemowe oraz model systemu, dostarcza kod programu i buduje prototypy.
- Solution Tester (Tester Rozwiązania) – testuje poprawność techniczną produktu, pisze testy, dodaje odpowiednie komentarze i tworzy dokumentację. Jest to tester techniczny (np. inne programista), które nie przeprowadza testów UAT.
- Team Leader (Lider Zespołu) – dowodzi zespołem ludzi i zapewnia im stale możliwość efektywnej pracy. Charakteryzuje go tzw. podejście przywództwa służebnego.
- Technical Advisor (Doradca Techniczny) – rolę tę pełni osoba techniczna wyznaczona do reprezentowania danego punktu technicznego budowanego rozwiązania, są przedstawicielami architektów, zewnętrznych konsultantów, ekspertów technicznych etc.
- Business Advisor (Doradca Biznesowy) – rolę tę pełni użytkownik (użytkownicy) wyznaczeni do reprezentowania danego punktu widzenia na projekt, są przedstawicielami użytkowników, ma wgląd w realizowany projekt, a w miarę potrzeb potrafi dostarczyć programistom odpowiedniej wiedzy na dany temat – za który jest odpowiedzialny.
Poziom Wsparcia Zespołu Rozwoju Rozwiązania:
- Workshop Facilitator (Facylitator Warsztatów, Ułatwiacz) – kieruje procesem warsztatu, stanowi motor do przygotowań do warsztatu, a także jest odpowiedzialny za sprawny oraz efektywny przebieg warsztatu, jest niezależny od wyniku warsztatu.
- DSDM Coach (Korepetytor, Trener DSDM) – wspiera zespoły projektowe w procesie DSDM (odpowiednik Agile Coach’a w innych metodykach)
Techniki obecne w DSDM
- Timeboxing (dwa warianty) – umiejętne rozdzielenie realizacji produktu na nieprzekraczalne czasowo zakresu czasu. Jest to bliski odpowiednik Sprintu w Scrumie, jednak istnieją pewne różnice między Scrum a DSDM.
- MoSCoW
- M – MUST have this – musi mieć tę funkcjonalność
- S – SHOULD have this if at all possible – jeśli jest to możliwe to powinno mieć tę funkcjonalność,
- C – COULD have this if it does not affect anything else – ta funkcjonalność jest potrzebna, pod warunkiem że nie wpłynie negatywnie na inne i efektywność systemu
- W – WON’T have this time but WOULD like in the future – nie tym razem, ale w przyszłości tę funkcjonalność można by dołożyć
- Modelowanie
- Prototypowanie
- Warsztaty Facylitowane
- Codzienne Zbiórki
- Rozwój Iteracyjny
Skład procesu DSDM
- Inspekcja zastosowalności – jest wykonywana zawsze na początku projektu jednokrotnie w celu potwierdzenia zasadności stosowania metody DSDM, w trakcie wykonywania inspekcji zastosowalności wstępnie określa się ryzykowne punkty w projekcie, jeśli to niezbędne buduje się prototypy, ilość prac, jaką przeznacza się na tę fazę, daje się zrealizować w kilka tygodni.
- Badania biznesowe służą rozpoznaniu kluczowych dla projektu lub jego części zagadnień i osób po stronie odbiorcy, w późniejszym okresie osoby te są włączane w proces opracowywania systemu; efektem działań w tej fazie są wysokopoziomowy opis systemu (Business Area Definition), specyfikacja zakresu systemu, zarys architektury systemu (System Architecture Definition) oraz Plan prototypowania (Outline Prototyping Plan).
- Iteracyjne opracowanie modelu funkcjonalnego (Functional model iteration) – jest to etap budowy modelu funkcjonalnego, składa się naprzemiennie z procesów analizy i budowy prototypów, wyniki prototypowania służą do poprawienia i uszczegółowienia modeli analitycznych; w miarę możliwości prototypy są udoskonalane w taki sposób, by można było je włączyć do produktu końcowego, efektem końcowym tej fazy jest model funkcjonalny oraz kod prototypów, prototypowanie jest często traktowane jako forma testowania modelu funkcjonalnego.
W każdej pętli iteracji tworzone są następujące dokumenty:
- iteracyjne projektowanie i implementacja (Design and build iteration)
Model funkcjonalny opracowany w poprzednim etapie jest przekształcany w kod źródłowy właściwego produktu, prototypy powstałe w trakcie prac nad modelem funkcjonalnym mogą być w tej fazie adaptowane do kodu aplikacji, wynikiem tej fazy jest przetestowany produkt zawierający uzgodniony wcześniej zestaw funkcjonalności,
Praktyki wprowadzane przez DSDM
- Użytkownik jest aktywny w całym procesie tworzenia oprogramowania,
- Zespoły biorące udział w DSDM są uprawnione do podejmowania decyzji (w ograniczonym zakresie),
- Duży nacisk na częste dostarczanie nowych wersji oprogramowania,
- Każda nowa wersja jest oceniana pod kątem przydatności i odpowiedniości w zastosowaniach biznesowych,
- Iteracyjne tworzenie oprogramowania,
- Inkrementalne dostarczanie oprogramowania,
- Prowadzenie kontroli wersji, aby zmiany mogły być wycofywane,
- Testowanie jest integralną częścią każdego etapu w projekcie,
Podstawową zaletą DSDM jest to, że produkt jest oceniany przez twórców i przyszłych użytkowników na każdym etapie projektowania i budowy. Uwagi powstałe w danej iteracji są oceniane i opracowywane w kolejnych iteracjach.