Velocity giảm dần dù đội không đổi: nhận diện và trả nợ kỹ thuật (technical debt) có kế hoạch

Tình huống minh hoạ

Tình huống dưới đây là giả định, dùng để minh hoạ.

Một công ty logistics nội địa vận hành ứng dụng điều phối đơn giao hàng cho khoảng 1.500 tài xế. Phiên bản đầu tiên được làm gấp trong bốn tháng để kịp mùa cao điểm cuối năm. Đội Scrum 7 người, PO là anh Bảo – Giám đốc Vận hành.

Một năm sau, Scrum Master là chị Ngọc thấy các dấu hiệu đáng lo:

• Velocity trung bình giảm từ khoảng 40 point xuống 26 point/sprint trong sáu sprint, dù thành viên đội không đổi.
• Mỗi bản phát hành phát sinh 5–8 lỗi hồi quy (regression); có lần lỗi tính phí giao hàng khiến tổng đài nhận hàng trăm cuộc gọi.
• Lập trình viên ngại sửa module tính tuyến vì "đụng vào là vỡ"; chỉ một người hiểu được đoạn mã đó.
• Kiểm thử chủ yếu thủ công, mất hai ngày cho mỗi lần phát hành.

Anh Bảo đề nghị "tăng thêm người cho nhanh". Đội thì muốn "dừng ba tháng để viết lại".

Phân tích theo PMBOK® Guide

Nợ kỹ thuật (technical debt) là chi phí tương lai phát sinh khi đội chọn giải pháp nhanh thay vì giải pháp bền vững. Như nợ tài chính, nó có "lãi": càng để lâu, mỗi thay đổi càng tốn kém. Nợ kỹ thuật không phải lúc nào cũng xấu – vay nợ có chủ đích để kịp thời điểm thị trường có thể hợp lý – miễn là được ghi nhận và có kế hoạch trả.

Measurement Performance Domain yêu cầu chọn thước đo phản ánh đúng sức khoẻ dự án, có cả chỉ số dẫn dắt (leading) lẫn trễ (lagging). Velocity giảm là chỉ số trễ; tỷ lệ lỗi hồi quy, độ phủ kiểm thử tự động, thời gian từ commit tới phát hành là các chỉ số có thể báo hiệu sớm hơn.

Delivery Performance Domain nhấn mạnh chất lượng gắn với giá trị: sản phẩm khó thay đổi làm giảm khả năng đáp ứng nhu cầu mới. Nguyên tắc liên quan: Build quality into processes and deliverables và Optimize risk responses – nợ kỹ thuật thực chất là một rủi ro tích luỹ.

Nguyên nhân gốc:

1. Áp lực tiến độ ban đầu dẫn tới bỏ qua kiểm thử tự động và tái cấu trúc (refactoring).
2. Nợ không được ghi nhận ở đâu nên PO không thấy, không ưu tiên.
3. Definition of Done thiếu tiêu chí về kiểm thử và chất lượng mã.
4. Tri thức tập trung vào một người, tăng rủi ro.

Cách xử lý

1. Làm cho nợ "nhìn thấy được"

Đội liệt kê các khoản nợ, ước lượng tác động và đưa vào Product Backlog như các hạng mục thực sự: