Ce este metodologia AGILE. Cele 12 principii AGILE explicate

AGILE, pentru cine nu știe, e cea mai en vogue, pe trend, metodologie utilizată în industria IT. Astfel că, la interviuri pentru poziții în cadrul echipelor de dezvoltare, testare, product management, business analysis, business intelligence, web design, o să fiți întrebați dacă ați lucrat cu AGILE. Acum, în funcție de tipul job-ului, cunoștințele variază. Astfel că, dacă aplici ca Product Owner sau Product Manager sau Delivery Manager-trebuie să știi mult mai multe lucruri de aplicare a metodologiei AGILE decât dacă aplici ca programator, tester, UX specialist etc. Adică una e să conduci un proiect, alta e să lucrezi la dezvoltarea lui.  

(sursa foto: Scrum/Agile via Shutterstock.com)

Istoria AGILE

În iarna lui 2001, 17 minți luminate într-ale dezvoltării de soluții software s-au întâlnit să skieze la un resort din Utah (US). Și după o zi de rupt picioarele pe pârtie, seara s-au întâlnit la un vin sec și vechi să-și rupă mințile. După ce au terminat de povestit despre amante, copii, neveste, golf club-uri, au ajuns inevitabil la muncă. Așa au început plângerile: ba ca se întârzie cu proiectele, ba ca nu se respectă timeline-ul, ba că nu pot introduce schimbări în proiectul deja aprobat. Astfel că, de la plângeri și de la vinul bun, au răsărit ca soarele de iarnă într-o dimineață geroasă și ideile de abordare a unei noi metodologii. Așa s-a născut ceea ce azi încă a rămas în istorie: AGILE Manifesto. 

Ce inseamna AGILE

AGILE înseamnă un set de tehnici care au la bază 12 principii. Pentru că mințile luminate atunci când se întâlnesc, în reguli noi se poticnesc, au zis să ia modelul Moise și să vina și ei nu cu 10 porunci, ci cu 12 principii, principii care au sperat ei, și au avut dreptate, vor revoluționa metodologiile de project management. (hooray!). 

12 principii AGILE

Și pentru că știu că nici poruncile n-ar fi fost înțelese dacă nu ar fi fost explicate și ras-explicate, o să le luăm pe fiecare în parte să vedem ce vor să spună de fapt. Toate sună fancy, dar dincolo de avalanșa de trendiness, au o aplicabilitate pe care adepții, pardon, entuziaștii AGILE e musai s-o înțeleagă. 

1. Satisfy the customer through early and continuous delivery

Nu degeaba acest principiu e primul. Pentru că în orice companie clientul trebuie satisfăcut prin toate mijloacele (ortodoxe, că nu degeaba am menționat de Moise mai sus). Și când zic client, mă refer atât la clienți externi cât și la internal stakeholders (product managers, delivery managers, sales management, marketing managers, support managers-adică bossii). Ei vin cu cerințele: ce vor, cu timpul: când vor să fie gata și mai ales cu de ce-ul: la ce vor folosi produsul/funcționalitățile.  

Și pentru că unele proiecte sunt complexe și implementarea lor poate dura până la 6 luni-1 an, uneori mai mult, e necesar ca aceste cerințe să fie sparte în task-uri, task-urile să fie integrate în sprint-uri, sprint-urile integrate în iterații-în funcție de ce e mandatory pentru crearea unui MVP (minimal viable poduct). Astfel că, la sfârșitul unui sprint să se poată face un demo către client. Dacă nu-i convine ce vede, echipele de development se vor mobiliza și vor adapta schimbările. (O vorba celebra printre AGIListi este “S-a schimbat schimbarea!”). Gândiți-vă dacă s-ar stabili de la început tot proiectul, durată lui 1 an și în timpul asta clientul să nu poată veni cu niciun feedback iar la final…să nu fie exact ce și-a dorit. FAIL. Big, big FAIL.  

2. Welcome changing requirements, even in late development

Din categoria s-a schimbat schimbarea, întotdeauna pe parcursul procesului de dezvoltare al proiectului, vor apărea, uneori chiar și într-un sprint (3 săptămâni) câteva schimbări. De asta echipa trebuie să fie agilă, Scrum Master-ul să fie unul care să știe să manageruiasca conflictele, la fel și Product Manager-ul, pentru a evita presiunea prea mare care va cădea inevitabil în cârca programatorilor. Un alt plus al schimbării constante este și avantajul competitiv. Poți schimba din mers strategia, funcționalitățile, să fii printre primii care livrează pe piață soluții unice. Așa, dacă apari după 1 an, după ce consumatorii deja au beneficiat de soluția respectivă de la alt furnizor, riști să cazi în redundanță și să nu mai fii un competitor relevant. 

