Grooming công việc trong phát triển di động: bản chất, mục tiêu và quy trình thực hiện

Grooming công việc là gì?

Backlog Grooming (làm mịn) là quá trình chuẩn bị các công việc Product Backlog cho các sprint sắp tới. Đây là cuộc họp nơi Product Owner và nhóm phát triển xem xét các công việc: làm rõ yêu cầu, thêm Acceptance Criteria, ước lượng độ phức tạp, xác định các phụ thuộc và rủi ro. Không có sự kiện bắt buộc nào gọi là “grooming” trong Scrum Guide — đây là một thực hành bổ sung mà các nhóm Scrum áp dụng để giảm sự không chắc chắn trong Sprint Planning. Tần suất khuyến nghị là một lần mỗi sprint, không quá 60 phút.

Thuật ngữ “grooming” phản ánh bản chất: nhóm “chải” backlog, loại bỏ các công việc lỗi thời, làm rõ các công việc không rõ ràng và chia nhỏ các công việc quá lớn. Trong phát triển di động, grooming đặc biệt quan trọng do tính đặc thù của nền tảng: một công việc Android có thể khác về độ phức tạp so với phiên bản iOS, và cần xem xét targetSdk, compileSdk và khả năng tương thích với các cấp độ API. Không có grooming, Sprint Planning trở nên hỗn loạn — nhóm lần đầu tiên thấy công việc và không thể ước lượng, dẫn đến không thể dự đoán và trễ hạn chót.

Kết quả của grooming là một số công việc sẵn sàng cho Sprint Planning: chúng có mô tả, Acceptance Criteria, ước lượng và đáp ứng Definition of Ready. Product Owner nên groom các công việc theo thứ tự ưu tiên: các công việc gần nhất với sprint hiện tại sẽ được chi tiết nhất. Các công việc cách 3–4 sprint chỉ ở cấp độ epic. Kỹ thuật Progressive Refinement: công việc càng gần sprint thì mô tả càng chi tiết. Đối với công việc của sprint hiện tại — làm mịn đầy đủ (AC, thiết kế, đặc tả API). Đối với công việc cách 2 sprint — cấp độ story (user story không có chi tiết triển khai). Đối với công việc cách 3+ sprint — cấp độ epic (chỉ tên và giá trị kinh doanh).

Definition of Ready: khi nào công việc sẵn sàng cho sprint

Definition of Ready (DoR) là danh sách kiểm tra các tiêu chí mà một công việc phải đáp ứng trước khi được đưa vào Sprint Backlog. DoR là hợp đồng giữa Product Owner và nhóm: PO đảm bảo mọi thông tin cần thiết cho phát triển đều có sẵn, và nhóm đảm bảo có thể ước lượng và hoàn thành công việc. DoR không phổ biến — mỗi nhóm tự xác định bộ tiêu chí riêng. Nếu không có DoR, công việc có thể vào sprint với yêu cầu không rõ ràng, dẫn đến làm lại và trễ hạn.

DoR điển hình cho phát triển di động: 1) Acceptance Criteria được mô tả (định dạng Given-When-Then). 2) Bản mẫu thiết kế sẵn sàng trong Figma (đối với công việc UI) với tất cả trạng thái: default, loading, error, empty state. 3) Đặc tả API được phê duyệt (OpenAPI/Swagger, ví dụ yêu cầu và phản hồi). 4) Ước lượng bằng story points. 5) Các phụ thuộc vào công việc khác đã được xác định. 6) Công việc không phụ thuộc vào các thành phần bên ngoài chưa hoàn thành. 7) Đặc thù di động: phiên bản OS mục tiêu được xác định, nhu cầu feature flag, hỗ trợ các cấp độ API cũ.

Kỹ thuật ước lượng công việc

Planning Poker là kỹ thuật ước lượng phổ biến nhất trong grooming. Mỗi lập trình viên nhận một bộ thẻ với các số Fibonacci (1, 2, 3, 5, 8, 13, 21). PO trình bày một công việc và giải thích. Sau khi thảo luận, mọi người cùng lúc giơ thẻ. Nếu ước lượng khác nhau đáng kể (ví dụ 3 và 13), các lập trình viên giải thích lý do, sau đó bỏ phiếu lại. Các lần lặp được lặp lại cho đến khi đạt được sự đồng thuận. Mục đích của Planning Poker không phải là ước lượng chính xác mà là khám phá sự khác biệt trong cách hiểu công việc.

T-Shirt Sizing là kỹ thuật đơn giản hóa cho ước lượng nhanh: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Phù hợp cho việc phân loại backlog ban đầu khi có nhiều công việc và cần thứ tự độ lớn sơ bộ. Sau T-Shirt Sizing, việc ước lượng chính xác hơn qua Planning Poker được thực hiện cho các công việc của sprint tiếp theo. Affinity Estimation là kỹ thuật sắp xếp nhóm nơi các công việc được đặt trên bàn từ đơn giản nhất đến phức tạp nhất mà không dùng số, sau đó được nhóm thành các cụm và mỗi cụm nhận ước lượng.

