Khi nào thì được gửi một sản phẩm có lỗi đã biết?

Khi nào thì được gửi một sản phẩm có lỗi đã biết?

Tôi giả sử bạn đang nói về một lỗi "đã biết" (câu hỏi này là vô nghĩa). Vâng, câu trả lời phụ thuộc vào các yếu tố sau:

1) Ai là người dùng và họ sẽ chấp nhận lỗi như thế nào trong trường hợp được tìm thấy?

2) Tác động tiềm tàng (thiệt hại) của lỗi là gì?

3) Có khả thi trì hoãn việc vận chuyển phần mềm để sửa lỗi không?

4) Quan trọng nhất: bạn mong đợi gì từ phần mềm của bạn? Đến giờ đi chợ? Phẩm chất? Bạn có muốn xem khách hàng của bạn sử dụng phần mềm đủ lâu để tìm lỗi không?

Nó phải luôn luôn ổn, bởi vì không có phần mềm nào bị lỗi.

Đó là một cuộc gọi phán xét. Hãy nhớ rằng, một lỗi có thể là nhiều thứ. Nếu đó là một phần lớn của chức năng mà không hoạt động, thì bạn sửa nó trước. Nếu một cái gì đó nhỏ mà có tác động tối thiểu hoặc không có tác động thực sự đến sự hữu ích của chương trình, bạn có thể để nó trượt.

Vì vậy, nhìn vào nó từ một quan điểm chi phí / lợi ích.

Bạn vận chuyển các sản phẩm có lỗi đã biết khi tổng chi phí và rủi ro sửa lỗi vượt trội hơn bất kỳ vấn đề và tác động tiêu cực nào sẽ phát sinh từ lỗi xuất hiện ngoài kia.

Vì vậy, nếu bạn có thời gian thử nghiệm 2 tuần trước khi phát hành và phát hiện ra một lỗi nhỏ, câu hỏi đặt ra là ... đang sửa lỗi đó trong 2 tuần nữa mà một nhóm có thể phải bỏ ra để kiểm tra lại ứng dụng và cài đặt (một bước thường bị lãng quên về bước tạo phần mềm)? Chi phí cho danh tiếng hoặc doanh số nếu phần mềm bị trễ là gì? Có phải mọi người sẽ tức giận? Họ có thể khá hạnh phúc khi sống với một lỗi nhỏ nếu chức năng chính có thể được cung cấp đúng hạn.

Rủi ro bao gồm rủi ro khi đưa ra một vấn đề mới, không chỉ trong việc sửa lỗi, mà cả những điều có thể phát sinh từ việc tạo một bản cài đặt mới.

Tác động tiêu cực là cả thời gian và nỗ lực đối phó với khách hàng báo cáo lỗi và những thứ như thiệt hại danh tiếng.

Lỗi đến ở mức độ nghiêm trọng khác nhau. Tại bất kỳ công ty phần mềm nào tôi từng làm việc, chúng tôi đã phân loại các lỗi theo thứ tự Ưu tiên từ P0 đến P4.

P0 Phần mềm không hoạt động / gặp sự cố và có thể gây thiệt hại cho doanh nghiệp của khách hàng. P1 Nó không hoạt động như được thiết kế và gặp sự cố liên tục trong chức năng cốt lõi P2 Nó thỉnh thoảng gặp sự cố và hoặc một phần chức năng phụ có thể không hoạt động. P3 Một số yếu tố của phần mềm không hoạt động như sự cố P4 Cosmetics được thiết kế / mong đợi.

Tôi đã làm việc ở những nơi mà P4 không được sửa chữa vì chúng có ảnh hưởng nhỏ đến phần mềm.

Tôi nói rằng sẽ ổn nếu giao hàng nếu phần mềm của bạn có vấn đề về P3 / P4, tôi sẽ đưa phần này vào ghi chú phát hành và lưu ý rằng chúng đang được xử lý.

Tôi sẽ không bao giờ phát hành phần mềm với sự cố P0, P1 hoặc P2 mà tôi biết.

Nó được gọi là " Vấn đề đã biết ". Google, Microsoft, Apple, v.v ... tất cả các sản phẩm đều có lỗi, cả được biết và chưa biết. Cố gắng giảm thiểu chúng, nhưng đừng chờ đợi sự hoàn hảo. Tàu nhanh, tàu thường xuyên.

Bạn không thể gửi phần mềm mà không có lỗi. Lời khuyên tôi có thể đưa ra là luôn luôn tốt hơn để nói với khách hàng của mình: "Phiên bản này không thể làm điều đó và chúng tôi sẽ sửa lỗi này" so với tình huống khi khách hàng nói với BẠN rằng bạn có lỗi.

khi đó là một "tính năng"! ;)

