Làm rõ nợ kỹ thuật trong quyết định sản phẩm

Nợ kỹ thuật là cách gọi hữu ích cho lối tắt hoặc điểm yếu cấu trúc làm thay đổi về sau khó hơn.[8] Nhãn này mất tác dụng nếu mọi phần hệ thống không được ưa thích đều bị gọi như vậy. Người phụ trách sản phẩm cần ràng buộc cụ thể, không chỉ yêu cầu dọn mã chung chung. Mô tả điều nhóm chưa thể thay đổi, kiểm thử hoặc hỗ trợ một cách tin cậy, rồi nối giới hạn đó với quyết định của khách hàng.

Chuyển quan ngại thành hệ quả quan sát được

Bắt đầu bằng ví dụ: sửa giá nhỏ phải chỉnh ở nhiều nơi, hoặc kiểm tra hồi quy cần chuẩn bị thủ công khiến phát hành bị chặn. Tách bằng chứng khỏi dự đoán. Đưa hồ sơ công việc hoặc bước lặp lại liên quan, nhưng không tự tạo lợi ích tài chính hay hứa viết lại sẽ xóa mọi chậm trễ tương lai.

Mô tả hiện trạng, tác vụ chịu ảnh hưởng, cách xử lý tạm và điều kiện có thể làm mức tiếp xúc tăng. Nêu phần chưa chắc chắn. Thành phần mong manh nhưng ít dùng chưa chắc cần ưu tiên ngang thành phần mà mọi tính năng dự kiến đều phải sửa. Cách mô tả này giúp chủ nghiệp vụ và kỹ thuật nói về cùng một vấn đề.

Đặt phương án sửa cạnh phương án sản phẩm

Scrum Guide mô tả Product Backlog là danh sách có thứ tự, liên tục phát triển, gồm những gì cần để cải thiện sản phẩm.[1] Khuyến nghị ở đây là làm rõ công việc sửa đáng kể trong danh sách đó, thay vì giấu trong ước tính tính năng khác. Hiển thị rõ không có nghĩa mọi việc dọn mã đều phải làm ngay.

Dùng hồ sơ quyết định ngắn cho phương án sửa đang cân nhắc.

• Nêu ràng buộc và đính kèm ví dụ đã quan sát.
• Nối ràng buộc với tính năng dự kiến hoặc nghĩa vụ hỗ trợ.
• Đưa phương án sửa nhỏ, thay đổi lớn hơn và trì hoãn.
• Định nghĩa phép kiểm tra chứng minh việc sửa có tác dụng.
• Ghi rủi ro còn lại và điều kiện xem lại quyết định trì hoãn.

Ví dụ giả định: quy tắc giảm giá bị lặp

Trong ví dụ giả định về dịch vụ thuê bao, điều kiện giảm giá nằm ở cả mã đăng ký và gia hạn. Chương trình khuyến mại dự kiến cần hành vi nhất quán tại hai nơi. Nhóm đề xuất thay đổi có giới hạn để tập trung quy tắc và thêm bài kiểm tra chung, thay vì yêu cầu viết lại hệ thống tính phí không có điểm kết thúc rõ.

Người phụ trách sản phẩm so sánh cách sửa đó với chỉnh tạm hai nơi và tăng kiểm tra. Hồ sơ quyết định thừa nhận phần sửa lấy năng lực từ tính năng khác. Hồ sơ cũng định nghĩa thành công: quy tắc khuyến mại chỉ đổi tại một nơi và các kiểm tra đăng ký, gia hạn đã thống nhất đều đạt. Đây là tiêu chí đề xuất, không phải kết quả đo lường đã có.

Bảo vệ chất lượng nhưng không coi mọi thiết kế lại là khẩn cấp

Scrum Guide nêu chất lượng không được giảm trong Sprint.[1] Đừng dùng nợ kỹ thuật để cho phép bỏ qua chuẩn chất lượng đã thống nhất. Phân biệt thỏa hiệp thiết kế có thể chấp nhận với kiểm tra bắt buộc còn thiếu hoặc lỗi đã biết khiến cách dùng dự kiến không thực hiện được.

Phạm vi sửa cũng có thể phình ra khi xuất hiện phụ thuộc ẩn. Đặt ranh giới điều tra và điểm xem lại phạm vi. Trong lần ưu tiên tiếp theo, mang một ràng buộc có bằng chứng và phương án. Hỏi nó làm đổi quyết định sắp tới nào, rồi chỉ dành năng lực cho phần sửa có mục đích khách hàng hiểu được.