Sprint sa mobile development: esensya, tagal, at pagpaplano

Ano ang sprint sa development?

Sprint — isang time interval (timebox) na may nakapirming tagal, sa dulo kung saan ang team ay naghahatid ng handa nang gamiting product increment. Ang konsepto ng sprint ay pundasyon ng Scrum, ngunit ginagamit din sa ibang Agile frameworks. Sa mobile development, ang increment ay isang build ng app na maaaring i-install sa device, subukan, at ipakita sa mga stakeholder. Ang sprint ay hindi maaaring pahabain — kung hindi natapos ang mga gawain, ililipat ang mga ito sa susunod na sprint.

Ang pangunahing katangian ng sprint ay nakapirming tagal. Hindi binabago ng team ang layunin ng sprint pagkatapos ng pag-apruba. Nagbibigay ito ng predictability: alam ng mga stakeholder kung kailan nila matatanggap ang resulta. Sa loob ng sprint, ang team mismo ang nagpapasya kung paano ipamahagi ang trabaho. Pinoprotektahan ng Scrum Master ang team mula sa panlabas na panghihimasok — hindi idinaragdag ang mga bagong gawain sa kasalukuyang sprint. Ayon sa Scrum Guide 2025, ito ang tanging paraan upang mapanatili ang sustainable pace ng development.

Ang sprint ay binubuo ng apat na sapilitang kaganapan: Sprint Planning (pagpaplano), Daily Scrum (araw-araw na pagsabay-sabay), Sprint Review (pagpapakita ng resulta), Sprint Retrospective (pagsusuri ng proseso). Sa pagitan — ang pangunahing trabaho: pagpapatupad ng mga gawain, pagsubok, code review. Ang tagal ng bawat kaganapan ay proporsyonal sa haba ng sprint: para sa 2-linggong sprint, Planning — 4 na oras, Review — 2 oras, Retro — 1.5 oras, Daily — 15 minuto. Sa kabuuan, ang mga ritwal ay tumatagal ng humigit-kumulang 8 oras bawat sprint — 10% ng oras ng trabaho ng team.

Mga ritwal ng Scrum sa sprint

Mga ritwal ng Scrum (ceremonies/kaganapan) — mga nakaayos na pulong ng team sa loob ng sprint. Sprint Planning — sa simula, Daily Scrum — araw-araw, Sprint Review at Retrospective — sa dulo. Lahat ng kaganapan ay may timebox (limitasyon sa oras). Tinitiyak ng Scrum Master ang pagsunod sa timebox at pokus. Bawat ritwal ay dinadaluhan ng buong Scrum team: Product Owner, Scrum Master, mga developer. Pagbubukod — Daily Scrum (mga developer lamang ang lumalahok, PO at SM — opsyonal).

Koneksyon ng mga ritwal sa mga yugto ng sprint: Planning ay nagbibigay ng direksyon (ano at paano natin gagawin), Daily ay nagsasabay-sabay (sino ang gumagawa ng ano, anong mga blocker), Review ay nagpapakita ng resulta (ano ang nagawa, ano ang hindi), Retrospective ay nagpapabuti ng proseso (kung paano gagawing mas mahusay ang susunod na sprint). Paglaktaw sa retrospective — ang pinakakaraniwang pagkakamali ng mga team: kapag nagmamadali ang mga deadline, ang Retro ang isinasakripisyo. Ito ay humahantong sa pagtigil ng pag-unlad ng proseso at pag-uulit ng parehong pagkakamali. Ipinapakita ng pag-aaral ng Scrum.org (2025): ang mga team na nagsasagawa ng Retro bawat 2 linggo ay 35% mas mabilis na nagpapabuti ng velocity.

Sprint Planning: pagpaplano ng pag-ulit

Sprint Planning — pulong ng team sa simula ng sprint kung saan tinutukoy kung ano ang gagawin at paano. Ipinakita ng Product Owner ang mga prayoridad na gawain mula sa Product Backlog. Tinatasa ng team ang capacity (available time na isinasaalang-alang ang bakasyon, pulong, technical debt) at pumipili ng mga gawaing kayang tapusin sa sprint. Resulta ng Planning — Sprint Goal (layunin ng sprint) at Sprint Backlog (listahan ng mga gawain). Ang Sprint Goal ay binuo bilang maikling pangungusap: “Ipatupad ang order screen at payment integration”.

