Phân loại nhiệm vụ / lỗi theo nguy cơ thay đổi

Dự án tôi hiện đang thực hiện có một vấn đề: lỗi và nhiệm vụ thường được giao cho những người còn quá mới hoặc quá thiếu kinh nghiệm và công việc của họ cuối cùng tạo ra nhiều lỗi hơn. Vấn đề là các phần của phần mềm của chúng tôi "nguy hiểm" hơn nhiều so với các phần khác do vấn đề về chất lượng mã. Tôi đã cố gắng chống lại vấn đề này bằng cách ước tính rủi ro liên quan đến các nhiệm vụ và chú ý xem nhà phát triển nào được giao nhiệm vụ nào.

Chúng tôi sử dụng JIRA vì vậy tôi bắt đầu dán nhãn các vấn đề để theo dõi ước tính này. Tôi nhận thấy rằng tôi đã kết thúc việc sử dụng một số số liệu để phân loại lỗi / tác vụ:

• Làm thế nào rõ ràng / đơn giản nó là. Ví dụ, liệu đó có phải là thứ cần nhiều công việc thiết kế hay chỉ là sửa lỗi UI đơn giản.
• Làm thế nào duy trì các khu vực bị ảnh hưởng của mã là. Đây có phải là một khu vực được thiết kế tốt hay một quả bóng bùn lớn.
• Bao nhiêu chương trình tôi nghĩ sẽ bị ảnh hưởng bởi sự thay đổi cần thiết.

Nhãn của tôi khá lộn xộn vì tôi không có ý tưởng rõ ràng khi tôi bắt đầu các danh mục có thể là gì và tôi vẫn không biết. Tôi đang suy nghĩ về việc yêu cầu một lĩnh vực mới được thêm vào (một cái gì đó như "Rủi ro") để chúng tôi có thể yêu cầu ước tính trước khi giao công việc cho ai đó.

Có ai đã xử lý loại này trước đây?

Một trong những thất bại của hầu hết các phương pháp theo dõi lỗi là chúng chỉ giải quyết một mặt của phương trình - quan điểm của người dùng cuối về hệ thống. Đây là một lỗi nghiêm trọng để sửa lỗi này có thể đợi một tuần (ưu tiên), lỗi này gây đau đớn vì đây là một strục trặc số nhiều (mức độ nghiêm trọng).

Một bài đăng blog mô tả theo dõi lỗi đa chiều xem xét việc giải quyết vấn đề này bao gồm cả chế độ xem của nhà phát triển: PEF và REV.

Các giá trị PEF là chế độ xem của người dùng:

• P ‍ain - lỗi đau đớn như thế nào khi gặp phải?
• E ffort - bao nhiêu nỗ lực hiện nó đi để làm việc xung quanh?
• F ‍requency - lỗi xảy ra thường xuyên như thế nào?

Phía REV là từ quan điểm của nhà phát triển:

• R ‍isk - cách khắc phục rủi ro như thế nào?
• E ffort - bao nhiêu nỗ lực nó sẽ thực hiện để khắc phục?
• V erifiability - làm thế nào dễ dàng là nó để xác minh rằng lỗi này là cố định?

Mỗi trong số này được đo trên thang điểm 1..9 với 1 là thấp / dễ và 9 là cao / cứng. Các con số được cộng lại với nhau để cho điểm PEF và REV.

Phần giải quyết các bit được mô tả:

• Làm thế nào rõ ràng / đơn giản nó là. Ví dụ, liệu đó có phải là thứ cần nhiều công việc thiết kế hay chỉ là sửa lỗi UI đơn giản.
• Làm thế nào duy trì các khu vực bị ảnh hưởng của mã là. Đây có phải là một khu vực được thiết kế tốt hay một quả bóng bùn lớn.
• Bao nhiêu chương trình tôi nghĩ sẽ bị ảnh hưởng bởi sự thay đổi cần thiết.

Những yếu tố này vào nỗ lực và rủi ro được mô tả trong REV.

Vâng, đó là một cái gì đó đã được chiến đấu với trước đây. Tôi đã (trong quá khứ) đã sử dụng mô hình này cho các trường tùy chỉnh trong Redmine và nó đã thành công một cách hợp lý.

Lợi thế lớn của điều này xuất hiện khi bạn so sánh điểm PEF và REV. Nếu bạn có PEF là 21 và REV là 7, đó là điều có thể là một chiến thắng lớn. Mặc dù PEF là 7 và REV là 21 là điều nên tránh trong một thời gian bởi vì khía cạnh rủi ro và nỗ lực có thể vượt xa lợi ích của việc khắc phục nó.

Sau đó, người ta có thể nhìn vào điểm số REV và gán những thứ có Rủi ro thấp cho các nhà phát triển ít kinh nghiệm (rủi ro thấp, nỗ lực cao thường rất lý tưởng cho tình huống này).

Tôi muốn nói rằng những gì bạn đang đề cập ở đây có thể được gọi là "sự phức tạp". Tất nhiên, một thay đổi càng phức tạp thì 'rủi ro' càng cao là một số lỗi mới có thể được đưa ra bởi một lập trình viên thiếu kinh nghiệm. Việc giới thiệu một lĩnh vực như vậy là một ý tưởng không tồi nếu đó là một vấn đề thực sự.

Tuy nhiên, đánh giá từ những gì bạn viết bạn dường như có hai vấn đề:

1. Bạn đang làm việc với các lập trình viên mới hoặc thiếu kinh nghiệm.
2. Chất lượng (nhiều / một số) mã của bạn dường như có vấn đề.

Ngoài việc giới thiệu một cái gì đó như trường 'phức tạp' (sẽ giúp quản lý và ưu tiên công việc của bạn), tôi sẽ đề nghị bạn tập trung vào việc giảm thiểu rủi ro của hai vấn đề nêu trên.

Để giải quyết vấn đề đầu tiên tôi sẽ tạo ra một quy trình theo đó các lập trình viên mới trước tiên thảo luận về tất cả các lỗi mới với một lập trình viên có kinh nghiệm hơn trước khi làm việc với lỗi này. Ngoài ra, tôi chắc chắn sẽ giới thiệu các đánh giá mã để giảm nguy cơ lỗi mới được giới thiệu và sử dụng làm cơ hội huấn luyện cho các lập trình viên mới để tăng tốc nhanh hơn.

Đối với chất lượng mã, tôi sẽ làm hai việc. Thứ nhất, dừng quá trình mục nát: đồng ý về các tiêu chuẩn và thực tiễn mã hóa sẽ ngăn chặn bất kỳ mã kém mới nào được đưa ra. Các đánh giá mã đề xuất cũng sẽ giúp ở đây. Thứ hai, tôi sẽ xác định các phần tồi tệ nhất trong mã của bạn và bắt đầu tái cấu trúc và dọn sạch chúng.

Vâng, đó là một ý tưởng tốt để không cung cấp cho các nhà phát triển thiếu kinh nghiệm các vấn đề quá phức tạp. Nhưng điều đáng nói là nếu bạn chỉ để họ làm những việc dễ dàng thì họ sẽ không học.

Tôi đề nghị một chiến lược thay thế là thiết lập một chế độ đánh giá mã. Hãy để những người mới làm việc với những thứ khó khăn (trong lý do), nhưng xem xét kỹ lưỡng công việc của họ.

Trong ngắn hạn, đây là công việc nhiều hơn cho tất cả mọi người. Về lâu dài, bạn sẽ kết thúc với cả một nhóm các nhà phát triển có thể xử lý các công cụ phức tạp, VÀ "trên cùng một trang" khi có liên quan đến chất lượng mã.