Với sự hiểu biết về Agile và Scrum, bạn dễ dàng nhận thấy việc quản lý rủi ro trong dự án áp dụng Agile/Scrum được thể hiện ở các đặc điểm của Agile hay trong các sự kiện của Scrum Framework.
– Lặp và tăng trưởng: Scrum chia “dự án” thành các giai đoạn – sprint kéo dài từ 1-4 tuần. Kết quả của mỗi sprint là một phần tăng trưởng có thể sử dụng được (tuỳ thuộc định nghĩa hoàn thành, phần tăng trưởng này có thể deploy hoặc không). Việc theo dõi thường xuyên và liên tục được phần tăng trưởng này giúp khách hàng tiếp cận được kết quả sản phẩm sớm hơn và đưa ra các phản hồi. Việc này giúp tránh lãng phí nguồn lực, thời gian và chi phí. Việc theo dõi kết quả của nhóm phát triển thường xuyên cũng giúp PO (SM) nhận định được năng suất thực tế của nhóm. Từ đó đưa ra các chiến lược để tối ưu hoá được năng suất lao động.
– Giao tiếp thường xuyên và hiệu quả: Scrum định nghĩa các sự kiện, tuân theo nó, nhóm phát triển thực hiện công việc theo nhịp độ đều đặn. Từ nội dung và kết quả các sự kiện, SM giúp nhóm phát lộ các vấn đề – bằng các kĩ thuật đặt câu hỏi, từ đó xử lý hoặc đưa ra các giải pháp thích ứng. Ví dụ thông qua buổi họp daily stand up, nhóm phát triển phát hiện một vài issues có thể ảnh hưởng tới tiến độ chung của cả đội, việc tìm ra giải pháp và người chịu trách nhiệm (follow up để hỗ trợ) là cần thiết, lúc này thay vì cá nhân đang gặp issue tự giải quyết vấn đề, buổi họp daily stand up có thể giúp đội nhóm hiểu vấn đề đang có, và cùng đưa giải pháp hoặc cùng tìm kiếm giải pháp trợ giúp thành viên của nhóm. Nhóm phát triển cũng luôn giao tiếp với PO nhờ hỗ trợ giải đáp các vấn đề liên quan tới User Story – nơi được hiểu là bao gồm các yêu cầu của các bên liên quan, và khách hàng cuối. Điều này khiến nhóm phát triển luôn hiểu đúng các yêu cầu và thực hiện đúng những mong muốn của PO (hay khách hàng)
– Vòng phản hồi ngắn và thích ứng thường xuyên, minh bạch thông tin: Các sự kiện trong Scrum giúp nhóm phát triển tương tác thường xuyên, minh bạch thông tin từ đó phát hiện sớm các vấn đề để giải quyết (hoặc thích ứng).
– Công cụ hỗ trợ, bao gồm: Tích hợp liên tục CI/CD, lập trình cặp – pair programing, refactoring code, lập trình hướng kiểm thử TDD…
Scrum không nhắc đến cụ thể việc quản lý rủi ro cho dự án phần mềm, tuy nhiên cùng với triết lý Agile, Scrum Framework thiết kế các sự kiện, các vai trò, sprint và các artifact từ đó giúp nhóm phát triển vận hành và làm việc theo một khung làm việc chung, đều đặn, từ đó dần cải thiện năng suất, sớm phát hiện các vấn đề để tìm cách xử lý thích nghi.
Là 1 PM truyền thống, và giờ đóng vai trò PO trong dự án phần mềm, bạn cần làm gì để quản lý rủi ro hiệu quả?
– Giao tiếp, giao tiếp và giao tiếp: Vai trò PM hay PO khá giống nhau ở yêu cầu công việc cần giao tiếp rất nhiều. Tương tự PM, PO cần giao tiếp với các stack holder, khách hàng để chuyển hoá những yêu cầu thành các User Story trong Product backlog.PO cần dành đủ thời gian cho nhóm phát triển để giải thích về các User Story trong Sprint backlog – trong trường hợp buổi planning chưa thể làm rõ được, hoặc tiêu chí hoàn thành cần phải cập nhật cho phù hợp với điều kiện thực tế. Bởi vậy, lời khuyên đầu tiên là Hãy dành đủ thời gian – cho nhóm phát triển và product backlog.
– Product backlog là quan trọng: Hãy luôn làm rõ các hạng mục công việc trong product backlog theo độ ưu tiên, càng ở trên cao thì các yêu cầu công việc càng phải rõ ràng, có tiêu chí hoàn thành – làm thế nào nhóm phát triển có thể hoàn thành công việc nếu họ không biết thế nào là hoàn thành? Bạn sẽ tốn bao nhiêu tài nguyên và nhân lực để làm một chức năng không đúng với yêu cầu của người dùng (khách hàng)?. Làm sao PO tối ưu hoá được ROI nếu không có thứ tự ưu tiên cho các công việc? Làm thế nào các manager có thể hỗ trợ team nếu không phát hiện ra các vấn đề. Hãy chú ý lời khuyên thứ 2: Product backlog là quan trọng, làm rõ nó, minh bạch với các bên liên quan.
– Tập trung vào một sản phẩm: Tuỳ tình huống, PO có thể phải đảm nhiệm hơn 1 sản phẩm. Việc này không bị cấm, nhưng không hề được khuyến khích. Đừng tham lam, lúc này bạn và tổ chức phải đánh đổi, 1 người chuyên hay 1 người đa nhiệm?
– Dù PO sẽ bị áp lực bởi nhiều bên để đưa vào các yêu cầu mới, cập nhật các yêu cầu cũ, nhưng bạn hãy cân nhắc việc này. Đưa nó vào product backlog, đánh độ ưu tiên, tạo tiêu chí hoàn thành, tiêu chí chấp nhận được thì tốt hơn là đưa vào sprint backlog – nơi các công việc của nhóm phát triển đã được định hình. Hãy chỉ nên dừng 1 sprint khi mục tiêu của nó đã lỗi thời – không nên vì một lý do nào khác. Lời khuyên thứ 3: Chuyển các yêu cầu vào product backlog. Đánh giá các cập nhật, nếu nó không làm ảnh hưởng tới sprint goal thì có thể thương lượng với nhóm phát triển để xử lý nó đồng thời trong sprint.
– Năng suất của nhóm cần được tôn trọng: Agile hay Scrum không giải quyết tất cả các vấn đề, nó chỉ giúp sớm phát hiện các vấn đề. Đừng đưa cho nhóm phát triển khối lượng công việc quá sức của họ và bắt họ làm theo. Hãy để nhóm tự ước lượng khối lượng công việc của mình, thực hiện nó đều đặn và tăng dần năng suất. Việc PO (hay bất kì ai) can thiệp vào khối lượng công việc của nhóm sẽ làm mất tính tự tổ chức của nhóm. Và vì vậy mô hình quản lý truyền thống lại được nhắc tên. Bạn không muốn điều này đúng không? Lời khuyên thứ 4: Mặc dù vài sprint đầu, nhóm có thể có tiến độ không tốt hoặc bộc lộ nhiều vấn đề, hãy để Scrum Master xử lý các vấn đề, và nhóm tự điều chỉnh năng suất lao động. Tôn trọng nhóm và nhóm sẽ trả lại bạn giá trị tương xứng.
– Học cách xem burndown chart, burnup chart, xem bảng kanban vật lý (nếu có) của nhóm: Quan sát các biểu đồ để trích xuất thông tin, từ đó nắm được tình trạng của nhóm
Nếu bạn mới tiếp cận với Agile và Scrum, từ vai trò truyền thống Project Manager bạn phải đóng vai trò mới là Product Owner, mình thực sự khuyên các bạn nên chú ý mội vài chỉ dẫn trên. Tất nhiên, nó là không đủ trong môi trường phát triển phần mềm phức tạp, nhưng ít nhất, bạn cũng có những khái quát để tiếp cận vấn đề. Chúc bạn thành công.
