Các trường hợp nên được mở lại cho các lỗi, hoặc các lỗi nên được mở như một trường hợp mới?

Hiện tại tại nơi làm việc của tôi, chúng tôi sử dụng FogBugz để quản lý tất cả các tính năng và lỗi cho các ứng dụng web khác nhau của chúng tôi.

Khi một tính năng mới được thêm vào một trong các ứng dụng web của chúng tôi, Trường hợp mới sẽ được tạo. Ví dụ: "Tạo mẫu tải lên CSV".

Sau đó tôi làm việc trong trường hợp ghi lại khoảng thời gian tôi đã dành cho nó. Khi vụ kiện này được hoàn thành, tôi sẽ giải quyết nó và nó được chỉ định lại cho người mở vụ án (thường là người quản lý dự án), người sau đó sẽ đóng vụ án.

Nếu có bất kỳ lỗi nào với tính năng này, Trình quản lý dự án của tôi sẽ mở lại trường hợp đó và gán lại cho tôi với một danh sách các lỗi về dấu đầu dòng.

Theo ý kiến ​​của tôi, tôi tin rằng các lỗi đạn nhọn này nên được mở dưới dạng các trường hợp lỗi riêng lẻ, để chúng có thể được theo dõi dễ dàng hơn và không bị lộn xộn với các ghi chú trường hợp tính năng ban đầu.

Các nhà quản lý của tôi không đồng ý với tôi nói rằng việc tính tổng thời gian dành cho tính năng sẽ dễ dàng hơn nếu tất cả chỉ trong một trường hợp.

Hơn nữa, họ tin rằng nó ít gây nhầm lẫn cho khách hàng của chúng tôi vì họ chỉ có 1 tham chiếu số trường hợp cho tính năng này. Tuy nhiên tôi sẽ nhấn mạnh rằng các lỗi nên được xử lý như các trường hợp riêng biệt vì đây là sau khi hoàn thành trường hợp ban đầu.

Tôi có đúng không khi nói rằng các lỗi nên được mở lại như một trường hợp mới? Và những ưu / nhược điểm của mỗi cách quản lý này là gì?

Cả bạn và người quản lý của bạn đều có lý do chính đáng để xử lý theo cách mà mỗi bạn thích, và không có nhu cầu thực sự để thỏa hiệp. Có một giải pháp phù hợp với tôi và giải quyết cả hai mối quan tâm.

Đối với các trường hợp như của bạn, tôi sử dụng phương pháp tiếp cận nhiệm vụ cấp cao / nhiệm vụ phụ cấp thấp (khái niệm tôi đã chọn từ JIRA , không thể biết FogBugz có hỗ trợ rõ ràng ^{như vậy không} ). Bằng cách này, các danh sách gạch đầu dòng "đối diện với khách hàng" chuyển đến các tác vụ cấp cao trong khi "các lần lặp của nhà phát triển" quan trọng đối với tôi được phản ánh trong các tác vụ phụ.

Khi nhiệm vụ cấp cao được "mở lại", tôi tạo một nhiệm vụ phụ mới để theo dõi nỗ lực bổ sung cho bản thân .

Cách đó cho phép nhà phát triển phản ánh rõ ràng tất cả các hoán vị, biến động và xoắn thông qua đặc tả tính năng, vẫn cho phép người quản lý trình bày nó cho khách hàng nếu như hoàn hảo. Bằng cách này, bản trình bày hoàn hảo có giá trị đối với tôi với tư cách là nhà phát triển - bởi vì việc đọc cho khách hàng dễ dàng hơn giúp nhận được các điều chỉnh chính xác hơn.

Điều này cũng tự nhiên cho phép có một lời biện minh rõ ràng trong các trường hợp khi việc thực hiện tính năng mất nhiều thời gian hơn dự kiến ​​ban đầu.

_{Đối với theo dõi thời gian cho mỗi nhiệm vụ hoặc nhiệm vụ phụ - vì JIRA cho phép bao gồm theo dõi nhiệm vụ phụ vào tóm tắt cấp cao hơn, người quản lý tôi có thể theo dõi thời gian trong các nhiệm vụ phụ. Tuy nhiên, ngay cả khi đây không phải là trường hợp, tôi có thể sống với thời gian theo dõi chính thức trong nhiệm vụ "cha mẹ" - trong trường hợp này tôi sẽ chỉ sử dụng các nhận xét nhiệm vụ phụ để nói rằng đã dành bao nhiêu thời gian cho việc lặp cụ thể.}

Nếu đây là tất cả xảy ra trước khi tính năng được phát hành cho khách hàng thì chỉ cần có một trường hợp. Lập luận ở đây là vụ án chưa thực sự hoàn tất cho đến khi nó vượt qua QA và sẵn sàng để được phát hành. Các lợi ích khác - một số trường hợp duy nhất cho hóa đơn và người dùng cuối tham chiếu là hợp lệ và quan trọng.

