Daily și stand-up — ce este, reguli ale întâlnirii zilnice și beneficii

Ce este daily și stand-up?

Daily Standup (stand-up zilnic, daily) — întâlnirea scurtă a echipei Scrum, desfășurată la aceeași oră și în același loc în fiecare zi lucrătoare. Timebox — 15 minute. Se întâlnește sub diferite denumiri: Daily Scrum (în Scrum Guide), sincronizarea de dimineață, morning circle, daily. Scopul — sincronizarea echipei, identificarea blocajelor și ajustarea planurilor pentru zi. Daily nu este un raport pentru manager, ci un instrument de autoorganizare a echipei. Echipa decide cum să structureze întâlnirea, nu managerul.

Originea termenului „stand-up” — de la practica de a sta în picioare în timpul întâlnirii în sens literal: participanții se adună la tablă și nu se așează. Aceasta creează un sentiment de temporaritate — nimeni nu vrea să stea în picioare mai mult de 15 minute. Stand-upul fizic este încă utilizat în 60% dintre echipe (conform datelor Scrum.org 2025), restul au trecut la formatul remote prin Zoom, Slack Huddle sau Teams. În formatul remote este important să se păstreze disciplina: camere pornite, lipsa multitaskingului, pregătirea anticipată a răspunsurilor.

Scrum Guide 2025 definește Daily Scrum ca un eveniment pentru Developers (dezvoltatori). Product Owner și Scrum Master pot fi prezenți, dar nu sunt obligați. Dacă PO sau SM sunt prezenți — ei nu conduc întâlnirea. Echipa însăși alege structura: clasicele trei întrebări sau plimbarea pe tabla (board walk). Cheia: daily este despre inspectarea progresului către Sprint Goal, nu despre statusul fiecărui task. Dacă întâlnirea se transformă în enumerarea taskurilor de pe tablă — echipa a pierdut focusul pe Sprint Goal.

Trei întrebări ale Daily Standup

Întrebarea 1: „Ce am făcut ieri pentru atingerea Sprint Goal?” — lista scurtă a sarcinilor finalizate. Nu „am lucrat la APP-123”, ci „am terminat ecranul de login, PR trimis la review”. Formularea „pentru atingerea Sprint Goal” nu este întâmplătoare — leagă munca zilnică de obiectivul general al sprintului. Dacă dezvoltatorul nu vede legătura sarcinii sale cu Sprint Goal — este un semnal că sarcina nu este necesară în sprintul curent. În dezvoltarea mobilă, rezultatul de ieri nu este doar cod, ci și teste, documentație, configurare CI/CD.

Întrebarea 2: „Ce planific să fac astăzi pentru atingerea Sprint Goal?” — planul pentru ziua curentă. Nu mai mult de 2-3 puncte. Dezvoltatorul poate spune: „Astăzi termin ViewModel pentru ecranul de profil, scriu teste unitare, rulez build-ul pe un dispozitiv real”. Dacă planul coincide cu cel de „ieri” — este un semnal că sarcina este prea mare și trebuie descompusă. Regula celor două zile: dacă sarcina nu este finalizată în 2 zile de lucru — trebuie împărțită în subsarcini, altfel va rămâne în In Progress săptămâni întregi.

Întrebarea 3: „Ce blocaje îmi împiedică progresul?” — cea mai importantă întrebare. Blocajul este ceva ce dezvoltatorul nu poate rezolva singur: așteaptă review (dacă SLA-ul de review a expirat), emulatorul nu funcționează, API-ul nu este gata, are nevoie de acces la repository. Important: blocajul trebuie numit, dar nu rezolvat în cadrul daily. După întâlnire, dezvoltatorul și Scrum Master / managerul convin asupra soluționării blocajului. Conform datelor Scrum.org (2025), 70% din blocajele echipei mobile sunt legate de: așteptarea review-ului (30%), indisponibilitatea dispozitivelor de testare (20%), dependențe de backend (20%).

Cum să conducem corect stand-upul

Timp și loc. Daily se desfășoară la aceeași oră în fiecare zi — de obicei la începutul zilei de lucru (9:00-10:00). Pentru echipele distribuite se alege un moment confortabil pentru toate fusurile orare. Durata — strict 15 minute. Cronometrul — obligatoriu. Dacă echipa nu se încadrează — problema nu este în daily, ci în proces: fie sunt prea mulți participanți, fie sarcinile sunt discutate în loc să fie doar numite. Regula ping-pong: fiecare participant vorbește maximum 60 de secunde. După răspuns, transmite cuvântul următorului.

Formatul „plimbarea pe tablă” (Board Walk). Alternativă la cele trei întrebări: echipa mută pe rând sarcinile pe tabla Scrum, comentând modificările. Dezvoltatorul își ia taskul din To Do, îl mută în In Progress și spune: „Preiau APP-123 — ecranul de comandă, adaug câmpul de cod promoțional”. Board Walk oferă o înțelegere vizuală a progresului și dezvăluie taskurile „uitate” — cele care stau fără mișcare de 3+ zile. Board Walk este preferabil pentru echipele distribuite cu Jira/Linear — toți văd tabla, nu ascultă un monolog.

Pentru echipele remote: camerele obligatoriu pornite — conform datelor Microsoft Research (2025), camera pornită crește implicarea cu 40%. Utilizați ecranul partajat cu tabla de sarcini (Jira, Linear, Miro). Scrieți blocajele în chat — aceasta creează o înregistrare scrisă. Încurajați emojiurile de reacție (cu excepția comenzii utilizatorului — emojiurile nu sunt folosite) — degetul mare în sus pentru mesajul colegului. După daily — 2-3 minute pentru „parcare” (parking lot): subiectele care necesită discuții separate se înregistrează în lista întâlnirilor de follow-up. Abilitatea cheie a Scrum Master-ului: opri discuția în daily și transfera în parking lot.

Greșeli tipice la desfășurare

Greșeala 1: raport de status pentru manager. Dezvoltatorii citesc pe rând ce este scris în Jira, managerul pune întrebări de clarificare, întâlnirea durează 45 de minute. Soluție: reamintiți că daily este pentru echipă, nu pentru manager. Managerul poate afla statusul de pe tablă. Dacă managerul pune întrebări — transferați-le în 1:1. Echipa care a transformat daily-ul într-un raport pierde 2-3 ore pe săptămână pentru toți participanții. La 8 dezvoltatori, aceasta înseamnă 16-24 ore-om pe lună — pierderea unui sprint întreg pe an.

Greșeala 2: rezolvarea problemelor pe loc. Dezvoltatorul spune „Am o problemă cu GRPC — proiectul nu se compilează” și toată echipa discută 20 de minute soluțiile. Soluție: înregistrați blocajul în parking lot, continuați daily-ul. După întâlnire — adunați părțile interesate (dezvoltatorul + cineva care poate ajuta) pentru o discuție de 10 minute. Conform datelor Basecamp (Shape Up), doar 20% din problemele descoperite la daily necesită discuția întregii echipe. Restul se rezolvă de câțiva dezvoltatori în 10 minute.

Greșeala 3: întârzieri și absențe. Cineva vine la 5 minute după începere — trebuie să se repete. Soluție: stabilim regula „daily-ul începe la timp, întârziații nu intră” sau „întârziatul plătește o amendă” (cafea pentru echipă). Și mai dur: daily-ul are loc la aceeași oră, dacă cineva întârzie sistematic — este o problemă de disciplină, se rezolvă în 1:1. Daily-ul este sincronizarea zilei. Dacă dezvoltatorul a lipsit — nu este sincronizat și riscă să facă o muncă de care echipa nu are nevoie.