Trong phát triển di động, việc ước lượng cần xem xét độ phức tạp của nền tảng. Một công việc Android có thể được ước lượng 5 SP trong khi cùng công việc đó cho iOS có thể là 3 SP (hoặc ngược lại). Điều này bình thường: các nền tảng khác nhau có độ phức tạp triển khai khác nhau. Mẹo: hãy ước lượng từng nền tảng riêng biệt nếu nhóm là đa nền tảng. Sử dụng thang tương đối: một công việc cơ sở (ví dụ màn hình có văn bản và nút) = 1 SP. Mọi thứ khác đều tương đối so với nó. Theo Scrum.org (2025), sau 3–4 sprint, độ chính xác ước lượng của nhóm đạt ±20% so với độ phức tạp thực tế.

Phân rã: cách chia nhỏ công việc lớn

Các công việc lớn hơn 8 SP cần được phân rã thành các công việc nhỏ hơn. Công việc lớn không thể hoàn thành trong một sprint, khó ước lượng và không tạo cảm giác tiến bộ. Kỹ thuật phân rã: chia công việc theo lớp ngang (UI → ViewModel → Repository → Network/DB) hoặc theo lát dọc (tính năng: một màn hình hoàn chỉnh). Phân rã ngang phù hợp hơn cho phát triển di động: Công việc con 1 — bố cục UI (XML/Jetpack Compose/SwiftUI), Công việc con 2 — ViewModel + State, Công việc con 3 — Repository + Network, Công việc con 4 — Kiểm thử đơn vị.

Phân rã dọc — chia các câu chuyện người dùng thành các câu chuyện nhỏ hơn có giá trị độc lập. Ví dụ: Epic “Giỏ hàng” → Story 1 “Thêm sản phẩm vào giỏ”, Story 2 “Hiển thị giỏ hàng”, Story 3 “Xóa sản phẩm khỏi giỏ”, Story 4 “Thanh toán”. Mỗi Story có giá trị kinh doanh riêng và có thể phát hành độc lập. SPoK (Story Points on Kano): xếp hạng các Story theo giá trị kinh doanh (Must-have, Should-have, Could-have) và triển khai theo thứ tự giá trị.

Danh sách kiểm tra phân rã trong grooming: 1) Công việc có lớn hơn 8 SP không? → Phân rã. 2) Đã có Acceptance Criteria chưa? → Nếu chưa, hãy thêm. 3) Có phụ thuộc vào công việc khác không? → Xác định và ghi lại các phụ thuộc. 4) Có chứa sự không chắc chắn không? → Thêm Spike (nghiên cứu) trước công việc chính. 5) Có cần thiết kế không? → Kiểm tra sự sẵn sàng của bản mẫu. Quy tắc INVEST: Independent (độc lập với các công việc khác), Negotiable (có thể thương lượng), Valuable (có giá trị kinh doanh), Estimable (ước lượng được), Small (nhỏ), Testable (có thể kiểm thử). Nếu công việc không đáp ứng INVEST, nó chưa sẵn sàng cho sprint.

Quy trình grooming: từng bước

Bước 1: Khởi động (5 phút). Scrum Master nhắc nhóm về mục tiêu của grooming và DoR. Nhóm nhìn vào bảng, PO chỉ ra các công việc sẽ được thảo luận. Bước 2: Xem xét công việc (30 phút). PO lần lượt trình bày các công việc từ cuối sprint hiện tại và đầu sprint tiếp theo. Cho mỗi công việc: tên, mô tả, Acceptance Criteria (nếu có), liên kết thiết kế, đặc tả API. Nhóm đặt câu hỏi làm rõ: “Có bản mẫu cho trạng thái trống không?”, “Phương thức HTTP nào?”, “Minimum deployment target của iOS là gì?”

Bước 3: Ước lượng (15 phút). Nhóm ước lượng công việc qua Planning Poker hoặc T-Shirt Sizing. Nếu chênh lệch lớn hơn 2 SP — họ thảo luận lý do và bỏ phiếu lại. Quy tắc: nếu không thể ước lượng công việc (yêu cầu không rõ, không có thiết kế) — nó sẽ được gửi lại cho PO để làm rõ và sẽ quay lại grooming tiếp theo với giải trình. Đừng ước lượng các công việc có ẩn số — điều này chắc chắn dẫn đến lỗi trong sprint. Bước 4: Ghi lại kết quả (10 phút). PO ghi lại ước lượng trong Jira/Linear, cập nhật mô tả công việc và đặt ưu tiên.

