Dynamic Systems Development Method
Dynamic Systems Development Method
Po dość długiej przerwie chciałbym podzielić się podejściem, którego używamy przy szybkim opracowaniu MVP lub podczas startu nowego projektu dla klientów, którzy chcą przyspieszyć swój biznes przy pomocy precyzyjnych, planowych i ciągłych innowacji przy użyciu automatyzacji programowej.
7 cze 2017
2691
Other articles
Testowanie aplikacji za pomocą JUnit5 i JMock. Część 2
Jak przygotować się do certyfikacji IIBA. Wyzwania i hacki
Testowanie aplikacji za pomocą JUnit5 i Mockito. Część 2
Testowanie aplikacji za pomocą JUnit5 i Mockito. Część 1
Testowanie aplikacji za pomocą JUnit5 i EasyMock. Część 2
Testowanie aplikacji za pomocą JUnit5 i EasyMock. Część 1
Test Driven Development z użyciem JUnit 5. Część 6
Test Driven Development z użyciem JUnit 5. Część 5
Test Driven Development z użyciem JUnit 5. Część 4
Test Driven Development z uzyciem JUnit 5. Czesc 3
Po dość długiej przerwie chciałbym podzielić się podejściem, którego używamy przy szybkim opracowaniu MVP lub podczas startu nowego projektu dla klientów, którzy chcą przyspieszyć swój biznes przy pomocy precyzyjnych, planowych i ciągłych innowacji przy użyciu automatyzacji programowej.
Myślę, że wielu delivery managerów zgodzi się, że sytuację podczas realizacji projektów w ramach ograniczonego czasu i budżetu, a także wymagań o real business value można porównać do łyżwiarstwa figurowego po bardzo cienkim lodzie.
W naszej firmie wypracowaliśmy następujące zasady, które bardzo pomagają w tego typu sytuacjach:
Za co lubimy DSDM Atern?
Zacznijmy od jednego z moich ulubionych schematów, by zobaczyć najważniejsze zasady Atern DSDM.

Dla zapewnienia real business value, należy:
Jak pokazuje nasza praktyka, dane podejście wyraźnie daje klientowi do zrozumienia, że wszystko idzie zgodnie z planem. I co najważniejsze, nie pojawiły się żadne pytania dotyczące uzgodnienia kolejnych etapów pracy, nie było żadnych poszukiwań dodatkowych funduszy na rozwiązanie problemów jakości. Idealny obraz z długiem równym zero jest cudowny i Atern DSDM pomaga w osiągnięciu tego stanu w projekcie.
Następny schemat pozwala przestrzegać zasadę "Plan first & then act".

Najpierw sprawdzamy możliwość wykonania/potrzebę wykonania całej konstrukcji:
Time boxing
Osiągamy główne cele - dostarczamy na czas, zgodnie z budżetem w wysokiej jakości.
MoSCoW
Metodyka priorytezacji zgodnie z następującymi priorytetami:
MUST: wymaganie MUSI zadowalać potrzeby biznesowe.
SHOULD: czy POWINNO się wypełniać wymaganie, jeśli nie zależy od niego sukces projektu?
COULD: NALEŻY zostawić wymaganie, jeśli nie wpływa ono na biznesowe zapotrzebowanie projektu?
WON'T: czy MOŻNA odłożyć realizację wymagania, jeśli jeszcze mamy czas?
Prototypowanie
Tworzymy prototypy, dajemy je realnym użytkownikom, dostajemy informację zwrotną i pozwalamy rzeczywiście przetestować i użyć produktu wcześniej.
Testowanie
Testujemy zawsze po każdej iteracji, tylko dzięki testowaniu możemy osiągnąć wysoką jakość.
Modelowanie
Moi stali czytelnicy (jeśli tacy są) pamiętają, że wizualizacja jest skrajnie potrzebna. Wizualizujemy wszystko schematami dla uproszczenia postrzegania informacji (patrz: artykuł Documentation in Pictures).
Na zakończenie, chciałbym wspomnieć o zasadzie Behavior Driven Development (BDD).
BDD to nie "złoty środek", to odgałęzienie od TDD, lecz "test" jest zamienione na "behavior", w wyniku czego powstaje myślenie skierowane na sprawdzenie rzeczywiście potrzebnej funkcjonalności. Najpierw piszemy testy na sprawdzenie specyfikacji, następnie wdrażamy kod programowy samego systemu.
Tym samym, ściśle pracujemy z klientem, wspomagamy prace prototypu na wszystkich etapach, staramy się przestrzegać wysokich standardów jakości i wypełniamy wymagania faktycznie niezbędne dla biznesu, w zgodzie z ograniczeniami czasowymi i budżetem.
Ivan Alyakskin
Software Consultant
Myślę, że wielu delivery managerów zgodzi się, że sytuację podczas realizacji projektów w ramach ograniczonego czasu i budżetu, a także wymagań o real business value można porównać do łyżwiarstwa figurowego po bardzo cienkim lodzie.
W naszej firmie wypracowaliśmy następujące zasady, które bardzo pomagają w tego typu sytuacjach:
- Scrum jest dobry, ale DSMS Atern jest lepszy
- Plan & only then act
- Behavior Driven Development
- Deliver ASAP
- Wizualizacja i dokumentacja jest lepsza niż tekst
Za co lubimy DSDM Atern?
Zacznijmy od jednego z moich ulubionych schematów, by zobaczyć najważniejsze zasady Atern DSDM.

