Tech debt không tự hết — cách team xử lý bằng Inspect & Adapt

Có một nghề bí ẩn không ai khai trên CV: kiếm tiền tổ tiên code mình để lại để trả nợ code ông dev 2019 để lại. Tên thật là “xử tech debt”, và nó đẹp như khoản vay lãi kép — chỉ có điều lãi trả từ riêng bạn, trừ lương overtime của bạn.

Mình từng đứng trước một codebase mà câu “cleanup chỉnh lại cái này” được dời 4 sprint liên tiếp. Không phải team lười. Team không có cơ chế để debt đi vào backlog và được trả đều. Hôm nay nói về cái cơ chế đó — gọi tắt là Inspect & Adapt, hai chữ tưởng khô khao mà đã thay đổi mọi thứ.

Tech debt giống nợ thật — chỉ xấu hơn

Dân trà đá hay ví vui, nhưng thật sự nó giống nợ vì cũng có lãi. Nợ bình thường ngân hàng tính lãi bằng tiền. Tech debt tính lãi bằng:

• Thời gian — thêm mỗi feature xài if đền chồng else ngày càng chậm
• Rủi ro — không ai dám đụng vì “vùng này ai cũng sợ”
• Pipeline — bộ test phụt mất 40 phút vì chạy qua 3 môi trường cũ
• Con người — dev giỏi bỏ đi, dev mới bỏ chạy

Cái khiến tech debt đáng sợ hơn nợ thật: không có lịch trả nợ. Nợ ngân hàng có hạn, có lãi suất cố định, có con số rõ. Tech debt vô hình — chui vô sprint review, đẻ ra “bug random”, làm demo “tự nhiên lag”. Nó không bao giờ xuất hiện tên trong một ticket để cả team ngồi nhìn vào và nói “à, đây là nợ”.

Đó là lý do “cứ để đó rồi nó tự hết” không bao giờ đúng. Debt không tự hết — nó tự sinh lãi và chờ người khác khổ.

Inspect & Adapt — nghe triết lý, làm thì mới hiểu

Agile có cái bộ ba tưởng như trang trí: Inspect (nhìn kỹ thực tế), Adapt (đổi mặt sau khi nhìn). Người ta hay nhắc nó như khẩu hiệu trên poster. Thật ra nó là vòng phản hồi có kỷ luật — và tech debt cực kỳ cần cơ chế đó, vì nó là thứ dễ bị “inspect rồi quên” nhất.

Vấn đề thực tế: team biết có debt. Retro ai cũng gật đầu “ừ điểm này tệ”. Nhưng sau retro, debt không có sponsor, không có đo đạc, không có nơi chứa. Kết cục: vòng Inspect có thật, vòng Adapt không. Retro xong, ai về làm feature tiếp.

Để Adapt chạy được thì phải trả lời 4 câu trước khi mở kho:

1. Debt ở đâu — đo được bằng gì, không phải bằng cảm giác?
2. Trả đúng cái nào trước — theo độ đau, không theo độ hợp gu?
3. Nó nằm chỗ nào để không bị rơi khỏi backlog?
4. Trả bao nhiêu mỗi sprint — để không tuần nổ một mạch rồi tháng sau quên?

Đo — debt không thành tội thì không thành nợ

Đừng hỏi “cái này sạch chưa” — chuyện đó không trả lời nổi. Hỏi “cái này tốn bao nhiêu khi chạm”:

Dấu hiệu	Cách đo (đừng phán bừa)
Vùng code ai cũng sợ	Số lần bị sửa trong 90 ngày / số incident liên quan
Test chậm	Thời gian one test vs cả suite; tỉ lệ flaky
Build/dependency cũ	Số major version tụt sau; thời gian upgrade
“Chỗ này xào code nản”	Feedback từ team (khảo sát nhỏ, gom điểm)
Chạm phát vỡ	Failure rate khi deploy chạm module đó

Ý không phải xây dashboard hoành tráng. Ý là: mỗi tiếng “dọn dẹp” đổi ra một con số để tuần sau so sánh được. Không đo thì không biết trả được chưa, trả có tiến không.