Greșeala 4: prea mulți participanți. Echipa de 15+ persoane, fiecare vorbește un minut — total 20+ minute. Soluție: împărțiți echipa în subgrupe pe feature-uri/module. Fiecare subgrupă își conduce propriul daily (5-7 persoane). Un reprezentant al subgrupei poate veni la stand-upul cross-echipă comun (dacă este necesară sincronizarea între echipe). Alternativă: stand-up asincron prin Slack/GeekBot, unde fiecare scrie ce a făcut/planifică/blocaje.

Stand-up asincron: alternative

Stand-upul asincron — un format în care participanții își scriu răspunsurile în chat (Slack, Telegram, Teams) sau printr-un bot specializat (GeekBot, Standuply, Status Hero) în locul unei întâlniri verbale. Potrivit pentru echipe distribuite cu diferență de fus orar de 3+ ore. Fiecare participant răspunde la aceleași trei întrebări până la o anumită oră (de exemplu, până la 11:00). Botul colectează răspunsurile și publică un rezumat pe canalul comun. Avantaje: flexibilitate, înregistrare scrisă, fără problema întârzierilor.

Dezavantajele formatului asincron: lipsa comunicării live — se pierd semnalele non-verbale, este mai dificil de identificat blocajele (dezvoltatorul poate să nu scrie despre problemă). Blocajul scris în chat poate rămâne neobservat până la sfârșitul zilei. Conform datelor GitLab (2025), 40% dintre echipele care au trecut la async standup s-au întors la cel verbal în 3 luni. Recomandare: utilizați un hibrid — 3 zile stand-up verbal (lu, mi, vi), 2 zile asincron (ma, jo). Sau: stand-up verbal de 1-2 ori pe săptămână, în celelalte zile — asincron.

Instrumente pentru stand-up asincron: GeekBot (Slack) — pune trei întrebări, publică rezumatul; Standuply — cu integrare Jira, urmărire automată; Status Hero — colectează statusurile și generează raport săptămânal pentru management. Alegerea instrumentului depinde de cultura echipei: în startup-uri este suficient un bot în Slack, în enterprise poate fi necesar Standuply cu integrare în procesele corporative. Regulă importantă: indiferent de format, răspunsurile trebuie să fie vizibile întregii echipe, nu doar managerului. Transparența — valoarea cheie a Agile.

Particularități ale daily pentru echipa mobilă

Echipa mobilă la daily se confruntă cu blocaje specifice. Principalele: compilarea proiectului în CI (Gradle build poate dura 20+ minute — dacă se strică, dezvoltatorul pierde o oră pentru diagnosticare), așteptarea TestFlight / Firebase App Distribution (publicarea build-ului pentru testeri durează 30-60 de minute), probleme cu emulatoarele și simulatoarele (Android Emulator necesită KVM/HAXM, iOS Simulator doar pe Mac). Daily-ul echipei mobile trebuie să includă o verificare rapidă a statusului build-ului: „Build-ul se compilează? Toate testele sunt verzi?”

Pentru proiecte cross-platform (Flutter, React Native) daily poate include o întrebare despre starea codului partajat. Dacă doi dezvoltatori modifică simultan același fișier Dart și unul își îmbină modificările — cel de-al doilea va avea conflicte. Sfat: utilizați Board Walk pe tabla cu împărțire pe platforme (Android / iOS / Shared). Aceasta ajută să vedeți cine lucrează unde și dacă modificările se suprapun. Pentru proiecte cu Flutter — tabla cu coloanele Platform Channel, BLoC/Cubit, UI, Tests.

Pregătirea pentru release — un alt punct specific dezvoltării mobile în daily. Cu 3-5 zile înainte de release adăugați întrebarea: „Build-ul este gata de release? Toate metadatele (icoane, capturi de ecran, descriere) sunt actualizate?” Aceasta previne situația în care dezvoltatorii termină codul în ziua release-ului, iar compilarea și publicarea durează încă 3-4 ore. Tracker de release — tablă separată cu checklist: actualizare versionCode/versionName, verificare ProGuard, semnare AAB, încărcare în consola dezvoltatorului, release notes.