Daily és stand-up — mi ez, a napi megbeszélés szabályai és haszna

Mi az a daily és stand-up?

Daily Standup (napi stand-up, daily) — a Scrum csapat rövid megbeszélése, amely minden munkanapon azonos időben és helyen kerül megrendezésre. Timebox — 15 perc. Különböző néven ismert: Daily Scrum (a Scrum Guide-ban), reggeli szinkronizáció, morning circle, daily. Cél — a csapat szinkronizálása, az akadályok azonosítása és a napi tervek módosítása. A daily nem jelentés a menedzsernek, hanem a csapat önszerveződésének eszköze. A csapat dönti el, hogyan strukturálja a megbeszélést, nem a menedzser.

A “stand-up” kifejezés eredete — a szó szerinti állás gyakorlatából: a résztvevők a táblánál gyűlnek össze és nem ülnek le. Ez átmenetiség érzetet kelt — senki sem akar 15 percnél tovább állni. Fizikai stand-up még mindig a csapatok 60%-ában használatos (a Scrum.org 2025-ös adatai szerint), a többiek áttértek a távoli formátumra Zoom, Slack Huddle vagy Teams segítségével. A távoli formátumban fontos a fegyelem: bekapcsolt kamerák, multitasking kerülése, a válaszok előzetes átgondolása.

A Scrum Guide 2025 a Daily Scrum-ot a Developers (fejlesztők) eseményeként határozza meg. A Product Owner és a Scrum Master jelen lehet, de nem kötelező. Ha PO vagy SM jelen van — nem irányítják a megbeszélést. A csapat maga választja meg a struktúrát: klasszikus három kérdés vagy board walk. Kulcsfontosságú: a daily a Sprint Goal felé tett előrehaladás ellenőrzéséről szól, nem pedig az egyes taskok státuszáról. Ha a megbeszélés a táblán lévő taskok felsorolásává válik — a csapat elvesztette a fókuszt a Sprint Goal-on.

A Daily Standup három kérdése

1. kérdés: “Mit tettem tegnap a Sprint Goal elérése érdekében?” — az elvégzett feladatok rövid listája. Nem “az APP-123-on dolgoztam”, hanem “befejeztem a bejelentkezési képernyőt, a PR elküldve review-ra”. A “a Sprint Goal elérése érdekében” megfogalmazás nem véletlen — összekapcsolja a napi munkát a sprint általános céljával. Ha a fejlesztő nem látja kapcsolatot a feladata és a Sprint Goal között — ez jelzés, hogy a feladat nem szükséges az aktuális sprintben. A mobilfejlesztésben a tegnapi eredmény nem csak kód, hanem tesztek, dokumentáció, CI/CD konfiguráció is.

2. kérdés: “Mit tervezek tenni ma a Sprint Goal elérése érdekében?” — a mai nap terve. Legfeljebb 2-3 pont. A fejlesztő mondhatja: “Ma befejezem a ViewModel-t a profilképernyőhöz, megírom az unit teszteket, lefuttatom a build-et egy valódi eszközön”. Ha a terv megegyezik a “tegnapival” — ez jelzés, hogy a feladat túl nagy és dekomponálásra szorul. Kétnapos szabály: ha egy feladat 2 munkanap alatt nem készül el — fel kell bontani alfaeladatokra, különben hetekig In Progress-ben ragad.

3. kérdés: “Milyen akadályok gátolják a haladásomat?” — a legfontosabb kérdés. Az akadály olyasmi, amit a fejlesztő nem tud egyedül megoldani: review-ra vár (ha a review SLA lejárt), nem működik az emulátor, nem kész az API, hozzáférés kell a repóhoz. Fontos: az akadályt meg kell nevezni, de nem megoldani a daily-n. A megbeszélés után a fejlesztő és a Scrum Master / menedzser megegyezik az akadály megoldásáról. A Scrum.org (2025) adatai szerint a mobil csapat akadályainak 70%-a a következőkhöz kapcsolódik: review-ra várás (30%), teszteszközök elérhetetlensége (20%), backend függőségek (20%).

Hogyan tartsuk helyesen a stand-upot

