Backlog trong phát triển ứng dụng: nó là gì, cấu trúc và quản lý tác vụ
Backlog — là danh sách có thứ tự của tất cả các tác vụ, yêu cầu và cải tiến cần được triển khai trong một dự án. Nó là một artifact trung tâm của các phương pháp linh hoạt: trong Scrum, backlog được quản lý bởi Product Owner, trong Kanban — bởi toàn bộ nhóm. Theo Scrum Guide, 2020, backlog không bao giờ hoàn thành: nó liên tục phát triển cùng với sản phẩm và nhu cầu thị trường.
Những Điểm Chính
- Backlog — danh sách tất cả các tác vụ dự án, được sắp xếp theo mức độ ưu tiên và sẵn sàng thực hiện.
- Các yếu tố chính — user story, lỗi, nợ kỹ thuật, nghiên cứu và tác vụ cải tiến.
- Sắp xếp ưu tiên — quy trình chính: các tác vụ ở đầu backlog là quan trọng nhất và sẵn sàng cho sprint.
- Product Owner — chủ sở hữu backlog, chịu trách nhiệm về nội dung và mức độ ưu tiên.
- Grooming (refinement) — hoạt động thường xuyên để làm rõ, ước lượng và sắp xếp lại thứ tự ưu tiên các mục trong backlog.
Backlog trong phát triển là gì?
Backlog — là một nguồn yêu cầu duy nhất cho tất cả các thay đổi trong sản phẩm. Product Owner chịu trách nhiệm về nội dung, tính khả dụng và tính minh bạch của nó: mọi thành viên trong nhóm phải hiểu những tác vụ nào có trong backlog và chúng sẽ được triển khai theo thứ tự nào.
Sự khác biệt giữa Product Backlog và Sprint Backlog
Product Backlog chứa tất cả các tác vụ dự án cho tương lai — từ tính năng cho quý tiếp theo đến ý tưởng cho năm. Sprint Backlog là một tập hợp con các tác vụ từ Product Backlog mà nhóm đưa vào sprint hiện tại. Sprint Backlog bị đóng băng trong sprint, trong khi Product Backlog thay đổi liên tục.
Backlog trong Scrum vs Kanban
Trong Scrum, backlog được cấu trúc chặt chẽ: có Product Backlog và Sprint Backlog, các tác vụ được ước lượng bằng story point, sprint có độ dài cố định. Trong Kanban, backlog linh hoạt hơn: các tác vụ được kéo khi nhà phát triển rảnh, mức độ ưu tiên có thể thay đổi hàng ngày và giới hạn WIP (work in progress) điều chỉnh luồng tác vụ.
Các yếu tố của backlog: nó bao gồm những gì
Một backlog chất lượng chứa nhiều loại tác vụ khác nhau, không chỉ các tính năng mới. Một backlog cân bằng xem xét tất cả các khía cạnh của phát triển sản phẩm.
| Loại yếu tố | Mô tả | Ví dụ |
|---|---|---|
| User Story | Chức năng mới từ góc nhìn người dùng | “Là người dùng, tôi muốn đặt lại mật khẩu” |
| Bug | Lỗi trong chức năng hiện có | “Nút đăng ký không hoạt động trên iOS 16” |
| Tech Debt | Cải thiện mã nguồn mà người dùng không thấy được | “Cập nhật dependencies lên phiên bản mới nhất” |
| Spike / Research | Nghiên cứu hoặc nguyên mẫu để giảm sự không chắc chắn | “Khám phá khả năng di chuyển sang Jetpack Compose” |
| Improvement | Cải tiến quy trình hoặc cơ sở hạ tầng | “Thiết lập CI/CD cho bản dựng tự động” |
User Story là yếu tố chính
Khối xây dựng chính của backlog là User Story (câu chuyện người dùng). Một User Story chất lượng mô tả giá trị mà người dùng sẽ nhận được, chứ không phải các hành động kỹ thuật cần thực hiện. Định dạng INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Một câu chuyện phải vừa trong một sprint, nếu không nó cần được phân rã.
Tiêu chí chấp nhận
Tiêu chí chấp nhận xác định khi nào một tác vụ được coi là hoàn thành. Chúng được viết theo định dạng Given-When-Then hoặc dưới dạng danh sách điều kiện đơn giản. Ví dụ: “Người dùng có thể đặt lại mật khẩu qua email, email đến trong vòng 30 giây, liên kết có hiệu lực trong 24 giờ.” Tiêu chí chấp nhận rõ ràng loại bỏ tranh cãi ở giai đoạn demo.
Sắp xếp ưu tiên backlog: phương pháp và cách tiếp cận
Sắp xếp ưu tiên là quy trình quan trọng và phức tạp nhất của quản lý backlog. Product Owner phải xem xét giá trị kinh doanh, công sức, rủi ro và sự phụ thuộc giữa các tác vụ.
MoSCoW: Must-Should-Could-Won’t
MoSCoW là phương pháp sắp xếp ưu tiên cổ điển. Must have — tác vụ quan trọng cho sản phẩm. Should have — tác vụ quan trọng có thể trì hoãn. Could have — cải tiến nên có. Won’t have — tác vụ dời lại tương lai. Phân bổ: 60% Must, 20% Should, 20% Could. Phương pháp này giúp tập trung vào chức năng quan trọng.
Ma trận Giá trị vs Công sức
Ma trận Giá trị vs Công sức chia tác vụ thành bốn góc phần tư: Quick Wins (giá trị cao, công sức thấp) — làm trước, Big Bets (giá trị cao, công sức cao) — lên kế hoạch trước, Fill-ins (giá trị thấp, công sức thấp) — làm xen kẽ, và Avoid (giá trị thấp, công sức cao) — không làm. Cách tiếp cận này tối đa hóa giá trị với nguồn lực hạn chế.
Weighted Shortest Job First (WSJF)
WSJF là phương pháp sắp xếp ưu tiên từ SAFe dựa trên công thức: giá trị / kích thước tác vụ. Tỷ lệ giá trị trên kích thước càng cao, mức độ ưu tiên càng cao. WSJF xem xét giá trị kinh doanh, tính cấp thiết về thời gian và rủi ro. Phương pháp này phù hợp với các nhóm sản phẩm trưởng thành có khối lượng backlog lớn.
Cách quản lý backlog: các phương pháp tốt nhất
Quản lý backlog hiệu quả đòi hỏi các hoạt động thường xuyên, công cụ phù hợp và kỷ luật của toàn bộ nhóm.
Backlog Refinement (Grooming)
Refinement là cuộc họp thường xuyên (thường mỗi tuần một lần) nơi nhóm làm rõ, ước lượng và sắp xếp lại thứ tự ưu tiên các mục backlog. Scrum Guide khuyến nghị dành không quá 10% thời gian của nhóm cho refinement. Kết quả: 20-30% đầu của backlog sẵn sàng cho kế hoạch sprint — có ước lượng, tiêu chí chấp nhận và phê duyệt.
Nguyên tắc DEEP cho backlog
- Detailed appropriately — tác vụ gần được chi tiết hóa, tác vụ xa chỉ là ý tưởng.
- Estimated — tất cả tác vụ cấp cao được ước lượng bằng story point hoặc giờ.
- Emergent — backlog thay đổi liên tục: tác vụ được thêm, xóa, sắp xếp lại ưu tiên.
- Prioritized — mỗi tác vụ có thứ tự riêng, không có tác vụ nào chia sẻ cùng mức ưu tiên.
Công cụ quản lý backlog
Các công cụ phổ biến nhất để quản lý backlog: Jira (tiêu chuẩn ngành với cấu hình quy trình linh hoạt), Linear (trình theo dõi nhanh và hiện đại), Trello (cho nhóm nhỏ và Kanban), Notion (không gian làm việc linh hoạt với cơ sở dữ liệu) và YouTrack. Việc chọn công cụ phụ thuộc vào quy mô nhóm, phương pháp luận và ngân sách.
Những sai lầm phổ biến trong quản lý backlog
Ngay cả Product Owner giàu kinh nghiệm cũng mắc sai lầm trong quản lý backlog làm giảm hiệu quả của nhóm và chất lượng sản phẩm.
Backlog như bãi chứa ý tưởng
Sai lầm phổ biến nhất là ném tất cả ý tưởng vào backlog mà không lọc hay sắp xếp ưu tiên. Backlog phình to đến hàng trăm tác vụ, gây khó khăn trong việc điều hướng. Giải pháp: thường xuyên dọn dẹp backlog — xóa tác vụ cũ, hợp nhất tác vụ tương tự, hoãn tác vụ không khẩn cấp. Một backlog lành mạnh chứa 50-100 mục, không phải hàng nghìn.
Thiếu tác vụ kỹ thuật
Khi backlog chỉ gồm User Stories, nợ kỹ thuật tăng lên và cải tiến cơ sở hạ tầng bị trì hoãn. Sớm hay muộn, nhóm sẽ chạm trần hiệu suất do dependencies cũ, thiếu kiểm thử hoặc vấn đề kiến trúc. Quy tắc: 20% tác vụ trong sprint phải là kỹ thuật — tái cấu trúc, kiểm thử, cập nhật.
Backlog dài hạn quá chi tiết
Chi tiết hóa tác vụ 3-6 tháng trước là lãng phí thời gian. Yêu cầu thay đổi, thị trường phát triển và các tác vụ chi tiết phải được viết lại. Chỉ chi tiết hóa những tác vụ sẽ vào 1-2 sprint tới. Đối với tác vụ xa, một tiêu đề và mô tả ngắn là đủ.
Bỏ qua lỗi
Lỗi nhỏ không vào backlog vì “không có thời gian” hoặc “để sau sửa.” Theo thời gian, lỗi tích tụ, chất lượng giảm và sản phẩm mất niềm tin của người dùng. Quy tắc: mọi lỗi đều được ghi vào backlog, ngay cả khi mức ưu tiên thấp. Nếu lỗi đã tích tụ nhiều — hãy dành một sprint để sửa chúng.
Câu hỏi thường gặp
Product Backlog khác Sprint Backlog như thế nào?
Product Backlog là danh sách đầy đủ tất cả tác vụ dự án dài hạn, được quản lý bởi Product Owner. Sprint Backlog là tập hợp con tác vụ từ Product Backlog mà nhóm đưa vào sprint hiện tại. Sprint Backlog bị đóng băng trong sprint, Product Backlog thì thay đổi liên tục.
Ai chịu trách nhiệm về backlog trong Scrum?
Backlog là trách nhiệm của Product Owner. Người này xác định mức độ ưu tiên, xây dựng tác vụ và quyết định khi nào các mục sẵn sàng cho sprint. Nhà phát triển có thể đề xuất thay đổi, thêm tác vụ kỹ thuật và ước lượng độ phức tạp, nhưng quyết định cuối cùng về ưu tiên thuộc về Product Owner.
Bao lâu nên tổ chức grooming backlog?
Grooming được khuyến nghị mỗi tuần một lần hoặc ít nhất mỗi sprint một lần. Scrum Guide khuyến nghị dành không quá 10% thời gian của nhà phát triển cho refinement. Với sprint hai tuần, đó là khoảng 1-2 giờ mỗi tuần. Grooming thường xuyên ngăn chặn sự tích tụ “rác” trong backlog.
Backlog nên có bao nhiêu mục?
Một Product Backlog lành mạnh chứa 50-100 mục. Ít hơn nghĩa là nhóm không nghĩ về tương lai; nhiều hơn nghĩa là backlog biến thành bãi chứa. Điều quan trọng không phải số lượng mục mà là chất lượng của chúng: 20-30% đầu phải sẵn sàng cho sprint, phần còn lại ở các mức độ chi tiết khác nhau.
Có thể thay đổi backlog trong sprint không?
Product Backlog có thể thay đổi bất cứ lúc nào — đó là trạng thái bình thường của nó. Tuy nhiên, Sprint Backlog bị đóng băng trong sprint để nhóm có thể tập trung vào mục tiêu. Ngoại lệ duy nhất: nếu Product Owner loại bỏ một tác vụ khỏi sprint vì nó không còn phù hợp.
Tổng kết
- Backlog — nguồn yêu cầu duy nhất cho mọi thay đổi trong dự án, được quản lý bởi Product Owner.
- Yếu tố chính — User Stories, lỗi, nợ kỹ thuật, nghiên cứu, cải tiến quy trình.
- Sắp xếp ưu tiên — kỹ năng chính của PO: phương pháp MoSCoW, Giá trị vs Công sức, WSJF giúp đặt ưu tiên.
- Nguyên tắc DEEP — backlog cần được Chi tiết, Ước lượng, Linh hoạt và Ưu tiên.
- Grooming — hoạt động hàng tuần để làm rõ và ước lượng tác vụ cấp cao.
- Sai lầm phổ biến — bãi chứa ý tưởng, thiếu tác vụ kỹ thuật, chi tiết quá mức, bỏ qua lỗi.
- Kích thước lành mạnh — 50-100 mục, 30% đầu sẵn sàng cho sprint.
Chúng tôi sẽ phát triển ứng dụng di động chìa khóa trao tay
IT Sectr tạo các ứng dụng iOS và Android cho các công ty khởi nghiệp và doanh nghiệp từ năm 2017. Chúng tôi sẽ tư vấn và đề xuất giải pháp tốt nhất cho bạn.
Đọc thêm