Tại sao chúng ta cần cả Ưu tiên và Mức độ nghiêm trọng?

Tôi hiểu những gì họ xác định nhưng nó có thực sự hữu ích khi gán chúng cho các vấn đề được tìm thấy không? Ý tôi là, nó là cần thiết để sửa chữa nhanh chóng hoặc không.

Tôi biết cách đặt chúng, phân loại chúng, v.v ... Tôi biết rằng IEEE / ISO bắt buộc phải làm điều đó. Tôi không hiểu tại sao.

Hoàn toàn có thể có những giá trị khác nhau. Nếu bạn bán cho một cơ quan chính phủ quan trọng đòi hỏi hiệu năng cao nhưng sẽ không bao giờ sử dụng mô-đun X, thì việc khắc phục lỗi cơ sở dữ liệu nhỏ sớm hơn một lỗi nghiêm trọng trong mô-đun X sẽ rất có ý nghĩa. Về cơ bản, lý do kỹ thuật không phải là yếu tố duy nhất khi bạn điều hành một doanh nghiệp phần mềm .

Lỗi ngày giờ

Lỗi: Xử lý cuối năm sẽ làm hỏng hoàn toàn cơ sở dữ liệu của bạn. Đó rõ ràng là một lỗi nghiêm trọng.

Ngày: 15 tháng 12. Lỗi được ưu tiên rất cao.

Ngày: 2 tháng 2. Lỗi là ưu tiên thấp.

Vô tình phóng tên lửa

Lỗi: Phần mềm kiểm soát ICBM xuất hiện khi đi từ ngày 28 tháng 2 đến ngày 1 tháng 3 sau khi chia hết cho 4. Kết quả là một lần khởi chạy không được phép.

Đó là một lỗi nghiêm trọng như có thể tồn tại. Tuy nhiên, mức độ ưu tiên rất thấp - có bất kỳ cơ hội thực tế nào mà phần mềm sẽ được sử dụng khi điều kiện được kích hoạt không?

Vô ý 'xấu' trên màn hình

Lỗi: Tin nhắn tràn ra không gian của họ trên màn hình dẫn đến một tham chiếu thô tục vô tình đến Bob xuất hiện. (Thế giới thực: Chúng tôi đã có những người làm việc trong bộ phận "Ass cuối cùng". "Ass" = "Hội".)

Thật không may, ngày mai bạn đang thực hiện một bài thuyết trình trong đó việc bán hàng được thực hiện hoặc phá vỡ cho công ty. Bạn đang thuyết trình cho ai đó tên là "Bob". Mức độ nghiêm trọng: Rất thấp. Ưu tiên: Rất cao.

Bạn đã viết:

Ý tôi là, nó là cần thiết để sửa chữa nhanh chóng hoặc không.

Đúng rồi. Nếu bạn giống như hầu hết các công ty, tuy nhiên, tài nguyên của bạn bị hạn chế. Hoặc bạn không có đủ người để khắc phục tất cả các vấn đề hoặc bạn không có đủ thời gian.

Với thực tế là một lỗi cần phải được sửa chữa nhanh chóng hoặc không, và bạn có rất nhiều lỗi cần phải sửa, "ưu tiên" trả lời câu hỏi "tôi phải sửa lỗi nào trước"?

Mặt khác, mức độ nghiêm trọng là một chỉ số được sử dụng bởi người đặt mức độ ưu tiên. Từ quan điểm của một nhà phát triển, mức độ nghiêm trọng là một điểm cần thiết. Từ quan điểm của một công việc được giao, mức độ nghiêm trọng là một phần thông tin quan trọng giúp cho quá trình ra quyết định.

Tất nhiên, tất cả những điều này là thông tin rất chung chung. Nếu bạn là một nhóm có nhiều lỗi tồn đọng lâu dài, mức độ ưu tiên và mức độ nghiêm trọng có nghĩa là một cái gì đó hoàn toàn khác so với khi bạn ở trong một nhóm có cơ sở dữ liệu lỗi gần như trống rỗng.

Nếu bạn thuộc nhóm có "mức độ nghiêm trọng cao == mức độ ưu tiên cao" thì không vấn đề nào trong số này và bạn không cần cả hai số liệu. Vào cuối ngày, đây chỉ là những công cụ. Nhóm của bạn cần quyết định cách sử dụng chúng. Đối với nhóm của bạn, nó có thể không có ý nghĩa để sử dụng cả hai.

