Có lợi ích cận biên trong việc sửa lỗi [đóng]


27

Tôi đã nghe một đồng nghiệp cũ nói rằng không phải tất cả các lỗi cần phải sửa, bởi vì khi bạn đi xuống danh sách các lỗi ưu tiên, trường hợp sử dụng khiến lỗi đó trở nên tối nghĩa hơn, hoặc sự hài lòng của khách hàng đạt được thấp hơn. Nhưng bạn vẫn phải dành thời gian đáng kể để sửa lỗi đó.

Trong nỗ lực thuyết phục chủ sở hữu sản phẩm của chúng tôi về khái niệm này, tôi không thể tìm thấy bất kỳ tài nguyên tốt nào. Tất cả những gì tôi có thể tìm thấy là các cuộc thảo luận về việc liệu có chi phí cận biên trong phát triển phần mềm hay không.

Có thực sự có lợi ích cận biên trong việc sửa lỗi? Có một thuật ngữ khác giải thích khái niệm này?



2
Câu hỏi của bạn khá không rõ ràng. "Không phải tất cả các lỗi đều cần phải sửa" có nghĩa là có một số lỗi không đáng để sửa. "Có thực sự có lợi ích nhỏ trong việc sửa lỗi" âm thanh đối với tôi bạn có nghĩa là một cái gì đó khác nhau. Bạn có thể vui lòng giải thích?
Doc Brown

2
Đó không phải là cho chủ sở hữu sản phẩm để tìm ra? Tại sao bạn nghĩ rằng bạn cần phải thuyết phục họ về nó?
Ngừng làm hại Monica

@Goyo Tôi không hỏi cụ thể câu hỏi này để thuyết phục họ. Đây là một khái niệm tôi đã gặp một thời gian trước đây nhưng không thể tìm thấy bất kỳ tài nguyên nào nữa. Ngoài ra, không có gì lạ khi một nhà phát triển phần mềm ở vị trí quản lý. Vì vậy, bản thân tôi có thể cần thông tin này trong tương lai.
Gökhan Kurt

2
@ GökhanKurt: Không tuân theo "Tất cả các lỗi cần phải sửa" mà tất cả chúng đều quan trọng như nhau. Một số có thể gây rối hơn những người khác và do đó có mức độ ưu tiên cao hơn.
JacquesB

Câu trả lời:


66

Từ góc độ kinh doanh, sửa lỗi không khác gì một yêu cầu tính năng. Nó có một chi phí nhất định trong thời gian phát triển, và nó có một giá trị nhất định cho khách hàng. Nếu một lỗi không nghiêm trọng, nó hoàn toàn có thể có ý nghĩa kinh doanh tốt để ưu tiên một tính năng có giá trị trên lỗi.

Nhưng từ góc độ kỹ thuật, các lỗi thể nghiêm trọng hơn, bởi vì chúng chỉ ra lỗi trong một nền tảng mà mã khác có thể sử dụng / xây dựng, trong trường hợp đó là lỗi "truyền nhiễm" và thêm chi phí cho bảo trì trong tương lai. Vì vậy, không sửa lỗi là một khoản nợ kỹ thuật cần quản lý, trong khi không triển khai một tính năng không thực sự có chi phí liên tục. Nhưng mức độ nợ kỹ thuật phát sinh do một lỗi rất nhiều phụ thuộc vào bản chất của lỗi.

Tất cả những yếu tố này nên được xem xét khi ưu tiên.

Về việc có một lợi ích cận biên để sửa lỗi hay không: Đây là một lợi ích nhất định. Vì không phải tất cả các lỗi đều có mức độ nghiêm trọng như nhau, nên bạn tự nhiên ưu tiên các lỗi quan trọng nhất trước tiên. Vì vậy, bạn càng sửa nhiều lỗi, giá trị biên của việc sửa lỗi tiếp theo càng thấp. Nhưng cho dù nó đã đạt đến cấp độ thì việc sửa lỗi không đáng để bỏ công sức, là một quyết định kinh doanh hơn là một quyết định kỹ thuật.


