Daily at stand-up — ano ito, mga patakaran ng araw-araw na pagpupulong at benepisyo

Ano ang daily at stand-up?

Daily Standup (araw-araw na stand-up, daily) — maikling pagpupulong ng Scrum team, na isinasagawa sa parehong oras at lugar bawat araw ng trabaho. Timebox — 15 minuto. Iba't ibang tawag: Daily Scrum (sa Scrum Guide), umagang pag-sync, morning circle, daily. Layunin — pag-sync ng koponan, pagtukoy ng mga blocker, at pag-aayos ng mga plano para sa araw. Ang daily ay hindi report para sa manager, kundi isang kasangkapan para sa self-organisasyon ng koponan. Ang koponan ang nagdedesisyon kung paano istruktura ang pagpupulong, hindi ang manager.

Ang pinagmulan ng terminong “stand-up” — mula sa praktika ng pagtayo sa panahon ng pagpupulong sa literal na kahulugan: ang mga kalahok ay nagtitipon sa pisara at hindi umuupo. Ito ay lumilikha ng pakiramdam ng pansamantala — walang gustong tumayo nang higit sa 15 minuto. Pisikal na stand-up ay ginagamit pa rin sa 60% ng mga team (ayon sa datos ng Scrum.org 2025), ang iba ay lumipat sa remote format sa pamamagitan ng Zoom, Slack Huddle o Teams. Sa remote format, mahalaga ang disiplina: naka-on ang camera, walang multitasking, handa nang isipan ang mga sagot nang maaga.

Ang Scrum Guide 2025 ay tumutukoy sa Daily Scrum bilang isang kaganapan para sa Developers (mga developer). Ang Product Owner at Scrum Master ay maaaring dumalo, ngunit hindi obligado. Kung dumalo ang PO o SM — hindi nila pinamumunuan ang pagpupulong. Ang koponan mismo ang pumipili ng istruktura: klasikong tatlong tanong o board walk. Susi: ang daily ay tungkol sa pag-inspeksyon ng progreso patungo sa Sprint Goal, hindi tungkol sa status ng bawat task. Kung ang pagpupulong ay naging paglista ng mga task sa pisara — nawala ang pokus ng koponan sa Sprint Goal.

Tatlong tanong ng Daily Standup

Tanong 1: “Ano ang ginawa ko kahapon upang makamit ang Sprint Goal?” — maikling listahan ng mga natapos na gawain. Hindi “nagtrabaho ako sa APP-123”, kundi “natapos ang login screen, ipinadala ang PR para sa review”. Ang pahayag na “upang makamit ang Sprint Goal” ay hindi aksidente — iniuugnay nito ang araw-araw na trabaho sa pangkalahatang layunin ng sprint. Kung ang developer ay hindi nakakakita ng koneksyon ng kanyang gawain sa Sprint Goal — ito ay senyales na ang gawain ay hindi kailangan sa kasalukuyang sprint. Sa mobile development, ang resulta kahapon ay hindi lamang code, kundi pati mga test, dokumentasyon, configuration ng CI/CD.

Tanong 2: “Ano ang plano kong gawin ngayon upang makamit ang Sprint Goal?” — plano para sa kasalukuyang araw. Hindi hihigit sa 2-3 puntos. Maaaring sabihin ng developer: “Ngayon tatapusin ko ang ViewModel para sa profile screen, susulat ng unit test, tatakbo ang build sa totoong device”. Kung ang plano ay katulad ng “kahapon” — ito ay senyales na ang gawain ay masyadong malaki at kailangang i-decompose. Patakaran ng dalawang araw: kung ang gawain ay hindi natapos sa loob ng 2 araw ng trabaho — dapat itong hatiin sa mga subtask, kung hindi man ito maiipit sa In Progress nang ilang linggo.

Tanong 3: “Anong mga blocker ang humahadlang sa aking pag-unlad?” — pinakamahalagang tanong. Ang blocker ay isang bagay na hindi kayang lutasin ng developer nang mag-isa: naghihintay ng review (kung ang SLA ng review ay lampas na), hindi gumagana ang emulator, hindi handa ang API, kailangan ng access sa repository. Mahalaga: dapat banggitin ang blocker, ngunit hindi lutasin sa daily. Pagkatapos ng pagpupulong, ang developer at Scrum Master / manager ay nag-uusap tungkol sa solusyon ng blocker. Ayon sa Scrum.org (2025), 70% ng mga blocker ng mobile team ay nauugnay sa: paghihintay ng review (30%), hindi pagkakaroon ng test device (20%), dependencies sa backend (20%).

