Lượng thời gian nên dành cho lỗi so với phát triển ban đầu? [đóng cửa]

Câu hỏi này hơi trừu tượng nhưng tôi hy vọng ai đó có thể chỉ cho tôi đi đúng hướng.

Câu hỏi của tôi là lượng thời gian mà người ta có thể mong đợi để dành cho các lỗi của dự án phần mềm liên quan đến thời gian phát triển ban đầu. Tôi nhận ra có một số lượng lớn các yếu tố xác định đi vào nhưng tôi đã hy vọng cho một sự cố điển hình hoặc trung bình.

Ví dụ: nếu Dự án A mất 40 giờ để hoàn thành và thêm 10 lỗi sửa lỗi thì dự án này sẽ có tỷ lệ 4: 1.

Nếu một Dự án (B) khác mất 10 giờ để hoàn thành nhưng 8 lỗi khác thì nó sẽ có tỷ lệ 5: 4.

Đây có phải là một khái niệm tài liệu / nghiên cứu?

CẬP NHẬT

Cảm ơn tất cả các câu trả lời thông tin. Tôi hiểu rằng không thể đặt tiêu chuẩn cho loại số liệu này do tất cả các biến và yếu tố môi trường liên quan. Trước khi tôi chỉ định một câu trả lời tôi muốn biết liệu số liệu này có tên được thỏa thuận hay không để tôi có thể nghiên cứu thêm. Tôi muốn đi đến điểm mà tôi có thể hiểu các phép đo cần thiết để tự tạo ra các số liệu và cuối cùng đưa ra một tiêu chuẩn cơ bản cho dự án của tôi.

Tỷ lệ phần trăm cân bằng của tổng công suất được phân bổ để sửa chữa khuyết tật bằng với tốc độ tiêm khuyết tật .

Tất nhiên, nhiều yếu tố có thể ảnh hưởng đến tỷ lệ này, trong số đó, nhóm phát triển loại sản phẩm nào, công nghệ và thực hành kỹ thuật nào họ sử dụng, trình độ kỹ năng của đội, văn hóa công ty, v.v.

Xem xét Đội B, nếu họ tạo trung bình 8 đơn vị làm lại cho mỗi 10 đơn vị công việc họ hoàn thành, thì 8 đơn vị đó sẽ tạo ra 6,4 đơn vị làm lại mới. Chúng tôi có thể ước tính tổng nỗ lực mà cuối cùng họ sẽ phải bỏ ra như là tổng của một tiến trình hình học:

10 + 8 + 6.4 + 5.12 + ...

Số lượng lỗi sẽ giảm theo cấp số nhân theo thời gian, nhưng Đội B có hệ số như vậy theo cấp số nhân của nó nên nó sẽ về không rất chậm. Trên thực tế, tổng của ba thuật ngữ đầu tiên trong chuỗi trên chỉ là 24,4; của năm đầu tiên, 33,6; của 10, 45 đầu tiên; của toàn bộ loạt, 50. Vì vậy, tóm tắt của Đội B: tỷ lệ tiêm khiếm khuyết, 0,8; phát triển tính năng, 10/50 = 20%; sửa lỗi, 80%. 20/80 là phân bổ năng lực bền vững của họ.

Ngược lại, đội A có phong độ tốt hơn nhiều. Sự tiến triển của họ trông như thế này:

40 + 10 + 2.5 + 0.625 + ...

Tổng của loạt bài này là 53 1/3, vì vậy phân bổ phát triển tính năng của Đội A là 40 / (53 1/3) = 75% và phân bổ sửa lỗi là 25%, phù hợp với tỷ lệ tiêm khiếm khuyết của họ là 10/40 = 0,25 .

Trên thực tế, tất cả các điều khoản trong loạt của Đội A sau ba lần đầu tiên là nhỏ không đáng kể. Điều này có nghĩa trong điều kiện thực tế là Đội A có thể xóa sạch tất cả các lỗi của họ bằng một vài bản phát hành bảo trì, bản phát hành thứ hai có phạm vi khá nhỏ. Điều này cũng tạo ra một ảo tưởng rằng bất kỳ đội nào cũng có thể làm điều đó. Nhưng không phải đội B.

