Công việc và vé — khái niệm, hệ thống theo dõi và quản lý tác vụ

Công việc và vé là gì?

Công việc — một đơn vị công tác được ghi lại trong hệ thống theo dõi. Nó bao gồm mô tả, ưu tiên (Critical, High, Medium, Low), người phụ trách, thời hạn và trạng thái. Trong phát triển di động, một công việc có thể là “Thêm màn hình hồ sơ với ảnh đại diện”, “Triển khai phân trang nguồn cấp dữ liệu” hoặc “Cập nhật targetSdk lên 35”. Mỗi công việc được gắn với một dự án, sprint và một nhà phát triển hoặc nhóm cụ thể.

Vé — một thực thể rộng hơn. Vé có thể là báo cáo lỗi (“Ứng dụng bị treo khi xoay màn hình trên Android 14”), yêu cầu tính năng (“Thêm hỗ trợ chủ đề tối”), yêu cầu hỗ trợ kỹ thuật (“Thông báo đẩy không đến”) hoặc nhiệm vụ của quản lý (“Chuẩn bị báo cáo tỷ lệ sập trong tháng”). Ranh giới giữa công việc và vé rất mờ nhạt: trong Jira, cả hai khái niệm được kết hợp trong Issue. Sự khác biệt chính: công việc luôn có người phụ trách, trong khi vé có thể là yêu cầu không có người phụ trách cụ thể cho đến khi phân loại.

Trong Scrum và Kanban, công việc là yếu tố chính của backlog. Mỗi công việc phải đáp ứng tiêu chí INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Công việc độc lập có thể triển khai theo bất kỳ thứ tự nào. Có thể ước lượng — nhóm có thể ước lượng công sức. Nhỏ — nằm gọn trong một sprint. Có thể kiểm tra — có tiêu chí chấp nhận rõ ràng. Công việc lớn (epic) được chia thành các công việc nhỏ hơn cho đến khi đáp ứng tất cả tiêu chí.

Các loại công việc trong phát triển di động

Feature — chức năng mới của ứng dụng. Ví dụ: “Màn hình đăng nhập sinh trắc học (Face ID / Touch ID)”. Công việc Feature luôn được liên kết với câu chuyện người dùng và có Tiêu chí Chấp nhận. Ước lượng bằng story points (1, 2, 3, 5, 8, 13). Bug — lỗi được tìm thấy trong quá trình phát triển hoặc kiểm thử. Mức ưu tiên của vé lỗi được xác định bởi mức độ nghiêm trọng (crash → Critical, lỗi UI → Medium, lỗi chính tả → Low). Trong phát triển di động, tỷ lệ sập trên 0,1% là lỗi nghiêm trọng cần sửa ngay lập tức.

Tech Debt / Chore — công việc kỹ thuật không ảnh hưởng trực tiếp đến người dùng: cập nhật thư viện (Dependency Bump), tái cấu trúc (Di chuyển từ ViewPager sang ViewPager2), thiết lập CI/CD, viết kiểm thử. Công việc Tech Debt thường bị đánh giá thấp, mặc dù theo Stripe 2025, có tới 30% thời gian của nhóm di động dành cho bảo trì và trả nợ kỹ thuật. Bỏ qua nợ kỹ thuật dẫn đến tăng lỗi và làm chậm phát triển tính năng mới.

Các loại bổ sung: Spike (công việc nghiên cứu — khám phá công nghệ mới, viết POC), Task (bất kỳ công việc không phải code — tài liệu, đánh giá thiết kế), Improvement (cải thiện chức năng hiện có — tối ưu hóa thời gian tải màn hình). Trong Jira, loại issue có thể tùy chỉnh theo dự án. Bộ tiêu chuẩn cho nhóm di động: Story, Bug, Task, Improvement, Epic. Epic — một chủ đề lớn hợp nhất nhiều câu chuyện. Ví dụ: “Thương mại điện tử: giỏ hàng và thanh toán”.

Vòng đời công việc: từ tạo đến hoàn thành

