Grooming ng mga gawain sa mobile development: esensya, layunin at proseso ng pagsasagawa

Ano ang grooming ng mga gawain?

Backlog Grooming (refinement) — proseso ng paghahanda ng mga gawain ng Product Backlog para sa mga susunod na sprint. Isang pagpupulong kung saan ang Product Owner at development team ay nagsusuri ng mga gawain: nililinaw ang mga kinakailangan, nagdadagdag ng Acceptance Criteria, sinusuri ang pagiging kumplikado, tinutukoy ang mga dependency at panganib. Sa Scrum Guide, walang mandatoryong kaganapan na „grooming" — ito ay isang karagdagang kasanayan na ipinakikilala ng mga Scrum team upang mabawasan ang kawalan ng katiyakan sa Sprint Planning. Inirerekomendang dalas — 1 beses bawat sprint, hindi hihigit sa 60 minuto.

Ang terminong „pag-aayos" (grooming) ay sumasalamin sa esensya: sinusuklay ng team ang backlog, inaalis ang mga luma nang gawain, nililinaw ang mga hindi malinaw at hinahati-hati ang mga masyadong malaki. Sa mobile development, ang grooming ay lalong mahalaga dahil sa mga detalye ng platform: ang isang gawain para sa Android ay maaaring magkaiba sa bersyon ng iOS sa pagiging kumplikado, kailangang isaalang-alang ang targetSdk, compileSdk, compatibility sa mga antas ng API. Kung walang grooming, ang Sprint Planning ay nagiging magulo: unang beses na nakikita ng team ang mga gawain at hindi nila ito masusuri, na humahantong sa hindi inaasahang resulta at pagkaantala.

Ang resulta ng grooming — ilang gawain na handa para sa Sprint Planning: mayroon silang deskripsyon, Acceptance Criteria, pagsusuri at tumutugma sa Definition of Ready. Dapat i-groom ng Product Owner ang mga gawain ayon sa pagkakasunod-sunod ng prayoridad: ang pinakamalapit sa kasalukuyang sprint — ang pinaka-detalyado. Ang mga gawain para sa 3-4 sprint na sumusunod — sa antas lamang ng epiko. Teknikang Progressive Refinement: kung mas malapit ang gawain sa sprint, mas detalyado ang deskripsyon nito. Para sa mga gawain sa kasalukuyang sprint — full refinement (AC, disenyo, API spec). Para sa mga gawain pagkatapos ng 2 sprint — story-level (user story walang detalye ng implementasyon). Para sa mga gawain pagkatapos ng 3+ sprint — epic-level (pangalan at halaga ng negosyo lamang).

Definition of Ready: kailan handa ang gawain para sa sprint

Definition of Ready (DoR) — checklist ng mga pamantayan na dapat matugunan ng gawain bago isama sa Sprint Backlog. Ang DoR ay isang kontrata sa pagitan ng Product Owner at ng team: ginagarantiyahan ng PO na ang lahat ng impormasyon para sa pag-develop ay magagamit, ginagarantiyahan ng team na masusuri at maisasagawa nila ang gawain. Ang DoR ay hindi unibersal — bawat team ay tumutukoy ng sarili nitong hanay ng mga pamantayan. Kung walang DoR, ang gawain ay maaaring makapasok sa sprint na may hindi malinaw na mga kinakailangan, na humahantong sa muling paggawa at pagkaantala.

Karaniwang DoR para sa mobile development: 1) Ang Acceptance Criteria ay inilarawan (pamantayan ng pagtanggap sa format na Given-When-Then). 2) Ang mockup ng disenyo ay handa sa Figma (para sa mga gawaing UI) kasama ang lahat ng estado: default, loading, error, empty state. 3) Ang spec ng API ay naaprubahan (OpenAPI/Swagger, mga halimbawa ng request at response). 4) May pagsusuri sa story points. 5) Ang mga dependency sa ibang gawain ay natukoy na. 6) Ang gawain ay hindi nakadepende sa hindi pa handang external na mga bahagi. 7) Mobile specifics: ang target na bersyon ng OS, pangangailangan ng feature flag, suporta para sa lumang antas ng API ay natukoy na.