Tôi đã nghĩ về sự tương đương này trong khi đọc cuốn sách mới của Kan Anderson, "Kanban" . (Cuốn sách thuộc một chủ đề khác, nhưng cũng giải quyết các mối quan tâm về chất lượng.) Khi thảo luận về chất lượng phần mềm, Anderson đã trích dẫn cuốn sách này của Capers Jones, "Đánh giá phần mềm, Điểm chuẩn và Thực tiễn tốt nhất" :

"... vào năm 2000 ... chất lượng phần mềm được đo cho các đội Bắc Mỹ ... dao động từ 6 lỗi trên mỗi điểm chức năng xuống dưới 3 trên 100 điểm chức năng, phạm vi từ 200 đến 1. Điểm giữa là khoảng 1 lỗi trên mỗi 0,6 đến 1 điểm chức năng. Điều này ngụ ý rằng thông thường các đội dành hơn 90 phần trăm nỗ lực của họ để sửa lỗi. "Ông trích dẫn một ví dụ được cung cấp bởi một trong những đồng nghiệp của mình trong một công ty dành 90% thời gian để sửa lỗi .

Sự lưu loát mà Anderson đi từ tốc độ tiêm khiếm khuyết đến phân bổ năng lực sửa lỗi ( nhu cầu thất bại là thuật ngữ của nó) cho thấy rằng sự tương đương của hai điều được các nhà nghiên cứu chất lượng phần mềm biết đến và có lẽ đã được biết đến từ lâu .

Các từ khóa trong dòng lý luận mà tôi đang cố gắng trình bày ở đây là "cân bằng" và "bền vững". Nếu chúng ta lấy đi tính bền vững, thì có một cách rõ ràng để gian lận những con số này: bạn thực hiện mã hóa ban đầu, sau đó chuyển sang mã ở một nơi khác và để bảo trì cho người khác. Hoặc bạn chạy lên các khoản nợ kỹ thuật và dỡ nó trên một chủ sở hữu mới.

Rõ ràng, không có phân bổ cụ thể sẽ phù hợp với tất cả các đội. Nếu chúng tôi đồng ý rằng 20% ​​phải được chi cho các lỗi, thì, nếu một đội có tỷ lệ tiêm khuyết tật cực thấp, đơn giản là họ sẽ không có đủ lỗi để lấp đầy thời gian và nếu một đội có tỷ lệ rất cao, thì lỗi của họ sẽ tiếp tục tích lũy.

Toán học tôi sử dụng ở đây là cách đơn giản hóa. Tôi đã bỏ qua những thứ như chi phí giao dịch (các cuộc họp lập kế hoạch và ước tính, sau khi chết, v.v.), sẽ ảnh hưởng đến phần trăm. Tôi cũng bỏ qua các phương trình mô phỏng duy trì một sản phẩm và phát triển đồng thời một sản phẩm khác. Nhưng kết luận vẫn đứng vững. Làm những gì bạn có thể, về mặt thực hành kỹ thuật, như kiểm tra đơn vị, tích hợp liên tục, đánh giá mã, v.v., để giảm tỷ lệ tiêm khiếm khuyết của bạn và do đó, nhu cầu thất bại của bạn. Nếu bạn chỉ có thể tạo một lỗi cho mỗi 10 tính năng, bạn sẽ có nhiều thời gian rảnh để phát triển các tính năng mới và làm hài lòng khách hàng của bạn.

Thật không may, tôi tin rằng tỷ lệ này rất khác nhau trong một dự án nhất định. Nó sẽ bị ảnh hưởng mạnh mẽ bởi môi trường, ngôn ngữ, công cụ, quy mô nhóm và kinh nghiệm của bạn.

Bạn chỉ nên dành thời gian cho một lỗi nếu những gì bạn đạt được từ bản sửa lỗi lớn hơn từ những gì bạn đầu tư.