Open (To Do) — công việc được tạo nhưng chưa bắt đầu. Bao gồm mô tả, Tiêu chí Chấp nhận, ưu tiên. Ở trạng thái này, công việc phải trải qua quá trình làm mịn (grooming) trước khi vào sprint. In Progress — nhà phát triển đã bắt đầu làm việc. Trong phát triển di động, việc liên kết commit và pull request với công việc rất quan trọng: trong Jira qua Smart Commits (APP-123 #comment fix bug), trong GitHub/GitLab qua từ khóa trong mô tả PR (Closes APP-123).

In Review — mã được gửi đi đánh giá. Kiểm tra tự động: CI (Gradle build, lint, unit tests), SonarQube (chất lượng mã), Danger (changelog, tests). Nhà phát triển không thể nhận công việc tiếp theo khi công việc hiện tại đang trong Review — điều này ngăn đa nhiệm. QA / Testing — người kiểm thử xác minh trên thiết bị thực (Android — các phiên bản OS và kích thước màn hình khác nhau, iOS — các mẫu iPhone khác nhau). Nếu tìm thấy lỗi, công việc quay lại In Progress với bình luận.

Done (Closed) — công việc hoàn thành: mã được hợp nhất vào main/master, đã kiểm thử, sẵn sàng phát hành. Một số nhóm thêm trạng thái Deployed — công việc đến tay người dùng chỉ sau khi bản build được phát hành trên cửa hàng. Việc đóng công việc với bình luận kết quả là quan trọng: phiên bản nào, PR nào, chỉ số nào đã thay đổi. Theo Linear (2025), các nhóm đóng công việc với mô tả kết quả có khả năng quay lại cùng công việc thấp hơn 40%.

Vòng đời có thể bao gồm trạng thái Blocked — công việc không thể hoàn thành do phụ thuộc bên ngoài (chờ thiết kế, phản hồi backend, phê duyệt của quản lý). Công việc bị chặn phải có bình luận kèm lý do và ngày kiểm tra tiếp theo. Đánh giá hàng tuần các công việc bị chặn giúp xác định sự chậm trễ hệ thống trong quy trình phát triển. Các trình chặn kéo dài hơn 2 tuần cần được leo thang lên cấp quản lý sản phẩm.

Hệ thống theo dõi công việc

Jira — tiêu chuẩn ngành cho nhóm từ 10 người trở lên. Hỗ trợ bảng Scrum và Kanban, tùy chỉnh quy trình làm việc nâng cao, trường tùy chỉnh, tự động hóa và tích hợp Bitbucket/GitHub. Nhược điểm: quá mức cho nhóm nhỏ, UI chậm, cấu hình phức tạp. Cho các dự án di động, Jira được tùy chỉnh với: plugin Mobile-specific fields (Platform, OS version, Device model), tích hợp TestFlight và Firebase Test Lab, và tự động hóa bản build phát hành. Jira là lựa chọn cho các dự án doanh nghiệp với quy trình quan liêu.

Linear — trình theo dõi hiện đại cho nhóm sản phẩm. UI nhanh, hỗ trợ phím tắt đẳng cấp đầu tiên, Cycle tích hợp (tương tự sprint), tích hợp GitHub và Slack. Ưu điểm: tạo công việc nhanh qua CMD+K, phân phối giai đoạn tự động (Triaged → Backlog → Upcoming → Current → Completed), tài liệu và lộ trình tích hợp. Linear được chọn bởi các startup và nhóm sản phẩm coi trọng tốc độ. Năm 2025, 40% dự án di động mới sử dụng Linear.

Trello — bảng kanban đơn giản cho nhóm nhỏ (2–5 người). Thẻ với danh sách kiểm tra, nhãn, ngày đáo hạn. Nhược điểm: không có sprint, phân tích hạn chế, khó mở rộng. YouGile — phiên bản tương tự Trello của Nga với bảng kanban, trò chuyện và cuộc gọi video. Asana — trình theo dõi tập trung vào dự án và dòng thời gian. Lựa chọn trình theo dõi phụ thuộc vào quy mô nhóm, ngân sách và sở thích: Jira cho doanh nghiệp, Linear cho nhóm sản phẩm, Trello/YouGile cho startup. Quan trọng: công cụ phải thống nhất cho toàn nhóm — nhà thiết kế, nhà phát triển, QA, quản lý đều làm việc trong cùng một hệ thống.

Thực hành tốt nhất cho quản lý công việc

Viết Tiêu chí Chấp nhận — tiêu chí chấp nhận phải cụ thể và có thể kiểm tra. Tệ: “Màn hình đăng nhập hoạt động”. Tốt: “Người dùng nhập email và mật khẩu, nhấp Đăng nhập. Nếu thông tin đúng — điều hướng đến màn hình chính. Nếu sai — hiển thị lỗi “Email hoặc mật khẩu không hợp lệ””. Tiêu chí Chấp nhận (AC) là hợp đồng giữa nhà phát triển, người kiểm thử và quản lý sản phẩm. Không có AC, công việc không đáp ứng Definition of Ready (DoR) và không nên vào sprint.

Liên kết mọi thứ. Commit, PR, trường hợp kiểm thử, bản mẫu thiết kế (Figma), thảo luận Slack — tất cả phải được liên kết với công việc. Trong Jira, điều này được thực hiện qua liên kết trong bình luận; trong Linear, qua liên kết PR tự động. Quy tắc một cú nhấp: từ công việc đến thiết kế/mã/kiểm thử — không quá một cú nhấp. Nhà phát triển mở công việc và thấy ngay bản mẫu Figma, liên kết PR và trường hợp kiểm thử. Điều này tăng tốc quá trình hội nhập thành viên mới lên 30% theo Linear (2025).

Đừng tạo công việc ma. Công việc không mô tả, không AC và không ưu tiên là rác. Nếu trong cuộc họp hàng ngày không ai nhớ tại sao công việc được tạo — nên xóa hoặc làm rõ. Quy tắc 48 giờ: nếu công việc ở trạng thái In Progress không có hoạt động trong 48 giờ, nhà phát triển phải để lại bình luận về lý do chậm trễ. Theo Jira (2025), 60% công việc không hoạt động hơn 3 ngày cuối cùng bị đóng mà không hoàn thành.

Phân rã công việc: epic, câu chuyện người dùng và công việc con

Epic — một lĩnh vực chức năng lớn hợp nhất nhiều câu chuyện. Ví dụ: “Hướng dẫn người dùng” bao gồm “Màn hình chào mừng”, “Chọn sở thích”, “Tải ảnh đại diện”, “Cài đặt thông báo”. Câu chuyện người dùng (User Story) — công việc từ góc nhìn người dùng. Định dạng: “Là một [vai trò], tôi muốn [hành động] để [giá trị]”. Ví dụ: “Là một người dùng, tôi muốn đăng nhập bằng sinh trắc học để không phải nhập mật khẩu mỗi lần”. Câu chuyện người dùng được viết bởi quản lý sản phẩm hoặc chủ sở hữu sản phẩm.

Công việc con (Sub-task) — phân rã công việc kỹ thuật trong Story / Task. Ví dụ cho Story “Màn hình hồ sơ”: Công việc con 1: Xây dựng UI (XML / SwiftUI), Công việc con 2: Kết nối với ViewModel, Công việc con 3: Viết Kiểm thử Đơn vị, Công việc con 4: Kiểm thử Snapshot, Công việc con 5: Kiểm thử UI (Espresso / XCUITest). Quy tắc phân rã: mỗi công việc con hoàn thành trong 1–2 ngày. Nếu nhà phát triển ước lượng công việc con lâu hơn — chia nhỏ thêm. Công việc con là kỹ thuật nội bộ của nhóm, không hiển thị trong backlog sản phẩm. Tổng ước lượng công việc con không nhất thiết bằng ước lượng của Story cha (một phần công việc là giao tiếp, đánh giá mã, kiểm thử).

Kim tự tháp phân rã: Epic (Quý / Nửa năm) → Feature / Story (Sprint) → Task (1–3 ngày) → Sub-task (Vài giờ). Kỹ thuật INVEST giúp kiểm tra chất lượng phân rã. Nếu công việc không Độc lập (phụ thuộc vào công việc khác) — điều này cho thấy phân rã không đúng. Nếu công việc không Nhỏ (hơn 8 story points) — cần chia nhỏ thêm. Mô hình phổ biến: Epic → 5–15 Stories → mỗi Story → 3–8 Sub-tasks. Ước lượng epic cuối cùng = tổng ước lượng Stories, nhưng sprint đầu tiên thường có sai số 20–30% trong ước lượng.

Lỗi thường gặp khi làm việc với công việc

Lỗi 1: công việc quá lớn. Công việc 2 tuần là một epic cần phân rã. Công việc lớn không thể tích hợp vào theo dõi hàng ngày; chúng nằm trong In Progress hàng tuần. Quy tắc: kích thước công việc tối đa — 2–3 ngày làm việc. Bất cứ thứ gì lớn hơn phải được phân rã. Hiệu ứng phụ: nhà phát triển cảm thấy tiến bộ khi đóng 2–3 công việc mỗi tuần thay vì một công việc khổng lồ. Điều này tăng động lực và khả năng dự đoán lịch trình.

Lỗi 2: thiếu Tiêu chí Chấp nhận. Nhà phát triển triển khai tính năng, người kiểm thử xác nhận — mọi thứ tốt. Quản lý: “Nút chỉnh sửa ở đâu?” — “Không có trong công việc”. Không có AC, mỗi bên hiểu công việc khác nhau. Kết quả: làm lại, xung đột, trễ thời hạn. AC là hợp đồng: nếu công việc không có tiêu chí, nó chưa sẵn sàng cho sprint. Trong quá trình làm mịn, điều đầu tiên được kiểm tra là sự hiện diện của AC. Nếu thiếu AC, công việc được trả lại cho Quản lý Sản phẩm để làm rõ.

Lỗi 3: quên nợ kỹ thuật. Nhóm chỉ làm công việc Feature sprint này qua sprint khác. Sáu tháng sau: bản build mất 15 phút, Gradle tụt hậu 3 phiên bản chính, kiểm thử thất bại trên CI do lỗi thời. Giải pháp: dành 20% thời gian nhóm cho Tech Debt (thực hành Google SRE “Ngân sách lỗi dựa trên SLO”). Tạo ít nhất một công việc Tech Debt cho mỗi sprint Feature. Tỷ lệ: cứ 3 công việc Feature — 1 Tech Debt hoặc Bug. Điều này ngăn tích tụ nợ kỹ thuật và duy trì tốc độ phát triển.