Do you need a clear vision in which context you should use Agile, Waterfall, Scrum or Kanban? We built a document where you will find relevant and useful information that can help you. Take a look!

1. MORE THAN ONE WAY
There is
To develop a software
Software Development beyond standard methodologies

2. Pentru a intelege procesul intreg prin care trebuie sa treaca un proiect,
trebuie sa intelegi urmatoarele faze cronologice ale proiectului.
Initializare proiect
Organizare
Executie
Finalizare
Stabilirea obiectivelor pe termen scurt, mediu si lung, stabilirea planului de
actiune pentru realizarea obiectivelor si estimarea resurselor necesare.
Stabilirea echipei de proiect, repartizarea sarcinilor catre membrii echipei,
stabilirea regulilor si a sistemului de lucru.
Inceperea si mentinerea activitatii in randul echipei de proiect.
Rapoarte si concluzii finale.
Supravegherea activitatii si stabilirea unor masuri de ajustare acolo unde este
nevoie. Corelarea, unificarea, si armonizarea tuturor activitatilor.
Monitorizare si control

3. Agile
Waterfall
vs
In dezvoltarea de produse software sunt folosite mai multe modele de lucru ce stau la
baza project managementului.
Care este diferenta dintre acestea si in ce context se folosesc?

4. Waterfall – Cand se foloseste modelul
• Definitia de “produs final” este stabilita
• Cand ai proiecte a caror cerinte majore nu se
schimba foarte des (ex: aerospatiala/navala etc)
• Cand cerintele proiectului sunt foarte clare.
• Ai proiecte care includ proceduri
• Ai la dispozitie resurse ample cu expertiza
necesare
• Tehnologia este inteleasa

5. Waterfall – La ce proiecte se foloseste
• Pentru dezvoltarea aplicatiilor critice din organizatii ( planificarea resurselor
intreprinderii, aplicatii de prelucrare a datelor)
• Pentru proiecte de mentenanta
• Cand nu exista presiune pentru implementare imediata
• Project Manager-ul nu trebuie sa fie foarte experimentat
• Membrii echipei pot fi fara experienta
• Componenta echipei este instabila si este de asteptat sa fluctueze
• Echipa de proiect este complet informata despre domeniu si modul de
functionare al domeniului
• Exista cerinte stricte pentru aprobari formale

6. Planning
Design
Coding
Testing
Deploy
Sep Oct Nov Dec Jan Feb Mar
Waterfall – modelul de lucru
Analysis
Este mai mult un MODEL de dezvoltare software decat o METODOLOGIE
Fiecare faza se dezvolta independent si
procesul functioneaza ca o cascada. Odata
ce faza de “Planning” e finalizata, se trece
la faza de “Analysis”.
Un dezavantaj major pe care il are modelul
este ca o data ce faza de Coding e finalizata si
se identifica o problema, trebuie repetate
toate fazele care preced Coding-ului. Asta se
poate intampla pentru orice faza a proiectului.

7. Avantaje Dezavantaje
Este usor de inteles si utilizat
Este usor de gestionat datorita rigiditatii
modelului
Fazele de dezvoltare ale produsului nu se
suprapun
Functioneaza bine pentru proiecte a caror
cerinte nu necesita schimbari constante si sunt
bine intelese
Timpul acordat planificarii poate reduce riscurile
si pierderile din etapele viitoare
Datorita documentatiei detaliate clientul stie la
ce sa se asteapte si are o idee despre
dimensiunea costurilor si timpul necesar
dezvoltarii proiectului
Datorita documentatiilor detaliate, angajatii noi
se adapteaza rapid cerintelor proiectului
Clientul nu are certitudinea realizarii unui
produs eficient in momentul lansarii
Prezinta o suma mare de riscuri si incertitudini
Modelul este rigid pentru proiectele in continua
schimbare si continua desfasurare
Adaptarea greoaie a modelului la cerintele pietei
care este in continua schimbare
Metodologia se bazeaza foarte mult pe cerintele
initiale
Daca o cerinta este gresita sau trebuie facuta o
schimbare, proiectul o ia de la capat
Testarea se face la sfarsit iar tentatia de a amana
testarea minutioasa este mare
Waterfall

8. Agile - Cand se foloseste metodologia
•Produsul final nu este foarte bine si clar definit
•In cazul unui proiect destinat unei industrii care necesita schimbari periodice
•Cand clientii pot schimba scopul proiectului
•Cand fiecare membru din echipa se poate adapta usor si este capabill sa lucreze
independent
•Cand schimbarile dintr-un plan pot fi discutate foarte des prin feedback
•Cand ai libertatea de a apela la alte optiuni decat cele din planul proiectului.