Sử dụng một ma trận như sau (yêu cầu thời gian theo chiều ngang để sửa lỗi, loại lỗi dọc - tác động đến người dùng)

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

Ví dụ về các vấn đề:

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add nice    | Fix: change architecture + DB
              | message                              |

Ma trận có thể phức tạp hơn với các mức độ nghiêm trọng, nỗ lực, rủi ro khác nhau, v.v.

Bạn thậm chí có thể tạo một thứ hạng cho từng lỗi và sửa chúng dựa trên xếp hạng. Cái gì đó như:

Bug priority = Risk x Severity x Effort

* Có thể là (1-x) cho một số toán hạng, tùy thuộc vào tỷ lệ bạn chọn :)

Vì vậy, để trả lời câu hỏi của bạn: phụ thuộc vào loại lỗi, thời gian / ngân sách có sẵn, v.v.

Nó rất khác nhau, không chỉ (tất nhiên) về kinh nghiệm và chất lượng của nhóm và về độ khó của dự án (nó không giống với việc tạo một ứng dụng web tiêu chuẩn khác so với nhân hệ điều hành mới), mà còn về cách tiếp cận quản lý của bạn Sẽ sử dụng.

Ví dụ: trên mô hình thác nước, bạn có thể đặt chính xác lỗi đầu tiên ở giai đoạn thử nghiệm đầu tiên, nhưng trên môi trường nhanh có thể khó đưa ra một dòng chữ "từ đây về sau, chúng tôi đang sửa lỗi", vì các tính năng có thể thay đổi ( và với tôi thật không công bằng khi tính một sự thay đổi tính năng là một lỗi)

Từ kinh nghiệm, tôi nói rằng đó là thứ gì đó LUÔN bị đánh giá thấp và rất dễ dàng có thể dành cùng số giờ so với "dự án ban đầu".

Câu trả lời thực sự chính xác sẽ là 0 giờ khi sửa lỗi vì mã của bạn là hoàn hảo. :-)

Trên thực tế, tôi không thể nói rằng tôi đã từng nghe ai đó yêu cầu hoặc đưa ra loại tỷ lệ đó. Điều đó không có nghĩa là một số công ty không theo dõi thời gian cho cả phát triển và bảo trì. Nhưng sự phát triển của một ứng dụng là một khung thời gian ngắn như vậy khi so sánh với việc bảo trì mà hầu hết các công ty không quay lại và tính tỷ lệ đó. Có lẽ họ quan tâm nhiều hơn đến việc tìm hiểu lý do tại sao một ứng dụng yêu cầu bảo trì và áp dụng những phát hiện đó vào các ứng dụng mới.

Có quá nhiều tiêu chí cho lỗi là gì có thể tăng gấp đôi thời gian của bạn. Một người quản lý quá nhiệt tình nghĩ rằng yêu cầu của khách hàng làm cho nút lớn hơn (họ có vấn đề về chuột) là một cách tuyệt vời để tăng số lượng lỗi chúng tôi đã sửa. Sẽ chỉ mất vài giây để khắc phục vì không cần phải xem xét, kiểm tra, biên dịch lại và phân phối một bản vá. Ồ, và nó được tính hai lần như một tính năng mới.

Yếu tố quyết định lớn nhất cho điều này là liệu bạn đang làm việc với một công nghệ mới hay một công nghệ hiện có. Nếu bạn đang làm việc với một cái gì đó mới và phát triển một cái gì đó chưa được thực hiện hoặc đã được thực hiện một vài lần trong các trường hợp khác nhau, bạn sẽ dành nhiều thời gian cho các lỗi và làm cho dự án của bạn hoạt động theo cách bạn muốn . Lỗi thường xuyên sẽ là kết quả của việc bạn tự làm việc trong một góc, và bạn sẽ cần phải thực hiện một lượng công việc đáng kể để cơ cấu lại những gì bạn đã làm. Ngoài ra, nhiều lỗi sẽ xuất phát từ sự hiểu biết không đầy đủ về kỳ vọng của người dùng và sự không nhận thức của nhà phát triển về các trường hợp cạnh.

