Optimizarea Lansărilor Scrum: O Abordare Practică
În mod tradițional, livrarea în scrum este percepută ca o acțiune ce are loc imediat după încheierea unui sprint, în special după o demonstrație reușită în fața clientului. Totuși, această așteptare ridică întrebări, mai ales când analizăm activitățile preliminare necesare.
Există numeroase sarcini esențiale ce trebuie îndeplinite, fie înaintea, fie în paralel cu lansarea efectivă:
- Finalizarea tuturor task-urilor din sprint, unele poate mai devreme, dar majoritatea, spre sfârșitul acestuia, sau chiar după demonstrație.
- Realizarea testelor amănunțite pentru a asigura calitatea codului înainte de lansare.
- Identificarea și rezolvarea promptă a eventualelor erori.
- Verificarea și actualizarea conductei de implementare, asigurându-ne de fiabilitatea acesteia.
- Rularea conductei în toate mediile relevante pentru a le alinia cu ultimele modificări de cod și date.
- Pregătirea notelor de lansare și comunicarea cu clientul privind impactul și modificările implementate.
- Sincronizarea cu alte echipe scrum paralele, dacă este cazul, pentru a asigura lansarea simultană a conținutului dependent și evitarea disfuncționalităților.
- Gestionarea tuturor ceremoniilor scrum, atât pentru sprintul curent, cât și pentru planificarea celui următor, inclusiv sesiunile de rafinare a cerințelor.
Având în vedere un sprint de două săptămâni, activitățile de lansare necesită timp și resurse semnificative. Cu toate acestea, timpul este limitat, deoarece imediat după încheierea unui sprint, începe un nou ciclu.
Așadar, mai este lansarea automată după fiecare sprint o așteptare realistă?
Procesarea Conținutului pentru Lansare
În teorie, dacă toate procesele sprintului ar fi automatizate, am putea implementa direct în producție la sfârșitul fiecărui sprint. Însă, în practică, o astfel de eficiență este greu de atins. Majoritatea echipelor scrum nu reușesc să atingă un asemenea nivel de maturitate. Procesele de lansare sunt adesea laborioase, extinzându-se în următorul sprint, afectând atât conținutul, cât și productivitatea. Lansarea devine astfel o sursă de stres pentru echipă.
Obiectivul meu a fost să identific un scenariu optim pentru a gestiona eficient lansările.
Soluția a fost să transformăm fiecare al doilea sprint într-un „Sprint de Lansare”. Iată ce presupune această abordare.
Ramură Separată de Cod pentru Următoarea Lansare
Această strategie se bazează pe gestionarea ramurilor separate în depozitul GIT. Există mai multe modalități de a aborda această problemă, toate cu potențial de succes. Pentru simplitate, voi prezenta o abordare de bază și impactul acesteia.
Pentru a reduce cât mai mult impactul asupra activităților de dezvoltare în curs, este esențial să separăm conținutul pentru următoarea lansare într-o ramură distinctă, denumită „Ramura de Lansare”. Această abordare adresează următoarele:
- Echipa de dezvoltare poate continua activitatea și implementarea noilor cerințe în ramura principală, fără întreruperi.
- Se elimină riscul ca modificări neașteptate de cod să afecteze conținutul destinat lansării.
- Testele pot fi efectuate într-un mediu izolat, unde se aplică doar modificările necesare pentru corectarea erorilor.
- Deoarece conducta de lansare va implementa doar conținutul din ramura dedicată, avem un control clar și complet asupra modificărilor ce vor ajunge în producție. Se previne astfel posibilitatea ca o modificare neașteptată să afecteze codul deja testat.
Astfel, conținutul viitoarei versiuni rămâne separat și are timp să atingă o stare stabilă, pregătită de lansare.
Programarea Lansărilor pentru Repetabilitate
Am renunțat la ideea lansării după fiecare sprint. Era evident că această abordare era greu de susținut fără efecte secundare negative, cum ar fi:
- Influențarea conținutului de dezvoltare al următorului sprint.
- Dificultatea de a stabiliza conținutul lansării.
- Imposibilitatea de a îndeplini toate activitățile de testare necesare.
Scopul a devenit executarea lansării la sfârșitul fiecărui al doilea sprint. Această abordare implică:
- O lansare va include conținut din ultimele două sprinturi finalizate. Deoarece lansarea are loc în timpul sprintului curent, acesta nu este inclus în ediție.
- Se alocă un întreg sprint pentru finalizarea testelor și a remedierilor necesare.
- Responsabilul lansării are suficient timp pentru a pregăti informațiile relevante (cazuri de test, note de lansare) în timpul sprintului de non-lansare. Aceștia pot lucra autonom, permițând restului echipei să se concentreze pe dezvoltarea noilor cerințe.
- În cazul identificării unor erori, responsabilul lansării poate colabora rapid cu dezvoltatorul implicat pentru a le remedia. O parte din capacitatea echipei ar trebui alocată pentru astfel de situații.
Utilizatorii nu vor primi cel mai recent conținut în ultima versiune, dar în timp, acest lucru va deveni mai puțin relevant. Cu fiecare lansare, vor primi conținutul a două sprinturi.
Această abordare reprezintă un compromis echilibrat între livrarea rapidă și respectarea ritmului scrum, fără perturbări majore.
Executarea Implementării Lansării
Odată finalizate activitățile de testare, corectare a erorilor și pregătire a conductei, execuția procesului de lansare în producție devine o sarcină simplă.
Fiindcă implementarea se face dintr-o ramură separată, procesul poate fi aproape invizibil. Nimeni nu trebuie să fie conștient de el. Dacă acesta este cazul, implementarea lansării este optimă.
Pentru aceasta, este necesară o conductă DevOps automată robustă, folosită nu doar pentru mediul de producție, ci și pentru cele inferioare (dezvoltare, sandbox, test, asigurarea calității, etc.). Astfel, implementarea soluțiilor în fiecare mediu devine o operațiune simplă.
Lansarea nu ar trebui să fie o sursă de stres. Ci, mai degrabă, un proces lin, imperceptibil. Dacă nimeni nu observă că a avut loc, acesta este un indicator al unei lansări reușite.
Reintegrarea Ramurii de Lansare în Ramura de Dezvoltare
Ramura de lansare conține modificări specifice, apărute în timpul perioadei de testare. Acestea trebuie reintegrate în ramura principală pentru a fi incluse în următoarele lansări.
În acest moment, ramura de lansare servește ca rezervă de cod de producție. Dacă o problemă urgentă trebuie rezolvată rapid după lansare, se poate folosi această ramură. Ea reprezintă o copie exactă a codului din producție, fără noutăți nelansate.
După începerea noii perioade de testare, ramura de lansare anterioară poate fi ștearsă și înlocuită cu o alta, creată ca o copie a ramurii de dezvoltare.
Stabilirea Lansărilor Regulate
Avem acum un proces robust pentru gestionarea lansărilor. Mai este necesară doar menținerea regularității, în acest caz, după fiecare al doilea sprint.
Menținerea regularității facilitează procesul, deoarece:
- Lansările nu vor conține un volum mare de cod nou. Creșterea este mică și considerată stabilă.
- Volumul redus de conținut implică mai puține eforturi de testare și mai puține comunicări cu părțile interesate.
- Echipa se va obișnui cu acest ciclu și va deveni o parte naturală a fluxului de lucru.
- Mediile de dezvoltare și testare vor primi actualizări de date în mod regulat. Acesta va fi un proces normal, integrat în rutină, care va influența pozitiv atmosfera echipei.
Concluzie
Acest capitol încheie seria despre ciclul de viață scrum și prezintă o metodă testată în practică.
Echipele agile deseori încep cu abordări eronate, dar evoluează și își îmbunătățesc procesele. Această serie poate oferi un ajutor valoros în acest proces de îmbunătățire.
Nici această abordare nu este perfectă. Pot apărea probleme, dar echipele trebuie să încerce să le rezolve, să îmbunătățească procesele și să renunțe la ceea ce nu funcționează.
Această abordare a dovedit că se poate face o schimbare. De la sprinturi haotice la o livrare stabilă, cu lansări regulate și fiabile, fără a necesita metodologii complicate, ci doar reguli simple și dorința de a urma planul.