ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 140
Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 135
Abonament PDF

Metodologia Agile – Eșuează devreme. Eșuează des

Cristina Temian
Project Delivery Manager @ Accesa



Larisa Iordache
Project Delivery Lead @ Accesa



MANAGEMENT


Cine ar fi crezut că o excursie în munții din Utah ar duce la așa o schimbare în privința modului în care privim munca? În februarie 2001, un grup de șaptesprezece oameni s-au întâlnit cu scopul de a petrece timp în aer liber și de a se bucura de natură, retrăgându-se într-o cabană la munte. Ei au făcut însă mai mult decât atât, pentru că - imediat după călătorie - întreaga lume urma să citească Manifestul Agile (Agile Software Development Manifesto).

Metodologia Agile este folosită în multe zone de dezvoltare, dar a devenit mai populară în industria software. Deși sună surprinzător, Agile este folosit și în Construcții (mai mult în etapa de planificare - Design și pre-construcție), Inginerie, Industria Farmaceutică și Aerospațială.

Cum eșuează proiectele și de ce unele au succes?

În pofida popularității și a vastei adoptări, există companii care au eșuat să încorporeze metodologia Agile. Unele organizații preferă să adopte Agile și Scrum, pentru că acestea sunt populare, însă omit să aibă în vedere faptul că metodologia nu se pliază pe orice tip de proiect sau serviciu. Agile nu este o rezolvare rapidă pentru orice nu funcționează în prezent. Deși o parte semnificativă din organizații au integrat Agile, doar 18% au dus implementarea la bun sfârșit în toate echipele. Menționăm în acest sens, State of Agile Survey in Software Development, un studiu realizat de Digital.ai și publicat ca 16th Annual State of Agile Report, care reflectă situația abordării tehnicilor Agile în anul 2022, la nivelul a 3220 de businessuri și profesioniști din industria IT).

Fig.1. Adoptarea Agile, link sursă: State of Agile 2022: Things You Need to Know (knowledgehut.com)

Agile poate fi dificil de implementat, dacă sunt necesare foarte multe schimbări la nivel cultural. Este, de asemenea, un proces empiric, ceea ce înseamnă că uneori trebuie să experimentăm diferite moduri de lucru, să ajustăm în timp și să aplicăm corecții. (O idee cheie din spatele Agile este "Eșuează devreme. Eșuează des.") Din acest motiv, studiile de caz pe care urmează să le prezentăm în acest articol, ar trebui interpretate drept oportunități de învățare în loc de eșecuri.

Dr. Jeff Sutherland, unul din creatorii cadrului Scrum Agile, a prezentat într-unul din podcasturile sale (Openview - unde activează ca Agile coach) un exemplu de eșec în proiect - healthcare.gov. Healthcare.gov este un website condus de Guvernul Statelor Unite, numit și "Schimb de Servicii Medicale" unde, o dată pe an, după ce consumatorul introduce câteva informații demografice pe site, poate să compare opțiunile de servicii medicale pentru care este eligibil și poate să achiziționeze unul dintre ele. Cu excepția ferestrei anuale în care oamenii se pot înrola, Healthcare.gov operează mai mult cu scop informativ. Este, de asemenea, și un instrument prin care consumatorul își poate gestiona planurile existente.

Fig. 2. Maturitatea Agile, link sursă: State of Agile 2022: Things You Need to Know (knowledgehut.com)

După mulți ani în care s-a încercat lansarea site-ului, în urma a doar șase zile de testare, proiectul s-a lansat în octombrie 2013, și doar în acel moment problemele au ieșit la suprafață. Proiectul nu a respectat principiul cu numărul 2 din Agile Manifesto: Produsul să fie funcțional. Cererea ridicată a dus la un site nefuncțional în două ore de la lansare: patru milioane de utilizatori au vizitat site-ul, însă doar șase au reușit să își creeze un cont. Mai multe probleme au apărut ca urmare a faptului că partea de design nu era completă și pentru că utilizatorii din toate Statele au avut acces de la început. Echipa care a făcut ca site-ul să funcționeze în zece săptămâni a fost numită Obama Trauma pe Time.com. Factorii cheie pentru War Zone creată de Obama Trauma pentru a rezolva problemele au fost:

Fig. 3. Provocări în adoptarea Agile, link sursă: State of Agile 2022: Things You Need to Know (knowledgehut.com)

În această perioadă, site-ul nu a mai fost funcțional de încă două ori. Din nou, renumita provocare în project management a reieșit la suprafață: a aloca 10 oameni să lucreze la o problemă care unui programator i-ar lua 10 zile să o repare, nu înseamnă că proiectul se va termina într-o zi. În final, site-ul a început să funcționeze între Ziua Recunoștinței și Crăciun, iar de la mijlocul lunii februarie 2014, raportul care prezenta utilizarea site-ului în perioada lunii ianuarie, reflecta faptul că site-ul a procesat 1.9 milioane de înrolări.

