Câu trả lời được chấp nhận
Nguyễn Thu Hà, PMP
Cả hai phía đều đúng một phần. Agile có cơ chế giảm rủi ro mạnh, nhưng điều đó không thay thế việc nhận diện và theo dõi rủi ro có chủ đích, nhất là rủi ro nằm ngoài phạm vi của đội (pháp lý, nhà cung cấp, ngân sách).
Cơ chế giảm rủi ro sẵn có trong agile
- Vòng lặp ngắn và Increment đạt Definition of Done → phát hiện sai lệch sớm, giới hạn thiệt hại trong một sprint.
- Sprint Review với bên liên quan → giảm rủi ro "làm đúng nhưng không ai cần".
- Daily Scrum, bảng trực quan → lộ trở ngại nhanh.
- Ưu tiên làm trước những hạng mục rủi ro cao, giá trị cao; dùng spike để giảm bất định kỹ thuật.
Cách làm rủi ro "kiểu agile"
- Sổ rủi ro gọn, sống cùng backlog: 10–15 rủi ro hàng đầu, mỗi rủi ro có người theo dõi, xem lại ở Sprint Planning hoặc Review.
- Biến ứng phó rủi ro thành hạng mục backlog (ví dụ: "kiểm thử tải với 5.000 người dùng đồng thời", "tích hợp thử với API đối tác") và để Product Owner xếp thứ tự cùng tính năng.
- Hiển thị rủi ro trên bảng thông tin trực quan (information radiator) hoặc biểu đồ burndown rủi ro để bên liên quan thấy xu hướng.
- Dành vài phút ở Retrospective cho câu hỏi "Điều gì có thể làm hỏng 3 sprint tới?".
Với phòng quản lý rủi ro: cung cấp sổ gọn, cập nhật theo nhịp sprint, kèm bằng chứng ứng phó (story đã làm). Như vậy đáp ứng yêu cầu quản trị mà không tạo thêm tài liệu riêng.
Hướng dẫn đánh giá agile của GAO cũng hướng tới việc giúp các cơ quan giảm rủi ro chương trình CNTT thất bại bằng thực hành agile — đồng thời coi giám sát và kiểm soát chương trình là một mảng thực hành bắt buộc.
Nguồn: