trung bình ngành cho thời gian dành cho bảo trì

Một người quản lý gần đây đã thông báo rằng họ đã dành quá nhiều thời gian để sửa lỗi. Tôi đoán anh ấy nghĩ rằng chúng ta nên viết mã hoàn hảo mọi lúc (trong khi vẫn đạt được những thời hạn không thể đó!) Và điều đó khiến tôi tự hỏi trung bình thời gian trong ngành dành cho việc sửa lỗi v viết mã mới là gì.

Vì vậy, có ai có bất kỳ số liệu về thời gian sửa lỗi chống lại sự phát triển mã mới không? Hoặc có bất kỳ phân tích thực nghiệm về thời gian sửa lỗi cho toàn bộ ngành công nghiệp? Là 50% chi tiêu sửa lỗi quá nhiều, hoặc về phải không? Làm thế nào khoảng 20% ​​hoặc 33%?

Tôi rất vui khi chấp nhận bằng chứng giai thoại từ kinh nghiệm cá nhân vì điều đó sẽ là một phần của một số thống kê ở đây mà tôi có thể so sánh hiệu suất của chúng tôi với.

Một người quản lý gần đây đã thông báo rằng họ đã dành quá nhiều thời gian để sửa lỗi.

Trên đây nghe có vẻ rất dốt. Đề nghị đọc cho các trường hợp như thế: Sự kiện và sai lầm của Kỹ thuật phần mềm của Robert L. Glass, đặc biệt là "Sự thật 43. Bảo trì là một giải pháp, không phải là vấn đề."

Bài viết Wikipedia đề cập đến 80% nỗ lực dành cho bảo trì phần mềm.

quản lý của tôi làm cho PHB của Dilbert trông giống như một thiên tài :)

Tôi đã đưa ra ở trên Tôi cũng sẽ có một số nỗ lực trong việc phân tích xem tất cả các yêu cầu bạn thực hiện có phải là lỗi không .

Theo kinh nghiệm của tôi, thông thường các yêu cầu cải tiến hoặc các tính năng mới đã được gửi dưới dạng lỗi. Các nhà quản lý giỏi liên quan đến các lập trình viên của họ trong việc tìm hiểu về điều đó - các nhà quản lý tồi, tốt, cứ phàn nàn về việc sửa lỗi quá nhiều thời gian .

Câu hỏi đầu tiên cần đặt ra là liệu "sửa lỗi" của bạn có thực sự sửa các lỗi mã hóa hay không. Việc sửa lỗi mã thực tế phải tương đối nhỏ trong hầu hết các trường hợp miễn là bạn có cơ sở mã tốt. Nếu bạn đang làm việc với một cơ sở mã kém, việc sửa lỗi sâu rộng là không thể tránh khỏi.

Tuy nhiên, trong quá trình đưa chương trình vào sản xuất, bạn sẽ tìm thấy các yêu cầu không được ghi lại, hoạt động bất ngờ của người dùng, sự bất thường về dữ liệu, sự không tương thích về phần cứng, sự cố cài đặt và các vấn đề khác không phải là lỗi mã nghiêm ngặt. Thông thường các nhà quản lý và người dùng sẽ nghĩ về các vấn đề hỗ trợ / bảo trì sản xuất này là các lỗi do chúng thường yêu cầu thay đổi mã.

Tôi cũng đã gặp những người quản lý sẽ nhóm những gì đáng lẽ phải được gọi là yêu cầu nâng cao nhỏ là lỗi. Thông thường chúng được đưa vào hệ thống theo dõi lỗi hoặc báo cáo sự cố và điều này có thể làm cho số liệu thống kê "lỗi" của bạn cao hơn so với thực tế.

Nó phụ thuộc vào số lượng mã bạn có ngoài đó, nó đã tồn tại bao lâu, v.v.

Thời gian dành cho việc sửa lỗi trong phần mềm nên được tải trước trong 6-12 tháng đầu phát hành, tuy nhiên khi thời gian đến vô cùng, thời gian dành cho bảo trì so với thời gian dành cho phát triển ban đầu sẽ vượt quá 100% - đó chỉ là cách mọi thứ công việc.

Mặc dù tôi không có bất kỳ số liệu thống kê cứng nào (Hoàn thành mã, nhưng tôi không thể cho bạn biết chính xác trang / phần nào), theo kinh nghiệm của tôi, khoảng 40% phát triển (đôi khi cao tới 60%) được dành cho bảo trì. Rõ ràng là bạn phát hành càng nhiều mã, bạn sẽ càng có nhiều thời gian bảo trì. Lỗi không phải lúc nào cũng hoạt động, và là kết quả của sự không chắc chắn vì chúng là khiếm khuyết lập trình.

nếu bạn sử dụng trình theo dõi vé tốt (chẳng hạn như Jira từ Atlasian) và bạn đã dành thời gian nhập tất cả các danh mục khác nhau, câu chuyện của người dùng, mức độ khẩn cấp một cách chính xác và với sự đồng ý của các đồng đội của bạn, thì hãy tính toán các số liệu này (và hơn thế nữa) thật dễ dàng

Trong một dự án trước đó, chúng tôi đã sử dụng Jira để quản lý danh sách lỗi / nhiệm vụ / việc cần làm của chúng tôi và cuối cùng nó thực sự cho chúng tôi thấy rằng nguyên nhân lớn nhất của sự chậm trễ và các vấn đề hóa ra là do thực tiễn quản lý không hiệu quả.

Thật kỳ lạ, khi thông tin đó xuất hiện, chúng tôi bất ngờ nói rằng chúng tôi sẽ không còn sử dụng Jira nữa, và một sản phẩm mới sẽ được đưa vào để thay thế.

Trong thời gian đó, tất cả các yêu cầu dữ liệu được chuyển qua Jira phải được gửi đến nhóm quản lý và chúng tôi đã xóa quyền truy cập trực tiếp của chúng tôi.

Điều không được chú ý là là một phần của tính toán thống kê, nhóm nhà phát triển đã Jira chọc dữ liệu vào một hook web và hook web này được sử dụng để truyền dữ liệu đến điểm cuối trên một số máy chủ nội bộ, nơi chúng tôi có mã được tạo các báo cáo này tự động.

Chúng tôi bắt đầu theo dõi web hook và thấy rằng mặc dù chúng tôi đã nói rằng Jira không còn được sử dụng nữa, nhưng nó vẫn tồn tại rất lâu trong một khoảng thời gian đáng kể (chính xác hơn 6 tháng) và sự lạm dụng bán buôn của quản lý cấp trên là chỉ đơn giản là tràn lan với việc sử dụng không chính xác.

Tất nhiên, nó không phải là thứ gì đó phức tạp như Jira.

Nếu bạn muốn một giải pháp năng suất thấp, bạn có thể sử dụng bảng tính google-docs và API thông báo GDocs, để theo dõi các nhiệm vụ / vé / lỗi / yêu cầu tính năng, v.v.

Bản thân GDocs hiện có thể phát hành web-hook và tất cả các loại.

Kết hợp với Git và / hoặc Github và một số hook kích hoạt khi mã được cam kết với kho lưu trữ của bạn và bạn đã có một hệ thống sản xuất bia tại nhà hiệu quả hợp lý, có thể ghi lại một lượng dữ liệu đáng ngạc nhiên.

Tuy nhiên, nói chung, trong số 100% tuổi thọ tự nhiên của sản phẩm, sự phân chia giữa nhà phát triển và bảo trì Greenfield thường là 20/80, phần lớn chi phí trong chu trình ALM (Quản lý trọn đời ứng dụng) được tính cho chi phí bảo trì và hỗ trợ.

Không có gì giống như dành quá nhiều thời gian để sửa lỗi, vì vậy đơn giản là không thể viết mã không có lỗi.

Thử nghiệm tốt và các chính sách tích hợp liên tục sẽ làm giảm thâm hụt, nhưng bạn sẽ không bao giờ xóa bỏ hoàn toàn.

Bất cứ ai tin khác (IMHO) không có đủ kiến ​​thức để đưa ra phán đoán chính xác, hoặc bị mù (Trường hợp thông thường hơn) về việc thực sự khó khăn như thế nào khi viết phần mềm.

Nếu người quản lý của bạn ủng hộ điều đó, và một vài người trong số họ, thì bạn có thể muốn đề nghị anh ta che chở bạn trong một ngày, để anh ta có thể thấy chính xác những gì bạn làm và cách bạn làm điều đó.

Iv'e đã ​​làm việc trong một vài công ty nơi loại công việc này được khuyến khích tích cực, với nhân viên cấp trên che chở nhân viên cấp dưới, và ngược lại, nó có thể là một kinh nghiệm học tập thực sự, thực sự tốt cho cả hai bên liên quan.