2008-09-10 42 views
21

Bạn có chủ động quản lý khoản nợ technical debt đối với các dự án phát triển phần mềm của mình không và nếu có, bạn làm như thế nào?Bạn có chủ động quản lý nợ kỹ thuật không?

+1

Câu hỏi này có vẻ ngoài chủ đề vì câu hỏi quản lý dự án không còn là chủ đề. Xem http://pm.stackexchange.com. – LittleBobbyTables

+0

Tôi đang bỏ phiếu để đóng câu hỏi này là không có chủ đề vì các câu hỏi quản lý dự án không còn là chủ đề. Xem [pm.stackexchange.com] (http://pm.stackexchange.com/tour). – Pang

Trả lời

3

Trên các nhóm của chúng tôi, chúng tôi chủ động quản lý nợ kỹ thuật. Chúng tôi làm Scrum, vì vậy chúng tôi tạo ra một thẻ nợ kỹ thuật cho lần lặp hiện tại hoặc lần lặp tiếp theo tùy thuộc vào ước tính và khả năng chạy nước rút còn lại của chúng tôi và chúng được ưu tiên giống như các tính năng và thẻ lỗi. Chúng tôi cũng quản lý các khoản nợ lớn hơn, nhóm chéo thông qua việc có một số dư nợ nhóm kỹ thuật mà chúng tôi ưu tiên và bơm vào mỗi nhóm Scrum trong quá trình lập kế hoạch chạy nước rút của họ.

9

Một khía cạnh của việc quản lý nợ kỹ thuật là thuyết phục các nhà quản lý phi kỹ thuật rằng bạn cần thời gian được phân bổ để tái cấu trúc và sửa lỗi.

Here's an article with specific suggestions cách thực hiện điều đó.

+2

+1 người hâm mộ lớn của blog của bạn Jason. –

+0

Cảm ơn @SnOrfus! Nếu bạn đang trên twitter theo @asmartbear và tôi sẽ đưa bạn trở lại. –

+0

Tôi đã đăng một số kỹ thuật và chiến thuật về nợ kỹ thuật tại đây: http://benlakey.com/2012/06/18/technical-debt/ –

2

Tôi nghĩ rằng điều quan trọng là phải lên lịch thời gian để xử lý nợ kỹ thuật nếu bạn đang cố gắng bù đắp cho những tội lỗi cũ, nhưng tôi cũng nghĩ bạn không nên tạo thói quen này. Một khi bạn dọn sạch mớ hỗn độn, bạn nên tránh đưa dự án của bạn vào nợ nhiều hơn, trừ khi bạn có lý do chính đáng để làm như vậy.

Chủ động quản lý nó như Mike gợi ý có vẻ là cách tiếp cận hợp lý nhất, nhưng tôi nghĩ rằng điều quan trọng là phải làm rõ (với nhóm của bạn) rằng bạn không nên lên lịch cho thời gian hoặc kế hoạch tái cấu trúc trong thời gian dài.

Việc tái cấu trúc phải là một phần tự nhiên của mã viết và do đó nên được bao gồm trong các ước tính và kế hoạch khác của bạn và không được coi là hoạt động riêng biệt — trừ khi bạn phải làm như vậy. đã quyết định triển khai một cái gì đó theo một cách nhất định và sau đó thực hiện lại nó sau này.

0

Nó phụ thuộc rất nhiều vào sản phẩm. Khi tôi làm việc trong một lĩnh vực mà mã của chúng tôi phải được kiểm toán bên ngoài, nó là một phần được hoạch định trong cuộc chạy nước rút của chúng tôi. PM chỉ yêu cầu phát triển khu vực cần tái cấu trúc và nó đã được đưa vào kế hoạch. Đó không phải là để nói rằng bạn sẽ không sửa mã trong khu vực bạn đang làm việc, nhưng bạn sẽ không dành một ngày để viết lại một đoạn mã bị xé nhỏ. Bây giờ tôi đang làm việc trong scrum và các nhà phát triển chỉ làm điều đó khi họ làm việc. Ấn tượng của tôi là về cùng một lượng thời gian đi vào công việc tái cấu trúc, dù bằng cách nào.

1

Những gì bạn làm là tạo văn hóa nơi mà nợ kỹ thuật không được chấp nhận trừ khi trong trường hợp cực đoan. Giống như những người chỉ trả tiền mặt và sử dụng tín dụng chỉ như một phương sách cuối cùng tuyệt đối.

0

Tôi đồng ý với Anders. Nếu bạn phải thiết lập hệ thống để quản lý nợ kỹ thuật, điều đó có nghĩa là bạn vẫn đang thêm nó. Ngừng đi vào nợ ở nơi đầu tiên bằng cách nâng cấp định nghĩa của bạn "thực hiện".

Điều này có nghĩa là các mô-đun "mắc nợ" sẽ khó thực hiện hơn. Các nhà phát triển nên nhận thức được điều này và chỉ định nhiều điểm câu chuyện hơn để họ để lại mọi thứ "thực hiện" trong nháy mắt của họ.

0

Nếu bạn trễ chu kỳ phát hành, bạn không muốn thay đổi cơ sở mã quá nhiều. Điều này có nghĩa là sẽ luôn có một số khoản nợ kỹ thuật. Tôi thường viết FIXME: s cho những thay đổi tối ưu và sau đó tôi chăm sóc chúng trước khi tôi bắt đầu triển khai các tính năng cho bản phát hành tiếp theo.

0

Java Posse đã bao gồm việc quản lý Technical Debt gần đây trông rất toàn diện.

1

Nếu tôi thực sự cần phải chồng chất nợ kỹ thuật, bởi vì tôi cần phải phát hành một cái gì đó NGAY BÂY GIỜ, tôi nộp một lỗi nghiêm trọng về nó, vì vậy nó được ưu tiên cao nhất.Nhưng nó chỉ dành cho những tình huống cực đoan (khách hàng đang nhảy lên và xuống, người vợ đang tìm kiếm một dingbat vv).

0

Về các dự án mà tôi đã tham gia cho đến nay, một số khoản nợ kỹ thuật đã được "thanh toán" (chỉ được quản lý) vào đầu giai đoạn mới của dự án, tức là sau "các bản phát hành lớn" hoặc các mốc quan trọng.

Một khía cạnh rất quan trọng về nợ kỹ thuật là nó không chỉ liên quan đến các nhà phát triển mà còn quản lý. Theo nghĩa đó, tôi biết rằng cách tốt nhất để giải quyết vấn đề là làm cho nó có thể nhìn thấy "các bên liên quan dự án phi kỹ thuật", người có thể phân bổ thời gian và nguồn lực để quản lý nợ kỹ thuật khi họ hiểu ý nghĩa của nó.

Điều này article thảo luận về một số loại nợ kỹ thuật, loại nợ nào có thể lành mạnh và đặc biệt cách quản lý và theo dõi tải nợ kỹ thuật.

Các vấn đề liên quan