Paano wastong magsagawa ng stand-up

Oras at lugar. Ang daily ay isinasagawa sa parehong oras araw-araw — karaniwang sa simula ng araw ng trabaho (9:00-10:00). Para sa mga distributed team, pinipili ang oras na komportable para sa lahat ng time zone. Tagal — mahigpit na 15 minuto. Timer — sapilitan. Kung hindi kasya ang team — hindi sa daily ang problema, kundi sa proseso: alinman sa sobrang dami ng kalahok, o ang mga gawain ay pinag-uusapan sa halip na banggitin lamang. Patakaran ng ping-pong: bawat kalahok ay nagsasalita nang hindi hihigit sa 60 segundo. Pagkatapos ng sagot, ipinapasa ang salita sa susunod.

Format na “board walk”. Alternatibo sa tatlong tanong: ang koponan ay salit-salit na naglilipat ng mga gawain sa Scrum board, nagkokomento ng mga pagbabago. Kinukuha ng developer ang kanyang task mula sa To Do, inililipat sa In Progress at sinasabi: “Kukunin ko ang APP-123 — order screen, magdadagdag ng promo code field”. Ang Board Walk ay nagbibigay ng visual na pag-unawa sa progreso at naglalantad ng mga “kinalimutang” task — ang mga hindi gumagalaw nang 3+ araw. Mas gusto ang Board Walk para sa mga distributed team na may Jira/Linear — lahat ay nakakakita ng board, hindi nakikinig sa monologo.

Para sa mga remote team: dapat naka-on ang camera — ayon sa Microsoft Research (2025), ang naka-on na camera ay nagpapataas ng pakikilahok ng 40%. Gumamit ng shared screen na may task board (Jira, Linear, Miro). Isulat ang mga blocker sa chat — ito ay lumilikha ng written record. Hikayatin ang reaction emoji (maliban sa utos ng user — hindi ginagamit ang emoji) — thumbs up sa mensahe ng kasamahan. Pagkatapos ng daily — 2-3 minuto para sa “parking lot”: ang mga paksang nangangailangan ng hiwalay na talakayan ay itinatala sa listahan ng follow-up na pagpupulong. Susing kasanayan ng Scrum Master: itigil ang talakayan sa daily at ilipat ito sa parking lot.

Mga karaniwang pagkakamali sa pagsasagawa

Pagkakamali 1: status report para sa manager. Salit-salit na binabasa ng mga developer ang nakasulat sa Jira, nagtatanong ang manager, ang pagpupulong ay tumatagal ng 45 minuto. Solusyon: paalalahanan na ang daily ay para sa koponan, hindi para sa manager. Maaaring malaman ng manager ang status mula sa board. Kung nagtatanong ang manager — ilipat sa 1:1. Ang koponan na ginawang report ang daily ay nawawalan ng 2-3 oras bawat linggo para sa lahat ng kalahok. Sa 8 developer, ito ay 16-24 oras-tao bawat buwan — pagkawala ng isang buong sprint bawat taon.

Pagkakamali 2: paglutas ng problema sa lugar. Sinasabi ng developer “May bug ako sa GRPC — hindi nagbu-build ang project” at ang buong koponan ay nag-uusap ng 20 minuto tungkol sa mga solusyon. Solusyon: itala ang blocker sa parking lot, ipagpatuloy ang daily. Pagkatapos ng pagpupulong — tipunin ang mga interesado (developer + isang taong makakatulong) para sa 10 minutong talakayan. Ayon sa Basecamp (Shape Up), 20% lamang ng mga problemang natuklasan sa daily ang nangangailangan ng talakayan ng buong koponan. Ang natitira ay nilulutas ng ilang developer sa loob ng 10 minuto.

Pagkakamali 3: pagka-late at pagliban. May dumating 5 minuto pagkatapos magsimula — kailangang ulitin. Solusyon: magtakda ng patakaran “nagsisimula sa oras ang daily, hindi pumapasok ang mga huli” o “ang huli ay nagbabayad ng multa” (kape para sa koponan). Mas mahigpit: ang daily ay isinasagawa sa parehong oras, kung may sistematikong nahuhuli — ito ay isyu ng disiplina, nilulutas sa 1:1. Ang daily ay pag-sync ng araw. Kung ang developer ay lumiban — hindi siya naka-sync at may panganib na gumawa ng trabahong hindi kailangan ng koponan.

