Đối với những lập trình viên nhiều năm kinh nghiệm (trong đó bao gồm chúng tôi - TIGO team) thì BugZilla là một kỷ niệm đẹp với vòng đời của lỗi (Bug Life Cycle) đã đi sâu vào tâm trí hơn một thập kỷ. Chúng tôi nhận thấy sự hiển diện của mô hình vòng đời này ở khắp mọi nơi: Sharepoint, Redmine, JIRA...
Sau này khi mở rộng khái niệm lỗi thành một vấn đề rộng hơn, gọi là "ticket", chúng ta đã tiến thêm một bước về quản lý công việc và quản lý vấn đề chuyên nghiệp. Cụ thể, đối với môi trường phát triển phần mềm, vòng đời của một ticket (bug/issue/task) bao gồm các trạng thái sau:
New
Task mới được tạo, chưa assign cho ai
In Progress (Assigned)
Task đã assign, đang làm
Resolved
Task đã được làm xong bởi người được assigned, tự review xong. Chờ review chéo hoặc review từ cấp trên hay confirm từ khách hàng.
Feedback
Vì một lý do nào đó, task bị "trả lại" cho người tạo ra nó.
Ví dụ: Tester X tìm ra lỗi #2020 assign cho developer Y. Đến lượt Y kiểm tra lại và thấy đó không phải là lỗi do mình gây ra. Khi đó Y sẽ "feedback" lại task #2020 cho X để X assign cho người thích hợp.
Incomplete
Task thiếu thông tin, cần được làm rõ.
Ví dụ: Tester X tìm ra lỗi #2020 assign cho developer Y. Tuy nhiên Y không thể tái hiện được lỗi đó. Khi đó Y sẽ đánh dấu task #2020 là "Incomplete" và assign cho X để X phân tích thêm.
Closed
Nghĩa là "done". Đóng task sau khi Tester X "verify" là hoàn thành hoặc vì một lý do nào đó không được xem là lỗi nữa, bất cứ ai cũng có thể đóng task đó miễn là có quyền đối với trạng thái này.
Rejected
Task sai hoặc không phải lỗi (thí dụ trông có vẻ là lỗi, nhưng thực tế là do thiết kế - By Design)
Pending
Treo task, tạm thời chưa làm. Có thể đẩy lùi task sang sprint sau nhưng không đóng task.
Reopen
Mở lại 1 task/issue đã đóng.
Ví dụ: Developer Y fixed xong lỗi #2020 và Tester X đã closed lỗi đó. Tuy nhiên sau đó Tester X phát hiện lỗi này chưa được fix hẳn. Khi đó Tester X reopen lại lỗi #2020 .
Verified
Lỗi đã được verified bởi tester X sau khi tiếp nhận báo cáo lỗi từ phía khách hàng. Mục đích của trạng thái này là để cho PM nắm được tình hình độ phủ của lỗi (bug coverage) cũng như ngầm kiểm tra xem Tester team có thực sự đang làm việc tích cực hay không. Nhiệm vụ số 1 của Tester là tìm ra bug chất lượng, nhiệm vụ số 2 của Tester là phải verify bug sau khi đã fix.
Ngoài các trạng thái chính ở trên, còn có các trạng thái phụ sinh ra từ một số trạng thái chính. Thí dụ một task đang ở trạng thái "Đang hoàn thành", khi chuyển tiếp trạng thái tiếp theo, bắt buộc Developer X hoặc Tester Y phải nhập một "giải pháp" (possible resolution). Thông tin này rất hữu ích để verify hoặc close task sau đó.
Các possible resolution có thể là:
INVALID
Lỗi sai. Thí dụ nhập dữ liệu không đúng với hướng dẫn.
WON_FIX
Không phải làm, không phải sửa. Lý do "won't fix" có thể là: báo cáo sai, chưa cần thiết phải làm/fix trong sprint hiện tại, tuy là lỗi nhưng có workaround (giải pháp cứu nguy) nên chấp nhận được, hoặc độ ưu tiên/cần thiết của task là thấp.
DUPLICATE
Task bị trùng lặp với một task khác. Cần chuyển Close ngay.
KẾT LUẬN
Trên đây là những status cơ bản của một issue/ticket/bug. Theo kinh nghiệm của các chuyên gia TIGO, dự án cỡ trung bình trở lên (> 1000 man-days) nên có quy trình 2 pha trạng thái như trên.
Đối với dự án bé hoặc công ty phần mềm non trẻ, chỉ cần 1 pha trạng thái với 3-4 điểm nút là đủ để hoàn thành nhanh một dự án với chất lượng vừa đủ. Cụ thể hơn, chúng ta có thể đơn giản hoá vòng đời của task với các bộ status như sau:
New, In Progress, Resolved, Closed
Hoặc theo cách của Kanban:
TODO, DOING, DONE (Basic Kanban)
hoặc TODO, DOING, VERIFYING, DONE (thêm Verifying: Kiểm tra)
Tham khảo:
1. A life cycle of a bug:
http://www.bugzilla.org/docs/3.0/html/lifecycle.html
2. Design a workflow with Redmine:
Nguồn: TIGO
