Là sửa lỗi được thực hiện bởi người khác là một cách tiếp cận tốt?

Hãy giả sử tình huống trong đó một nhóm bốn nhà phát triển đang xây dựng một ứng dụng. Trong giai đoạn thử nghiệm, lỗi được báo cáo bởi người dùng. Ai nên sửa chúng? Người đã phạm mã sai, hoặc bất cứ ai là miễn phí?

Cách tiếp cận ưa thích trong phát triển nhanh (scrum) là gì?

Cách tiếp cận ưa thích trong phát triển nhanh sẽ là sửa chúng càng nhanh càng tốt, bởi bất kỳ ai cũng có sẵn. Điều này đơn giản là vì quyền sở hữu của mã không thuộc về một người nào, mà thuộc về toàn bộ nhóm nhà phát triển. Nếu một cá nhân liên tục gây ra lỗi, đó là một vấn đề khác cần được giải quyết riêng.

Theo mặc định người. Lý do khá đơn giản: thông tin phản hồi. Lỗi cung cấp một cơ hội tuyệt vời cho phản hồi cá nhân và chuyên nghiệp. Nếu ai đó sửa lỗi của tôi, tôi sẽ lại mắc lỗi tương tự, vì tôi sẽ không học được từ đó.

Nếu người đó không có sẵn, người khác có thể sửa nó, nhưng người đó nên theo vòng đời lỗi.

Là một PM tôi sẽ tránh liên kết các lỗi với các nhà phát triển cụ thể. Nếu nó cần phải được thực hiện hãy để người quản lý chức năng / phát triển làm điều đó. Quan tâm đến bản thân với đội. Có một lỗi mà nhóm cần sửa.

Tôi không biết làm thế nào scrum xử lý tình huống này, nhưng trong nhóm của tôi, chúng tôi có một cái gì đó giống như kiểm tra chéo / đánh giá mã. Bằng cách này, trong trường hợp tìm thấy lỗi, cả nhà phát triển và người đánh giá thảo luận về phương pháp tốt nhất để khắc phục nó.

Tôi tin rằng, miễn là giải pháp phù hợp, không quan trọng nếu nhà phát triển hoặc người đánh giá áp dụng nó. Tuy nhiên, điều quan trọng là để tránh bất kỳ loại xung đột nào giữa nhà phát triển và người thử nghiệm.

Rgds

Chỉnh sửa: Không chắc chắn nếu tôi làm cho mình rõ ràng, nhưng điều quan trọng là làm nổi bật rằng người đánh giá là một nhà phát triển khác trong nhóm.

1. Đánh giá lỗi
2. Nếu nó sẽ nhanh hơn / có ý nghĩa hơn cho nhà phát triển ban đầu để sửa nó, hãy cung cấp cho họ
3. Nếu nó có thể được sửa bởi bất cứ ai trong đội, hãy để bất cứ ai làm điều đó.

Tôi hoàn toàn đồng ý với Steven về mã thuộc về tất cả các đội; và có thêm một số lý do mà bạn không nên đưa ra lỗi cho người tạo ra chúng:

Như tôi biết, trong nhiều trường hợp, thật khó để xác định ai gây ra lỗi. Ngay cả khi bạn đang sử dụng một hệ thống quản lý tài liệu như SVN, việc theo dõi mã lỗi có thể tiêu tốn rất nhiều thời gian. Vì vậy, theo quan điểm của tôi, chỉ cần đưa ra lỗi cho bất cứ ai miễn phí.

Nếu bạn muốn theo dõi cách thức lỗi được tạo ra, trong thời gian rảnh rỗi, bạn có thể hỏi người sửa chữa về trường hợp này (trước tất cả các đội). Vì nhóm của bạn nhỏ, tôi nghĩ điều này sẽ chia sẻ kinh nghiệm về các lỗi có thể xảy ra và không khiến ai phải bối rối.

Chỉ có ba lý do để quan tâm đến việc ai sửa lỗi: chi phí, tốc độ và phát triển chuyên nghiệp.