Velocity — bilis ng team, sinusukat sa story points bawat sprint. Average ng huling 3-5 sprint. Ayon sa Scrum.org (2025), ang team ng 5 mobile developer (3 Android + 2 iOS) ay may velocity na 25-40 SP para sa 2-linggong sprint. Ginagamit ng Planning ang velocity bilang pang-itaas na hangganan — kumukuha sila ng 10-15% mas kaunti para sa hindi inaasahang gawain (code review, insidente, tulong sa ibang team). Capacity vs Velocity: capacity ay “tao-oras”, velocity ay “story points”. Isinasaalang-alang ng capacity ang bakasyon, sakit, pulong. Typical loss rate — 25-30% ng oras ng trabaho ay napupunta sa hindi code na aktibidad.

Ang pagpaplano ay nahahati sa dalawang bahagi: “ano” (PO nagpapaliwanag ng mga gawain, team naglilinaw) — 2 oras, at “paano” (team nagdedecompose at nag-eestimate) — 2 oras. Para sa mobile projects, sa bahaging “paano” tinatalakay: compatibility sa mga bersyon ng Android/iOS, pangangailangan ng feature flag, epekto sa laki ng APK/IPA, mga bagong permission. Ang Planning Poker technique ay ginagamit para sa pagtantiya: bawat developer ay nagbibigay ng kanyang tantiya sa story points (1, 2, 3, 5, 8, 13). Ang pagkakaiba ng > 2 unit — tinatalakay ang mga dahilan. Ito ay naglalantad ng mga nakatagong panganib sa yugto ng pagpaplano, hindi sa gitna ng sprint.

Pagpapatupad ng sprint: Daily Standup at pagsubaybay

Daily Scrum (Standup) — araw-araw na 15 minutong pulong para sa pagsabay-sabay ng team. Bawat kalahok ay sumasagot sa tatlong tanong: “Ano ang ginawa ko kahapon?”, “Ano ang plano ko ngayon?”, “Anong mga blocker?”. Ang Daily ay hindi status report para sa manager, kundi kasangkapan ng self-organization ng team. Kung sa Daily ay lumabas na dalawang developer ang nagtatrabaho sa parehong gawain — ito ay senyales para sa reorganisasyon. Mahalaga: Hindi nilulutas ng Daily ang mga problema, kundi tinutukoy ang mga ito — para sa paglutas, isang hiwalay na pulong ay tinatawag pagkatapos ng Daily.

Scrum Board (sprint board) — visualization ng Sprint Backlog. Mga kolum: To Do / In Progress / In Review / Done. Bawat gawain ay gumagalaw sa board. Burndown Chart — grap ng natitirang trabaho ayon sa mga araw ng sprint. Ideal na burndown — tuwid na linya mula total SP hanggang 0. Tunay na burndown — paangat na grap na isinasaalang-alang ang pagsasara ng mga gawain. Bumabagsak na burndown (sa ibaba ng ideal na linya) — nahuhuli tayo. Senyales ng problema: kung sa gitna ng sprint ay wala pang 30% ng mga gawain ang tapos — kailangan ng pagwawasto. Maaaring hindi isinasaalang-alang ang mga panganib o sobra ang tantiya sa mga gawain.

Para sa mobile development, ang pagsubaybay ng sprint ay naiimpluwensyahan ng mga tiyak na salik: oras ng build (pagbuo ng Android project sa CI ay maaaring tumagal ng 30+ minuto), paghihintay sa moderasyon ng App Store / Google Play (kung kailangan maghatid ng build sa testers sa pamamagitan ng TestFlight), compatibility sa iba’t ibang device (pagsubok sa 10+ modelo ay tumatagal ng oras). Payo: maglaan ng 1 araw na buffer sa dulo ng sprint para sa huling pagsubok at pagbuo ng release build. Ito ay nagpapababa ng panganib ng hindi tapos na sprint ng 40% ayon sa Mind the Product (2025).

Sprint Review at Retrospective

Sprint Review — pagpapakita ng increment sa mga stakeholder. Ipinapakita ng team ang gumaganang build ng app, hindi slides. Tagal — 2 oras para sa 2-linggong sprint. Sinusuri ng Product Owner ang pagsunod sa Acceptance Criteria. Ang mga stakeholder ay nagbibigay ng feedback na maaaring makaimpluwensya sa Product Backlog. Ang Review ay hindi ulat, kundi diyalogo: ang mga stakeholder ay maaaring magtanong at magmungkahi ng mga pagbabago. Pangunahing tuntunin: Sprint Review ay tungkol sa produkto, hindi sa proseso. Ipinapakita namin kung ano ang nakamit, hindi kung paano namin ginawa.

