Quản lý yêu cầu thay đổi mà không mất dấu phạm vi gốc

Khách hàng cần thay đổi ý kiến khi hiểu thêm về sản phẩm. Nhóm triển khai cũng cần hồ sơ ổn định về nội dung đã cam kết cung cấp. Yêu cầu thay đổi phải đáp ứng cả hai nhu cầu. Mục đích không phải ngăn học hỏi, mà là làm rõ khác biệt, hệ quả và thẩm quyền chấp nhận các hệ quả đó.

Giữ mốc phạm vi gốc không bị sửa mất

Lưu phiên bản đã thống nhất của phạm vi ban đầu, cùng giả định, nội dung loại trừ và điều kiện nghiệm thu. Liên kết từng thay đổi đề xuất với phiên bản này. Đừng ghi đè nội dung mới rồi yêu cầu mọi người tự nhớ nghĩa vụ nào đã đổi.

Phân biệt yêu cầu mới với lỗi hoặc làm rõ yêu cầu. Lỗi nghĩa là thiếu hành vi đã thỏa thuận. Làm rõ giúp giải quyết mơ hồ nhưng chưa chắc làm tăng công việc. Nếu có tranh luận về phân loại, ghi lại các cách hiểu và yêu cầu người có thẩm quyền quản lý phạm vi giải quyết trước khi dùng nhãn đó để phân bổ công sức.

So sánh lựa chọn thay vì chỉ đưa một ước tính

Scrum Guide cho phép làm rõ và thương lượng lại phạm vi với Product Owner khi có hiểu biết mới, đồng thời bảo vệ Sprint Goal.[1] Điều này không thay thế thỏa thuận thương mại. Khuyến nghị ở đây là giữ luồng phê duyệt theo hợp đồng, nhưng vẫn cho phép kế hoạch triển khai phản ánh kiến thức mới.

Đưa ra phương án thực chất: thêm việc, đổi lấy hạng mục khác, thu hẹp hành vi hoặc để sau. Tính cả phân tích và kiểm thử, không chỉ lập trình.

• Liên kết yêu cầu gốc cụ thể và nội dung thay thế dự kiến.
• Xác định giao tiếp hệ thống, bài nghiệm thu và tài liệu hỗ trợ bị ảnh hưởng.
• Nêu từng phương án thêm, bỏ hoặc làm chậm điều gì.
• Ghi người có quyền phê duyệt và giả định chưa giải quyết.
• Chỉ cập nhật kế hoạch bàn giao sau khi ghi nhận quyết định.

Ví dụ giả định: quy tắc hoàn tiền mới

Trong ví dụ giả định về dịch vụ đặt chỗ, phạm vi gốc cho phép hoàn tiền toàn bộ trước hạn chót. Một bên liên quan yêu cầu hoàn một phần sau hạn đó. Nhóm ghi rõ quy tắc tính mới, quyền phê duyệt, thông báo khách hàng và kiểm tra đối soát, thay vì coi đây là thay đổi nhỏ ở một nút bấm.

Người bảo trợ có thể đổi một tính năng báo cáo ít dùng lấy phần hoàn tiền, chấp nhận dự báo mới hoặc hoãn yêu cầu. Nghĩa vụ hoàn tiền toàn bộ ban đầu vẫn hiển thị trong mọi phương án. Nếu chọn hoán đổi, hồ sơ phải nêu chính xác hành vi báo cáo nào được loại khỏi phạm vi hiện tại.

Theo đến cùng sau phê duyệt

Yêu cầu được duyệt chưa hoàn tất chỉ vì đã có chữ ký. Kết nối quyết định với tiêu chí nghiệm thu sửa đổi, công việc phụ thuộc, phạm vi kiểm thử và kế hoạch thông tin cho khách hàng. Giữ yêu cầu bị từ chối hoặc hoãn ở nơi tìm được để chúng không quay lại dưới dạng cam kết tưởng như đã có.

Bắt lập hồ sơ chính thức cho mọi sửa câu chữ nhỏ sẽ gây chậm trễ và tốn quản trị. Thống nhất ngưỡng cho cách làm rõ gọn nhẹ, nhưng chuyển cấp thay đổi ảnh hưởng nghĩa vụ, rủi ro hoặc dự báo bàn giao. Cùng khách hàng và nhóm xem lại một thay đổi gần đây. Mọi người cần giải thích được lời hứa ban đầu, khác biệt đã chấp nhận và phần vẫn nằm ngoài kế hoạch.