Tôi thích câu trả lời này, nhưng tôi sẽ không đi xa để nói rằng một tính năng mới không có chi phí liên tục. Nó thường yêu cầu làm cho mã tổng quát hơn để phù hợp với chức năng mới và bạn sẽ phải sống với mức độ trừu tượng cao hơn bất kể giá trị thực sự của tính năng này là bao nhiêu.
Doval

25
@Doval Bạn hiểu lầm. Những gì Jacques nói là một tính năng chưa được viết không có chi phí hoạt động. Hay nói cách khác, việc không có một tính năng sẽ không làm cho việc triển khai một tính năng khác trở nên khó khăn hơn (tất nhiên trừ khi cái sau phụ thuộc vào cái trước, tất nhiên). Mặt khác, một lỗi khiến cho việc thực hiện bất cứ điều gì khác trở nên khó khăn hơn ngoại trừ sửa nó. Như vậy, "các tính năng không được ghi nhận" và "các lỗi không trộn" là khác nhau, ở chỗ cái trước không ảnh hưởng đến cơ sở mã của bạn, trong khi cái sau thì không.
Sebastian Redl

3
Tôi muốn nói thêm rằng một lỗi cũng có thể ảnh hưởng lớn đến hình ảnh của chương trình (và do đó là toàn bộ sản phẩm và công ty đã sản xuất nó) ... Điều này cần được tính đến: có ai muốn Để lại một lỗi khi, nếu được tìm thấy, có thể chi phí cho công ty một số khách hàng và / hoặc doanh nghiệp?
Olivier Dulac

2
Một ví dụ về các lỗi truyền nhiễm: Trong một trong các dự án của tôi, mọi thứ đều hoạt động tốt, ngoại trừ bộ nhớ được giải phóng trong một đoạn mã không phải lúc nào cũng chạy. Như đã xảy ra, trong tất cả các mã tôi đã viết cho đến lúc đó, nó luôn luôn như vậy; Tôi không bị rò rỉ bộ nhớ cũng không giải phóng gấp đôi, chỉ là một số nhật ký gỡ lỗi có vẻ không đúng. Vì mọi thứ đã hoạt động, tôi đã không sửa nó. Sau đó, tôi đã thêm một số mã, những mã này không còn xếp hàng nữa và tôi bắt đầu bị rò rỉ bộ nhớ. Lỗi như thế là nhỏ, nhưng đáng sửa; thật không may, họ cũng khó có thể nhận ra từ những lỗi nhỏ.
Vụ kiện của Quỹ Monica

5
Chỉ cần mở rộng quan điểm của @ OlivierDulac, một lỗi có thể khiến người dùng cuối nghĩ rằng "Tôi không thể tin tưởng phần mềm này là đáng tin cậy" và bỏ qua nó, bất chấp các tính năng của nó. Tôi chắc chắn rằng tất cả chúng ta đã cài đặt một số phần mềm có vẻ thực sự hữu ích chỉ để gỡ cài đặt phần mềm sau đó vài phút vì nó có vẻ ổn. Trong khi đó, một tính năng bị thiếu có thể được chú ý nhưng khiến người dùng cuối nghĩ rằng "Tôi sẽ tiếp tục sử dụng tính năng này vì tôi thích các tính năng mà nó có". Tôi không nghĩ rằng các lỗi và tính năng nên được xem là tương đương từ góc độ kinh doanh.
Jon Bentley

12

Đây là một tài liệu tham khảo tốt

http://www.joelonsoftware.com/articles/fog0000000043.html

Bạn có sửa lỗi trước khi viết mã mới không? Phiên bản đầu tiên của Microsoft Word dành cho Windows đã được coi là một dự án chết chóc của Vương quốc Hồi giáo. [...] bởi vì giai đoạn sửa lỗi không phải là một phần của lịch trình chính thức [...]

Microsoft đã áp dụng một cách phổ biến một cái gì đó [...] ưu tiên cao nhất là loại bỏ các lỗi trước khi viết bất kỳ mã mới nào [...] Nói chung, bạn càng chờ đợi lâu hơn trước khi sửa lỗi, thì càng tốn kém (về thời gian và tiền bạc). .