Exemple personale

Suntem o echipă formată din șase membri (Senior Backend Developer, Senior Quality Assurance Engineer, Junior Frontend Developer, Junior Quality Assurance Engineer, Proxy Product Owner, Scrum Master) și alți trei membri din partea clientului (doi programatori Backend și un programator Frontend), având misiunea de a dezvolta o aplicație funcțională până la finalul lunii octombrie 2023, folosind metodologia SAFe. Vom împărtăși în ce fel a fost implementat modelul și valorile Agile, precum și eficiența integrării lor.

1. Oamenii și interacțiunile primează în fața proceselor și instrumentelor

Procedurile și aplicațiile ajutătoare încetinesc câteodată echipa pentru că documentația nu este tot timpul actualizată, iar atât echipamentul furnizat din partea clientului, cât și ecosistemul de software impus cauzează întârzieri în cadrul proiectului. Pe parcursul retrospectivelor, echipa a împărtășit părerea lor legată de aceste impedimente și s-a propus alocarea unui inginer DevOps, căutând încă soluții pentru documentația neactualizată.

2. Produsul funcțional primează în fața documentației cuprinzătoare

Documentația este foarte importantă și condiționează lansarea produsului pe diferite medii, Product Ownerul având nevoie de trei săptămâni pentru a pregăti pachetul care urmează să fie publicat. Am început să filtrăm cerințele esențiale în avans (cele legate de validarea legală și Compliance fiind considerate esențiale).

3. Colaborarea cu clientul primează în fața negocierilor de contract

Clientul este foarte deschis la părerea membrilor echipei privind modelul de lucru și utilizabilitatea produselor pe care le dezvoltă. E foarte important pentru noi să înțelegem "de ce" avem anumite termene limită și cum se schimbă prioritățile în cadrul echipei. Rolurile pentru menținerea relației cu clientul și cele de management al livrării lucrează îndeaproape pentru a întreține colaborarea și pentru a naviga în cadrul conflictelor, luând în considerare nevoile clientului, ale echipei precum și calitatea produsului.

4. Abilitatea de a răspunde la schimbare primează în fața urmăririi unui plan

Răspundem schimbării într-un mod eficient, însă avem în continuare nevoie de cerințe clare și complete pentru a putea dezvolta un produs funcțional. Numeroasele schimbări în structura echipei, roluri și priorități pot cauza foarte multă confuzie.

Vom parcurge în rândurile următoare încă un exemplu, concentrat pe scenariul de tip buget-timp-conținut fixe, unde vom putea observa cu ușurință diferențele dintre practică și teorie când vine vorba despre implementarea metodologiei Agile.

Echipa urmează structura de organizare Agile (Programatori Backend, Frontend și Testeri, Product Owner Senior, Scrum Master). Urmând modelul de mai sus, vom continua să prezentăm felul în care ne raportăm la valorile Agile în cadrul proiectului.

1. Oamenii și interacțiunile primează în fața proceselor și instrumentelor

Considerând faptul că la începutul anului clientul a primit un buget fix, primul lucru pe care l-am avut în vedere a fost o întâlnire introductivă, pentru a vedea ce poate fi acoperit cu respectivul buget. În cadrul acestei întâlniri, am discutat despre cele mai importante cerințe care necesitau implementare, despre așteptările în ceea ce privește conținutul proiectului și timpul necesar, precum și procesele implicate: aveam de gând să utilizăm o modalitate nouă de a oferi estimări, la nivel de funcționalitate. Având un buget fix, clientul nostru a fost constrâns să planifice foarte detaliat ce avea să livreze pe parcursul anului. Putem vedea cu ușurință că, până acum, atenția a fost pe procese mai mult decât pe oameni și interacțiunea dintre ei. Pentru a readuce concentrarea în punctul de interes, ne-am asigurat că echipa rămâne conectată la client prin oferirea constantă de feedback. Comunicarea este foarte importantă în acest tip de situații și credem că alinierea constantă poate ajuta la îmbunătățirea și schimbarea stării de fapt. Am oferit feedback prin ședințele de retrospectivă, ședințe săptămânale de status, precum și interacțiuni ad-hoc.

2. Produsul funcțional primează în fața documentației cuprinzătoare

