In acest articol as vrea sa vorbesc despre o abordare pe care o folosim pentru un design MVP rapid sau la inceputul unui nou proiect pentru clientii care vor vor sa creasca viteza cu care fac business prin intermediul unor inovatii precise si continue folosind automatizarea programabila.

Sunt convins ca majoritatea delivery managerilor sunt de acord ca atunci cand ai situatii in care trebuie sa implementezi proiecte cu timp si resurse limitate dar unde trebuie sa produci valoare pentru business e ca si cum ai patina pe o gheata foarte subtire.
Din experienta mea urmatoarele principii s-au dovedit foarte utile in acest tip de situatii:

• Scrum este bun dar DSMS Atern este si mai bun
• Planifica si abia apoi actioneaza
• Behaviour Driven Development
• Livrare cat mai rapida
• Vizualizarea si documentarea sunt mai bune ca documentele scrise

De ce imi place DSDM Atern?

Pentru a intelege cele mai importante principii ale Atern DSDM haideti sa incepem cu una dintre diagramele mele favorite.

• Timpul de implementare si costurile sunt fixe.
• Calitatea este prioritara in fata unei functionalitati complete a sistemului.

Aplicarea acestor principii ne va permite sa livram un produs de incredere, care poate sa fie folosit imediat si fara nici un fel de dubiu cu privire la calitate acestuia.

Pentru a asigura cu adevarat valoarea pentru business ar trebui sa:

• Ne concentram pe nevoile de business
• Livram la timp
• Interactionam eficient
• Nu facem nicioadata compromis cand vine vorba de calitate

Din experienta noastra, aceasta abordare, ii permite clientului sa inteleaga ca totul merge conform a ceea ce s-a stabilit. Si mai important decat atat, cand am folosit-o, nu au existat intrebari cu privire la etapele urmatoare ale proiectului sau provocari legate de suplimentarea bugetului pentru a rezolva diferite probleme legate de calitate. Aceasta situatie ideala este utila si DSDM Atern ne ajuta sa o atingem.

Diagrama de mai jos ne ajuta sa respectam principiul “Planifica si abia apoi actioneaza”.


Mai intai ne uitam la intreaga structura pentru a verifica gradul de implementabilitate (implementability) /nevoia de implementare:

• Redefinirea nevoilor de business
• Estimarea valorii de business care va fi cu adevarat necesara implicand reprezentati ai clientului
• Respectarea tehnicilor DSDM

Acum trebuie sa dezvoltam un model functional: un prototip functional si modele.

• Coordonarea functionalitatilor si a planurilor
• Crearea unui prototip, testarea intregului sistem
• Analiza prototipului impreuna cu utilizatorii din partea clientului

Apoi urmatorul pas este design-ul si dezvoltarea:

• Coordonarea functionalitatii prototipului si a etapelor
• Crearea unui prototip pentru utilizare zilnica, apoi analiza prototipului cu utilizatorii din partea clientului, colectarea feedback-ului, test logs.

Etapa finala a implementarii:

• Coordonarea functionalitatilor cu utilizatorii finali
• Pregatirea utilizatorilor pentru a folosi sistemul
• Implementarea sistemului
• Analiza de piata

Etapele ne permit sa simplificam procesarea cerintelor care necesita schimbari, sa testam si sa livram la timp produsul. Toate aceste lucruri se fac in concordanta cu metodele DSDM:

Time boxing

Atingerea obiectivelor principale: livrare la timp, respectand bugetul cu un nivel ridicat de calitate.

MoSCoW

Aceasta este o metoda de a prioritiza conform aspectelor de mai jos:

TREBUIE: o cerinta TREBUIE sa satisfaca o nevoie de business
AR TREBUI: AR TREBUI ca cerinta sa fie indeplinita daca succesul proiectului nu depinde de ea?
AR PUTEA: AR PUTEA cerinta sa fie data la o parte daca nu are un impact asupra nevoilor de business ale proiectului?
NU VA: Indeplinirea cerintei NU VA fi amanata daca ne ramane timp?

Prototyping

Dezvolta prototipuri, lasa utilizatorii sa le foloseasca, obtine feedback-ul lor, si permite testarea si folosirea produsului in avans.

Testare

Testeaza continuu, dupa fiecare iteratie; doar prin testare putem sa atingem un nivel ridicat de calitate.

Modelare

Vizualizarea este necesara. Trebuie sa ne asiguram ca facem asta prin diagrame pentru a face informatia mai usor de inteles. Vezi Documentare in imagini.

In cadrul concluziei as vrea sa aduc in vedere si idea de BDD (Behaviour Driven Development). BDD nu este o solutie pentru toate problemele, este doar o consecinta a TDD, doar ca “Test” este inlocuit de “Behaviour” lucru care are un impact asupra modului nostru de gandire – mai exact sa verificam functiile care sunt cu adevarat necesare. Mai intai scriem teste pentru a verifica specificatiile, apoi implementam codul.

Astfel lucram in colaborare cu clientul, fiecare etapa avand un prototip. Incercam sa avem un nivel de calitate cat mai mare si sa respectam cerintele care sunt cu adevarat cruciale pentru business.

Ivan Alyakskin 
Software Consultant