Nếu bạn đang làm việc trên một công nghệ đã được thiết lập, hầu hết các vấn đề sẽ được giải quyết bởi các thư viện hoặc bởi các hoạt động trong cộng đồng và bạn sẽ có thể google, mua hoặc hỏi cách thoát khỏi bất kỳ lỗi nào bạn gặp phải.

Trên các phần mềm quan trọng, tỷ lệ 1: 1 không phải là bất thường. Đối với thử nghiệm đơn vị, tôi đã thấy các chỉ số đề cập đến 1 ngày thử nghiệm đơn vị cho mỗi 10 dòng mã.

Tôi nghĩ rằng câu hỏi này là sai lệch: nó bắt đầu từ giả định rằng sửa lỗi là một giai đoạn tương tự như phát triển các chức năng mới . Đây không phải là trường hợp.

Một nhà phát triển giỏi sẽ không mất nhiều thời gian để gỡ lỗi mã vì mã của anh ta sẽ không có lỗi ngay từ đầu. Một nhà phát triển tồi sẽ dành nhiều thời gian để gỡ lỗi mã của anh ta vì anh ta không thể tạo ra sự trừu tượng phù hợp để giải quyết các vấn đề thực sự.

Lưu ý rằng các nhà phát triển nên tự kiểm tra mã của riêng họ. Trách nhiệm của họ là cung cấp mã không có lỗi. Vì vậy, thật khó để tách mã hóa khỏi gỡ lỗi.

Đó cũng là một vấn đề ưu tiên. Khi phát triển, thời gian cần thiết để sửa lỗi có liên quan theo cấp số nhân với thời gian đã qua kể từ thời điểm bạn chèn lỗi vào mã. Vì vậy, sửa lỗi nên được ưu tiên lớn hơn so với việc phát triển các chức năng mới.

Vì vậy, thay vì nói về "thời gian dành cho lỗi", bạn nên nói về "thời gian dành cho kiểm tra" (kiểm tra tích hợp, kiểm tra chấp nhận của người dùng ...)

Tôi nghĩ rằng bạn đúng - bạn sẽ không nhận được bất kỳ số liệu có ý nghĩa nào do số lượng các yếu tố ảnh hưởng.

Nếu nó giúp tôi có thể cho bạn biết các dự án tôi làm việc (không gian doanh nghiệp, các hệ thống phức tạp lớn, rất nhiều tích hợp với các hệ thống khác) có tỷ lệ khoảng 3: 2. Hầu hết trong số này không phải là lỗi với mã - thường là lỗi với các giao diện. Ví dụ: hệ thống A và B nói chuyện với nhau thông qua giao diện X. Các nhà phát triển hệ thống A diễn giải giao diện X hơi khác so với các nhà phát triển hệ thống B. Hài kịch xảy ra.

Một quan sát cần thực hiện là việc phát triển mã và kiểm tra / sửa lỗi mã không nên là hai giai đoạn riêng biệt. Nếu bạn kiểm tra khi bạn phát triển "chi phí" sửa lỗi sẽ ít hơn.

Tôi có quan điểm hoàn toàn thực tế: Điều gì cản trở tính hữu dụng thực tế của dự án hơn? Nếu đó là lỗi trong chức năng hiện có, bạn nên sửa lỗi. Nếu nó thiếu các tính năng, bạn nên thực hiện phát triển ban đầu, sau đó quay lại và sửa các lỗi một khi các tính năng bị thiếu nghiêm trọng nhất được triển khai. Điều này đòi hỏi sự quen thuộc với các trường hợp sử dụng của bạn. Một lỗi làm hỏng chương trình trong một số trường hợp góc lẻ có thể có mức độ ưu tiên thấp hơn các cải tiến khả năng sử dụng nhỏ ảnh hưởng đến tất cả mọi người. Một lỗi nhỏ phiền toái trong chức năng được sử dụng phổ biến nhất có thể quan trọng hơn một tính năng chỉ mang lại lợi ích cho những người đang đẩy phần mềm của bạn đến mức cực đoan.