Quy trình xử lý lỗi trong nhóm nhanh / Scrum của bạn là gì?

Quy trình xử lý lỗi trong nhóm nhanh / Scrum của bạn là gì?

Đây là của chúng tôi: - Nếu lỗi liên quan đến một câu chuyện trong lần chạy nước rút hiện tại, chúng tôi sẽ sửa nó. - Nếu lỗi không liên quan đến một câu chuyện trong lần chạy nước rút hiện tại và nó không nghiêm trọng, nó sẽ được gửi cho chủ sở hữu sản phẩm để ưu tiên. - Nếu lỗi không liên quan đến một câu chuyện trong giai đoạn nước rút và nó rất nghiêm trọng, chúng tôi sẽ sửa nó.

Bất cứ điều gì liên quan đến công việc trong lần chạy nước rút hiện tại đều được khắc phục, chúng tôi thậm chí không coi chúng là lỗi và không viết chúng lên như vậy. Chúng tôi chỉ coi một cái gì đó là một lỗi nếu nó là một phần của một cái gì đó chúng tôi đã coi là Xong.

Khi một lỗi mới phát sinh, chúng tôi thêm nó vào hồ sơ tồn đọng và nó được ưu tiên bởi các bên liên quan của chúng tôi. Nếu chúng ta còn thời gian trong giai đoạn nước rút, chúng ta có xu hướng khắc phục các lỗi dễ dàng hơn có thể có mức độ ưu tiên thấp hơn nhưng là thứ chúng ta có thể hoàn thành trong thời gian còn lại.

Tôi luôn nghĩ rằng một lỗi chỉ là một câu chuyện đã có một thử nghiệm thất bại, do đó, nó được xác định tốt hơn so với bản thảo truyện đầu tiên điển hình cho các tính năng.

Vì vậy, nếu bạn tin rằng bọ là câu chuyện, bạn coi chúng như những câu chuyện khác liên quan đến ước tính và ưu tiên.

Tôi nghĩ rằng cách tốt nhất để tiếp cận điều này là xác định những gì bạn thực sự muốn xem xét một lỗi trước tiên.

Rất nhiều nhà phát triển sẽ không xem xét một cái gì đó không hoạt động như dự định mà họ hiện đang làm việc không phải là một lỗi, vì thực sự đó không phải là một lỗi. Nếu bạn hiện đang làm việc trên một cái gì đó và nó vẫn còn khiếm khuyết thì lỗi cụ thể không thực sự hoàn tất nên không có lỗi thực sự. Điều ngược lại áp dụng cho công việc đã hoàn thành, nếu bạn đã xác định rằng một cái gì đó đã hoàn thành và sẵn sàng để thử nghiệm / phát hành / sản xuất và sau đó bạn tìm thấy một lỗi trong mã hoặc sử dụng thì bạn chắc chắn có lỗi.

Công ty của tôi sử dụng phương pháp sau để xác định khi nào cần sửa lỗi:

Nếu lỗi nghiêm trọng thì nó được thêm vào lần chạy nước rút hiện tại liên quan đến sản phẩm đó, với mức độ ưu tiên thích hợp. Thông thường, chúng tôi lên kế hoạch thêm khoảng 10% thời gian để cho phép điều này vào giai đoạn nước rút, cũng như có thêm những thứ mà chúng tôi không thực sự có kế hoạch hoàn thành nhưng nếu chúng tôi không có lỗi hoặc điều gì đó đã hoàn thành nhanh hơn chúng tôi dự kiến ​​thì chúng tôi có thể hoàn thành.

Nếu một lỗi không nghiêm trọng thì chúng ta chỉ cần thêm nó vào backlog và thường hoàn thành nó trong lần chạy nước rút tiếp theo.

Tại sao đây là dòng chảy lý tưởng có một số rò rỉ rõ ràng cho nó, và đôi khi những thứ không 'quan trọng' từ góc độ lập trình có thể cần phải được hoàn thành ngay lập tức nếu quản lý quyết định rằng nó cần phải được hoàn thành sớm hơn chúng ta nghĩ hoàn thành

Ở một bên tôi nghĩ rằng điều tốt nhất để làm là chọn một cấu trúc và sau đó gắn bó với nó. Một số tổn thất lớn nhất đối với năng suất bắt đầu xảy ra khi bạn bắt đầu làm những việc không có cấu trúc. Một khi bạn bắt đầu xuống cấp cấu trúc của mình, nó rất dễ dàng để nó đi xuống dốc.

Điều đó có thể đã trả lời quá mức câu hỏi của bạn, nhưng đó chỉ là suy nghĩ của tôi về cách xử lý những điều này.

Chúng tôi làm công việc khiếm khuyết đang diễn ra. Tương tự như thiết lập của bạn, nếu có một vấn đề quan trọng liên quan đến công việc hiện tại, chúng tôi sẽ khắc phục nó như một phần của công việc. Rốt cuộc, không thể gọi một câu chuyện là "xong" nếu có khiếm khuyết liên quan đến nó.

Đối với các lỗi khác, chúng tôi thường sửa chúng khi thời gian cho phép. Nếu có vấn đề cấp bách, chúng tôi sẽ rút lại một số câu chuyện và dành thời gian cho việc sửa lỗi trước khi quay lại công việc tính năng thông thường.

Lỗi được tìm thấy trong Sprint chỉ là một phần của sự phát triển.

Lỗi được tìm thấy sau khi kết thúc Sprint đi vào Product Backlog. Chúng tôi không bao giờ tranh luận với người dùng nếu có gì đó là lỗi hoặc cải tiến hoặc thay đổi. Nếu người dùng muốn gọi nó là một lỗi, thì tốt, nhưng nó vẫn đi vào PB chỉ là bất kỳ công việc mới nào khác.