Bạn có thể chắc chắn rằng những lỗi đó sẽ tồn tại càng lâu, thì sẽ mất nhiều thời gian hơn để sửa chúng một khi chúng trở thành ưu tiên. Vì vậy, thay vì có một lợi ích thô ngay bây giờ, bạn đang tránh một khoản lỗ đắt hơn trong tương lai.

Một cách tốt để quản lý đó là xác định một lượng thời gian được phân bổ để xử lý các vấn đề tồn đọng. Điều này sẽ không gây khó khăn như Microsoft đã làm, nhưng nó sẽ đảm bảo một số lượng giải quyết các vấn đề trong tương lai, nếu chúng chưa phải là vấn đề của bạn ngay cả khi khách hàng không thực sự quan tâm.


3

Trong nỗ lực thuyết phục chủ sở hữu sản phẩm của chúng tôi về khái niệm này, tôi không thể tìm thấy bất kỳ tài nguyên tốt nào.

Giả sử bạn đang làm việc cho một tổ chức thương mại, chắc chắn sẽ có người biết về Phân tích lợi ích chi phí .

Tổ chức của bạn có một lượng tài nguyên nhà phát triển hữu hạn và một danh sách vô hạn những việc có ích để làm. Những điều có lợi bao gồm cả việc thêm các tính năng mới và loại bỏ các lỗi hiện có - loại bỏ một lỗi giúp cải thiện phần mềm, giống như việc thêm một tính năng mới.

Vì vậy, rõ ràng có những quyết định được đưa ra về cách phân bổ nguồn tài nguyên hữu hạn này vào danh sách vô hạn này, và không có gì đáng ngạc nhiên khi kết quả là một số lỗi không được sửa ngay bây giờ, hoặc tuần tới, hoặc năm tới, hoặc trong thực tế bao giờ hết

Nếu bạn đang tìm kiếm một cách tiếp cận có cấu trúc hơn ở đây, bạn có thể thử hệ thống PEF / REV gán số cho chế độ xem của Người dùng và Lập trình viên về lỗi, làm điểm khởi đầu để quyết định cái gì được sửa - và cái gì không.

Xem thêm hai bài viết ở đây trên Kỹ thuật phần mềm:

Giải quyết những lỗi nào sẽ mang lại lợi ích lớn nhất về chi phí

Hầu như mọi lỗi được báo cáo là một lỗi ưu tiên cao


2

Không phải tất cả các khía cạnh vô ý hoặc không mong muốn của hành vi phần mềm đều là lỗi. Điều quan trọng là đảm bảo rằng phần mềm có một loạt các điều kiện hữu ích và được ghi lại trong đó nó có thể được dựa vào để vận hành theo cách hữu ích. Ví dụ, hãy xem xét một chương trình được cho là chấp nhận hai số, nhân chúng và đưa ra kết quả và đưa ra một số không có thật nếu kết quả là nhiều hơn 9,95 nhưng nhỏ hơn 10,00, hơn 99,95 nhưng dưới 100,00, v.v. Nếu chương trình được viết cho mục đích xử lý các số có sản phẩm nằm trong khoảng từ 3 đến 7 và sẽ không bao giờ được yêu cầu xử lý bất kỳ ai khác, việc khắc phục hành vi của nó với 9,95 sẽ không hữu ích hơn cho mục đích của nó. Tuy nhiên, nó có thể làm cho chương trình phù hợp hơn cho các mục đích khác.

Trong tình huống như trên, sẽ có hai cách hành động hợp lý:

  1. Khắc phục sự cố, nếu làm như vậy là thực tế.

  2. Chỉ định các phạm vi trong đó đầu ra của chương trình sẽ đáng tin cậy và nói rằng chương trình chỉ phù hợp để sử dụng trên dữ liệu được biết là tạo ra các giá trị trong phạm vi hợp lệ.

Cách tiếp cận # 1 sẽ loại bỏ lỗi. Cách tiếp cận # 2 có thể làm cho tiến trình không phù hợp với một số mục đích hơn so với cách khác, nhưng nếu không có chương trình để xử lý các giá trị có vấn đề có thể không phải là vấn đề.