IMHO, đặt cả Ưu tiên và Mức độ nghiêm trọng chỉ là quan liêu.

Trong thực tế, bạn chỉ cần một thước đo "tầm quan trọng". Thông thường, ưu tiên được sử dụng cho nó và mức độ nghiêm trọng sau đó được sử dụng như thuật ngữ kỹ thuật như "high = crash system hoặc làm cho nó không sử dụng được", "trung bình = hành vi lỗi, có khả năng gây hại", "thấp = phiền toái, khó chịu nhưng vô hại"

Thông thường, ưu tiên đi đôi với mức độ nghiêm trọng. Một vài ví dụ phản biện là "sự phiền toái mà mọi người luôn phàn nàn" hoặc "sự cố đã xảy ra một lần trong một môi trường kỳ lạ".

... Nhưng, cuối cùng, với tư cách là nhà phát triển (hoặc người quản lý, v.v.), bạn chỉ cần biết theo thứ tự nào bạn nên sửa chữa / cải thiện mọi thứ, chỉ vậy thôi. Vì vậy, một biện pháp là đủ.

Nhu cầu ưu tiên rất rõ ràng: cần biết các báo cáo lỗi cần được xử lý theo thứ tự nào. Một cái khác, IMHO như thường lệ, là quan liêu. Tại sao bạn cần nó? Nó rõ ràng là vô dụng để sắp xếp bởi vì ưu tiên làm điều đó. Và hậu quả (mô tả mức độ nghiêm trọng) được mô tả trong báo cáo lỗi.

Tôi thậm chí nghĩ rằng nó có hại vì nó làm cho nó không rõ ràng về lỗi nào quan trọng hơn:

• Một số người có thể nghĩ rằng lỗi "quan trọng" có mức độ ưu tiên cao hơn lỗi "mức độ ưu tiên cao".
• Một số người dùng báo cáo lỗi có thể nhầm lẫn mức độ nghiêm trọng và mức độ ưu tiên
• ... hoàn toàn, nó làm tăng thêm sự nhầm lẫn về thứ tự các lỗi nên được xử lý

Ngoài các câu trả lời khác, hãy xem xét kịch bản này: lỗi A sẽ mất 30 phút để khắc phục và có mức độ nghiêm trọng 'thấp'; lỗi B có thể mất hơn 2 tuần để khắc phục và có mức độ nghiêm trọng 'cao'. Ngoài ra, lỗi B có thể mất nhiều thảo luận và phối hợp trong nhóm phát triển và có lẽ ngoài nhóm; lỗi A có thể được sửa bởi một dev ngay lập tức. Hoàn toàn ổn khi đặt mức độ ưu tiên cao hơn cho lỗi A.

Tất nhiên, "mức độ nghiêm trọng" và "mức độ ưu tiên" có thể được diễn giải theo nhiều cách khác nhau.

Trong một trình theo dõi lỗi nhỏ tôi đã sử dụng cho riêng mình, thay vào đó tôi ưu tiên 'độ khó' và 'mức độ ưu tiên' trong đó các vấn đề nghiêm trọng cao sẽ luôn có mức độ ưu tiên cao nhất và tôi có thể quyết định trì hoãn việc xử lý chúng dựa trên độ khó.

Một điều tôi không thích về 'mức độ nghiêm trọng' là nó chỉ áp dụng cho các lỗi và không phải là các tính năng. Có thể tốt hơn nếu có một danh sách duy nhất tất cả các vấn đề được sắp xếp theo mức độ ưu tiên và độ khó vì nó hữu ích hơn để quyết định 'tôi sẽ làm gì tiếp theo?'.

Tôi đã thiết kế và thực hiện các quy trình trong một công ty phần mềm được chứng nhận ISO 9001: 2007. Đã có những cập nhật cho tiêu chuẩn từ năm 2007 vì vậy có thể có những yêu cầu bổ sung mà tôi không biết ... tuy nhiên:

Tiêu chuẩn ISO 9001 là về việc đảm bảo rằng công ty của bạn thiết kế và thực hiện các quy trình có các vòng phản hồi để cải thiện quy trình khi xác định lỗi sản phẩm và quy trình.