Sprint Retrospective — panloob na pulong ng team para sa pagsusuri ng nakaraang sprint. Format: Start Doing (ano ang simulan), Stop Doing (ano ang itigil), Continue Doing (ano ang ipagpatuloy). Tagal — 1.5 oras para sa 2-linggong sprint. Ang Retrospective ay isang ligtas na espasyo para sa pagtalakay ng mga problema. Tuntunin: sa Retro hindi tinatalakay ang mga teknikal na detalye (para doon ay may teknikal na pulong). Tanging proseso, komunikasyon, kasangkapan, kultura. Pinapadali ng Scrum Master ang pulong at tinitiyak na bawat kalahok ay nakapagsasalita.

Ang resulta ng Retrospective — 1-3 pagpapabuti para sa susunod na sprint. Kung natukoy ng team ang problemang “Code review ay masyadong mahaba” — action item: “Magtakda ng SLA para sa review — 4 na oras. Kung hindi nagawa ang review sa tamang oras — nagpapaalala ang developer sa Slack”. Action Items ay dapat kongkreto, masusukat, at nakatalaga sa tiyak na tao. Ayon sa Atlassian (2025), ang mga team na nagsasagawa ng kanilang Retro action items ay nagpapabuti ng velocity ng 15-25% sa loob ng 3-4 sprint. Ang mga hindi nagsasagawa — nakatayo sa isang lugar.

Paano pumili ng tagal ng sprint

2 linggo — standard para sa mobile development. Pinakamainam na balanse sa pagitan ng predictability at flexibility. Sapat: magplano, magpatupad ng 3-5 katamtamang feature, subukan, ipakita ang resulta. 1 linggo — para sa mga team na may mataas na maturity ng proseso at CI/CD. Nangangailangan ng mabilis na desisyon, minimal na burukrasya. Angkop para sa startup sa maagang yugto na kailangang mabilis na mag-eksperimento. Disbentaha: mataas na overhead para sa mga ritwal (bawat linggo Planning + Review + Retro = 7.5 oras).

3-4 na linggo — para sa mga kumplikadong proyekto na may hardware integration (wearables, IoT, BLE devices), mahabang moderasyon ng store, o malalaking migration (halimbawa, paglipat mula RxJava patungong Coroutines). Ang mahabang sprint ay nagbibigay ng mas maraming oras para sa pagsubok, ngunit pinapataas ang panganib ng “waterfall effect” — nawawalan ng Agile flexibility ang team. Rekomendasyon ng Scrum Guide: huwag lumampas ng 1 buwan. Kung mas mahaba ang sprint — sa Review ay magkakaroon ng masyadong maraming konteksto, hindi makakapagbigay ng kalidad na feedback ang mga stakeholder.

Mga karaniwang problema sa sprint

Problema 1: Scope Creep. Sa gitna ng sprint, nagdadagdag ang Product Owner ng bagong gawain na “apurahan at mahalaga”. Pumapayag ang team — at nabibigo ang sprint. Solusyon: Sprint Goal — kontrata. Bawat pagbabago ay nangangailangan ng pagrerebisa ng Sprint Goal, at ito ay posible lamang sa mga emergency. Ang bagong gawain ay pumupunta sa Product Backlog at susunod na sprint. Kung ang gawain ay talagang kritikal — kinakansela ang lumang Sprint Goal, muling pinaplano ang sprint, ngunit ito ay eksepsiyon, hindi praktika. Dalas ng scope creep na higit sa 1 beses sa 3 sprint — tanda ng mahinang Product Owner.

Problema 2: Hindi tapos na gawain. Sa dulo ng sprint, 50% ng mga gawain ay nasa In Progress, 20% ay nasa Review, 30% lang ang Done. Mga dahilan: sobrang tantiya ng capacity, kulang na tantiya ng complexity, hindi planadong bug. Solusyon: suriin ang dahilan sa Retro. Kung sistematikong hindi kayang tapusin — huwag dagdagan ang bilang ng mga gawain sa Planning, bagkus bawasan. Ang mga team na kumukuha ng 20% mas kaunting gawain ay nagpapakita ng mas mataas na porsyento ng pagkumpleto (80%+ kumpara sa 50-60%). Checklist para sa Planning: para sa bawat gawain, suriin ang Acceptance Criteria, Definition of Ready, at dependencies sa ibang gawain.

Problema 3: Formal na Retro. Ang team ay nagsasagawa ng Retro para lang masabi — 15 minuto, pangkalahatang parirala, walang action items. Solusyon: baguhin ang format ng bawat Retro. Mga metodo: Sailboat (ano ang nagpapabagal, ano ang nagpapabilis), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Italaga ang action items na may deadline at responsable. Sa simula ng susunod na Retro, suriin ang pagpapatupad ng mga nakaraang action items. Ayon sa Atlassian (2025), ang mga team na gumagamit ng iba’t ibang format ng Retro ay nakakalikha ng 50% mas maraming kapaki-pakinabang na pananaw.