Gawain at ticket — ano ito, mga sistema ng pagsubaybay at paggawa sa mga gawain

Ano ang gawain at ticket?

Gawain (mula sa Ingles task) — isang yunit ng trabaho na naitala sa sistema ng pagsubaybay. Naglalaman ng paglalarawan, priyoridad (Critical, High, Medium, Low), tagapagpatupad, deadline at status. Sa mobile development, ang gawain ay maaaring “Pagdagdag ng screen ng profile na may avatar”, “Pagpapatupad ng pagination ng feed” o “Pag-update ng bersyon ng targetSdk sa 35”. Bawat gawain ay naka-link sa proyekto, sprint at partikular na developer o team.

Ticket (mula sa Ingles ticket) — isang mas malawak na entidad. Ang ticket ay maaaring ulat ng bug (“Ang app ay nag-crash kapag umiikot ang screen sa Android 14”), kahilingan ng feature (“Pagdagdag ng suporta para sa dark theme”), reklamo sa technical support (“Hindi dumarating ang push notification”) o gawain mula sa manager (“Paghahanda ng ulat ng crash rate para sa buwan”). Ang pagkakaiba sa pagitan ng gawain at ticket ay malabo: sa Jira, parehong konsepto ay pinag-isa sa Issue. Pangunahing pagkakaiba: ang gawain ay palaging trabaho na may tagapagpatupad, ang ticket ay maaaring kahilingan na walang tiyak na tagapagpatupad hanggang sa triage.

Sa Scrum at Kanban, ang mga gawain ay pangunahing elemento ng backlog. Bawat gawain ay dapat tumugon sa pamantayang INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Ang mga independiyenteng gawain ay maaaring ipatupad sa anumang pagkakasunod-sunod. Matatantya — maaaring tantyahin ng team ang pagod. Maliit — kasya sa isang sprint. Naisusubok — may malinaw na pamantayan ng pagtanggap. Ang malalaking gawain (epik) ay hinahati sa mas maliliit na bahagi hanggang sa matugunan ang lahat ng pamantayan.

Mga uri ng gawain sa mobile development

Feature — bagong functionality ng app. Halimbawa: “Screen ng pag-login sa pamamagitan ng biometrics (Face ID / Touch ID)”. Ang mga Feature na gawain ay palaging naka-link sa user story at may Acceptance Criteria. Pagtantiya — sa story points (1, 2, 3, 5, 8, 13). Bug — depekto na natagpuan sa proseso ng development o testing. Ang priyoridad ng bug ticket ay tinutukoy ng severity (crash → Critical, UI-bug → Medium, typo → Low). Sa mobile development, ang crash rate na higit sa 0.1% ay kritikal na bug at nangangailangan ng agarang pag-aayos.

Tech Debt / Chore — mga teknikal na gawain na walang nakikitang epekto sa user: pag-update ng mga library (Dependency Bump), refactoring (Migration mula ViewPager patungong ViewPager2), pag-configure ng CI/CD, pagsusulat ng mga test. Ang mga Tech Debt na gawain ay madalas na minamaliit, bagaman ayon sa datos ng Stripe 2025, hanggang 30% ng oras ng mobile team ay ginugugol sa pagpapanatili at pagbabayad ng teknikal na utang. Ang pagbalewala sa Tech Debt ay humahantong sa pagtaas ng bilang ng mga bug at pagbagal ng development ng mga bagong feature.

Mga karagdagang uri: Spike (gawaing pananaliksik — pag-aaral ng bagong teknolohiya, pagsusulat ng POC), Task (anumang trabaho na hindi nauugnay sa code — dokumentasyon, review ng disenyo), Improvement (pagpapabuti ng umiiral na functionality — pag-optimize ng oras ng pag-load ng screen). Sa Jira, ang mga uri ng issues ay nako-configure ayon sa proyekto. Karaniwang set para sa mobile team: Story, Bug, Task, Improvement, Epic. Epic — malaking paksa na pinag-iisa ang maraming kwento. Halimbawa: “E-commerce: cart at checkout”.

Lifecycle ng gawain: mula sa paggawa hanggang sa pagsasara