Mga teknik sa pagsusuri ng gawain

Planning Poker — pinakasikat na teknik sa pagsusuri sa grooming. Bawat developer ay tumatanggap ng set ng cards na may mga numero ng Fibonacci (1, 2, 3, 5, 8, 13, 21). Ipinapakita at ipinapaliwanag ng PO ang gawain. Pagkatapos ng diskusyon, sabay-sabay na ipapakita ng lahat ang kanilang card. Kung malaki ang pagkakaiba ng mga pagsusuri (hal. 3 at 13) — ipapaliwanag ng mga developer ang kanilang pagsusuri, pagkatapos ay boboto muli. Mga iterasyon ay uulit hanggang sa magkaroon ng kasunduan. Ang layunin ng Planning Poker ay hindi ang eksaktong pagsusuri, kundi ang pagtuklas ng mga pagkakaiba sa pag-unawa sa gawain.

T-Shirt Sizing — pinasimpleng teknik para sa mabilis na pagsusuri: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Angkop para sa paunang pag-uuri ng backlog kapag maraming gawain at kailangang mabilis na matantya ang antas ng laki. Pagkatapos ng T-Shirt Sizing, isinasagawa ang mas tumpak na pagsusuri sa pamamagitan ng Planning Poker para sa mga gawain ng susunod na sprint. Affinity Estimation — pagsasama-sama ng mga gawain ayon sa relatibong pagiging kumplikado nang walang numero; inilalagay ang mga gawain sa mesa mula sa pinakasimple hanggang sa pinakakomplikado, pagkatapos ay pinagsasama-sama sa mga cluster, bawat cluster ay makakakuha ng pagsusuri.

Sa mobile development, ang pagsusuri ay dapat isaalang-alang ang pagiging kumplikado ng platform. Ang isang Android gawain ay maaaring masuri sa 5 SP, at ang parehong gawain para sa iOS — sa 3 SP (o kabaliktaran). Ito ay normal: ang iba't ibang platform ay may iba't ibang pagiging kumplikado ng implementasyon. Payo: suriin ang bawat platform nang hiwalay kung ang team ay cross-platform. Gumamit ng relatibong scale: base na gawain (hal. screen na may text at button) = 1 SP. Lahat ng iba pa — kaugnay nito. Ayon sa Scrum.org (2025), pagkatapos ng 3-4 sprint, ang accuracy ng pagsusuri ng team ay umaabot sa ±20% ng aktwal na pagiging kumplikado.

Pagdekompos: paano hatiin ang malalaking gawain

Mga gawaing mas malaki sa 8 SP ay dapat na idekompos sa mas maliliit. Ang malalaking gawain ay hindi makukumpleto sa isang sprint, mahirap suriin at hindi nagbibigay ng pakiramdam ng progreso. Teknik ng pagdekompos: hatiin ang gawain ayon sa pahalang na layer (UI → ViewModel → Repository → Network/DB) o patayong hiwa (feature: isang buong screen). Pahalang na pagdekompos ay mas angkop para sa mobile development: Sub-task 1 — layout ng UI (XML/Jetpack Compose/SwiftUI), Sub-task 2 — ViewModel + State, Sub-task 3 — Repository + Network, Sub-task 4 — Unit test.

Patayong pagdekompos — paghiwa ng user story sa mas maliliit na kwento na may independiyenteng halaga. Halimbawa: Epic „Shopping Cart" → Story 1 „Pagdagdag ng produkto sa cart", Story 2 „Pagpapakita ng cart", Story 3 „Pag-alis ng produkto mula sa cart", Story 4 „Pag-checkout ng order". Bawat Story ay may sariling halaga sa negosyo at maaaring ilabas nang independiyente. SPoK (Story Points on Kano): i-rank ang Stories ayon sa halaga ng negosyo (Must-have, Should-have, Could-have) at ipatupad ayon sa pagkakasunod-sunod ng halaga.