3. Deliver working software frequently

Principiul 3 este strâns legat de 2, adică atunci când echipele de dezvoltare și QA fac demo-urile de produs, de obicei la final de sprint, ceea ce arată trebuie să funcționeze. Cu o zi înainte de demo, se instalează pe serverul de test sau de stage, build-ul la care s-a lucrat și care s-a testat, și a doua zi se prezintă clientului și, de preferat, să fie funcțional, altfel…înseamnă că ședințele de stand-up zilnice nu au avut nicio utilitate. (o să povestim despre ele detaliat într-un articol viitor). 

4. Business people and developers work together daily

Toată lumea lucrează cu toată lumea. Programatorii cu business analystii, business analystii cu product managerii, product managerii comunică direct cu stakeholderii implicați și tot așa. E o familie mare și numeroasă care comunică și iar comunică despre proiectul la care lucrează. Se clarifică cerințe, se pun întrebări, se vine cu soluții. All the goody and jucy things. 

5. Build projects around motivated individuals

Indivizi motivați = fără presiune, fără deadline-uri imposibil de atins, suportul tehnologic de care au nevoie și cel mai important este să li se aloce dreptul de self-organizing-organizarea task-urilor în interiorul echipelor, fără intervenția externă a managementului. De asta n-o să vedem team leaderi în echipele care funcționează după standardele AGILE, și o să avem scrum-master care organizează task-urile alături de programatori. 

6. Convey information via face-to-face conversation

Fără mail-uri lungi, (NO TLDR!!) fără proceduri alambicate, AGILE promovează interacțiunile face-to-face, sau acolo unde se lucrează în remote teams, prin video-conferințe. Scopul este ca întrebările să fie adresate direct și răspunsurile să fie cât mai concise, fără loc de interpretări ulterioare. Și cum poți obține cel mai bine elocvența în clarificările de cerințe altfel decât prin comunicarea verbală? 

7. Working software is the primary measure of progress

Orice se livrează trebuie să fie funcțional. Adică nu prezinți clientui un mock-up, ci funcționalitatea cu care acesta se poate juca în mediul de test până se va ajunge la implementarea live. 

8. Maintain a contant pace indefinitely

Un mediu plăcut de lucru, o balanța optimistă între viața personală și job, armonie și înțelegere între memebrii echipelor, fără tensiuni și orgolii expandate inutil. All is good and give peace a chance. 

9. Give continuous attention to technical exellence

Să meargă, să meargă, dar să meargă bine. Nu cu opriri, frâne neașteptate, poticniri și scârțâieli. Ori facem o treabă bună, ori n-o mai facem. De aceea foarte importante sunt și ședințele de retrospectivă când fiecare povestește la ce a lucrat, ce a aflat nou, de ce impedimente s-a lovit, etc. Stiu, provocarea vine atunci când functionalitatile trebuie livrate și repede și foarte bune. Dar asta e un subiect pentru altădată. 

10. Simplify: maximize the amount of work not done

Aici se aplică principiul PARETO: 80/20. Ce presupune el? Pe scurt că 80% din rezultatele obținute vin din 20% efort depus. Cheia e să te educi să te concentrezi pe partea cea mai productivă a celor 20%, parte care în final produce cele mai bune rezultate din cele 80%. Astfel că, poți optimiza timpul și efortul celor 20% în a produce cei mai buni 80%. Adică, timp bine optimizat, cod bun livrat. Yey.

11. Teams self-organize

Așa cum ziceam, membrii echipelor se organizează singuri, își împart task-urile, fără să fie nevoia de intervenția unui lider impus. 

12. Teams retrospect and tune behaviour.

Retrospectivă proiectului. Se poate face la final de sprint sau de iterație pentru a împărtăși din know-how, pentru transfer of knowledge și induction către juniori sau către cei care nu au avut o vizibilitate de ansamblu asupra proiectului.  

Rezumand:

Related Post

One Thought on Ce este metodologia AGILE. Cele 12 principii AGILE explicate

  1. punctul 8: e vorba de pace (ritm) si nu de peace (pace, înțelegere). Adică ceva de genul: tine un ritm constant pe o perioada indefinită. 🙂 

Leave a Comment