Ưu tiên — trả theo độ đau, không theo độ sạch

Đừng chọn “cái nào mình thích nhất”. Chọn theo giá trả:

• Đau mỗi tuần (dân cứ chạm là than) → trả trước
• Chặn feature sắp tới (báo trước cần chạm thì phải động, syntax cũ đắt quá) → trả trước
• Rủi ro âm thầm (không ai đụng nhưng đang sát lõi critical path) → trả trước mặc dù “bây giờ đang chạy ngon”

Một mẹo hay: gắn chi phí cơ hội vào. “Cái này chặn feature X đang mất tiền” nghe rõ hơn “cái này code cũ quá”. Người duyệt ngân sách (kể cả chính bạn) dễ gật đầu cho thứ chặn doanh thu hơn thứ xấu xí.

Chỗ chứa — đừng để debt loảng xoảng dưới đáy backlog

Debt cần nơi chứa được thấy — không trôi dạt. Ví dụ:

• Task riêng trong backlog có tag tech-debt, có estimate, có owner
• Spike task cho thứ cần mò trước mới ước lượng được
• Bổ sung acceptance — “chạy xong không tăng thêm flaky test”, “không hạ độ phủ dốc”

Quan trọng: đừng đưa debt vào một cuộc thi “tuyệt đối sạch”. Tap trả đều vẫn hơn đợt tắm trắng một tuần xong quên. Một team nợ nần kiểu mạn phép — mỗi sprint dành 20% cho debt — sau 2 tháng nhìn lại thấy suite test ổn hơn hẳn một team khác để dành “tuần lễ rửa tội” mỗi quý.

Trả đều — 20% hay một lượng cố định, tùy chỗ

Số cụ thể tùy ngữ cảnh, nhưng quy tắc vàng: cố định và lặp lại. Vì tech debt chui vô nơi vô định, nên nó cần đều đặn hơn nhiều. Hai cách chơi:

1. Tỉ lệ phần trăm — 20% capacity mỗi sprint cho debt. Dễ nhớ, luôn có “luồng trả nợ”.
2. Đơn vị đo cố định — mỗi sprint “giảm X% flaky test” hoặc “rút Y phút build”. Kết quả đo được, không cãi.

Cái nào cũng được, miễn là nó nằm trong cam kết sprint ngang hàng feature — không phải “dọn được thì dọn”. Một khi debt có chỗ trong cam kết, nó mới thật sự được trả, không phải được hứa.

Vì sao cách này hết “nợ này” của team

Quay lại codebase mình kể đầu bài. Thay đổi thật sự không phải thêm mấy task — mà là đổi câu hỏi. From “có nên dọn không?” — câu hỏi cho phép trả lời để đó đã — sang “tuần này trả phần nào?” Không ai hỏi “có nên không” nữa. Hỏi “bao nhiêu”. Toàn bộ cơ chế Inspect & Adapt chỉ để biến câu “có nên không? (chần chừ)” thành câu “được bao nhiêu? (hành động)”.

Đổi câu hỏi, đổi cả lịch trình. Retro không còn là nơi than vãn — là nơi đo, chọn, chốt con số tuần sau. Fail qua failed nhưng rủi ro giảm dần vì ai cũng thấy tiến.

Takeaway

Tech debt là thứ nợ nần mà nợ ngân hàng còn rõ hơn. Muốn hết thì không phải chờ “có thời gian” — phải cho nó khung kỷ luật:

• Inspect: đo bằng con số, đừng đo bằng cảm giác
• Adapt: ưu tiên theo độ đau, đưa vào backlog, trả đều mỗi sprint
• Kỷ luật: 20% hay một mức cố định — miễn là lặp lại, không phải “tuần lễ rửa tội”

Sprint tới, đừng hỏi “có nên dọn tech debt không?”. Hỏi: “tuần này mình trả được phần nào?” — và chốt con số. Đó mới là Inspect & Adapt mà không cần dán chữ lên tường.