„Așadar, vreau să vă spun despre Agile și Scrum .”
„La începutul secolului 21, modul în care oamenii se gândeau la programare a fost dat peste cap”.
„Toată lumea era convinsă că planificarea pe termen lung nu funcționează, așa că au decis să o abandoneze cu totul”.
— Cum au făcut asta?
"Iată cum."
„Au inventat cea mai flexibilă abordare de management de proiect posibilă”.
Iată principalele idei din spatele dezvoltării agile :"
- oamenii și comunicarea sunt mai importante decât procesele și instrumentele;
- un produs de lucru este mai important decât documentația exhaustivă;
- colaborarea cu clientul este mai importantă decât respectarea termenilor unui contract;
- disponibilitatea de a se schimba este mai importantă decât a rămâne la planul inițial.
Iată principiile dezvoltării rapide:
- satisface clientul prin furnizarea de software valoros din timp și continuu;
- salută schimbările de cerințe chiar și la sfârșitul dezvoltării (acest lucru poate crește competitivitatea produsului final);
- livrați software de lucru frecvent (în fiecare lună sau săptămână sau mai des);
- comunicare strânsă zilnică între client și dezvoltatori pe parcursul întregului proiect;
- proiectul este lucrat de persoane motivate cărora li se asigură condițiile de muncă necesare, sprijinul și încrederea;
- metoda preferată de comunicare a informațiilor este o conversație personală (față în față);
- software-ul de lucru este cea mai bună măsură a progresului;
- sponsorii, dezvoltatorii și utilizatorii ar trebui să poată menține un ritm constant pentru o perioadă nedeterminată;
- concentrare constantă pe îmbunătățirea excelenței tehnice și a designului ușor de utilizat;
- simplitatea este arta de a nu face o muncă de prisos;
- cele mai bune cerințe tehnice, design și arhitectură provin de la o echipă auto-organizată;
- adaptare constantă la circumstanțe în schimbare.
„Principala problemă cu dezvoltarea software-ului a fost că, în nicio etapă, niciunul dintre participanți nu avea informații complete despre ce să facă”.
„Clientul vă poate spune cum își imaginează programul, dar va lăsa ceva deoparte sau va lua ceva de la sine înțeles.”
„Managerul trebuie, în general, să traducă cerințele din jargonul de programare în limbajul clientului și înapoi.”
„Există prea multă incertitudine”.
„Adesea, cerințele clientului sunt astfel: fă-o într-un fel, apoi arată-mi – dacă nu îmi place, atunci poți să o refac.”
— Uh... asta e îngrozitor.
„Conform noii paradigme, programatorii nu mai dezvoltă un produs sau program. În schimb, implementează funcționalitatea de care are nevoie clientul”.
"Care este diferența?"
„Ei bine, să presupunem că dezvoltarea programului obișnuia să dureze un an. Și a trebuit să treacă șase luni înainte de a fi ceva de văzut. Este ca și cum ai construi o casă mare: mai întâi, sapi o groapă pentru fundație, apoi turni fundația, construiți pereții, acoperișul, ornamentele etc.”
„Dar acum programatorii încearcă să lanseze funcționalitatea necesară cât mai curând posibil. Ar fi ca mai întâi să construiești o colibă, apoi o casă mobilă, apoi o casă mică și abia apoi o casă mare, în rate.”
„Având în vedere că probabil că clientul nu știe exact ce vrea, atunci aceasta este o abordare foarte rezonabilă.”
— Să presupunem că clientul dorește o cabană mare de vânătoare.
"Dezvoltatorii îi construiesc un mic. El locuiește o iarnă în el. Apoi decide că nu-i plac casele din lemn. Să facem una din cărămidă."
„Trăiește o vară lângă lac, dar țânțarii îl mănâncă de viu. Auzise undeva că lacurile sunt răcoroase, așa că și-a dorit să aibă unul. Dar acum nu mai vrea un lac. Și va fi mai ușor de construit. casa astfel: fără lac nu înseamnă amenințare cu inundații și poți construi casa pe pământ în loc de piloni, ceea ce va fi cu 25% mai rapid.”
"O analogie interesantă. Clienții își schimbă într-adevăr cerințele atât de des?"
— Da, dar problema nu este clientul.
„În primul rând, este foarte dificil să ne imaginăm cum vor decurge lucrurile în viitor. Managerii, testerii și programatorii fac toți acest lucru. De asemenea, se răzgândesc în funcție de modul în care se desfășoară lucrurile.”
"În al doilea rând, nu sunt cerințele clientului ceea ce contează cel mai mult? La urma urmei , scopul tuturor acestor lucrări este de a crea ceea ce are nevoie clientul , nu ceea ce a spus inițial să creeze ."
„Într-adevăr, înainte funcționa așa: analiștii de afaceri făceau o listă cu toate cerințele. Includeau această listă într-un contract, o semnau și lucrau numai conform listei.”
„Dacă din listă lipsea ceva de care clientul chiar avea nevoie, dar a uitat, nimeni nu ar face nimic în privința asta”.
"Îmi dau seama. E mai ușor să urmezi un plan, dar nu totul se poate face după un plan!"
"Exact."
„De aceea s-au inventat metode de dezvoltare agile”.
„Și astăzi am să vă povestesc despre Scrum , cel mai popular dintre ei.
„Caracteristica principală a Scrum este împărțirea dezvoltării proiectului în iterații mici – de obicei, de 2-4 săptămâni. Fiecare iterație se numește sprint.”
"La începutul unui sprint se ține o ședință de planificare a sprintului. Durează 3-4 ore."
„La sfârșit, există o demonstrație a tuturor sarcinilor complet finalizate.”
„Iată cum funcționează de obicei totul:”
„Înainte de primul sprint, clientul (sau un reprezentant al clientului) formează o listă de cerințe, adică setul de lucruri pe care programul ar trebui să le poată face. Aceste cerințe sunt de obicei numite user story , iar clientul este de obicei numit proprietarul produsului .”
„Se numește proprietarul produsului , deoarece produsul este scris pentru el. El, și singurul, definește lista de cerințe – ce, când și în ce ordine.”
„În plus, proprietarul produsului atribuie, de obicei, priorități de sarcini. Sarcinile cu cea mai mare prioritate vor fi implementate mai întâi. Întreaga listă de cerințe este numită și backlog de produs .”
„Când începe un sprint, toată lumea se adună pentru o întâlnire. Scrum master , de obicei un membru al echipei, conduce de obicei întâlnirea. Scopul întâlnirii este de a selecta sarcinile ( povestea utilizatorului ) pentru sprintul curent (iterația dezvoltării). "
„În primul rând, echipa atribuie fiecărei sarcini o estimare aproximativă în zile-man abstracte, cunoscute și sub denumirea de puncte de poveste. Apoi echipa decide câte sarcini vor avea timp să le termine în timpul sprintului”.
„Din nou, echipa însăși este cea care decide câte sarcini vor avea timp să termine în timpul sprintului”.
„Să presupunem că proprietarul de produs se aștepta ca echipa să selecteze primele 7 sarcini, dar a selectat doar 5, apoi sarcinile 6 și 7 sunt amânate pentru următorul sprint. Dacă acest lucru nu se potrivește proprietarului de produs , el poate crește prioritatea sarcinilor. 6 și 7 pentru a vă asigura că sunt selectați, dar apoi unele dintre celelalte sarcini vor renunța la sprint.”
„ Scrum Master poate propune, de asemenea, să împartă unele dintre sarcini în altele mai mici și să stabilească diferite priorități pentru ca proprietarul produsului să fie cât mai fericit posibil.”
„Asta este scopul întâlnirii: sarcinile pot fi schimbate și împărțite, prioritățile pot fi schimbate etc. Aceasta este munca care nu era vizibilă la început, dar care aduce multă valoare”.
"Am înțeles. E ca și cum ai conduce o mașină. Chiar dacă inițial crezi că trebuie doar să mergi drept, realitatea este că trebuie să eviți constant gropile, să virezi la dreapta și la stânga și să treci pe alții sau să-i lași pe lângă tine."
— Da, ceva de genul ăsta.
„Lista de sarcini alese pentru sprint se numește backlog de sprint ”.
„Programatorii decid cine va face ce și abia apoi se pun pe treabă. „Pentru a îmbunătăți eficiența, Scrum sugerează ca în fiecare zi să fie organizată o întâlnire de 5-15 minute, în care toată lumea să își poată spune reciproc ce au făcut ieri și ce sunt. o să fac azi.”
"Lucrarea în echipă. Pot să respect asta!"
„Pentru a face lucrurile mai ușor de vizualizat, de obicei este recomandat să afișați starea curentă a sprintului pe o tablă specială:”
„Rețineți cele trei coloane din stânga”.
"Numele abreviate ale sarcinilor sunt scrise pe note lipicioase. Iar notele lipicioase sunt plasate în coloane diferite, în funcție de starea lor (planificat, în curs, finalizat)."
„În dreapta, puteți vedea o diagramă burndown . Pentru fiecare zi, această diagramă listează sarcinile care rămân încă nerealizate. În mod ideal, numărul sarcinilor incomplete scade la zero în timpul sprintului.”
„Când sprintul se termină, scrum-masterul oferă o demonstrație pentru a arăta lista cu tot ce a fost complet terminat.”
„Apoi ține o întâlnire retrospectivă de sprint, care durează și câteva ore. În timpul acestei întâlniri, participanții încearcă de obicei să-și dea seama ce a mers bine și ce (și cum) lucrurile ar fi putut fi făcute mai bine.”
„De obicei, după 2-3 sprinturi, puteți identifica și elimina principalele probleme care împiedică echipa să lucreze mai eficient. Acest lucru duce la o productivitate mai mare fără a crește volumul de lucru al echipei. Acest lucru nu era posibil înainte de era metodologiilor agile. ”
„Uneori, o întâlnire de îngrijire este organizată și în timpul sprintului. Scopul este de a planifica următorul sprint. Participanții, de obicei, clarifică prioritățile sarcinilor în această întâlnire. De asemenea, pot împărți unele sarcini în părți și/sau pot adăuga sarcini noi la stocul de produse . ”
"Ei bine, practic asta este tot ce am. Aceasta este doar o prezentare generală. Este imposibil să explic totul în doar câteva cuvinte, dar puteți citi un articol bun pe acest subiect aici:"
GO TO FULL VERSION