Một lưu ý nghiêm trọng, trừ khi bạn là một lập trình viên hoàn hảo với thiết lập thử nghiệm hoàn hảo, để kiểm tra hoàn hảo mọi đường dẫn mã duy nhất và cuối cùng có khả năng tồn tại, không thể chấp nhận được rằng bạn sẽ gửi một sản phẩm không có lỗi.

Do đó, hãy thực dụng, nếu mọi thứ bạn gặp phải trong thử nghiệm của bạn đã được sửa chữa, mọi thứ cần được sửa chữa thêm trên cơ sở khi cần thiết.

Miễn là bạn trung thực với khách hàng của mình, bạn có thể giao hàng với lỗi. Nói với họ về tất cả các lỗi hiện có cho họ thấy rằng bạn có kiến ​​thức tốt về phần mềm của mình và điều đó thực sự đã được kiểm tra tốt (nếu đó là ..). :)

Rõ ràng điều tốt nhất là tránh vận chuyển với lỗi.

Thông thường tốt hơn là có một sản phẩm vận chuyển đúng thời gian, với một danh sách các vấn đề đã biết, hơn là không giao hàng.

Một trong những điều trong thế giới lập trình khiến mọi người tin tưởng vào một dự án là liệu họ có phát hành theo lịch trình hay không và liệu lịch trình có được giữ không .

Đây là lý do tại sao các tàu Ubuntu phát hành mỗi nửa năm, ngay cả khi vẫn còn các vấn đề mở.

Tôi muốn nói rằng một quy tắc tốt là "lỗi này có phải là một showstopper không?"

Nếu lỗi khiến "kịch bản đường dẫn hạnh phúc" thất bại, thì tuyệt đối không giao hàng với lỗi đó.

Nếu lỗi gây ra "kịch bản tiếp tuyến hạnh phúc" không thành công và không có cách giải quyết, thì đừng giao hàng với lỗi đó.

Nếu một lỗi được ghi lại và có một cách giải quyết đã biết, thì có lẽ bạn có thể giao hàng với lỗi đó.

Từ quan điểm của người tiêu dùng ... Không bao giờ. Quan điểm của tôi là miễn là bạn biết có một lỗi lớn trong phần mềm thì bạn không bao giờ nên gửi nó. Tuy nhiên, các lực lượng tự nhiên (doanh nghiệp) sẽ ghi đè lên điều này nếu chu kỳ sản xuất phần mềm hiện đang ở giai đoạn có thể gây hại cho mô hình kinh doanh và chúng là những lỗi nhỏ không làm ảnh hưởng đến tính bảo mật của phần mềm (ii)

Như mọi người đã nói, đó là một câu hỏi rất rộng. Nó thực sự đưa tôi đến một viễn cảnh thú vị: cái gọi là "lỗi" mà bạn cho là chỉ là lỗi được phát hiện bởi những người thử nghiệm của bạn. Có thể có một lỗ hổng vô hạn hơn. Chỉ cần nhắc về một câu chuyện thú vị mà tôi đã nghe từ một Giáo sư đáng kính trong một Hội thảo tốt nghiệp: Khi người dân ở một trong các quốc gia Scandinavi sử dụng máy bỏ phiếu kiểu "chữ viết tay", một số người đã hack toàn bộ hệ thống bằng cách viết mã SQL độc hại (mà hệ thống đưa vào như đầu vào bình thường).

Có một thứ gọi là FMEA (Chế độ thất bại và phân tích hiệu ứng) rất hữu ích để quyết định khi nào một lỗi đã biết là quan trọng hay không dựa trên:

1. Xảy ra
2. Mức độ nghiêm trọng
3. Phát hiện

Một yếu tố quyết định khác có thể là làm thế nào khiếm khuyết liên quan đến bản phát hành cuối cùng của bạn. Nếu lỗi là một phần của tính năng mới, nhưng bị hỏng, thì chức năng không có chức năng này không thể hiện sự hồi quy của chức năng. Đi trước và tàu.

Mặt khác, nếu lỗi gây ra mất chức năng hiện có được sử dụng cho các khách hàng hiện tại, thì nó phải chặn việc phát hành. Một bản phát hành như vậy sẽ là một hạ cấp cho khách hàng của bạn và sẽ không phục vụ lợi ích của bạn cũng như của họ.

Có thể có sắc thái của màu xám trong này. Một hồi quy trong chức năng cốt lõi không bao giờ nên đi ra khỏi cửa. Một số hồi quy trong các tính năng ngoại vi có thể dẫn đến người dùng nếu bản phát hành cũng chứa chức năng mới mà họ bày tỏ sự quan tâm. Một khiếm khuyết không có khả năng ảnh hưởng đến nhiều khách hàng có thể phát hành, miễn là một công việc xung quanh được cung cấp khi Nó ảnh hưởng đến những khách hàng đó. Khiếm khuyết trong các tính năng thử nghiệm cao bị tắt theo mặc định dù thế nào cũng không bao giờ khiến việc phát hành bị trì hoãn.