9. Agile - La ce proiecte se foloseste
•Pentru dezvoltarea de aplicatii a caror cerinte nu sunt clar definite
•Exista incapacitatea de a face presupuneri cu privire la cunostintele
utilizatorului
•Proiecte unde bugetele se schimba
•Pentru proiecte unde tehnologia se schimba foarte des
•Acolo unde cerintele proiectului sunt intr-o continua evolutie

10. Planning
Design
DesignUnit Testing
Deploy
Sep Oct Nov Dec Jan Feb Mar
AGILE
Coding
Analysis
AGILE a aparut ca o nevoie ce acopera o parte din dezavantajele modelului WATERFALL si are ca
principal scop reducerea costului de dezvoltare a produsului cat si al timpului de lansare pe piata
Agile functioneaza
dupa urmatoarea
abordare:
Analiza-adaptare
Iterativa

11. Avantaje Dezavantaje
Planuri adaptative si predictive
Produsul este livrat frecvent
Imbunatatire continua
Feedback constant
Incurajeaza schimbarea rapida in etapele
incipiente proiectului, astfel reducand costul
necesar schimbarilor identificate tarziu
Minimizeaza riscul aducerii pe piata a unui
proiect nefunctional
Ofera feedback la sfarsitul fiecarui ciclu de timp
in urma caruia se poate imbunatati produsul
Prin testarea la sfarsitul fiecarui sprint, te asiguri
ca problemele aparute se pot repara in
urmatorul ciclu de dezvoltare
Nu se vor gasi erori la sfarsitul proiectului
Comunicare puternica intre persoanele din
echipa
In cazul livrarii unor proiecte, in special a celor
de lunga durata, este dificil sa evaluezi efortul
necesar la inceputul ciclului de viata.
Nu se pune mult accent pe documentatia
necesara
Proiectul poate avea multe intreruperi daca
clientul nu stie cu exactitate forma finala a
produsului
Numai seniorii pot lua anumite decizii care sa
influenteze procesul de dezvoltare al produsului
Planul poate sa fie ambiguu
Echipa trebuie sa fie bine formata
AGILE

12. Waterfall Agile
Iterativ x
Linear x
Proces flexibil (raspunde la schimbari) x
Proces rigid(necesita cerinte bine definite) x
Faza de testare se realizeaza in acelasi timp cu
faza de dezvoltare
x
Faza de testare este separata de faza de
dezvoltare
x
In fiecare etapa este finalizata o parte a
proiectului care sa fie validata de client
x
Documentatie detaliata x
Livreaza produse de calitate x x
vsWaterfall Agile

13. Kanban
Scrum XP
DSDMCrystal Clear
RAD
+others
AGILE
Agile este definita ca filozofie iar cele mai folosite metode de implementare
sunt SCRUM si KANBAN

14. SCRUM STRUCTURE
Roles Artifacts Meetings
SPRINT Perioada de timp cuprinsa ideal intre 2-4 saptamani.
Fiecare SPRINT combina toate fazele de lucru (planning, coding, testing, etc)
Scram este o METODA de dezvoltare software prin care sunt puse in practica
principiile metodologiei Agile

15. Product Owner Development Team Scrum Master
SCRUM - Roles
▪ Responsabil pentru proiect
▪ Persoana decizionala
▪ Prioritizeaza cerintele
▪ Se concentreaza mai mult
pe “CE” decat pe “CUM”
▪ Facilitator
▪ Are grija ca echipa sa urmeze
obiectivele
▪ Elimina factorii distractori
▪ Nu are autoritate manageriala
▪ Monitorizeaza si optimizeaza
procesul
▪ Echipa formata ideal din 5-9
persoane
▪ Echipa expertizata pe mai
multe domenii de activitate
▪ Se organizeaza singura
▪ Colaboreaza si ofera feedback
constant
▪ Se concentreaza pe “CUM”

16. SCRUM - Artifacts
Product Backlog Sprint Backlog
Prioritate ridicata
Prioritate scazuta
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Obiectivele intregului
proiectului
Obiectivele si cerintele
din cadrul unui SPRINT.
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Not
Started
In
Progress
In
Progress
CE? CUM?
Task
Task
Task
Task
Task
Task
Task

17. SCRUM –are la baza 5 timpuri de sedinte
Sprint Backlog
Meeting
Sprint Planning
Meeting
Daily Scrum
Sprint Review
Meeting
Sprint Retrospective
Meeting
Se stabilesc obiectivele proiectului
Echipa se intalneste o data pe zi, timp de 15 minute pentru a-si raporta activitatile
din ziua precedenta, isi ofera feedback si cauta solutii pentru problemele
intampinate
Se stabilesc cerintele si task-urile pentru urmatorul SPRINT din cadrul proiectului.
Echipa demonstreaza functionalitatea produsului potential. La intalnire sunt
prezenti, product owner-ul si persoanele interesate de proiect. Se ofera
feedback. Se stabileste ce s-a finalizat si la ce mai trebuie sa se lucreze si se
redefinesc anumite cerinte
Intalnirea in care se analizeaza si optimizeaza procesul de lucru. Ce a mers bine?
Ce poate fi imbunatatit? Ce am invatat?

18. SCRUM – Fluxul procesului

19. LIMITARILE
SCRUM
Pentru echipe care au abilitati foarte
specializate.
Produse care au multe dependente externe.
(De ex: Primirea unor module de la alte echipe)
Pentru echipe a caror membri sunt dispersati
geografic sau cu programe diferite de lucru.
Pentru produse mature sau de tip legacy si
care au sesiuni specifice de QA.

20. SCRUM - Cateva concluzii
•Este proiectat pentru a produce cele mai bune solutii de business.
•Eficienta variaza foarte mult in functie de fiecare organizatie.
•Eficienta depinde de structura organizatiei respective, cultura
organizationala si practicile de business.

21. Kanban
Kan = Visual Ban = Card
De La Sistemul De Productie Toyota La Software Development
Taiichi Ohno A pus bazele Sistemului de Productie Toyota si conceptelor Just In Time (JIT)
KANBAN
Este un concept care se referea la obtinerea de materiale sau cerinte necesare
“Just in time” pentru introducerea lor in asamblare sau proces
Este un sistem care SEMNALEAZA nevoia de actiune si apare in completarea
detaliata a proceselor de lucru din SCRUM

22. Conceput initial de Henry Ford
Tinta: Zero stocuri. Problema: Zero Flexibilitate
Idee aplicata mai mult in supermarket-uri.
SEMNALEAZA faptul ca raftul trebuie realimentat.
Kanban – Scurt Istoric

23. Transport Stocuri Miscare
Timpul de
asteptare
SupraprocesareaSupraproductia
Defectele de
reprelucrare
KANBAN - Axarea pe diminuarea pierderilor
Taichii Ohno – a exportat ideea din supermarket-uri si a implementat-o in
productia de automobile a companiei Toyota. Scopul: Reducerea costurilor prin
optimizarea a 7 procese principale.
Dezvoltat in domeniul IT de David J Anderson

24. KANBAN
2 principii
Furnizare de servicii care se
orienteaza catre client
De management al schimbarii prin
care pune accentul pe schimbari
evolutive
•Metoda nu trece prin anumiti pasi specifici, dar porneste de la context si
stimuleaza schimbarea continua, incrementala si evolutiva a sistemului.
•Urmareste sa reduca la minim rezistenta la schimbare.
•Scopul este de a face fluxul de lucru si progresul cerintelor din proiect CLARE
atat pentru cei direct implicati cat si pentru stakeholders

25. Kanban Board
On Desk
5
Analysis Dev Test Done
4 2
Task
Este un sistem care SEMNALEAZA nevoia de actiune si functioneaza
dupa sistemul PULL.
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Task
Task
Task
Doing DoingDone Done
Task
Task Task
Pull
Task
Task
Task
Task
Task
Pull
Another
Task
Here
In cazul fazei de testare unde s-a stabilit faptul ca se poate lucra la 2 cerinte, una din cele doua
cerinte fiind finalizata, sistemul iti transmite un mesaj/semnal “ Pull Another Task Here”

26. KANBAN – Cateva concluzii
In Kanban se pune accentul pe milestones, nu pe viteza.
Echipa este concentrata doar pe munca aflata in desfasurare
Cat timp Product Owner-ul mentine priotitatea sarcinilor, echipa de proiect aduce profit
maxim business-ului acestuia
Echipa poate face predictii cu privire la momentul livrarii produsului final
Cum toate sarcinile sunt realizate la cerere, nu este nevoie de foarte multi oameni pentru
proiect deci eficienta costurilor este ridicata
Kanban este foarte bun pentru proiecte complexe deoarece raspunde rapid la cerinte

27. Scrum Kanban
Roluri specifice x
Nu are roluri x
Utilizare in salturi x
Utilizare continua x
Echipa trebuie sa fie expertizata pe mai multe domenii x
Functioneaza dupa sistemul Pull x x
Transparenta x x
Livreaza produsul in mod iterativ x x
Sistem empiric x x
Imbunatatire continua x x
Lean and Agile x x
Raspunde la schimbari x x
vsScrum Kanban

28. SCRUMBAN - Un mixt intre Scrum si Kanban, folosit:
Pentru a obtine eficienta maxima in SPRINT-uri
Pentru a eficientiza rolurile din Scrum
Pentru a reduce volumul de munca aflat “in progres” prin Kanban

