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ă.
Î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:
Ședințe Daily - la începutul și la finalul zilei (45 min. fiecare);
O linie telefonică deschisă 24/24 pentru a primi feedback direct de la utilizatorii conectați în fiecare locație;
Ședințele și War Zone erau doar pentru a rezolva probleme;
Înlăturarea micro-managementului;
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.
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.
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ă.
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).
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.
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.
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.
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.
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.
Î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.
https://medium.com/swlh/agile-failure-patterns-in-organizations-2-0-b198ade309b0
https://www.linkedin.com/pulse/sentinelsaved-orhan-sancakli-m-sc-eng-/
https://effectiveagile.com/agile/overview-of-the-us-dept-of-defense-agile-case-study/
https://brianwernham.wordpress.com/2012/05/31/fbi-sentinel-programme-saved-by-agile-2/
