Câu trả lời:
Các vấn đề mở thường là sự xuất hiện đầu tiên của bất kỳ vấn đề nào.
Các vấn đề được mở lại là 1) xảy ra lại và / hoặc 2) không được khắc phục đúng cách. Có thể có bất kỳ lý do nào cho điều đó - một lý do chính thường có thể được liên kết với mô tả ban đầu của vấn đề cho người dùng cuối.
Tôi không nghĩ rằng bất kỳ cửa hàng hợp lý nào sẽ sử dụng nó như một thước đo để đánh giá nhân viên kỹ thuật [một mình] nhưng nó hữu ích như một biện pháp để xác định mức độ hiệu quả của các phản hồi và cũng có thể biểu thị các vấn đề tiềm ẩn cần được giải quyết.
Công ty cũ của tôi đã sử dụng các trạng thái đó để theo dõi số lần vấn đề của bạn đã được chuyển đến "Mở lại" để xem mức độ "tệ" của nhà phát triển bạn. Họ nghĩ rằng một mối tương quan tồn tại giữa số lần một mục công việc được "Mở lại" và giá trị của bạn với tư cách là một lập trình viên.
Tôi không làm việc ở đó nữa.
Thời gian tồn tại của một lỗi thường là:
I E.
Ai đó tìm thấy một lỗi và mở nó trong trình theo dõi. Các nhà phát triển sửa chữa nó tốt nhất có thể với sự hiểu biết của họ về vấn đề. Người kiểm tra lại kiểm tra để xác minh bản sửa lỗi hoạt động và mở lại nếu họ có thể xác minh rằng bản sửa lỗi không. Nếu sửa chữa được xác minh thì lỗi được đóng lại.
Kịch bản khác, là một sửa chữa ở một nơi khác gây ra hồi quy và lỗi phải được sửa lại. Do đó, nó được mở lại.
Nó cũng có thể làm cho rõ ràng hơn rằng vấn đề cần được chú ý gần hơn hoặc sự chú ý nhanh hơn bởi vì nó tiếp tục là một vấn đề sau khi vấn đề được cho là đã được giải quyết.
Đã mở có nghĩa là nó là một vấn đề mới. Mở lại có nghĩa là ti là một vấn đề đã được mở-> Clossed và sau đó được mở lại.
Tại sao nó được mở lại? Có thể nhà phát triển và người kiểm tra nghĩ rằng sự cố đã được khắc phục nhưng nó không thực sự được khắc phục. Hoặc có thể vấn đề đã thực sự được khắc phục nhưng một số thay đổi mã tiếp theo khác khiến vấn đề trở lại. Không quan trọng bằng cách nào nhưng một vấn đề được mở lại là một dấu hiệu xấu và do đó nó được phân loại khác nhau.
Cách chúng tôi sử dụng nó ở đây:
Nhiệm vụ mới: Được tạo khi bắt đầu dự án để hiển thị tất cả các công việc cần phải hoàn thành. Nó được mở cho đến khi ai đó mã hóa nó, sau đó nó được giải quyết. Nó chỉ được mở lại nếu một cái gì đó không được thực hiện hoặc nếu chức năng thay đổi và nhà phát triển phải quay lại và dành một phần lớn thời gian để làm việc với nó.
Lỗi / Lỗi: Được mở bởi ai đó trong QA hoặc nhà phát triển khác đang kiểm tra tổng thể sản phẩm làm việc. Nếu bạn được chỉ định một lỗi, bạn sửa nó và sau đó giải quyết nó và nó quay lại kiểm tra. Nếu QA cảm thấy nó chưa được sửa, họ sẽ mở lại và đính kèm bất kỳ thông tin nào khác mà họ có vào đó. Chu trình được giải quyết / mở lại có thể diễn ra cho đến khi QA hài lòng rằng lỗi đã được sửa, sau đó họ đóng vé.
Vì vậy, về cơ bản, bạn sử dụng Reopen để nói rằng một vé đã được xem và ai đó đã thực hiện công việc mà họ cảm thấy đã giải quyết nó, nhưng đó không phải là trường hợp.
Về cơ bản, đây là một loại điều nhất quán: Một lỗi (hoặc một vấn đề nói chung) là "mở" nếu nó được tạo ra từ đầu. Đó là "mở lại" nếu được tạo sau khi quá trình xử lý trước đó được thực hiện.
Đối với nhà phát triển (hoặc bất kỳ ai xử lý vấn đề), nó không nên tạo ra bất kỳ sự khác biệt nào. Một hiện tại đã được nâng lên và bây giờ sẽ được xử lý.
Tuy nhiên, trạng thái "mở lại" riêng biệt vẫn có thể hữu ích cho một số tình huống:
Đầu tiên, nó có thể được sử dụng như một cách theo dõi xem quy trình đảm bảo chất lượng của bạn có hoạt động hay không. Nếu QA đã làm mọi thứ đúng, một lỗi sẽ không bao giờ xảy ra sau khi nó đã được sửa. Vì vậy, bạn có thể nói số lần lỗi được đặt ở trạng thái "mở lại" là số lần QA không thực hiện đúng công việc của mình. Tất nhiên điều này ngụ ý rằng có một quy trình QA tốt được thiết lập và người dùng tích cực tham gia vào quy trình và biết khi nào "mở" và khi nào "mở lại" một vấn đề.
Một cách sử dụng khác là, khi một lỗi xảy ra lần nữa, bạn không cần phải khắc phục sự cố mà có thể thêm thông tin một vấn đề đã tồn tại (và do đó giữ thông tin quan trọng như lịch sử sự cố, tệp bổ sung đã được tải lên, nhận xét trước đó và vân vân) nhưng vẫn biểu thị "này, chuyện này lại xảy ra rồi ).
Một lý do chính để theo dõi "mở lại" là nó có thể cung cấp cho bạn một dấu hiệu của các vấn đề được định tuyến sâu, thay vì trượt đơn giản và giám sát chi tiết. Nếu một mô-đun hoặc phần chức năng cụ thể có nhiều "repopens", thì nó chỉ ra một điểm yếu cần giải quyết. Một số lượng lớn các điểm duy nhất mở ra cho công việc gấp rút và / hoặc thực hành cẩu thả.