Sprint în dezvoltarea mobilă: esența, durata și planificarea

Ce este un sprint în dezvoltare?

Sprint — este un interval de timp (timebox) de durată fixă, la sfârșitul căruia echipa livrează un increment de produs gata de utilizare. Conceptul de sprint este baza Scrum, dar este folosit și în alte cadre Agile. În dezvoltarea mobilă, incrementul este un build al aplicației care poate fi instalat pe un dispozitiv, testat și arătat părților interesate. Sprintul nu poate fi prelungit — dacă sarcinile nu sunt finalizate, se transferă în sprintul următor.

Caracteristica cheie a sprintului este durata fixă. Echipa nu modifică obiectivul sprintului după aprobare. Acest lucru oferă predictibilitate: părțile interesate știu când vor primi rezultatul. În cadrul sprintului, echipa decide singură cum să distribuie munca. Scrum Master protejează echipa de interferențele externe — sarcinile noi nu se adaugă în sprintul curent. Conform Scrum Guide 2025, acesta este singurul mod de a menține un ritm de dezvoltare sustenabil (sustainable pace).

Sprintul constă din patru evenimente obligatorii: Sprint Planning (planificare), Daily Scrum (sincronizare zilnică), Sprint Review (demonstrarea rezultatului), Sprint Retrospective (analiza procesului). Între ele — munca principală: executarea sarcinilor, testarea, code review. Durata fiecărui eveniment este proporțională cu lungimea sprintului: pentru un sprint de 2 săptămâni, Planning — 4 ore, Review — 2 ore, Retro — 1.5 ore, Daily — 15 minute. În total, ritualurile ocupă aproximativ 8 ore pe sprint — 10% din timpul de lucru al echipei.

Ritualurile Scrum ale sprintului

Ritualurile Scrum (ceremonii/evenimente) — întâlniri structurate ale echipei în cadrul sprintului. Sprint Planning — la început, Daily Scrum — în fiecare zi, Sprint Review și Retrospective — la sfârșit. Toate evenimentele au timebox (limită de timp). Scrum Master asigură respectarea timebox-ului și a concentrării. La fiecare ritual participă întreaga echipă Scrum: Product Owner, Scrum Master, dezvoltatori. Excepție — Daily Scrum (participă doar dezvoltatorii, PO și SM — opțional).

Legătura ritualurilor cu etapele sprintului: Planning stabilește direcția (ce și cum facem), Daily sincronizează (cine ce face, care sunt blocajele), Review arată rezultatul (ce s-a făcut, ce nu), Retrospective îmbunătățește procesul (cum să facem următorul sprint mai bine). Omisiunea retrospectivei — cea mai frecventă greșeală a echipelor: când termenele presează, sacrifică tocmai Retro. Aceasta duce la stagnarea proceselor și repetarea acelorași greșeli. Cercetarea Scrum.org (2025) arată: echipele care fac Retro la fiecare 2 săptămâni își îmbunătățesc velocity cu 35% mai rapid.

Sprint Planning: planificarea iterației

Sprint Planning — întâlnirea echipei la începutul sprintului, în care se stabilește ce va fi făcut și cum. Product Owner prezintă sarcinile prioritare din Product Backlog. Echipa evaluează capacitatea (capacity) — timpul disponibil ținând cont de concedii, ședințe, datorie tehnică — și selectează sarcinile pe care le poate executa în sprint. Rezultatul Planning — Sprint Goal (obiectivul sprintului) și Sprint Backlog (lista de sarcini). Sprint Goal se formulează ca o propoziție scurtă: „Implementarea ecranului de comandă și integrarea plății prin card”.