Trong giai đoạn thiết kế, các yêu cầu tập trung vào việc liệu giải pháp được đề xuất nếu được triển khai đúng có thực sự giải quyết được bản tóm tắt thiết kế (xác nhận) hay không và kiểm tra xem việc triển khai có thực sự được thực hiện mà không có lỗi hay không (xác minh)

Trên vòng phản hồi, khi các lỗi được xác định, chúng không được ghi lại. Một khiếm khuyết cũng cần được đánh giá mức độ nghiêm trọng, và việc làm lại được ưu tiên.

Phần quan trọng, là cách công ty cụ thể của bạn quyết định đánh giá mức độ nghiêm trọng của nó và đưa ra quyết định về mức độ ưu tiên không được xác định theo tiêu chuẩn ISO. Đó là một vấn đề thương mại và quản trị để công ty quyết định và lập tài liệu.

Vì nó được viết thành tiêu chuẩn theo yêu cầu, bất kỳ công ty được chứng nhận nào cũng sẽ có một quy trình xoay quanh việc đánh giá mức độ nghiêm trọng của khuyết tật và quy trình xác định mức độ ưu tiên của công việc để khắc phục lỗi. Chúng chắc chắn là hai quyết định riêng biệt cần phải được đưa ra.

Mức độ nghiêm trọng của lỗi chỉ là một điểm dữ liệu. Tác động của khách hàng Là một điểm dữ liệu khác. Ngoài ra còn có nỗ lực khắc phục, lỗi tuổi tác, tuổi thọ thương mại còn lại trong sản phẩm và bất kỳ yếu tố nào khác mà công ty quyết định đưa vào quyết định của mình. Một điều không nên viết là khiếm khuyết hiện tại cho người quản lý sản phẩm để quyết định mức độ ưu tiên vì điều đó chỉ xác định thẩm quyền đưa ra quyết định và không xác định quy trình mà họ tuân theo để đưa ra quyết định.

Tôi có một ưu tiên cho việc ưu tiên thiên về việc cung cấp một tỷ lệ cao các thay đổi nhỏ và quan trọng, vì điều này dường như mang lại sự thúc đẩy tốt nhất cho độ tin cậy của sản phẩm nói chung. Điều này có nghĩa là một lỗi nghiêm trọng cần nhiều công sức để khắc phục sẽ cần công việc của nó được chia thành các phần nhỏ hơn để có đủ mức độ ưu tiên để được lên lịch.

Vì lý do khác biệt mạnh mẽ về mức độ ưu tiên và mức độ nghiêm trọng:

Một ví dụ đơn giản. Hãy tưởng tượng trường hợp bạn có một vị trí hẹp ngăn cản việc mở rộng hệ thống của bạn - một số thuật toán có độ phức tạp O (N ^ 3), trong đó N là số lượng cửa hàng của khách hàng. Khách hàng nói rằng họ sẽ mở 200 cửa hàng mới trong năm tới và các tính toán cần thiết (phân phối hàng hóa, lập kế hoạch vận chuyển, v.v.) sẽ không được hoàn thành kịp thời gian. Nhưng, hiện tại khách hàng này chỉ có 30 cửa hàng, và tài nguyên là đủ. Nhiệm vụ tối ưu hóa thuật toán này (thành O (N ^ 2) hoặc tốt hơn) chắc chắn rất quan trọng (bạn sẽ mất ứng dụng khách nếu không triển khai), nhưng có thể không khẩn cấp: bạn có vài tháng để thực hiện thuật toán mới.

Ví dụ 2: một ứng dụng gặp sự cố một cách có hệ thống, nhưng phiên bản này sẽ hết sử dụng trong một vài ngày do nâng cấp hoặc di chuyển. Khắc phục là khẩn cấp vì sự cố thực sự ảnh hưởng đến trải nghiệm người dùng, nhưng có tầm quan trọng thấp.

Tất nhiên, cả hai tham số được thống nhất bằng cách sử dụng một số số liệu (chính thức hoặc không chính thức) để tạo ra một kế hoạch làm việc ngắn hạn, bởi vì tham số này là một chiều (chuỗi nhiệm vụ). Nhưng trong quan điểm dài hạn, họ sẽ không được thống nhất.