Checklist ng pagdekompos sa grooming: 1) Gawain mas malaki sa 8 SP? → Idekompos. 2) May Acceptance Criteria ba? → Kung wala — idagdag. 3) Nakadepende ba sa ibang gawain? → Tukuyin at itala ang mga dependency. 4) May kawalan ba ng katiyakan? → Magdagdag ng Spike (pananaliksik) bago ang pangunahing gawain. 5) Kailangan ba ng disenyo? → Suriin ang kahandaan ng mga mockup. Panuntunan ng INVEST: Independent (independiyente sa iba), Negotiable (maaaring pag-usapan), Valuable (mahalaga para sa negosyo), Estimable (masusuri), Small (maliit), Testable (masusubok). Kung ang gawain ay hindi nakakatugon sa INVEST — hindi ito handa para sa sprint.

Proseso ng grooming: hakbang-hakbang

Hakbang 1: Pag-init (5 minuto). Ipinapaalala ng Scrum Master ang layunin ng grooming at DoR. Tumingin ang team sa board, ipinapakita ng PO kung aling mga gawain ang tatalakayin. Hakbang 2: Pagsusuri ng gawain (30 minuto). Sunod-sunod na ipinapakita ng PO ang mga gawain mula sa dulo ng kasalukuyang sprint at simula ng susunod na sprint. Para sa bawat gawain: pangalan, deskripsyon, Acceptance Criteria (kung mayroon), link sa disenyo, spec ng API. Ang team ay nagtatanong ng mga paglilinaw: „May mockup ba para sa empty state?", „Anong HTTP method?", „Ano ang iOS minimum deployment target?".

Hakbang 3: Pagsusuri (15 minuto). Sinusuri ng team ang gawain sa pamamagitan ng Planning Poker o T-Shirt Sizing. Kung ang pagkakaiba ay > 2 SP — tatalakayin nila ang mga dahilan at boboto muli. Panuntunan: kung ang gawain ay hindi masusuri (hindi malinaw na mga kinakailangan, walang disenyo) — ibabalik ito sa PO para sa rebisyon at darating sa susunod na grooming na may mga paglilinaw. Huwag suriin ang mga gawaing may hindi kilalang mga bagay — tiyak na hahantong ito sa pagkakamali sa sprint. Hakbang 4: Pagtala ng resulta (10 minuto). Itinatala ng PO ang mga pagsusuri sa Jira/Linear, ina-update ang deskripsyon ng gawain at nagtatakda ng mga prayoridad.

Mga resulta ng grooming: 3-7 gawain na ganap na handa para sa Sprint Planning (may DoR, pagsusuri, disenyo, API). Ina-update ng PO ang backlog: inaalis ang mga lumang gawain, pinagsasama ang mga duplicate, nililinaw ang mga prayoridad. Mahalaga: hindi tinatapos ng grooming ang trabaho ng PO — sa pagitan ng mga grooming session dapat siyang maghanda ng mga susunod na gawain. Inirerekomendang bilis: naghahanda ang PO ng 3-4 na gawain para sa grooming, pinoproseso sila ng team. Kung may higit sa 50 gawain sa backlog — dapat magsagawa ng prayoritisasyon ang PO (MoSCoW o Weighted Shortest Job First) bago ang grooming.

Pagkakaiba ng grooming sa Sprint Planning

Grooming — ay paghahanda. Walang obligasyon — ang gawain ay nililinaw at sinusuri lamang. Sprint Planning — ay isang commitment. Pinipili ng team ang mga gawain mula sa mga inihanda sa grooming at nangangakong kukumpletuhin ang mga ito sa sprint. Mga pangunahing pagkakaiba: ang grooming ay hindi nakatali sa isang partikular na sprint (pangkalahatang refinement ng backlog), sa grooming ay walang Sprint Goal, ang grooming ay maaaring gawin anumang oras sa sprint. Ang Sprint Planning — mahigpit sa simula ng sprint at laging humahantong sa Sprint Goal.

