'Y'

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.

Jun 7, 2017 2083
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:

  • 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.

Dynamic_Systems_Development_Method_1.png

  • Czas realizacji i wartość są stałe.
  • Jakość jest ważniejsza od pełnofunkcjonalnych możliwości systemu.
Użycie tych zasad umożliwi szybkie dostarczenie wartościowego produktu, który może być od razu użyty, bez jakichkolwiek pytań odnośnie jakości.

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".

Dynamic_Systems_Development_Method_2.png

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
Tworzymy wysokopoziomowy model funkcjonalny: działający prototyp i modele

  • Uzgadniamy funkcjonalność i plany
  • Tworzymy prototyp, testujemy cały system
  • Analizujemy prototyp razem z biznesem
Następnie zajmujemy się projektowaniem I programowaniem:

  • 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.
Końcowy etap realizacji:

  • Uzgodnienie funkcjonalności z użytkownikami końcowymi
  • Nauka użytkowników obsługi systemu
  • Wdrożenie systemu
  • Analiza rynku
Dane etapy pracy pozwalają na uproszczenie pracy z Change Requestami, przeprowadzenie testowania oraz dostarczenie rzeczywiście niezbędnego produktu na czas. Wszystko jest zrealizowane zgodnie z metodami DSDM:

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

Udostępnij


Masz jeszcze jakieś pytania?
Skontaktuj się z nami
Thank you.
Your request has been received.