Cứ bốn sprint lại có một "sprint ổn định" để sửa lỗi: hardening sprint là triệu chứng, không phải giải pháp

Tình huống minh hoạ

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

Một công ty fintech có ba đội Scrum phát triển nền tảng cho vay tiêu dùng, sprint 2 tuần. Lịch phát hành được tổ chức theo nhịp: 4 sprint tính năng + 1 "sprint ổn định" (hardening sprint). Trong sprint ổn định, các đội:

• Chạy kiểm thử hồi quy thủ công toàn hệ thống (khoảng 800 kịch bản).
• Kiểm thử hiệu năng và bảo mật trên môi trường giống thật.
• Sửa các lỗi tích luỹ từ 4 sprint trước.
• Cập nhật tài liệu vận hành.

Ban đầu sprint ổn định có vẻ hợp lý. Nhưng sau một năm: số lỗi tìm thấy trong sprint ổn định ngày càng nhiều, sprint ổn định thường phải kéo thành hai, và các Sprint Review của sprint tính năng trở nên vô nghĩa — mọi người đều biết "tính năng xong" chưa thật sự xong.

Scrum Guide 2020 nói gì

Hai quy định của Scrum Guide 2020 trực tiếp liên quan:

1. Mỗi sprint phải tạo ra ít nhất một Increment — một bước tiến cụ thể hướng tới Product Goal, và Increment phải dùng được (usable). Scrum Guide không có khái niệm sprint "chuẩn bị", sprint "tích hợp" hay sprint "ổn định".
2. Definition of Done (DoD) là mô tả chính thức về trạng thái của Increment khi đạt các tiêu chuẩn chất lượng cần thiết cho sản phẩm. Một mục backlog chưa đạt DoD thì không được phát hành, thậm chí không được trình bày tại Sprint Review; nó quay lại Product Backlog.

Như vậy, nếu story được gọi là "Done" ở sprint tính năng nhưng vẫn cần kiểm thử hồi quy, kiểm thử hiệu năng, sửa lỗi trước khi phát hành, thì nó chưa Done theo nghĩa của Scrum. Hardening sprint chính là nơi phần "chưa Done" được dồn tới — một dạng dây chuyền thác nước thu nhỏ đặt sau bốn sprint.

Agile Alliance gọi đúng tên khoảng cách này: "lập trình xong" khác với "xong thật sự" (gồm kiểm thử, tài liệu, sẵn sàng triển khai). DoD tồn tại để xoá khoảng cách đó, và phải được hiển thị rõ như một thoả thuận mà mọi thành viên đều biết.

Chi phí ẩn của hardening sprint