Velocity — viteza echipei, măsurată în story point-uri pe sprint. Media ultimelor 3-5 sprinturi. Conform Scrum.org (2025), o echipă de 5 dezvoltatori mobili (3 Android + 2 iOS) are un velocity de 25-40 SP pentru un sprint de 2 săptămâni. Planning folosește velocity ca limită superioară — se iau cu 10-15% mai puține sarcini pentru cele neprevăzute (code review, incidente, ajutor altor echipe). Capacity vs Velocity: capacity înseamnă „ore-om”, velocity înseamnă „story point-uri”. Capacity ia în calcul concediile, concediile medicale, ședințele. Rata tipică de pierdere (loss rate) — 25-30% din timpul de lucru se duce pe activități non-cod.

Planificarea se împarte în două părți: „ce” (PO prezintă sarcinile, echipa clarifică) — 2 ore, și „cum” (echipa decompose și estimează) — 2 ore. Pentru proiectele mobile, în partea „cum” se discută: compatibilitatea cu versiunile Android/iOS, necesitatea feature flag, impactul asupra dimensiunii APK/IPA, permisiunile noi. Tehnica Planning Poker este folosită pentru estimare: fiecare dezvoltator își dă estimarea în story point-uri (1, 2, 3, 5, 8, 13). Diferența > 2 unități — discută motivele. Asta dezvăluie riscurile ascunse în faza de planificare, nu la mijlocul sprintului.

Executarea sprintului: Daily Standup și monitorizare

Daily Scrum (Standup) — întâlnirea zilnică de 15 minute pentru sincronizarea echipei. Fiecare participant răspunde la trei întrebări: „Ce am făcut ieri?”, „Ce plănuiesc azi?”, „Care sunt blocajele?”. Daily nu este un raport de status pentru manager, ci un instrument de autoorganizare a echipei. Dacă în Daily se descoperă că doi dezvoltatori lucrează la aceeași sarcină — acesta este un semnal de reorganizare. Important: Daily nu rezolvă problemele, ci le identifică — pentru rezolvare se convoacă o întâlnire separată după Daily.

Scrum Board (tabla sprintului) — vizualizarea Sprint Backlog. Coloane: To Do / In Progress / In Review / Done. Fiecare sarcină se deplasează pe tablă. Burndown Chart — graficul muncii rămase pe zilele sprintului. Burndown-ul ideal — o linie dreaptă de la total SP la 0. Burndown-ul real — un grafic în trepte care ține cont de închiderea sarcinilor. Burndown-ul coborât (sub linia ideală) — întârziem. Semnale de problemă: dacă la jumătatea sprintului s-au executat mai puțin de 30% din sarcini — este nevoie de corecție. Poate că nu s-au luat în calcul riscurile sau sarcinile sunt supraestimate.

Pentru dezvoltarea mobilă, monitorizarea sprintului este influențată de factori specifici: timpul de build (construirea unui proiect Android în CI poate dura 30+ minute), așteptarea moderării App Store / Google Play (dacă trebuie livrat un build testerilor prin TestFlight), compatibilitatea cu diferite dispozitive (testarea pe 10+ modele ia timp). Sfat: alocați 1 zi tampon la sfârșitul sprintului pentru testarea finală și construirea versiunii de release. Aceasta reduce riscul de sprint neterminat cu 40% conform Mind the Product (2025).

Sprint Review și Retrospective

Sprint Review — demonstrarea incrementului părților interesate. Echipa arată un build funcțional al aplicației, nu slide-uri. Durata — 2 ore pentru un sprint de 2 săptămâni. Product Owner verifică conformitatea cu Acceptance Criteria. Părțile interesate oferă feedback care poate influența Product Backlog. Review nu este un raport, ci un dialog: părțile interesate pot pune întrebări și propune modificări. Regula cheie: Sprint Review este despre produs, nu despre proces. Arătăm ce s-a realizat, nu cum am făcut.