Open (To Do) — gawain na ginawa ngunit hindi pa sinimulan. Naglalaman ng paglalarawan, Acceptance Criteria, priyoridad. Sa status na ito, ang gawain ay dapat dumaan sa grooming (paglilinaw at pagtantiya) bago pumasok sa sprint. In Progress — developer ay nagsimula ng trabaho. Sa mobile development, mahalaga na i-link ang mga commit at pull request sa gawain: sa Jira sa pamamagitan ng Smart Commits (APP-123 #comment pag-aayos ng bug), sa GitHub/GitLab sa pamamagitan ng mga keyword sa paglalarawan ng PR (Closes APP-123).

In Review — code na ipinadala para sa review. Mga awtomatikong pagsusuri: CI (Gradle build, lint, unit test), SonarQube (kalidad ng code), Danger (changelog, test). Hindi maaaring kunin ng developer ang susunod na gawain habang ang kasalukuyang gawain ay nasa Review — pinipigilan nito ang multitasking. QA / Testing — sinusuri ng tester sa mga totoong device (Android — iba't ibang bersyon ng OS at laki ng screen, iOS — iba't ibang modelo ng iPhone). Kung may natagpuang mga bug, ang gawain ay babalik sa In Progress na may komento.

Done (Closed) — gawain na natapos: code na pinagsama sa main/master, pumasa sa testing, handa para ilabas. Ang ilang team ay nagdadagdag ng status na Deployed — ang gawain ay makakarating sa user pagkatapos lamang mailabas ang build sa mga store. Mahalaga na isara ang mga gawain na may komento tungkol sa resulta: anong bersyon, anong PR, anong mga metrics ang nagbago. Ayon sa datos ng Linear (2025), ang mga team na nagsasara ng mga gawain na may paglalarawan ng resulta ay 40% mas madalas na bumabalik sa parehong mga gawain.

Ang lifecycle ay maaaring magsama ng status na Blocked — ang gawain ay hindi maisasagawa dahil sa panlabas na dependency (naghihintay ng disenyo, sagot mula sa backend, pag-apruba ng manager). Ang mga Blocked na gawain ay dapat may komento na may dahilan at petsa ng susunod na pagsusuri. Ang lingguhang pagsusuri ng mga Blocked na gawain ay tumutulong sa pagtukoy ng mga sistematikong pagkaantala sa proseso ng development. Ang mga blocker na mas mahaba sa 2 linggo ay nangangailangan ng escalation sa antas ng product manager.

Mga sistema ng pagsubaybay ng gawain

Jira — pamantayan ng industriya para sa mga team na may 10 tao pataas. Sumusuporta sa Scrum at Kanban boards, advanced na configuration ng workflow, custom na field, automation, integrasyon sa Bitbucket/GitHub. Mga Kakulangan: sobra para sa maliliit na team, mabagal na interface, kumplikadong configuration. Para sa mga mobile project, ang Jira ay naka-configure gamit ang: plugin na Mobile-specific fields (Platform, OS version, Device model), integrasyon sa TestFlight at Firebase Test Lab, automation ng paggawa ng release builds. Jira — pagpili ng corporate projects na may burukratikong proseso.

Linear — modernong tracker para sa product teams. Mabilis na interface, first-class na suporta para sa keyboard shortcuts, built-in na Cycle (kahalintulad ng sprint), integrasyon sa GitHub at Slack. Mga Bentahe: bilis ng paggawa ng gawain sa pamamagitan ng CMD+K, awtomatikong pamamahagi sa mga phase (Triaged → Backlog → Upcoming → Current → Completed), built-in na dokumentasyon at roadmaps. Ang Linear ay pinipili ng mga startup at product team na pinahahalagahan ang bilis ng trabaho. Sa 2025, 40% ng mga bagong mobile project ay gumagamit ng Linear.

Trello — simpleng kanban board para sa maliliit na team (2-5 tao). Mga card na may checklist, label, deadline. Kakulangan: walang sprint, limitadong analytics, mahirap i-scale. YouGile — Russian na katumbas ng Trello na may kanban boards, chat at video call. Asana — tracker na may pokus sa mga proyekto at timeline. Ang pagpili ng tracker ay depende sa laki ng team, budget at preferences: Jira para sa enterprise, Linear para sa product teams, Trello/YouGile para sa startup. Mahalaga: ang tool ay dapat na pare-pareho para sa buong team — mga designer, developer, tester, manager ay nagtatrabaho sa isang sistema.

Pinakamahusay na kasanayan sa pamamahala ng gawain

Isulat ang Acceptance Criteria — ang acceptance criteria ay dapat na konkreto at nabe-verify. Masama: “Gumagana ang login screen”. Mabuti: “Ang user ay naglalagay ng email at password, pinipindot ang Login. Kung tama ang datos — paglipat sa pangunahing screen. Kung mali — ipinapakita ang error na “Maling email o password””. Ang Acceptance Criteria (AC) ay kontrata sa pagitan ng developer, tester at product manager. Kung walang AC, ang gawain ay hindi tumutugon sa Definition of Ready (DoR) at hindi dapat pumasok sa sprint.

I-link ang lahat. Mga commit, PR, test case, design mockup (Figma), mga diskusyon sa Slack — lahat ay dapat na naka-link sa gawain. Sa Jira ito ay ginagawa sa pamamagitan ng mga link sa komento, sa Linear — sa pamamagitan ng awtomatikong pag-link ng PR. Rule ng isang click: mula gawain hanggang disenyo/code/test — hindi hihigit sa isang click. Binuksan ng developer ang gawain at agad na nakikita ang mockup sa Figma, link ng PR at test case. Ito ay nagpapabilis ng onboarding ng mga bagong miyembro ng team ng 30% ayon sa datos ng Linear (2025).

Huwag gumawa ng multong gawain. Ang gawain na walang paglalarawan, walang AC at walang priyoridad ay basura. Kung sa araw-araw na standup walang nakatatanda kung bakit ginawa ang gawain — dapat itong tanggalin o linawin. Rule ng 48 oras: kung ang gawain ay nasa status na In Progress na walang aktibidad sa loob ng 48 oras — ang developer ay dapat mag-iwan ng komento tungkol sa mga dahilan ng pagkaantala. Ayon sa datos ng Jira (2025), 60% ng mga gawain na hindi aktibo nang higit sa 3 araw ay sa huli ay nagsasara nang hindi natatapos.

Pagdecompose ng mga gawain: epik, user story at sub-gawain

Epic — malaking functional area na pinag-iisa ang maraming kwento. Halimbawa: “Onboarding ng user” ay kinabibilangan ng “Welcome screen”, “Pagpili ng interes”, “Pag-upload ng avatar”, “Pag-setup ng notification”. User Story — gawain mula sa pananaw ng user. Format: “Bilang [role], gusto kong [action] upang [value]”. Halimbawa: “Bilang user, gusto kong mag-login sa pamamagitan ng biometrics upang hindi mag-input ng password sa bawat oras”. Ang User Story ay isinusulat ng product manager o product owner.

Sub-gawain (Sub-task) — pagdecompose ng teknikal na trabaho sa loob ng Story / Task. Halimbawa para sa Story “Profile Screen”: Sub-task 1: Paggawa ng UI ng screen (XML / SwiftUI), Sub-task 2: Pagkonekta sa ViewModel, Sub-task 3: Pagsusulat ng unit test, Sub-task 4: Snapshot test, Sub-task 5: UI test (Espresso / XCUITest). Rule ng pagdecompose: bawat sub-gawain ay natatapos sa loob ng 1-2 araw. Kung tinatantiya ng developer ang sub-gawain na mas mahaba — hinahati pa namin. Ang sub-gawain ay panloob na pamamaraan ng team, hindi nakikita sa product backlog. Ang kabuuan ng mga pagtantiya ng sub-gawain ay hindi kinakailangang katumbas ng pagtantiya ng parent na Story (bahagi ng trabaho — komunikasyon, code review, testing).

Pyramid ng pagdecompose: Epic (Quarter / Half-year) → Feature / Story (Sprint) → Task (1-3 araw) → Sub-task (Ilang oras). Technique ng INVEST ay tumutulong sa pagsusuri ng kalidad ng pagdecompose. Kung ang gawain ay hindi Independent (depende sa iba) — ito ay senyales na mali ang pagdecompose. Kung ang gawain ay hindi Small (higit sa 8 story points) — kailangan pang hatiin. Common pattern: Epic → 5-15 Stories → bawat Story → 3-8 Sub-task. Ang huling pagtantiya ng epik = kabuuan ng pagtantiya ng Stories, ngunit ang unang sprint ay karaniwang may 20-30% na pagkakamali sa mga pagtantiya.

Mga karaniwang pagkakamali sa paggawa sa mga gawain

Pagkakamali 1: masyadong malalaking gawain. Ang gawain na 2 linggo ng trabaho ay isang epik na kailangang idecompose. Ang malalaking gawain ay hindi angkop para sa araw-araw na pagsubaybay, nakabitin sa In Progress nang ilang linggo. Rule: maximum na laki ng gawain — 2-3 araw ng trabaho. Lahat ng mas malaki — idecompose. Side effect: nararamdaman ng developer ang progreso sa pagsasara ng 2-3 gawain bawat linggo sa halip na isang malaking gawain. Ito ay nagpapataas ng motibasyon at predictability ng mga deadline.

Pagkakamali 2: kawalan ng Acceptance Criteria. Ginawa ng developer ang feature, sinuri ng tester — lahat ok. Manager: “Nasaan ang edit button?” — “Hindi nakasulat sa gawain”. Kung walang AC, bawat partido ay nauunawaan ang gawain sa sarili nitong paraan. Resulta: paggawa muli, mga alitan, sirang deadline. AC — kontrata: kung walang pamantayan sa gawain — hindi ito handa para sa sprint. Sa grooming, unang sinusuri ang pagkakaroon ng AC. Kung walang AC — ang gawain ay ipinapadala para sa pagbabago sa Product Manager.

Pagkakamali 3: nakakalimutan ang Tech Debt. Ang team ay gumagawa lamang ng Feature na gawain sprint pagkatapos ng sprint. Pagkatapos ng anim na buwan: ang compilation ay tumatagal ng 15 minuto, ang Gradle ay luma na ng 3 pangunahing bersyon, ang mga test ay bumagsak sa CI dahil sa deprecation. Solusyon: magtabi ng 20% ng oras ng team para sa Tech Debt (praktika ng Google SRE na “SLO-based error budget”). Gumawa ng hindi bababa sa isang Tech Debt na gawain para sa bawat Feature sprint. Proporsyon: sa bawat 3 Feature na gawain — 1 Tech Debt o Bug. Pinipigilan nito ang pag-ipon ng teknikal na utang at pinapanatili ang bilis ng development.