Idő és hely. A daily minden nap azonos időben kerül megrendezésre — általában a munkanap elején (9:00-10:00). Elosztott csapatok esetén olyan időpontot választanak, amely minden időzónában kényelmes. Időtartam — szigorúan 15 perc. Időzítő — kötelező. Ha a csapat nem fér bele — a probléma nem a daily-ben, hanem a folyamatban van: vagy túl sok a résztvevő, vagy a feladatokat megbeszélik ahelyett, hogy csak megneveznék. Ping-pong szabály: minden résztvevő legfeljebb 60 másodpercig beszél. A válasz után átadja a szót a következőnek.

A “tábla körbejárás” formátum (Board Walk). Alternatíva a három kérdésre: a csapat sorra mozgatja a feladatokat a Scrum táblán, kommentálva a változásokat. A fejlesztő elveszi a taskját a To Do-ból, áthelyezi In Progress-be és mondja: “Elveszem az APP-123-at — rendelési képernyő, hozzáadok egy promóciós kód mezőt”. A Board Walk vizuális megértést ad az előrehaladásról és felfedi az “elfelejtett” taskokat — azokat, amelyek 3+ napja mozdulatlanok. A Board Walk előnyösebb az elosztott, Jira/Linear-t használó csapatok számára — mindenki látja a táblát, nem monológot hallgat.

Távoli csapatok esetén: kötelező a bekapcsolt kamera — a Microsoft Research (2025) adatai szerint a bekapcsolt kamera 40%-kal növeli a bevonódást. Használjon megosztott képernyőt a feladattáblával (Jira, Linear, Miro). Írja az akadályokat a chat-be — ez írásos feljegyzést hoz létre. Ösztönözze a reakció emojikat (kivéve a felhasználói parancsot — az emojik nem használatosak) — hüvelykujj fel a kolléga üzenetére. A daily után — 2-3 perc a “parking lot” számára: a külön megbeszélést igénylő témák feljegyzésre kerülnek a follow-up találkozók listájába. A Scrum Master kulcskészsége: megállítani a vitát a daily-n és áthelyezni a parking lot-ba.

Tipikus hibák a lebonyolítás során

1. hiba: státuszjelentés a menedzsernek. A fejlesztők sorra felolvassák, mi van a Jirába írva, a menedzser pontosító kérdéseket tesz fel, a megbeszélés 45 percig tart. Megoldás: emlékeztessük, hogy a daily a csapaté, nem a menedzseré. A menedzser a tábláról is megtudhatja a státuszt. Ha a menedzser kérdez — irányítsuk át 1:1-re. Az a csapat, amelyik jelentéssé változtatta a daily-t, heti 2-3 órát veszít minden résztvevő esetében. 8 fejlesztőnél ez havi 16-24 munkaóra — egy egész sprint elvesztése évente.

2. hiba: problémák helyben megoldása. A fejlesztő azt mondja: “Bugom van a GRPC-vel — nem épül a projekt”, és az egész csapat 20 percig vitatja a megoldásokat. Megoldás: rögzítsük az akadályt a parking lot-ba, folytassuk a daily-t. A megbeszélés után — gyűjtsük össze az érintetteket (fejlesztő + aki segíteni tud) egy 10 perces megbeszélésre. A Basecamp (Shape Up) adatai szerint a daily-n felfedezett problémák csak 20%-a igényli az egész csapat vitáját. A többit néhány fejlesztő 10 perc alatt megoldja.

3. hiba: késések és hiányzások. Valaki 5 perccel a kezdés után érkezik — ismételni kell. Megoldás: állítsuk fel a szabályt “a daily időben kezdődik, a késők nem lépnek be” vagy “a késő büntetést fizet” (kávét a csapatnak). Még szigorúbb: a daily azonos időben zajlik, ha valaki rendszeresen késik — ez a fegyelme kérdése, 1:1-en oldandó meg. A daily a nap szinkronizációja. Ha a fejlesztő kihagyta — nincs szinkronban, és fennáll a veszélye, hogy olyan munkát végez, amire a csapatnak nincs szüksége.

