Tôi thường được nghe mọi người nói rằng Scrum không quan tâm đến việc quản lý rủi ro. Không có risk log, không có nội dung nào liên quan đến rủi ro trong các buổi Sprint Review hoặc Retrospective. Development Team phải chịu trách nhiệm về chất lượng của sản phẩm tạo ra cũng như là cách mà họ làm. Có một rủi ro ở ngay đây. Nếu không có một người cụ thể chịu trách nhiệm về chất lượng, deadline, ngân sách, process ... vậy rủi ro sẽ được quản lý thế nào trong Scrum.

Rủi ro phụ thuộc góc nhìn mỗi người

Trước hết chúng ta nên tìm hiểu xem risk là gì. Trong từ điểm Oxford English có định nghĩa như sau :

(Exposure to) the possibility of loss, injury, or other adverse or unwelcome circumstance; a chance or situation involving such a possibility.

Đó là một định nghĩa rất rộng. Mỗi người sẽ có một giải thích cho riêng mình. Chính vì vậy tất cả chúng ta đều nhìn nhận rủi ro đôi chút khác nhau. Rủi ro cũng liên quan nhiều đến sự tham gia của chính chúng ta. Đôi khi rủi ro của người này nhưng đối với người khác thì không.

Rủi ro cũng liên quan mật thiết đến công việc mà chúng ta làm. Đối với một dự án hoặc sản phẩm có thể có mức độ rủi ro khác nhau với số còn lại có cùng tính chất.

Các lại rủi ro khác nhau

Trong các môi trường liên quan đến công việc chúng ta thường nói về :

• Rủi ro tài chính - chúng ta có thể chi trả cho nó không ?
• Rủi ro kinh doanh - sản phẩm sẽ được đón nhận và sử dụng ? Nó có giải quyết được vấn đề đặt ra không ?
• Rủi ro kỹ thuật - có thể thực hiện được không ?

Kiểm soát rủi ro với Scrum

Scrum là một phương pháp rất tốt để kiểm soát rủi ro trong một số cách. Dưới đây tôi nói rõ hơn về các rủi ro bên trên trong bối cảnh sử dụng Scrum

Rủi ro tài chính

Khi chuẩn bị xây dựng một hệ thống mới hoặc thay đổi một sản phẩm đã có, chúng ta muốn biết chi phí cho công việc đó là bao nhiêu. Thật không may, sự phúc tạp của việc phát triển các sản phẩm này gây ra sự sai lệch và gây khó khăn cho việc ước tính chi phí của dự án.

Đây thường là một chủ đề khó với nhiều người, bởi vì cách chúng ta điều hành dự án (không sử dụng Scrum) trước tiên là thiết lập phạm vi, tài chính và nguồn nhân lực. Với Scrum, một số người nói rằng bỏ qua giai đoạn đó nhưng thực sự thì không. Chúng ta xây dựng nó theo kinh nghiệm vì đó là cách tốt nhất để kiểm soát tương lai trong môi trường phức tạp.

Chúng ta xác định vai trò và trách nhiệm rõ ràng.

• Thiết lập vai trò của Product Owner: Người kiểm soát ngân sách và kế hoạch của sản phẩm
• Thành lập Development Team: nhóm tự tổ chức (self-organizing) gồm các chuyên gia đa chức năng, những người có thể hoàn thành công việc từ đầu đến cuối.
• Yêu cầu Scrum Master hỗ trợ, khuyến khích Scrum Team kiểm soát quy trình theo kinh nghiệm đồng thời huấn luyện nhóm tốt hơn từng chút mỗi ngày

Sau đó, nhóm sẽ phải đưa ra họ cần bao lâu để thực hiện những yêu cầu đầu tiên thành một kết quả cụ thể. Càng ngắn càng tốt, vì điều đó giúp tiết kiệm tiền. Còn nếu thời gian đó quá dài có thể dẫn đến lãng phí vào một công việc sai lầm.

Thường các nhà đầu tư chỉ tài trợ cho một vài sprint lúc đầu và xem xét kết quả sau mỗi sprint. Trao đổi với Product Owner và Development Team về kết quả và lợi tức từ việc đầu tư. Điều này có ý nghĩa là chi phí có thể đoán trước được. Chính là chi phí bỏ ra cho những sprint này.

Bản phát hành đầu tiên đến tay người dùng càng sớm thì rủi ro tài chính càng giảm !

Rủi ro kinh doanh

Rủi ro kinh doanh là khi người dùng không thực sự sử dụng sản phẩm của bạn do sản phẩm không giải quyết được vấn đề mà đáng ra nó phải làm được. Việc này thường xuyên xảy ra. Nguyên nhân không phải team của bạn ngu ngốc. Mọi thứ team làm trước đó đều hữu ích (Product Backlog refinement, yêu cầu kỹ thuật, nói chuyện với người dùng, thực hiện khảo sát ...) nhưng lại bỏ qua nguy cơ mọi người không thực sự sử dụng sản phẩm.

Trong Scrum, vai trò của Product Owner là giữ liên lạc chặt chẽ với các bên liên quan và Development Team do đó điều phù hợp chắc chắn được thực hiện. Cùng nhau xem xét phần gia tăng của mỗi Sprint và đưa ra quyết định thay đổi hoặc kiên trì theo đuổi ý tưởng đó.

Product Owner không phải là một Business Stakeholder cũng không phải là một nhà phân tích. Anh/cô ấy là đại điện kinh doanh trong team để quản lý và giám sát rủi ro kinh doanh, tạo ra một sản phẩm tốt nhất có thể.

Khi bắt đầu sử dụng Scrum hãy nhớ tới một yếu tố vô cùng quan trọng: Không còn "chúng ta" và "họ" nữa, tất cả cùng làm việc để giải quyết các vấn đề liên quan đến business

Rủi ro kỹ thuật

Những rủi ro kỹ thuật có thể được chia thành hai loại chính :

• Có thể tạo ra sản phẩm với tỷ lệ ROI (Return on Investment – tỷ lệ lợi nhuận ròng trên tổng chi phí đầu tư) không ?
• Có thể bảo trì sản phẩm trong suốt quá trình phát triển và sau đó không ?

Đây là những câu hỏi quan trọng bạn luôn phải tự hỏi bản thân trong suốt quá trình phát triển sản phẩm. Hàng ngày, Development Team cần phải đưa ra quyết định xem nếu dành thời gian cho một tính năng nào đó thì kết quả nhận được có xứng đáng với Product Owner hay không ? Vì vậy giao tiếp chính là chìa khóa chính ở đây.

Đối với việc maintain sản phẩm: Luôn giữ thói quen tìm kiếm các vấn đề kỹ thuật. Bất kể khi nào bạn gặp phải một vấn đề kỹ thuật không tốt hãy cố gắng làm nó tốt hơn (kể cả là chỉ một chút)

Quay lại với "Definition of Done" ở trong Scrum, một lần nữa chúng tao thấy nó có giá trị. Việc xác định "Done" rất quan trọng để kiểm soát những rủi ro về kỹ thuật. Điều này có thể nâng cao cả chất lượng và khả năng bảo trì của sản phẩm. Các kỹ thuật, công cụ và cải tiến được thể hiện rõ ràng trong "Definition of Done" giúp cho việc kiểm tra, xác nhận và kiểm soát rủi ro kỹ thuật.

Tổng kết: Cách tốt nhất để giảm thiểu rủi ro là nhanh chóng đưa đến tay người dùng sản phẩm của mình.

Tôi nhớ có ai đó đã nói rằng:

The day we started to deliver, people stop asking about our velocity.

Nguồn :