Ngay cả khi việc không thể xử lý các giá trị 99,95 đến 100,0 một cách chính xác là kết quả của một lỗi lập trình [ví dụ: quyết định xuất hai chữ số sang bên trái của dấu thập phân trước khi làm tròn đến một vị trí sau đó, do đó, chỉ nên xem xét một lỗi nếu chương trình sẽ được chỉ định là sản xuất đầu ra có ý nghĩa trong các trường hợp như vậy. [Ngẫu nhiên, sự cố đã nói ở trên xảy ra trong mã printf Turbo C 2.00; trong bối cảnh đó, rõ ràng đó là một lỗi, nhưng mã gọi printf bị lỗi sẽ chỉ bị lỗi nếu nó có thể tạo ra kết quả đầu ra trong phạm vi có vấn đề].


0

Trong một ý nghĩa lỏng lẻo, có, không phải tất cả các lỗi cần phải được sửa chữa. Đó là tất cả về việc phân tích tỷ lệ rủi ro / lợi ích.

Điều thường xảy ra là doanh nghiệp sẽ có một cuộc họp với các lãnh đạo kỹ thuật và các bên liên quan để thảo luận về các lỗi không rõ ràng trong 'cần phải sửa chữa'. Họ sẽ quyết định xem thời gian (= tiền) đầu tư vào việc sửa lỗi có xứng đáng với doanh nghiệp hay không.

Ví dụ: 'một lỗi nhỏ' có thể là một lỗi chính tả / ngữ pháp nhẹ trong phần Điều khoản và Điều kiện của trang web. Cá nhân nêu ra điều này có thể nghĩ rằng nó quá nhỏ để thay đổi, nhưng doanh nghiệp sẽ nhận ra tác hại tiềm tàng mà nó có thể gây ra cho thương hiệu và sự dễ dàng tương đối của việc sửa một vài ký tự.

Mặt khác, bạn có thể có một lỗi có vẻ quan trọng, nhưng khó khắc phục và chỉ ảnh hưởng đến một lượng người dùng không đáng kể. Ví dụ: một liên kết nút nhỏ bị hỏng đối với người dùng sử dụng phiên bản Google Chrome cũ và cũng bị vô hiệu hóa Javascript.

Các lý do khác để doanh nghiệp KHÔNG sửa lỗi có thể là do thời gian đầu tư sẽ khiến dự án quay trở lại một khoảng thời gian không mong muốn hoặc thời gian của nhà phát triển sẽ tốt hơn khi làm việc với các bản sửa lỗi / mã hóa khác. Nó cũng có thể là lỗi nhỏ đến mức nó có thể đi vào hoạt động, và sau đó sẽ được sửa vào một ngày sau đó.

Hy vọng rằng giải thích các khái niệm tốt hơn một chút! Tôi chắc chắn sẽ tránh xa suy nghĩ về điều này nói chung - mọi lỗi đều là duy nhất và nên được xử lý như vậy.


-4

Bởi vì khi bạn đi vào danh sách ưu tiên của các lỗi, trường hợp sử dụng gây ra lỗi đó trở nên tối nghĩa hơn hoặc sự hài lòng của khách hàng đạt được sẽ thấp hơn.

Vì vậy, "đối số" của họ thực sự là

Nếu bạn bỏ qua lỗi đủ lâu, Người dùng sẽ quên vấn đề là gì hoặc tìm cách khắc phục.

Lỗi phải được ưu tiên và xử lý "theo thứ tự" giống như các Yêu cầu tính năng mới (nhưng, có thể nói là hơn và hơn tất cả các yêu cầu sau).


3
Không, lập luận của ông là các lỗi ưu tiên thấp hơn chỉ hiếm khi xảy ra và có thể không thực sự bổ sung nhiều giá trị trong việc sửa lỗi (ví dụ: nếu bạn có đồng hồ trên trang web của mình cách đó nửa phút hoặc nếu bạn là trang web lỗi vào nửa đêm ngày 1 tháng 1 cho người dùng ở Moldova)
Tên hiển thị
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.