Rủi ro trong dự Agile phải được quản lý ra sao vì không thấy nhắc đến trong Scrum

Quản lý rủi ro trong dự án Agile (Scrum) là câu hỏi nhiều người gặp phải trong quá trình tìm hiểu về Agile và Scrum. Ở bài viết này mình sẽ chia sẻ về nội dung này để mọi người có thêm góc nhìn.

  1. Đặc điểm quản lý rủi ro trong dự án Agile/Scrum.
  2. Thực hành quản lý rủi ro trong Agile.
  3. Có thể sử dụng 2 phương pháp quản lý rủi ro cùng nhau không.
  4. Tổng kết.

Phần 1: Đặc điểm của quản lý rủi ro trong dự án áp dụng Agile và Scrum

Đầu tiên, xin quay lại với tuyên ngôn Agile:

Cá nhân và tương tác hơn là quy trình và công cụ.
Phần mềm chạy tốt hơn là tài liệu đầy đủ.
Cộng tác với khách hàng hơn là đàm phán hợp đồng.
Phản hồi với thay đổi hơn là tuân theo kế hoạch.
Mặc dù những điều ở bên phải vẫn còn giá trị, nhưng chúng tôi đề cao những điều ở bên trái.

Tuyên ngôn Agile giúp tập trung vào con người và đội nhóm, sản phẩm, việc tương tác với khách hàng, và sự “linh hoạt” khi thích nghi nhanh chóng với các thay đổi. Mang trong mình triết lý Agile, Scrum framework thể hiện việc giảm thiểu rủi ro dự án thông qua các đặc điểm:

1. Tính minh bạch về thông tin: Scrum có tôn chỉ minh bạch về mọi thông tin, các công việc đang làm, các vấn đề của đội nhóm, các vấn đề kĩ thuật…để chúng ta có thể sớm thấy rủi ro.

2. Tương tác đội nhóm: Thông qua các sự kiện, Scrum giúp nhóm tương tác tích cực dần theo thời gian, từ đó khai thác kiến thức của tập thể và giúp sớm phát hiện nhiều rủi ro hơn.

3. Hợp tác với khách hàng: Suốt vòng đời của sản phẩm, sau mỗi sprint từ 1-4 tuần, khách hàng cùng tham gia với đội nhóm để theo dõi tiến trình của sản phẩm. Điều này giúp dự án giảm thiểu rủi ro từ phía khách hàng.

Phần 2: Quản lý rủi ro trong dự án Agile/Scrum diễn ra như thế nào?

Tiếp cận dự án theo phương pháp Agile giúp nhóm phát triển và khách hàng đồng bộ với nhau về nhu cầu của sản phẩm. Nhóm hiểu rõ, và hiểu đúng những gì mà khách hàng mong muốn, điều này giúp hạn chế rủi ro giao nhầm sản phẩm (release những thứ nhóm cho là đúng nhưng khách hàng không cần). Ngoài ra việc thấu hiểu giá trị sản phẩm với khách hàng cũng giúp nhóm có thêm nhiều trách nhiệm và hỗ trợ cho sản phẩm.

Scrum cho phép nhóm thực hành lập kế hoạch dựa trên lịch sử, điều này giúp giảm thiểu rủi ro ước tính (thay cho cách làm thông thường, sau khi estimate, nhóm sẽ buffer thêm 20-40% thời gian làm). Thay vì vậy Scrum khuyến khích nhóm nhìn lại quá trình làm việc trong các sprint và đưa ra ước tính dựa trên kinh nghiệm và năng lực thực sự của nhóm. Từ đó các bên liên quan có trách nhiệm sẽ minh bạch được thông tin và đưa ra các quyết định kịp thời. Ngoài ra khi lập kế hoạch, nhóm phát triển luôn có cơ hội lập kế hoạch công việc ở cấp độ tính năng, điều này khiến nhóm có góc nhìn rộng hơn để đánh giá các rủi ro tiềm ẩn khi tích hợp vào sản phẩm.

