Khái niệm

Backlog và công việc

Product Backlog, các loại công việc (Story, Task, Bug, task con), User Story với tiêu chí chấp nhận, phân hệ, nhãn và ưu tiên.

Khoảng 3 phút đọc

Product BacklogBacklog

Định nghĩaDanh sách tất cả những việc dự án có thể cần làm — tính năng, lỗi, cải tiến, nợ kỹ thuật — xếp theo độ ưu tiên. Trên cùng là việc sẽ làm sớm nhất và được mô tả rõ nhất; càng xuống dưới càng thô. Backlog “sống”: luôn được thêm, bớt, sắp lại.

Ví dụ

Backlog của dự án UMS có “Xếp lịch thi tự động theo phòng” (13 điểm, ưu tiên cao), “Tích hợp SSO với email trường” (5 điểm), “Quản lý đề tài NCKH” (8 điểm, ưu tiên thấp). Mỗi kỳ lập kế hoạch, PM kéo các việc trên cùng vào sprint.

Trong PentaraDự ánBacklog

Tab Backlog liệt kê các sprint và khối Backlog (việc chưa thuộc sprint nào). Kéo tay nắm ⠿ để chuyển một việc, hoặc tích chọn nhiều việc rồi đưa vào sprint. Thành viên nào cũng tạo được việc mới (nút Tạo công việc trong từng khối, hoặc tab Công việc); việc mới mặc định nằm ở Backlog, cột đầu tiên của Board.

Bộ lọc chung theo người, loại, ưu tiên, phân hệ, nhãn, trễ hạn — dùng khi backlog dài.

Tab Backlog của dự án UMS với sprint đang chạy, sprint kế hoạch và khối Backlog — Tab Backlog: sprint đang chạy, sprint kế hoạch và khối Backlog; mỗi dòng là một công việc có nhãn, phân hệ, ưu tiên, trạng thái, hạn và story point.

Lưu ý thực hành

Backlog không phải kho chứa mọi ý tưởng mơ hồ: việc đưa vào phải có tiêu đề rõ nghĩa và đủ thông tin để ước lượng trong 1–2 sprint tới.
Chỉ một người (PM/PO) chịu trách nhiệm thứ tự ưu tiên; ai cũng được đề xuất nhưng không tự kéo việc của mình lên đầu.
Làm Backlog Refinement đều đặn (30–60 phút mỗi tuần): làm rõ, tách nhỏ, ước lượng trước các việc sắp tới để buổi Planning không kéo dài.

Công việc: Story, Task, Bug, task conIssue

Định nghĩaĐơn vị công việc nhỏ nhất được theo dõi trên Board. Có ba loại: Story — một tính năng nhìn từ phía người dùng; Task — việc kỹ thuật, tài liệu, cấu hình, không trực tiếp là tính năng; Bug — lỗi cần sửa. Việc lớn có thể chia thành task con để nhiều người làm song song.

Ví dụ

Story “Xếp lịch thi tự động theo phòng” (UMS-5) có 2 task con: “Thuật toán xếp lịch tránh trùng giảng viên” (UMS-6) và “Màn hình xem lịch thi theo phòng” (UMS-7). Bug “Không xuất được bảng điểm PDF tiếng Việt có dấu” (UMS-8).

Trong PentaraDự ánCông việcChi tiết công việc

Mã việc = mã dự án + số thứ tự (UMS-12); số tự tăng, không đổi khi sửa. Nhắc đến việc trong bình luận hay chat thì dùng mã này.

Mỗi việc có tiêu đề, mô tả (soạn thảo định dạng), loại, ưu tiên, phân hệ, nhãn, người thực hiện, người tạo, story point, ngày bắt đầu và hạn, trạng thái (cột), sprint, task cha, bình luận có @nhắc tên, đính kèm và lịch sử hoạt động. Task con chỉ 1 cấp. Quản lý dự án xóa được mọi việc; thành viên chỉ xóa việc mình tạo.

Lưu ý thực hành

Tiêu đề theo mẫu “<động từ> + <đối tượng> + <điều kiện>”: “Xuất bảng điểm PDF có dấu tiếng Việt” thay vì “PDF lỗi”.
Mô tả bug: bước tái hiện, kết quả mong đợi, kết quả thực tế, môi trường, ảnh chụp. Mô tả story: tiêu chí chấp nhận (xem mục tiếp theo).
Việc lớn hơn 3 ngày công thì tách task con.
Việc vào sprint luôn phải có người thực hiện — “Chưa giao” là cảnh báo trên báo cáo.

User Story và tiêu chí chấp nhậnAcceptance Criteria

Định nghĩaUser Story là cách viết yêu cầu ngắn gọn từ góc nhìn người dùng: “Là <vai trò>, tôi muốn <điều gì>, để <lợi ích>”. Tiêu chí chấp nhận là danh sách điều kiện kiểm tra được để nói story đã xong.

Ví dụ

“Là cán bộ phòng Khảo thí, tôi muốn xếp lịch thi tự động theo phòng, để không phải xếp tay và tránh trùng giảng viên coi thi.”

Tiêu chí: (1) không có 2 ca thi trùng phòng–giờ; (2) một giảng viên không coi 2 phòng cùng giờ; (3) xuất được lịch ra Excel; (4) chạy dưới 30 giây với 5.000 sinh viên.

Trong PentaraCông việc loại StoryMô tả

Viết story và tiêu chí chấp nhận ngay trong Mô tả (dùng danh sách trong trình soạn thảo). QA dựa vào tiêu chí này để test ở cột Review trước khi kéo sang Done.

Lưu ý thực hành

Story tốt theo INVEST: Independent (độc lập), Negotiable (thương lượng được), Valuable (có giá trị), Estimable (ước lượng được), Small (nhỏ), Testable (kiểm thử được).

Không có tiêu chí chấp nhận = không đưa vào sprint.

Phân hệ, nhãn và ưu tiênModule · Label · Priority

Định nghĩaPhân hệ là mảng nghiệp vụ lớn của sản phẩm (Đào tạo, Khảo thí, Công tác sinh viên, Tài chính, KHCN…) — dùng để nhóm việc và báo cáo theo mảng, tương đương Epic/Component ở công cụ khác. Nhãn là thẻ tự do để gắn thêm ngữ cảnh (backend, report, integration, tech-debt…). Ưu tiên nói việc nào làm trước: Khẩn cấp > Cao > Trung bình > Thấp.

Trong PentaraDự ánCài đặtNhãn

Phân hệ và nhãn do Quản lý dự án quản lý (tab Phân hệ, Cài đặt › Nhãn); mỗi việc thuộc tối đa 1 phân hệ và gắn được nhiều nhãn. Báo cáo có biểu đồ Theo phân hệ (đã xong / còn mở) và Theo loại & ưu tiên; bộ lọc trên Board và Backlog lọc theo cả hai.

Khi chuyển yêu cầu khách hàng thành task, phân hệ và ưu tiên được điền tự động (mức độ Nghiêm trọng → Khẩn cấp, Cao → Cao, …).

Lưu ý thực hành

Giữ số nhãn ít (không quá 10) và viết thống nhất (chữ thường, tiếng Anh) để lọc được.
Không để mọi việc đều “Cao”; nếu hơn 30% việc trong sprint là Khẩn cấp hoặc Cao thì cần sắp lại ưu tiên.