Phân loại bug sẵn sàng ra quyết định
Mẫu phân loại bug để xác định mức ưu tiên và người phụ trách
Làm rõ từng kết quả phân loại: yêu cầu thêm thông tin, chấp nhận và giao phụ trách, gộp trùng lặp, hoãn kèm ngày xem xét lại hoặc từ chối kèm lý do.
Đăng nhập để kiểm tra chế độ xem đã có dữ liệu này, rồi cài App với dữ liệu mẫu để kiểm thử bản ghi, quyết định và bảng tổng quan được liên kết.
Quyết định mà phân loại phải tạo ra
Phân loại bug chuyển một báo cáo thành hành động kế tiếp có kiểm soát. Quyết định nên dựa trên khả năng tái hiện, tác động người dùng và mức khẩn cấp, không phải yêu cầu ồn ào nhất, và cần để lại người phụ trách, phiên bản phát hành mục tiêu hoặc ngày xem xét lại.
- Mức độ nghiêm trọng và mức ưu tiên luôn tách biệt
- Kết quả trùng lặp và cần thông tin vẫn giữ bối cảnh
- Bug được chấp nhận rời hàng đợi cùng người phụ trách và phiên bản phát hành mục tiêu
Quy tắc phân loại
Dùng cùng câu hỏi theo cùng thứ tự
Phân loại nhất quán giúp quyết định backlog dễ giải thích và giảm thổi phồng ưu tiên tùy tiện.
Chúng ta có tái hiện được không?
Xác nhận đường đi hoặc trả lại yêu cầu thông tin cụ thể.
Vấn đề này đã được biết chưa?
Gộp bản trùng lặp vào một vấn đề chuẩn và giữ bối cảnh báo cáo.
Tác động là gì?
Đặt mức độ nghiêm trọng theo hậu quả với người dùng, dữ liệu, bảo mật và vận hành.
Khi nào phải hành động?
Đặt mức ưu tiên theo mức khẩn cấp, cách xử lý tạm và thời điểm phát hành.
Ai phụ trách hành động tiếp theo?
Giao người phụ trách thành phần và phiên bản phát hành mục tiêu hoặc ngày xem xét lại.
Đừng gộp hai quyết định
Mức độ nghiêm trọng mô tả hậu quả; mức ưu tiên mô tả thứ tự xử lý
Hai yếu tố này thường liên quan, nhưng một defect tác động cao có thể được hoãn khi có cách xử lý tạm an toàn, trong khi một vấn đề nhỏ hơn có thể khẩn cấp vì sắp ra mắt.
| Chiều đánh giá | Question | Ví dụ |
|---|---|---|
| Mức độ nghiêm trọng | Defect ảnh hưởng đến người dùng hoặc doanh nghiệp nặng đến mức nào? | Thanh toán đã bị ghi nhận nhưng không có xác nhận là nghiêm trọng. |
| Mức ưu tiên | Đội ngũ cần hành động sớm đến đâu so với các việc khác? | Blocker phát hành là P0 ngay cả trước khi lộ rộng. |
| Cách xử lý tạm | Người dùng có thể hoàn tất tác vụ an toàn bằng cách khác không? | Đối soát thủ công làm giảm mức khẩn cấp tức thời, không làm giảm tác động. |
| Phiên bản phát hành mục tiêu | Ứng viên nào nên chứa phần sửa lỗi? | Web 4.28.0 bị giữ lại cho đến khi xác minh đạt. |
Mỗi dòng cần một lối ra
Ghi lại vì sao bug đã chuyển hoặc chưa chuyển
Backlog trở nên hữu ích khi quyết định bền vững và có thể xem lại.
Cần thông tin
Trả lại yêu cầu cụ thể cho người báo cáo.
Đã chấp nhận
Giao người phụ trách, mức ưu tiên và phiên bản phát hành mục tiêu.
Trùng lặp
Liên kết đến vấn đề chuẩn và giữ bằng chứng mới.
Đã hoãn
Ghi lý do và ngày hoặc tác nhân kích hoạt để xem xét lại.
Đã từ chối
Giải thích ranh giới, hành vi kỳ vọng hoặc trường hợp không được hỗ trợ.
Câu hỏi và ranh giới
Câu hỏi phân loại bug
Hướng dẫn thực tế để xác định mức ảnh hưởng, độ khẩn cấp và người phụ trách.
Đội ngũ nên phân loại bug thường xuyên đến đâu?
Điều chỉnh nhịp theo khối lượng và rủi ro. Báo cáo sản xuất nghiêm trọng cần được định tuyến ngay; đội sản phẩm có thể xem báo cáo thông thường hằng ngày hoặc vài lần mỗi tuần.
Ai nên tham gia phân loại?
Cần có người hiểu tác động đến người dùng, người nắm rõ thành phần bị ảnh hưởng và người có thể nhận trách nhiệm hoặc cam kết thời điểm phát hành.
Có nên đóng bản trùng lặp không?
Có thể đánh dấu là trùng lặp, nhưng hãy giữ người báo cáo, bối cảnh và bằng chứng, rồi liên kết chúng với vấn đề chuẩn. Số lượng bản trùng lặp có thể cho thấy tác động.
Điều gì xảy ra với bug bị hoãn?
Cho chúng một lý do và tác nhân xem xét lại. Trạng thái “để sau” không ai sở hữu chỉ là backlog ẩn tăng thêm.
Làm cho quyết định backlog có thể giải thích
Bắt đầu với các kết quả phân loại đã có dữ liệu
Xem ví dụ đã chấp nhận, cần thông tin, trùng lặp, hoãn và mở lại trước khi điều chỉnh quy tắc.