- Czas realizacji i wartość są stałe.
- Jakość jest ważniejsza od pełnofunkcjonalnych możliwości systemu.
Dla zapewnienia real business value, należy:
- Skupić się na potrzebach biznesu
- Dostarczyć na czas
- Współpracować maksymalnie efektywnie
- Nigdy nie iść na kompromis odnośnie jakości
Jak pokazuje nasza praktyka, dane podejście wyraźnie daje klientowi do zrozumienia, że wszystko idzie zgodnie z planem. I co najważniejsze, nie pojawiły się żadne pytania dotyczące uzgodnienia kolejnych etapów pracy, nie było żadnych poszukiwań dodatkowych funduszy na rozwiązanie problemów jakości. Idealny obraz z długiem równym zero jest cudowny i Atern DSDM pomaga w osiągnięciu tego stanu w projekcie.
Następny schemat pozwala przestrzegać zasadę "Plan first & then act".

Najpierw sprawdzamy możliwość wykonania/potrzebę wykonania całej konstrukcji:
- Precyzujemy potrzeby biznesu
- Szacujemy business value, który będzie rzeczywiście potrzebny, wraz z zaangażowaniem ludzi z biznesu
- Robimy wszystko zgodnie z metodyką DSDM
- Uzgadniamy funkcjonalność i plany
- Tworzymy prototyp, testujemy cały system
- Analizujemy prototyp razem z biznesem
- Uzgodnienie funkcjonalności prototypu i terminów
- Tworzenie prototypu dla codziennego użytku, później analiza prototypu razem z użytkownikami biznesu, gromadzenie opinii użytkowników, test logi.
- Uzgodnienie funkcjonalności z użytkownikami końcowymi
- Nauka użytkowników obsługi systemu
- Wdrożenie systemu
- Analiza rynku
Time boxing
Osiągamy główne cele - dostarczamy na czas, zgodnie z budżetem w wysokiej jakości.
MoSCoW
Metodyka priorytezacji zgodnie z następującymi priorytetami:
MUST: wymaganie MUSI zadowalać potrzeby biznesowe.
SHOULD: czy POWINNO się wypełniać wymaganie, jeśli nie zależy od niego sukces projektu?
COULD: NALEŻY zostawić wymaganie, jeśli nie wpływa ono na biznesowe zapotrzebowanie projektu?
WON'T: czy MOŻNA odłożyć realizację wymagania, jeśli jeszcze mamy czas?
Prototypowanie
Tworzymy prototypy, dajemy je realnym użytkownikom, dostajemy informację zwrotną i pozwalamy rzeczywiście przetestować i użyć produktu wcześniej.
Testowanie
Testujemy zawsze po każdej iteracji, tylko dzięki testowaniu możemy osiągnąć wysoką jakość.
Modelowanie
Moi stali czytelnicy (jeśli tacy są) pamiętają, że wizualizacja jest skrajnie potrzebna. Wizualizujemy wszystko schematami dla uproszczenia postrzegania informacji (patrz: artykuł Documentation in Pictures).
Na zakończenie, chciałbym wspomnieć o zasadzie Behavior Driven Development (BDD).
BDD to nie "złoty środek", to odgałęzienie od TDD, lecz "test" jest zamienione na "behavior", w wyniku czego powstaje myślenie skierowane na sprawdzenie rzeczywiście potrzebnej funkcjonalności. Najpierw piszemy testy na sprawdzenie specyfikacji, następnie wdrażamy kod programowy samego systemu.
Tym samym, ściśle pracujemy z klientem, wspomagamy prace prototypu na wszystkich etapach, staramy się przestrzegać wysokich standardów jakości i wypełniamy wymagania faktycznie niezbędne dla biznesu, w zgodzie z ograniczeniami czasowymi i budżetem.
Ivan Alyakskin
Software Consultant