Dự án agile không có sổ rủi ro: nhận diện rủi ro liên tục qua backlog, spike và các sự kiện Scrum

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 khởi nghiệp công nghệ tài chính phát triển ứng dụng ví điện tử theo Scrum, sprint 2 tuần, đội 7 người. Khi Giám đốc sản phẩm hỏi về quản lý rủi ro, Scrum Master trả lời: "Agile không cần sổ rủi ro. Sprint ngắn và giao hàng liên tục tự nó đã giảm rủi ro rồi."

Sáu sprint đầu diễn ra tốt, velocity ổn định. Đến sprint 7, đội bắt đầu làm tính năng liên kết tài khoản ngân hàng — hạng mục giá trị nhất trong backlog nhưng được xếp sau vì "phụ thuộc đối tác". Khi kết nối thật với cổng API của ngân hàng đối tác, đội phát hiện:

• Quy trình cấp quyền truy cập môi trường thử của ngân hàng mất 4–6 tuần.
• Chuẩn xác thực của ngân hàng khác với thư viện đội đã chọn từ sprint 2.
• Một số trường dữ liệu bắt buộc theo quy định chưa có trong thiết kế.

Mốc ra mắt bị lùi gần 2 tháng. Khi nhìn lại, cả ba điều trên đều có thể phát hiện từ sprint 1 nếu có ai đó hỏi đúng câu hỏi.

Agile có quản lý rủi ro không?

Có — nhưng theo cách khác. Scrum Guide 2020 nói rõ Scrum dùng cách tiếp cận lặp và tăng trưởng (iterative, incremental) để tối ưu khả năng dự đoán và kiểm soát rủi ro. Một số điểm trong Scrum Guide:

• Sprint ngắn hơn tạo nhiều vòng học hơn và giới hạn rủi ro về chi phí, công sức trong khoảng thời gian nhỏ hơn.
• Các artifact có tính minh bạch thấp có thể dẫn tới quyết định làm giảm giá trị và tăng rủi ro.
• Các artifact và tiến độ phải được kiểm tra thường xuyên để phát hiện sai lệch hoặc vấn đề không mong muốn.

Nhưng sprint ngắn chỉ giới hạn thiệt hại khi phát hiện, không tự động phát hiện rủi ro. Nếu hạng mục rủi ro nhất bị xếp cuối backlog, sprint ngắn cũng không giúp gì cho tới khi đội chạm tới nó.

PMBOK® Guide ấn bản 7 xếp vấn đề này vào lĩnh vực hiệu suất Development Approach and Life Cycle (chọn cách tiếp cận phù hợp với mức bất định) và Uncertainty. Quy trình Identify Risks của PMBOK 6 vẫn áp dụng — chỉ là được thực hiện liên tục, nhẹ nhàng và gắn vào nhịp làm việc thay vì một sự kiện lớn ở đầu dự án.

Đưa nhận diện rủi ro vào nhịp Scrum

1. Product Backlog: xếp hạng có tính đến rủi ro

Thứ tự backlog nên cân nhắc cả giá trị lẫn rủi ro. Hạng mục giá trị cao, rủi ro cao (như liên kết ngân hàng) thường nên làm , vì phát hiện vấn đề sớm thì còn thời gian và lựa chọn để xử lý. Một số đội đưa thẳng hoạt động giảm rủi ro thành hạng mục trong backlog — đôi khi gọi là backlog điều chỉnh theo rủi ro (risk-adjusted backlog).