Valoarea aceasta este pusă în aplicare: atât echipa, cât și clientul se concentrează pe a avea un Produs Minim Viabil (MVP), iar discuțiile sunt întotdeauna orientate în direcția aplicației funcționale, și nu a documentației. După cum putem vedea, chiar dacă adoptarea Agile în adevăratul sens al cuvântului este dificilă, există aspecte care nu pot fi ignorate și care sunt asimilate de echipă independent de relația buget-timp-conținut.

3. Colaborarea cu clientul primează în fața negocierilor de contract

Contractul nu a fost adus pe masa de discuții, iar de fiecare dată când ne întâlnim cu provocări ne amintim cât de mult contează colaborarea dintre noi și feedbackul continuu. Există cazuri în care timpul limită, conținutul proiectului și bugetul sunt condiționate de contract. Acestea sunt dictate de relația clientului cu sponsorul. Contează foarte mult ca acestea să fie transparente și reiterate în cadrul echipei.

Cu toate acestea, ajută foarte mult atunci când echipa este conștientă de astfel de restricții și se colaborează permanent pentru a ajunge la cel mai bun rezultat posibil.

4. Abilitatea de a răspunde la schimbare primează în fața urmăririi unui plan

În condițiile menționate - timp-buget-conținut fixe - este destul de dificil să fim flexibili în privința schimbării. Mai mult decât atât, planul este cerut în mod special, necesar și actualizat la aceleași intervale. Cum răspundem, totuși, la schimbare în condițiile acestea? Adăugăm mai jos câteva din soluțiile propuse și puse în aplicare de noi:

Când termenul limită nu este flexibil, estimările nu mai sunt privite ca estimări - sunt văzute ca angajamente. Având această informație, am ajustat planul, incluzând timp adițional pentru cerințe neluate în considerare, pentru documentație, pentru rezolvarea de probleme de funcționalitate etc. În acest fel, chiar dacă va fi adusă în discuție extinderea scopului în mijlocul implementării, aceasta va fi acoperită de timpul adițional luat în considerare anterior.

Pe lângă aceasta, este foarte important să avem un Product Owner, care controlează extinderile de context și este responsabil de ele. În momentul în care apare o cerință nouă, este responsabilitatea Product Ownerului să le amintească tuturor celor din echipă faptul că interesul ar trebui să fie pe cerințele deja convenite și planificate inițial. De asemenea, acesta este responsabil cu actualizarea de Backlog, conform Ghidului Scrum.

O altă soluție implementată de noi a fost comunicarea constantă cu clientul. În cadrul echipei, ne asigurăm că persoana de contact este continuu informată cu privire la impedimente, iar atunci când e cazul, căutăm soluții împreună. Spuneam că planul proiectului este constant actualizat, pentru a reflecta realist ce capacitate a rămas disponibilă - acest aspect ne ajută să explorăm moduri de a păstra neschimbat bugetul și calitatea livrată.

Situația ideală ar fi să schimbăm tipul contractului din Time and Material în Fixed Price, având în vedere condițiile contractuale. Chiar dacă variabilele timp-buget-conținut ar rămâne fixe, am putea mult mai ușor să urmăm intern principiile Agile - în cadrul echipei - până când funcționalitățile ar fi implementate. Din păcate, această schimbare nu se poate realiza pe termen scurt, drept urmare vom explora în continuare și alte soluții.

În graficul de mai jos, vă prezentăm o serie de indicatori care pot să reflecte eficiența adoptării metodologiei Agile.

Fig. 4. Succesul Agile - metrice, link sursă: State of Agile 2022: Things You Need to Know (knowledgehut.com)

Vă invităm acum să reflectați la exemplele noastre și să vă gândiți la alte soluții optime pentru situațiile în care ne dorim să lucrăm Agile. Lista de răspunsuri nu are o finalitate, deoarece nu există o rețetă secretă pentru a depăși aceste provocări. Cu toate acestea, discutarea și împărtășirea de soluții ajută întotdeauna.

Bibliografie:

  1. https://earthweb.com/agile-statistics/

  2. https://medium.com/swlh/agile-failure-patterns-in-organizations-2-0-b198ade309b0

  3. https://www.linkedin.com/pulse/sentinelsaved-orhan-sancakli-m-sc-eng-/

  4. https://effectiveagile.com/agile/overview-of-the-us-dept-of-defense-agile-case-study/

  5. https://digital.ai/catalyst-blog/case-study-of-a-difficult-federal-government-scrum-project-fbi-sentinel/

  6. https://brianwernham.wordpress.com/2012/05/31/fbi-sentinel-programme-saved-by-agile-2/

  7. https://learning.oreilly.com/library/view/the-project-managers/9781118991046/28_chapter18.html#s2h424

  8. https://openviewpartners.com/blog/agile-done-right-agile-gone-wrong/

NUMĂRUL 138 - Maps & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO