Tính toán chi phí của mã xấu

Tôi đang tìm kiếm các lập luận để thuyết phục ban lãnh đạo nỗ lực đầu tư vào tái cấu trúc.

Chúng tôi đăng nhập công việc bằng Jira và liên kết mọi svn-commit với một cuộc gọi jira.

Ý tưởng của tôi là làm như sau:

• theo cách thủ công một khu vực mã được triển khai cực kỳ xấu, nhưng thường được sử dụng: cả từ User-POV và của Developer-POV (bugfix)
• nhận các cam kết svn có chứa các vấn đề JIRA
• lọc các vấn đề theo một số tiêu chí (loại vấn đề, phiên bản, nguyên tắc, v.v ...)
• tính thời gian / công sức dành cho những lỗi này
• ước tính nỗ lực và rủi ro của tái cấu trúc
• trình bày các con số và yêu cầu nỗ lực để sửa nó.

Bạn nghĩ gì về điều này? Một phép đo như vậy sẽ hữu ích và / hoặc thuyết phục? Những ưu và khuyết điểm là gì?

Tôi thấy rằng nếu bạn có thể cung cấp số hợp lệ, người quản lý có nhiều khả năng hành động. (Nếu họ có thể hiểu logic và chi phí / lợi ích.)

IMHO, để tạo ra một trường hợp thuyết phục, bạn sẽ cần những điều sau đây để cho thấy nó tệ như thế nào:

• số sự cố hỗ trợ được ghi lại cho các vấn đề
• thời gian dành cho hàng giờ để duy trì / hỗ trợ mã xấu / sửa lỗi hỗ trợ
• chi phí thời gian dựa trên tỷ lệ hàng giờ của những người thực hiện bảo trì / hỗ trợ ban nhạc / hỗ trợ
• một số cách để chứng minh nhiệm vụ quan trọng như thế nào đối với doanh nghiệp

Và để làm cho trường hợp tái cấu trúc, bạn sẽ cần:

• ước tính thời gian để tái cấu trúc và thực hiện từng trong số 3 điều tồi tệ nhất
• dự toán chi phí để thực hiện (cùng tỷ lệ hàng giờ như được sử dụng ở trên)

Với những điều này, bạn có thể thực hiện trường hợp để tiết kiệm thời gian nếu việc tái cấu trúc mất ít hơn rất nhiều thời gian hỗ trợ cho 3 sự cố cho mỗi 3 mục hàng đầu đó. Bạn có thể lập luận rằng khoảng thời gian ngắn hơn này sẽ

• ít hơn n sự cố hỗ trợ
• sẽ không có thêm những sự cố này cho những điều này (NGAY CẢ TỐT HƠN!)

Tuy nhiên, phần khó nhất của việc bán hàng này sẽ là trả lời câu hỏi sau đây, vì nhiều người không dành thời gian cho ngân sách theo lịch trình cho tất cả các hỗ trợ bạn đang làm:

Tôi sẽ phải đợi bao lâu để dự án Y hiện tại hoàn thành trong khi bạn dành thời gian làm việc với những vấn đề này với X ????? (mặc dù thời gian hỗ trợ hiện tại, không thể dự đoán và lên lịch trong biểu đồ Gantt)

Điều này phụ thuộc rất nhiều vào mức độ bạn giao tiếp với những người ra quyết định và cách họ hiểu tình huống.

Tôi thấy chắc chắn rằng việc này rất đáng làm, vì vậy bạn có thể thực hành xây dựng trường hợp với các số liệu và để tiết kiệm thời gian của mình, ngay cả khi họ không thực hiện. Thật không may, không phải ai cũng dễ dàng thuyết phục, bất chấp dữ liệu. CHÚC MAY MẮN!

Hãy nhớ rằng tái cấu trúc cũng giới thiệu các lỗi (mà bạn sẽ bắt gặp trong thử nghiệm của mình, nhưng dù sao đó cũng là các lỗi và phải được sửa). Đừng kéo Netscape một cách tình cờ. Nó phụ thuộc vào định nghĩa cá nhân của bạn về "tái cấu trúc." Đối với một số người, điều này có nghĩa là "viết lại tất cả mã" cho người khác, nó có nghĩa là "thay đổi một số nội bộ." Làm thế nào để bạn biết bạn là loại gì? Hãy tự hỏi mình câu hỏi sau:

Tôi có thay đổi giao diện công cộng không?

Nếu câu trả lời là có, bạn đang thiết kế lại. Nếu câu trả lời là không, bạn đang thực hiện tái cấu trúc và có thể chỉ cần thực hiện nó trong suốt quá trình hoạt động hàng ngày của bạn mà không có sự chấp thuận đặc biệt. Điều này có liên quan đến câu hỏi của bạn bởi vì thiết kế lại sẽ tạo ra nhiều lỗi hơn, trong khi việc tái cấu trúc thường dễ thực hiện hơn (vì các thử nghiệm của bạn sẽ thực hiện giao diện công cộng và bản thân chúng sẽ không cần phải sửa đổi).

Đây là một trường hợp khó thực hiện, bởi vì không ai từng biết X sẽ có chi phí bao nhiêu nếu không có bộ tái cấu trúc đã được thực hiện một năm trước. Theo kinh nghiệm của tôi, các nhà quản lý thực dụng luôn bắn loại này xuống vì:

1. Không có nguồn thu trực tiếp đến từ nỗ lực (chi phí tài chính, không phải xuất hóa đơn)
2. Mã làm việc xấu vẫn là mã làm việc, bạn có nguy cơ tạo ra sự cố thay vì sửa chúng (chi phí chất lượng tiềm năng)
3. Các dự án khác sẽ bị trì hoãn trong khi bạn tái cấu trúc (chi phí thời gian)

Tất cả các số như vậy cuối cùng dựa trên dự đoán, trong trường hợp của bạn so sánh số tiền bạn đoán sẽ không tốn cho việc tái cấu trúc so với số tiền bạn đoán sẽ phải trả cho việc tái cấu trúc. Điều tốt nhất bạn có thể làm là cho thấy bạn có một số loại số, cơ sở thực tế cho các dự đoán và bạn có một số khá tốt.

Ưu điểm là nó có thể sẽ có hiệu quả trong việc thuyết phục họ cho phép bạn tái cấu trúc, và nó có thể hoạt động tốt và giảm số lượng lỗi.

Nhược điểm là nếu lượng thời gian dành cho việc sửa lỗi không giảm ít nhất bằng thời gian tái cấu trúc, bạn có thể sẽ không được phép tái cấu trúc nữa và có thể bạn sẽ bị đổ lỗi cho thời gian "lãng phí" .

Tiết kiệm thời gian gỡ lỗi có được bằng cách giảm độ phức tạp của toàn bộ dự án hoặc để dễ dàng thêm các tính năng, có thể quá khó để đo lường để giúp bạn nhiều, nhưng bạn có thể đề cập rằng chúng tồn tại.