Sprint Retrospective — întâlnirea internă a echipei pentru analiza sprintului trecut. Format: Start Doing (ce să începem să facem), Stop Doing (ce să oprim), Continue Doing (ce să continuăm). Durata — 1.5 ore pentru un sprint de 2 săptămâni. Retrospective este un spațiu sigur pentru discutarea problemelor. Regulă: în Retro nu se discută detaliile tehnice (pentru asta există întâlniri tehnice). Doar procesul, comunicarea, instrumentele, cultura. Scrum Master facilitează întâlnirea și se asigură că fiecare participant se exprimă.

Rezultatul Retrospective — 1-3 îmbunătățiri pentru sprintul următor. Dacă echipa a identificat problema „Code review prea lung” — action item: „Stabiliți SLA pentru review — 4 ore. Dacă review-ul nu este făcut la timp — dezvoltatorul reamintește pe Slack”. Action Items trebuie să fie concrete, măsurabile și atribuite unei persoane specifice. Conform Atlassian (2025), echipele care își execută action items-urile din Retro își îmbunătățesc velocity cu 15-25% în 3-4 sprinturi. Cele care nu le execută — bat pasul pe loc.

Cum să alegem durata sprintului

2 săptămâni — standardul pentru dezvoltarea mobilă. Echilibrul optim între predictibilitate și flexibilitate. Ajunge: să planifici, să implementezi 3-5 funcționalități medii, să testezi, să arăți rezultatul. 1 săptămână — pentru echipe cu maturitate ridicată a proceselor și CI/CD. Necesită decizii rapide, birocrație minimă. Potrivit pentru startup-uri în fază incipientă, când trebuie să experimentezi rapid. Dezavantaj: supraîncărcare mare pe ritualuri (în fiecare săptămână Planning + Review + Retro = 7.5 ore).

3-4 săptămâni — pentru proiecte complexe cu integrare hardware (wearables, IoT, dispozitive BLE), moderare lungă a magazinelor sau migrări mari (de exemplu, trecerea de la RxJava la Coroutines). Sprinturile lungi oferă mai mult timp pentru testare, dar cresc riscul „efectului de cascadă” — echipa pierde flexibilitatea Agile. Recomandarea Scrum Guide: nu depășiți 1 lună. Dacă sprintul este mai lung — la Review va fi prea mult context, părțile interesate nu vor putea oferi feedback de calitate.

Probleme tipice ale sprinturilor

Problema 1: Scope Creep. La mijlocul sprintului, Product Owner adaugă o sarcină nouă „urgentă și importantă”. Echipa este de acord — și sprintul eșuează. Solutie: Sprint Goal — contract. Orice modificare necesită revizuirea Sprint Goal, iar acest lucru este posibil doar în cazuri de urgență. Sarcina nouă merge în Product Backlog și în sprintul următor. Dacă sarcina este cu adevărat critică — vechiul Sprint Goal este anulat, sprintul este replanificat, dar aceasta este o excepție, nu o practică. Frecvența scope creep mai mare de 1 dată la 3 sprinturi — semn de Product Owner slab.

Problema 2: Sarcini neterminate. La sfârșitul sprintului, 50% din sarcini sunt în In Progress, 20% în Review, doar 30% Done. Cauze: supraestimarea capacității, subestimarea complexității, bug-uri neplanificate. Solutie: analizați cauza la Retro. Dacă nu reușiți sistematic — nu creșteți numărul de sarcini în Planning, ci reduceți-l. Echipele care iau cu 20% mai puține sarcini arată un procent mai mare de finalizare (80%+ față de 50-60%). Checklist pentru Planning: pentru fiecare sarcină, verificați Acceptance Criteria, Definition of Ready și dependențele de alte sarcini.

Problema 3: Retro formal. Echipa face Retro de ochii lumii — 15 minute, fraze generale, fără action items. Solutie: schimbați formatul fiecărui Retro. Metode: Sailboat (ce încetinește, ce accelerează), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Atribuiți action items cu termene și responsabili. La începutul următorului Retro, verificați executarea action items-urilor anterioare. Conform Atlassian (2025), echipele care folosesc diferite formate de Retro generează cu 50% mai multe perspective utile.