Câu trả lời được chấp nhận
Nguyên tắc thứ 8 sau Tuyên ngôn Agile nói các quy trình agile thúc đẩy phát triển bền vững — nhà tài trợ, người phát triển và người dùng có thể duy trì nhịp độ ổn định vô thời hạn. Thực hành này có nguồn gốc từ Lập trình cực hạn (XP), ban đầu mang tên "tuần 40 giờ" trước khi Kent Beck đổi thành "nhịp độ bền vững"; Agile Alliance mô tả tư duy agile coi tăng ca thường xuyên là thứ che giấu vấn đề (lập kế hoạch, quản lý, chất lượng) chứ không giải quyết chúng.
Vì sao tăng ca kéo dài phản tác dụng
- Mệt mỏi làm tăng lỗi → chi phí sửa lỗi sau phát hành ăn mất phần "tăng tốc".
- Velocity "đẹp" là ảo: nó được duy trì bằng giờ làm không bền vững, nên dùng để dự báo sẽ sai khi đội không còn chịu nổi.
- Mất người → mất tri thức, tuyển và đào tạo người mới tốn nhiều thời gian.
- Tăng ca thường xuyên che giấu vấn đề thật: nhận quá nhiều việc vào sprint, ước lượng lạc quan, việc chen ngang.
Việc nên làm
- Làm hiển thị: ghi nhận giờ làm thêm, số lỗi thoát, xu hướng nghỉ việc và trình bày cùng velocity — để lãnh đạo thấy toàn cảnh.
- Lập kế hoạch sprint theo năng lực thực (giờ hành chính), chấp nhận velocity giảm trong vài sprint để có con số trung thực.
- Xử lý gốc: tách story nhỏ hơn, giới hạn WIP, kênh tiếp nhận việc chen ngang, đầu tư tự động hoá kiểm thử.
- Bảo vệ đội trước áp lực "chốt sprint bằng mọi giá": story chưa xong thì quay về Product Backlog — đó là cơ chế bình thường của Scrum, không phải thất bại.
- Theo dõi sức khoẻ đội trong Retrospective (khảo sát nhanh, lịch tâm trạng…).
Tăng ca thỉnh thoảng cho sự kiện thật sự đặc biệt có thể chấp nhận; tăng ca mỗi sprint là tín hiệu hệ thống cần sửa.
Nguồn: