Sa „faci” este foarte simplu. Putin conteaza ca este un website sau o aplicatie de mobil, important este modul in care este contruit/a. La fel ca si o casa sau un laptop, software ul este un produs ce trebuie sa indeplineasca anumite tehnici de construire. Dezvoltarea unei pagini web sau a unei aplicatii mobile presupune mai multi pasi care , la final duc la un produs corect construit din punct de vedere tehnic dar si design, fara a se face rabat de la nevoile clientului.

1. Cerinte obligatorii de inceput:

A. Product owner și Stakeholders (părți interesate)

– Crearea hărții procesului „As is”;
– Cartografierea fluxului/procesului pentru a observa, înțelege și elimina timpul pierdut (de exemplu, timpul de așteptare pentru aprobare, pentru rapoarte, din motive de securitate) ;
– Harta procesului „As is” este revizuită și ajustată pe baza modificărilor și a standardizării procesului;
– Crearea hărții procesului „To be”.

B. Planificare

B.1. Proiect Kick-off & Sprint 0

(Scrum Master, Product Owner, părți interesate și/ sau utilizator final)
– Un rezumat al proiectului la nivel simplist și crearea unui desfășurator al proiectului;
– Definirea tehnologiilor și sarcinilor nefuncționale;
– Definirea procesului de dezvoltare, elaborarea a unor părți funcționale (MVP) și ordonarea acestora în funcție de prioritate.

B.2. Product owner, părțile interesate și/sau utilizatorul final

– Crearea unei liste de cerințe pe baza hărții procesului „To be”;
– Verificarea faptului că fiecare cerință îndeplinește criteriile INVEST;
– Elaborarea unei definiții a cuvantului „Done” pentru fiecare cerință;
– Crearea Backlog-ul produsului;
– Alocarea de puncte fiecărei cerințe pentru a le acorda prioritate (de la valoare ridicată la valoare scăzută);
– Utilizarea următorul șablon „Ca un (bulgăre) doresc (funcționalitate), astfel încât (avantajele afacerii)” Pentru a avea suficiente detalii pentru a converti fiecare cerință în User Story;
– Pe baza priorităților, va fi creată harta detaliilor proiectului (Backbones, Walking Skeletons și lista de povești ale utilizatorilor utilizând abordarea MoSCoW).

2. Dezvoltare și testare (la nivel de sprint)

A. Product owner și echipa de dezvoltare – Planificarea Sprint-ului

– Pe baza detaliilor proiectului, se acordă prioritate specificațiilor utilizatorilor care vor fi incluse în primele Sprinturi – luând în considerare poveștile utilizatorilor cu valoare ridicată și cu risc ridicat.
– Product owner-ul ar trebui să aibă toate detaliile despre specificațiile utilizatorilor care vor fi incluse în următorul Sprint (flux de lucru pas cu pas – instrucțiuni de lucru – cu capturi de ecran și toate detaliile relevante) pentru a sprijini echipa de dezvoltare.
– Înainte de fiecare sesiune de planificare, Sprint, proprietarul produsului (și Scrum Master) perfecționează Backlog-ul.

B. Scrum Master și echipa de dezvoltare – Scrum zilnic

– Se discută despre progres, impedimentele întâlnite și ce se va face/ care sunt următorii pași.

C. Product owner, echipa de dezvoltare, părțile interesate și/ sau utilizatorul final – Sprint Review

– Demonstrație/Testare de produs/ MVP realizat în timpul sprintului;
– Se va folosi feedback-ul primit de la părțile interesate și/ sau utilizatorul final pentru a reprioritiza Backlog-ul (opțional);
– Confirmarea creșterii – în cazul în care depozitele utilizatorilor efectuate în sprint pot fi considerate „Done”.

D. Echipa de dezvoltare și Scrum Master – Retrospectiva Sprint

– Experiențele căpătate și zonele de îmbunătățire.
Notă:
– După 3 Sprint-uri, cadența și WIP-ul pot fi definite astfel încât Scrum Master-ul să poată estima, pe baza diagramei de viteză de lucru a echipei, termenul până la care produsul poate fi finalizat
– Crearea unei diagrame de flux cumulativă pentru a monitoriza timpul de lucru vs ciclu de lucru (ca zonă de îmbunătățire); – de cautat ce inseamna
– Product owner-ul poate anula un Sprint doar dacă este necesar – în acest caz, scopul Sprintului este modificat.
– Product owner-ul ar trebui să aibă toate detaliile referitoare la proiectul din Sprint-ul curent. În caz contrar, Product owner-ul sau dezvoltatorul va purta o discuție față în față cu utilizatorul final pentru a înțelege detaliile referitoare la proiect.
– Product owner-ul se va asigura întotdeauna că Backlog-ul produsului este actualizat (prioritizat corect).

3. Integrare

A. Echipa de dezvoltare

– Echipa testeaza integrarea detaliilor proiectului și repară erorile

4. UAT – User acceptance test

A. Product Owner-ul, utilizatorul final și echipa de dezvoltare

Utilizatorul final și/ sau product owner-ul evaluează detaliile proiectului, testează produsul și trimit confirmarea către echipa de dezvoltare.

5. Implementare

A. Product owner, utilizatorul final și echipa de dezvoltare

Instrucțiuni despre proiect trimise către client

Notă:

Detaliile proiectului: „Done” va însemna dezvoltat, documentat și testat;

Lansări: „Done” înseamnă că nu există defecte mari sau solicitări de modificare rămase;

Livrabilele finale ale proiectului: sunt implementate caracteristici prioritare (echivalentul două Sprint-uri fără erori, îndeplinind un de scor de satisfacție al utilizatorului final).

Legendă:

As is = momentul T0
To be = momentul T1
Done = finalizat
Backlog
Timpul de lucru = măsoară timpul de când clientul cere proiectul până cand acesta primește livrabilul
Ciclu de lucru = măsoară timpul in care echipa de dezvoltare muncește pentru a duce la îndeplinire ceea ce clientul a cerut