Và có những ưu và nhược điểm cho cả ba. Ví dụ, phát triển chuyên môn, một mặt là cơ hội để tìm hiểu thêm về mã, mặt khác đó là cơ hội để nhận ra các loại lỗi bạn mắc phải và tránh một số lỗi trong tương lai. Hoặc mất chi phí, có lẽ là lỗi đã gây ra lỗi có thể sửa chữa nhanh hơn và có thể rẻ hơn, mặt khác, có một khoảng thời gian dành cho việc xác định ai đã phạm lỗi và giao nó cho người thích hợp - thời gian mà trong rất nhiều trường hợp vượt quá việc sửa lỗi.

Cách tiếp cận nhanh là để cho các nhà phát triển tự giải quyết vấn đề, tôi sẽ ghi đè lên điều đó chỉ vì một lý do chính đáng.

Trong đội của tôi, chúng tôi luôn quyết định theo mức độ ưu tiên. nếu người gửi mã có sẵn, anh ấy / cô ấy sửa mã. Nếu người đó đang thực hiện một số câu chuyện ưu tiên cao hơn, bất kỳ ai có sẵn và có thể sửa mã càng sớm càng tốt sẽ sửa nó. Nếu mọi người đều bận rộn với việc thực hiện các nhiệm vụ ưu tiên cao hơn trong lần lặp hiện tại, việc khắc phục được lên lịch trong lần lặp tiếp theo theo mức độ ưu tiên so với các câu chuyện và khiếm khuyết khác.

Hãy nghĩ về: Ai có thêm thông tin về lỗi này? Nhóm phát triển.

Vì vậy, hãy để họ quyết định làm gì với lỗi. Họ sở hữu mã, vì vậy họ chịu trách nhiệm về nó.

Bạn có thể giúp họ bằng cách quản lý dự án, phân bổ thời gian trên phạm vi dự án để sửa lỗi và để họ một mình thực hiện công việc.

Tránh đưa ra nhiều quyết định trong đó bạn (với vai trò PM) có ít thông tin hơn nhóm.

Xem câu hỏi về: Làm thế nào để tránh vi quản lý nhóm phát triển phần mềm?

Tôi nói, bạn cần một hệ thống theo dõi lỗi, để ghi lại các lỗi, gây ra bởi những gì, được báo cáo và sau đó gán các lỗi cho những người khác nhau dựa trên khối lượng công việc của họ. Cũng cho biết mã của ai gây ra lỗi và sau đó có báo cáo cho biết có bao nhiêu lập trình viên và ứng dụng nào đã gây ra x số lỗi trong tuần.

Sau đó, bạn có thể chỉ ra điều đó cho các lập trình viên, để cho thấy họ đang gây ra lỗi như thế nào.

Và cách tốt nhất để ngăn chặn lỗi, là lôi kéo mọi người tham gia sửa lỗi. Tôi có nghĩa là chỉ định một sửa lỗi cho những người khác nhau, để cung cấp kinh nghiệm toàn diện về nguyên nhân gây ra lỗi và những gì sửa chúng.

Sau đó, có thể sau một hoặc hai tháng mọi người sửa lỗi, sửa đổi hoặc tạo hướng dẫn về kiểu mã hóa của bạn để giúp ngăn ngừa các lỗi trong tương lai, trên toàn hệ thống, bằng cách có các tiêu chuẩn bằng văn bản / tài liệu cho cách bạn lập trình.

Khi một lỗi được tìm thấy, trách nhiệm của toàn bộ nhóm phát triển là sửa lỗi.

Nếu mọi người tin rằng một lỗi nên được sửa bởi tác giả của nó, thì giống như nói rằng "Tôi không sửa lỗi, cái lỗ không nằm ở phía thuyền của tôi". Nhưng thuyền vẫn sẽ chìm nếu lỗ không được cố định, và bạn đang ở trên thuyền đó với những người khác.

Các cá nhân cần nhận ra rằng họ là một phần của một nhóm và hiểu rằng mã, cùng với trách nhiệm của nó, thuộc về tất cả chúng. Sự thành công của một dự án dựa trên tất cả các thành viên trong nhóm.