29. Se realizeaza o planificare de baza
Extinde sarcinile pentru SPRINT-uri
Se poate face o estimare a numarului membrilor din echipa
Se poate face o estimare a cantitatii volumului de munca destinat echipei
Intalnirile zilnice permit membrilor echipei sa identifice imediat problemele proiectului
Se face o retrospectiva a sprint-ului care permite imbunatatirea urmatorului sprint
Ofera feedback la sfarsitul fiecarui SPRINT prin care se poate imbunatati produsul
Te ajuta sa inveti din greseli si din realizari
SCRUMBAN - Avantaje

30. SPIRAL RAD
Alte procese folosite in software development

31. Prototype Cycles
Alte procese folosite in software development

32. Business Modelling
Requirements
Analysis and design
Implementation
Test
Deployment
Configuration and Change Management
Project management
Environment
1
2
3
4
5
6
7
8
9
RUP – Rational Unified Process folosit de IBM
Prezinta 9 discipline care trebuie acoperite la fiecare iteratie
6 Discipline care tin de domeniul ingineriei
3 “Discipline suport”

33. RUP – Best Practices
Fii concentrat pe nevoile clientului
Foloseste OOP
Utilizeaza diagrame
Testeaza tot timpul
Asigura-te ca schimbarile aduse
sistemului sunt sincronizate si
verificate constant.
Imparte problema in probleme mai mici
1
Dezvolta
iterativ
2
Manageriaza
Cerintele
3
Utilizeaza
componente
4
Modeleaza
Vizual
5
Verifica
calitatea
6
Controleaza
schimbarile

34. TEORIE
PRACTICA
-vs-

35. PROIECTUL - Dezvoltarea unei aplicatii bancare
Gestionarea in timp real al conturilor curente
(incasari si plati)
Gestionarea depozitelor in lei si valuta
Casa de schimb valutar
Extrase de cont
Interfata cu celelalte aplicatii
Una din top 3 banci din Romania
FUNCTIONALITATI PRINCIPALE CERUTE
PENTRU REALIZAREA PROIECTULUI
CLIENTUL
UNDE si CAND
Romania anilor 1996 -1997

36. Existau foarte putine firme de
consultanta si training care sa ofere
cursuri de PM in software dev
Internetul si telefonia mobila erau
la inceputuri
Nu exista Google
Documentatiile tehnice erau
pe suport hartie, daca se
cumparau licentele
Nu aveam acces la tutoriale
on-line sau forumuri
Conceptul open-source era
doar un vis
CONTEXTUL in care proiectul a fost dezvoltat?

37. CINE a dezvoltat proiectul?
Echipa formata
din
6 persoane cu
4-5 ani
experienta
Manager de
proiect
Tech Lead
4 Developeri
Tehnologiile au fost impuse de client si erau doar partial cunoscute de echipa de proiect
2 persoane IT din
partea clientului
Business Analyst
din partea
clientului
+

38. Formare rapida pe tehnologiile impuse de proiect
Analiza detaliata si design de interfete impreuna cu clientul
Arhitectura si design de aplicatie
Dezvoltare impartita pe module, submodule, taskuri
Testare ‘unitara’
Integrare si testare functionala facuta de utilizatori ai aplicatiei
Milestone : « pilot de laborator »
Acceptanta si trecere in faza de testare live
Pregatire pentru live si crearea unor mulinete de transfer de date reale
Milestone : « pilot live »
1
2
3
4
5
6
7
8
CUM am dezvoltat proiectul?

39. Ce a urmat?
•Un alt proiect de implementare a aplicatiei in peste 100 de sucursale si agentii
bancare. Vinerea banca termina lucrul pe vechile aplicatii si baze de date iar
lunea pornea pe cele dezvoltate de noi
•Support tehnic on-call si crearea unei baze de date cu incidente frecvente, cu
solutii de ocolire si rezolvarea problemelor si cazuisticii neacoperite din faza de
analiza
•Mentenanta corectiva si evolutiva a aplicatiei pentru 5 ani

40. Waterfall Agile
Scrum Kanban
Cheia succesului?
• Am inteles rolurile dintr-un
proiect si ni le-am asumat
• Am creat o aplicatie care le-a
placut foarte mult utilizatorilor
• Am construit o relatie pe
termen lung cu clientul
Am aplicat filozofii si metodologii
diferite in functie de context

41. NB: Toti cei implicati in proiect au
devenit persoane cheie in industrie
A fost un proiect de
SUCCES

42. Este VOIE sa iesiti din pattern-urile studiate
Analizati si adaptati la CONTEXT
Asa s-au nascut filozofiile, metodele, metodologiile
Nu ganditi inchistat
CATEVA SFATURI

43. Noi la AXON Soft lucram tinand cont de context si ne
mandrim cu o rata de 100% proiecte de succes.

44. VA MULTUMIM!
Address: Bd. 21 Decembrie 1989, nr. 126
400604, Cluj-Napoca Romania
Tel: +40246487026
Email: office@axonsoft.ro