Nhiều nhóm không làm Scrum hay Agile nhưng vẫn thực hiện Daily Meeting, với cá nhân mình thì không có đúng hoặc sai, chỉ là nó có phù hợp cho nhóm – hay tổ chức của bạn không mà thôi. Câu hỏi là nếu Daily Meeting không có bất kì lợi ích nào, vì sao mọi người lại áp dụng nó, và dường như nó còn đang trở thành phong trào trong các công ty làm phần mềm? Bàn luận thêm về Daily Meeting, các bạn có thể xem bài viết khác của mình. Còn ở khía cạnh quản lý rủi ro, Daily Meeting giúp bạn phát hiện sớm rủi ro sau mỗi 24h! Thật lợi ích đúng không?

Sau mỗi 1-4 tuần, nhóm sẽ có buổi Sprint Review theo Scrum Framework. Điều này giúp nhóm liên tục tiếp xúc và đưa sản phẩm tới khách hàng, giúp giảm thiểu rủi ro xây dựng dự án theo tiêu chuẩn kĩ thuật nhưng không theo nhu cầu thực tế của khách hàng. Việc này khá thường xuyên xảy ra với các dự án phần mềm theo mô hình thác nước cũ, khi nhóm phát triển demo sản phẩm cho khách hàng vào cuối giai đoạn phát triển, tất cả các chức năng đều hoạt động tốt theo tiêu chuẩn kĩ thuật, nhưng khách hàng thì lại mong muốn có một chức năng khác mà không quan tâm tới công sức đội phát triển!

Scrum định nghĩa rủi ro khác với cách quản lý thông thường, thay vì việc quản lý rủi ro theo phần trăm tiến độ hoàn thành của công việc (lưu ý rằng có những công việc chỉ còn 1% là hoàn thành, nhưng chiếm tới 99% để phát triển) Scrum hướng tới việc quản lý dựa trên các tiêu chí hoàn thành khác nhau.

Quản lý theo phần trăm tiến độ công việc.

 

Quản lý theo định nghĩa hoàn thành

 

3. Có thể sử dụng 2 phương pháp quản lý rủi ro này cùng nhau không?

Câu trả lời là có. Thực tế khi áp dụng triển khai phát triển phần mềm theo phương pháp Agile, các phương pháp quản lý rủi ro trong phương pháp truyền thống vẫn còn nguyên giá trị. Thêm nữa, Agile hay Scrum cũng không hề đề cập tới việc quản lý rủi ro ở mặt chi phí hay con người (thực ra ở cách vận hành team cũng đã hướng tới đội nhóm và con người, nhưng dù sao một kế hoạch backup cho nhân sự cũng nên là một phương án cần đảm bảo khi thực thi dự án).

4. Tóm tắt

– Quản lý rủi ro kiểu truyền thống bằng cách hình dung trước tất cả các vấn đề, phân tích chúng và đưa ra giải pháp. Khác với phương pháp này, phát triển phần mềm theo Agile hay Scrum giảm thiểu rủi ro bằng cách thực hiện liên tục các hành động nhằm minh bạch hoá thông tin và phát lộ sớm vấn đề sau đó là hình dung và giải quyết chúng.

Một nhân viên công ty trước kia làm ở vị trí Project Manager. Bây giờ công ty chuyển đổi qua làm dự án theo Agile. Team dự án được tổ chức theo Scrum và đang đề bạt bạn PM này làm Product Owner. Bạn này thắc mắc rằng: Rủi Ro trong dự Agile phải được quản lý ra sao vì không thấy nhắc đến trong Scrum? Trên cương vị là Scrum Master, mà công ty đang làm việc từ xa, không có điều kiện gặp mặt đào tạo trực tiếp, bạn hãy viết một bài giải thích cho PM hiểu về việc quản lý rủi ro trong dự án. Cũng như hướng dẫn PM cách thức quản lý rủi ro hiệu quả.