4. hiba: túl sok résztvevő. 15+ fős csapat, mindenki egy percet beszél — összesen 20+ perc. Megoldás: osszuk fel a csapatot funkció/modul szerinti alcsoportokra. Minden alcsoport tartja a saját daily-jét (5-7 fő). Egy képviselő az alcsoportból elmehet a közös cross-team stand-upra (ha szükséges a csapatok közötti szinkronizáció). Alternatíva: aszinkron stand-up Slack/GeekBot segítségével, ahol mindenki leírja, mit tett/tervez/akadályokat.

Aszinkron stand-up: alternatívák

Aszinkron stand-up — olyan formátum, ahol a résztvevők a válaszaikat chat-ben (Slack, Telegram, Teams) vagy speciális boton (GeekBot, Standuply, Status Hero) keresztül írják meg a szóbeli megbeszélés helyett. Alkalmas elosztott csapatok számára 3+ óra időkülönbséggel. Minden résztvevő ugyanarra a három kérdésre válaszol egy meghatározott időig (pl. 11:00-ig). A bot összegyűjti a válaszokat és közzéteszi az összefoglalót a közös csatornán. Előnyök: rugalmasság, írásos feljegyzés, nincs késési probléma.

Az aszinkron formátum hátrányai: nincs élő kommunikáció — elvesznek a nonverbális jelek, nehezebb az akadályok azonosítása (a fejlesztő lehet, hogy nem ír a problémáról). A chat-ben írt akadály észrevétlen maradhat a nap végéig. A GitLab (2025) adatai szerint az async stand-upra áttért csapatok 40%-a 3 hónapon belül visszatért a szóbeli formához. Ajánlás: használjunk hibridet — 3 nap szóbeli stand-up (h, sze, p), 2 nap aszinkron (k, cs). Vagy: szóbeli stand-up heti 1-2 alkalommal, a többi napon — aszinkron.

Eszközök aszinkron stand-up-hoz: GeekBot (Slack) — felteszi a három kérdést, közzéteszi az összefoglalót; Standuply — Jira integrációval, automatikus követéssel; Status Hero — összegyűjti a státuszokat és heti jelentést készít a menedzsment számára. Az eszköz kiválasztása a csapat kultúrájától függ: startupokban elég egy bot a Slack-ben, enterprise-ban szükség lehet a Standuply-ra vállalati folyamatokba integrálva. Fontos szabály: formátumtól függetlenül a válaszoknak az egész csapat számára láthatónak kell lenniük, nem csak a menedzsernek. Az átláthatóság az Agile alapértéke.

A daily sajátosságai a mobil csapat számára

A mobil csapat a daily-n specifikus akadályokkal szembesül. Főbbek: a projekt build-je CI-ben (Gradle build 20+ percig is tarthat — ha elromlik, a fejlesztő egy órát veszít a diagnosztizálással), várakozás a TestFlight / Firebase App Distribution-re (a build közzététele a tesztelők számára 30-60 percet vesz igénybe), problémák az emulátorokkal és szimulátorokkal (Android Emulator KVM/HAXM-et igényel, iOS Simulator csak Mac-en). A mobil csapat daily-jének tartalmaznia kell a build státusz gyors ellenőrzését: “Buildel a projekt? Minden teszt zöld?”

Cross-platform projektekhez (Flutter, React Native) a daily tartalmazhat egy kérdést a megosztott kód állapotáról. Ha két fejlesztő egyszerre szerkeszti ugyanazt a Dart fájlt, és az egyik egyesíti a változtatásokat — a másiknak konfliktusai lesznek. Tanács: használjon Board Walk-ot platformok szerint osztott táblán (Android / iOS / Shared). Ez segít látni, ki hol dolgozik, és hogy a változtatások átfedik-e egymást. Flutter projektekhez — Platform Channel, BLoC/Cubit, UI, Tests oszlopokkal rendelkező tábla.

Release-készség — egy másik, mobilfejlesztésre jellemző pont a daily-n. 3-5 nappal a release előtt adja hozzá a kérdést: “Kész a build a release-hez? Minden metaadat (ikonok, képernyőképek, leírás) frissítve?” Ez megelőzi azt a helyzetet, amikor a fejlesztők a release napján fejezik be a kódot, és a buildelés és közzététel további 3-4 órát vesz igénybe. Release tracker — külön tábla checklist-el: versionCode/versionName frissítése, ProGuard ellenőrzés, AAB aláírás, feltöltés a fejlesztői konzolba, release notes.