Sa grooming, ang mga gawain ay sinusuri lamang, ngunit hindi dinadala sa sprint. Sa Planning, ang mga gawain ay pinipili mula sa inihandang pool. Kung walang grooming, ang Sprint Planning ay tumatagal ng 6-8 oras (sa halip na 4), dahil unang beses na nakikita ng team ang mga gawain at hindi nila ito mabilis na masusuri. Panuntunan 80/20: 80% ng mga gawain sa Sprint Planning ay dapat na ganap nang handa (dumaan sa grooming), 20% — ay maaaring bago (mga agarang bug, hotfix). Kung sa Planning ay may higit sa 20% na hindi nasuring mga gawain — hindi sapat ang grooming.

Mga karaniwang pagkakamali sa grooming

Pagkakamali 1: grooming isang beses sa isang buwan. Nag-iipon ang team ng 3-4 sprint na gawain, sinusubukang linawin lahat sa loob ng 2 oras. Resulta: kalahati ng gawain ay nananatiling hindi nasuri, ang Planning ay tumatagal ng buong araw. Solusyon: ang grooming ay dapat regular — 1 beses bawat sprint, 60 minuto. Kung maraming gawain — magdagdag ng pangalawang grooming sa gitna ng sprint. Mas mainam na i-groom ang mas kaunting gawain nang may kalidad, kaysa marami — ngunit mababaw. Bilis: 3-5 gawain bawat grooming, bawat isa ay makakakuha ng buong diskusyon at pagsusuri.

Pagkakamali 2: pagsusuri nang walang konteksto. Ipinakita ng PO ang gawaing „Ipatupad ang screen ng cart" nang walang disenyo, walang API, walang AC. Sinusuri ng team „sa mata" — 13 SP. Sa Planning ay lumalabas na 5 SP lang ito (dahil simple ang screen). Solusyon: ang gawain ay hindi sinusuri kung walang disenyo o API. Obligado ang PO na maghanda ng mga materyal bago ang grooming. Panuntunan: „Walang mockup — walang pagsusuri". Pagbubukod: Spike na gawain — pananaliksik ng kawalan ng katiyakan, sinusuri nang hiwalay nang walang disenyo (2-5 SP depende sa pagiging kumplikado ng pananaliksik).

Sinimulan ng team na ipamahagi ang mga gawain sa mga tagapagpatupad at pag-usapan kung sino ang gagawa ng ano. Solusyon: paalalahanan na ang grooming ay para sa paglilinaw, hindi para sa pamamahagi. Ang pamamahagi — sa Daily pagkatapos magsimula ang sprint. Sinasagot ng grooming ang tanong na „ano ang gagawin?", Planning — „kailan gagawin?", Daily — „sino ang gagawa?". Ang paghahalo ng mga tanong na ito sa isang pagpupulong ay nagpapababa sa bisa ng bawat isa. Dapat itigil ng Scrum Master ang diskusyon ng Planning at ituon ang atensyon sa paglilinaw ng gawain.

Pagkakamali 4: pagbalewala sa Tech Debt. Sa grooming, ang mga bagong feature lamang ang tinatalakay, ang mga teknikal na gawain ay binabalewala. Pagkatapos ng 3-4 sprint, ang teknikal na utang ay naipon sa kritikal na antas. Solusyon: sa bawat grooming, hindi bababa sa 1 Tech na gawain ang dapat masuri. Proporsyon: bawat 3 feature → 1 teknikal na gawain. Gamitin ang metrikong Tech Debt Ratio: ratio ng Tech na gawain sa Feature na gawain sa sprint. Target na halaga: 0.25-0.3 (25-30% ng oras sa teknikal na utang). Kung ang ratio ay mas mababa sa 0.2 — bababa ang bilis ng pag-develop sa mga susunod na sprint.