Pagkakamali 4: sobrang daming kalahok. Team na 15+ tao, bawat isa ay nagsasalita ng isang minuto — kabuuang 20+ minuto. Solusyon: hatiin ang koponan sa mga subgroup ayon sa feature/module. Bawat subgroup ay nagsasagawa ng sarili nitong daily (5-7 tao). Isang kinatawan mula sa subgroup ay maaaring dumalo sa karaniwang cross-team stand-up (kung kailangan ang pag-sync sa pagitan ng mga team). Alternatibo: asynchronous stand-up sa pamamagitan ng Slack/GeekBot, kung saan isusulat ng bawat isa ang kanilang ginawa/plano/mga blocker.

Asynchronous stand-up: mga alternatibo

Asynchronous stand-up — format kung saan isinusulat ng mga kalahok ang kanilang mga sagot sa chat (Slack, Telegram, Teams) o sa pamamagitan ng specialized bot (GeekBot, Standuply, Status Hero) sa halip na oral na pagpupulong. Angkop para sa mga distributed team na may pagkakaiba sa time zone na 3+ oras. Bawat kalahok ay sumasagot sa parehong tatlong tanong hanggang sa takdang oras (halimbawa, hanggang 11:00). Kinokolekta ng bot ang mga sagot at naglalathala ng digest sa pangkalahatang channel. Bentahe: flexibility, written record, walang problema sa pagka-late.

Disbentahe ng asynchronous format: walang live na komunikasyon — nawawala ang non-verbal na senyales, mas mahirap tukuyin ang mga blocker (maaaring hindi magsulat ang developer tungkol sa problema). Ang blocker na isinulat sa chat ay maaaring hindi mapansin hanggang sa katapusan ng araw. Ayon sa GitLab (2025), 40% ng mga team na lumipat sa async stand-up ay bumalik sa oral sa loob ng 3 buwan. Rekomendasyon: gumamit ng hybrid — 3 araw oral stand-up (Lun, Miy, Biy), 2 araw asynchronous (Mar, Huw). O: oral stand-up 1-2 beses sa isang linggo, sa ibang araw — asynchronous.

Mga tool para sa asynchronous stand-up: GeekBot (Slack) — nagtatanong ng tatlong tanong, naglalathala ng summary; Standuply — may integration sa Jira, awtomatikong pag-track; Status Hero — kumokolekta ng mga status at bumubuo ng lingguhang report para sa management. Ang pagpili ng tool ay nakadepende sa kultura ng team: sa startups, sapat na ang bot sa Slack, sa enterprise maaaring kailanganin ang Standuply na may integration sa corporate processes. Mahalagang patakaran: anuman ang format, ang mga sagot ay dapat makita ng buong koponan, hindi lamang ng manager. Transparency — pangunahing halaga ng Agile.

Mga katangian ng daily para sa mobile team

Mobile team sa daily ay nahaharap sa mga specific na blocker. Pangunahin: pagbuo ng project sa CI (Gradle build ay maaaring tumagal ng 20+ minuto — kung sira, ang developer ay nawawalan ng isang oras sa pag-diagnose), paghihintay sa TestFlight / Firebase App Distribution (pag-publish ng build para sa mga tester ay tumatagal ng 30-60 minuto), problema sa mga emulator at simulator (Android Emulator ay nangangailangan ng KVM/HAXM, iOS Simulator ay sa Mac lamang). Daily ng mobile team ay dapat magsama ng mabilis na check ng build status: “Nagbu-build ba? Lahat ng test ay berde?”

Para sa cross-platform projects (Flutter, React Native) ang daily ay maaaring magsama ng tanong tungkol sa estado ng shared code. Kung dalawang developer ang sabay na nag-eedit ng parehong Dart file at isa sa kanila ay nag-merge ng mga pagbabago — ang pangalawa ay magkakaroon ng conflicts. Payo: gumamit ng Board Walk sa board na may hati ayon sa platform (Android / iOS / Shared). Ito ay tumutulong upang makita kung sino ang nagtatrabaho saan at kung ang mga pagbabago ay nag-o-overlap. Para sa Flutter projects — board na may columns na Platform Channel, BLoC/Cubit, UI, Tests.

Kahandaan para sa release — isa pang specific na punto para sa mobile development sa daily. 3-5 araw bago ang release, magdagdag ng tanong: “Handa na ba ang build para sa release? Lahat ng metadata (icons, screenshots, description) ay na-update na?” Ito ay pumipigil sa sitwasyon kung saan tinatapos ng mga developer ang code sa araw ng release, at ang pagbuo at pag-publish ay tumatagal pa ng 3-4 na oras. Release tracker — hiwalay na board na may checklist: pag-update ng versionCode/versionName, pagsuri ng ProGuard, pag-sign ng AAB, pag-upload sa developer console, release notes.