Khi tính năng đã được phát hành và các lỗi được tìm thấy, các lỗi này sẽ được nêu lên như các vấn đề mới trong phần mềm theo dõi vấn đề của bạn.

Tôi hoàn toàn đồng ý với bạn và FogBugz cũng vậy - đó là lý do tại sao nó xác định các danh mục khác nhau cho Lỗi và Tính năng. FogBugz không được thiết kế để trở thành một công cụ để theo dõi thời gian sử dụng; đây là sản phẩm phụ tình cờ của việc giới thiệu lịch trình dựa trên bằng chứng.

Lỗi cho một tính năng đã hoàn thành có thể được liên kết với trường hợp chính cho tính năng (trong FogBugz, bằng cách sử dụng tên thẻ hoặc tham chiếu chéo hoặc bằng cách đặt chúng thành trường hợp phụ). Tôi có thể thấy rằng đây là một công việc nhiều hơn cho PM của bạn để hợp nhất thông tin trong một số trường hợp, nhưng nó cũng có ý nghĩa để có thể tách thời gian dành cho phát triển ban đầu và thời gian dành cho bảo trì, đặc biệt là cho các hợp đồng giá cố định và bạn sẽ mất khả năng làm điều này nếu bạn đặt mọi thứ vào một trường hợp.

Theo ý kiến ​​của tôi, một khi vé bị đóng thì nên đóng lại, trình theo dõi lỗi của bạn sẽ có khả năng liên kết với các trường hợp khác. Tôi sẽ cố gắng chỉ ra rằng việc tạo ra các lỗi mới và liên kết chúng với trường hợp ban đầu mang lại lợi ích tốt hơn so với phương pháp bạn mô tả.

• khách hàng vẫn có thể có một số tham chiếu có chứa các liên kết đến từng lỗi.
• mỗi trạng thái của lỗi có thể được theo dõi riêng, cho phép ưu tiên và báo cáo trạng thái tốt hơn.
• có các lỗi riêng biệt sẽ cho phép người quản lý của bạn chia nhỏ thời gian dành cho lỗi so với thời gian dành cho việc phát triển các tính năng mới và chỉ nên là một nỗ lực bổ sung tối thiểu để có được tổng số cho tất cả các lỗi liên quan đến thay đổi và sự phát triển của thay đổi đó.
• phân tách các lỗi giúp người quản lý của bạn dễ dàng thu thập các số liệu khác như tổng số lỗi, thời gian trung bình cho mỗi lần sửa lỗi, tỷ lệ các lỗi đã đóng / đang tiến hành / đã sửa.
• các trường hợp riêng biệt cho mỗi lỗi cho phép các nhiệm vụ được phân chia tốt hơn giữa tất cả các nhà phát triển và giữ mỗi trách nhiệm cho công việc của họ hoặc cho phép khả năng này nên được nhiều nhà phát triển thuê hơn vào một ngày sau đó.

Ưu điểm duy nhất cho thiết lập hiện tại của bạn là cực kỳ đơn giản cho những người không phải là người dùng chính của hệ thống. Mục đích của trình theo dõi lỗi là để nhà phát triển có một nơi để báo cáo mọi thứ về một lỗi ở một nơi cũng đủ thân thiện để người khác thấy được tiến trình, hệ thống hiện tại của bạn dường như làm suy yếu hầu hết mọi phần của điều đó.

Các lỗi được tìm thấy trước hoặc sau khi sản phẩm đã được 'vận chuyển / phát hành' cho khách hàng?

Nếu là trước khi phát hành, các lỗi sẽ được theo dõi so với vé ban đầu.

Nếu đó là sau khi phát hành, mỗi lỗi nên là vé riêng của nó.

Nơi tôi làm việc, chỉ những người QA mới có thể đóng một vụ án. Chúng tôi có các hộp kiểm cho Mã được đánh giá, Đã kiểm tra kỹ sư và Demo cho bên liên quan (trong trường hợp của bạn là Trình quản lý dự án). Nếu nhóm QA thấy một trường hợp được đánh dấu là "Xong" không có tất cả các trường này được đánh dấu, họ sẽ đánh dấu nó hoàn tác và gửi lại cho chúng tôi.

Khi một trường hợp đã vượt qua tất cả các giai đoạn này và QA sẽ đóng hồ sơ, mọi vấn đề mới mà họ tìm thấy đều được ghi lại dưới dạng lỗi.

Hệ thống này dường như hoạt động tốt cho chúng tôi.

Tôi nghĩ rằng bạn có thể tranh luận cả hai cách. Tôi sẽ cố gắng ngồi xuống với Thủ tướng và giải thích lý do tại sao bạn nghĩ rằng có những vấn đề riêng biệt sẽ giúp bạn giải quyết. Cá nhân tôi muốn mỗi mục cần làm nên là vé riêng của mình nhưng tôi có thể thấy lý do tại sao anh ấy muốn nó theo cách đó.