Kết quả grooming: 3–7 công việc được chuẩn bị đầy đủ cho Sprint Planning (có DoR, ước lượng, thiết kế, API). PO cập nhật backlog: xóa các công việc lỗi thời, hợp nhất các công việc trùng lặp và điều chỉnh ưu tiên. Quan trọng: grooming không kết thúc công việc của PO — giữa các buổi grooming, PO nên chuẩn bị các công việc tiếp theo. Tốc độ khuyến nghị: PO chuẩn bị 3–4 công việc cho grooming và nhóm xử lý chúng. Nếu có hơn 50 công việc trong backlog, PO nên thực hiện phân loại ưu tiên (MoSCoW hoặc Weighted Shortest Job First) trước khi grooming.

Khác biệt giữa grooming và Sprint Planning

Grooming là sự chuẩn bị. Không có cam kết — công việc chỉ được làm rõ và ước lượng. Sprint Planning là một cam kết. Nhóm chọn các công việc từ những công việc đã chuẩn bị trong grooming và cam kết hoàn thành chúng trong sprint. Khác biệt chính: grooming không gắn với một sprint cụ thể (làm mịn backlog tổng thể), không có Sprint Goal trong grooming, và grooming có thể được tổ chức bất cứ lúc nào trong sprint. Sprint Planning diễn ra nghiêm ngặt vào đầu sprint và luôn dẫn đến Sprint Goal.

Trong grooming, các công việc chỉ được ước lượng nhưng không được đưa vào sprint. Trong Planning, các công việc được chọn từ nhóm đã chuẩn bị. Không có grooming, Sprint Planning mất 6–8 giờ (thay vì 4), vì nhóm lần đầu thấy công việc và không thể ước lượng nhanh. Quy tắc 80/20: 80% công việc ở Sprint Planning phải được chuẩn bị đầy đủ (đã qua grooming), 20% có thể là mới (lỗi khẩn cấp, hotfix). Nếu ở Planning có hơn 20% công việc chưa được ước lượng — grooming chưa đủ.

Các lỗi grooming thường gặp

Lỗi 1: grooming một tháng một lần. Nhóm tích lũy công việc của 3–4 sprint và cố gắng làm mịn tất cả trong 2 giờ. Kết quả: một nửa công việc không được ước lượng, Planning mất cả ngày. Giải pháp: grooming nên được thực hiện thường xuyên — một lần mỗi sprint, 60 phút. Nếu có nhiều công việc — hãy thêm buổi grooming thứ hai vào giữa sprint. Tốt hơn là grooming ít công việc nhưng chất lượng hơn nhiều công việc mà hời hợt. Tốc độ: 3–5 công việc mỗi buổi grooming, mỗi công việc được thảo luận và ước lượng đầy đủ.

Lỗi 2: ước lượng không có bối cảnh. PO trình bày công việc “Thực hiện màn hình giỏ hàng” mà không có thiết kế, API hoặc AC. Nhóm ước lượng “bằng mắt” — 13 SP. Trong Planning hóa ra thực tế là 5 SP (vì màn hình đơn giản). Giải pháp: công việc không được ước lượng nếu không có thiết kế hoặc API. PO phải chuẩn bị tài liệu trước khi grooming. Quy tắc: “Không có bản mẫu — không có ước lượng”. Ngoại lệ: công việc Spike — nghiên cứu sự không chắc chắn, được ước lượng riêng không cần thiết kế (2–5 SP tùy độ phức tạp nghiên cứu).

Lỗi 3: grooming biến thành Planning. Nhóm bắt đầu phân công công việc cho cá nhân và thảo luận ai sẽ làm gì. Giải pháp: nhắc nhở rằng grooming là để làm rõ, không phải để phân công. Phân công — trong Daily sau khi sprint bắt đầu. Grooming trả lời “làm gì?”, Planning trả lời “khi nào làm?”, Daily trả lời “ai đang làm?”. Trộn lẫn các câu hỏi này trong một cuộc họp làm giảm hiệu quả của từng cuộc. Scrum Master nên dừng các cuộc thảo luận kiểu Planning và chuyển hướng tập trung vào làm rõ công việc.

Lỗi 4: bỏ qua Tech Debt. Trong grooming chỉ thảo luận các tính năng mới, các công việc kỹ thuật bị bỏ qua. Sau 3–4 sprint, nợ kỹ thuật tích lũy đến mức nguy kịch. Giải pháp: trong mỗi buổi grooming, ít nhất 1 công việc kỹ thuật phải được ước lượng. Tỷ lệ: cứ 3 tính năng → 1 công việc kỹ thuật. Sử dụng chỉ số Tech Debt Ratio: tỷ lệ công việc kỹ thuật so với công việc tính năng trong một sprint. Giá trị mục tiêu: 0.25–0.3 (25–30% thời gian cho nợ kỹ thuật). Nếu tỷ lệ dưới 0.2 — tốc độ phát triển sẽ giảm trong các sprint tiếp theo.