Các Kỹ Thuật Ma Trận Chuyển Nhượng Trách Nhiệm Về Thế Giới Agile

15/03/2020 - 07:00 1089     0

Hôm nay, SAGA.VN sẽ giúp các bạn hiểu rõ hơn một khía cạnh mới của Agile mà không phải ai cũng nắm rõ, đó chính là các kỹ thuật ma trận chuyển nhượng trách nhiệm

Mặc dù các kỹ thuật trong mô hình phân định trách nhiệm công việc (Responsibility Assignment Matrice- RAM) thường được sử dụng trong phương pháp quản lý dự án , Waterfall, trong khi với phương pháp Scrum thường không đòi hỏi phải tạo ra những mô hình RAM rõ ràng. Tuy nhiên, khi mọi thứ đi lệch hướng, Chủ sở hữu Sản phẩm (Product Owners - PO), Trưởng nhóm Scrum (Scrum Masters - SM) và cuối cùng là các bên liên quan khác cùng nhìn lại và hỏi: "Chúng ta có ma trận RACI cho dự án này chưa vậy?"

Những người sử dụng phương pháp quản lý dự án Agile thấy rằng RACI cần phải được tinh chỉnh cho Scrum

Có những người sử dụng phương pháp Scrum cho rằng RACI không thể áp dụng được trong thực tiễn với việc quản lý dự án theo Scrum. Mặc dù có nhiều biến thể của RACI tồn tại, một số người cảm thấy cần phải bổ sung các vai trò cụ thể của Scrum (như "F = Facilitator / Coach: Người huấn luyện"), các hoạt động và trách nhiệm cụ thể trong Scrum (như "đảm bảo tính nhất quán với việc thực hiện các nguyên tắc Scrum trong các nhóm hoặc loại bỏ các trở ngại") , hoặc những vị trí công việc và vai trò mới (như "Scrum Team: Nhóm Scrum") vào ma trận như trong hình minh hoạ dưới đây.

Mẫu ma trận Scrum RACI. Nguồn: Christophe Le Coent, Ma trận RACI + F, tháng 6 năm 2012.

Một điều khá rõ ràng và đúng đắn khi những ý tưởng nêu trên sẽ thúc đẩy cuộc thảo luận. Một số cuộc thảo luận chủ yếu liên quan đến các khía cạnh kỹ thuật của ma trận này, trong khi các vấn đề khác mang tính bản chất cao hơn và đi sâu vào cốt lõi của các nguyên tắc cũng như những trụ cột của phương pháp Agile/Scrum, như Tuyên ngôn Agile, và Hướng dẫn cho Scrum.

Nếu cần, mẫu Matrix Scrum dựa trên Scratch mới sẽ trông như thế nào?

Khi nói đến các hoạt động và trách nhiệm của Scrum, cần phải hỏi tại sao trong ma trận nói trên lại có các hoạt động và trách nhiệm như "đảm bảo tính nhất quán với việc thực hiện các nguyên tắc Scrum trong các nhóm hoặc loại bỏ các trở ngại" và không phải là các hoạt động như "bảo vệ nhóm khỏi sự gián đoạn" hoặc " duy trì việc cung cấp thông tin cho các bên liên quan ". Có một danh sách của hơn năm mươi hoạt động và trách nhiệm được chia ra trong những đề xuất về các vai trò, vị trí mới trong scrum. Một mẫu ma trận RACI cần phải nhất quán và liệt kê tất cả các hoạt động và trách nhiệm cụ thể trong Scrum, và nhiều hơn thế nữa. Một khi khuôn mẫu RACI đã được thông báo cho nhóm Sprint, cần phải xác định rõ các lĩnh vực cần quan tâm và chúng ta phải hiểu rõ trách nhiệm của chủ sở hữu sản phẩm (PO) nên được duy trì như thế nào, và mức độ phân quyền từ chủ sở hữu sản phẩm đến đội nhóm về trách nhiệm giải trình ra sao.

Sau đó, là về các vị trí công việc và vai trò biện hộ mới trong Scrum. Trong hình minh hoạ ở trên, các vai trò Scrum điển hình như nhóm các bên liên quan và nhóm phát triển đang còn thiếu, trong khi những vị trí khác thì được lấp đầy như quản lý dự án và quản lý chức năng. Để nhất quán với Scrum, ít nhất chúng ta cần xác định ra tất cả các vai trò Scrum bị thiếu.

Xác định rõ các thuộc tính RACI trong Scrum

Đúng là cả tuyên ngôn Agile (Agile Manifesto) và Hướng dẫn Scrum (Scrum Guide) chỉ là các framework, và cung cấp những phương pháp luận đầy đủ cho quản lý dự án. Và Tuyên ngôn Agile hiện đã hơn 15 tuổi. Tuy nhiên, khi tạo ra khuôn mẫu cho Ma trận Scrum-RACI, chúng ta nên đọc lại các tài liệu này một cách sáng tạo và chỉ "cải tiến" khi nó thực sự cần thiết. Khi đọc Scrum Guide, chúng tôi thấy rằng:

Chủ sở hữu sản phẩm là người duy nhất chịu trách nhiệm quản lý Product Backlog (danh sách các tính năng mong muốn của sản phẩm).
[Hướng dẫn Scrum, p5]

và:

Chủ sở hữu sản phẩm có thể thực hiện các công việc trên hoặc có Nhóm phát triển làm điều đó. Tuy nhiên, Chủ sở hữu sản phẩm vẫn phải chịu trách nhiệm giải trình.

[Hướng dẫn Scrum, p5]

Từ đó, có thể thấy rõ ràng rằng PO thực tế chịu cả trách nhiệm về mặt triển khai (R-Responsible) cúng như trách nhiệm phê duyệt, giải trình (A-Accountable) đối với việc quản lý Product/Project, nhìn từ góc nhìn của ma trận RACI. Tuy nhiên, PO có thể ủy thác một số công việc của mình cho Nhóm phát triển, và do đó R cũng nên được đặt trong cột Team phát triển cho các hoạt động được ủy thác từ PO.

Nguyên tắc thứ tư trong Tuyên ngôn Agile, cho thấy:

Đội ngũ kinh doanh và nhóm phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án.

[Tuyên bố Agile]

Theo nguyên tắc này các bên liên quan cũng có trách nhiệm phê duyệt giải trình (A) và thậm chí chịu trách nhiệm thực hiện (R) ít nhất là cung cấp phản hồi cho đội Scrum.

Ngụ ý của RACI trong Scrum

Cả hai khuôn khổ Agile và Scrum đều thúc đẩy một loạt các nguyên tắc, khái niệm và giá trị bắt nguồn từ các mô hình quản lý dự án trước đây. Theo những giá trị và nguyên tắc này, chúng ta có thể mô tả những nghĩa vụ cũng như trách nhiệm trong Scrum.

Teamwork đề cao hiệu quả của đội nhóm hơn là những anh hùng cá nhân Nhóm phát triển là một đơn vị được tự tổ chức vận hành và mang tính chức năng chéo, chịu trách nhiệm tổng thể cho sự tăng trưởng của Sprint. Trong khi các nhiệm vụ riêng lẻ được giao cho từng cá nhân, những người có nghĩa vụ hoàn thành nhiệm vụ (R), tuy nhiên cả nhóm sẽ cùng phải chịu trách trách nhiệm, giải trình cho kết quả cuối cùng (A).

Scrum khuyến khích sự minh bạch, sự xem xét kỹ lưỡng và tính thích ứng. Các buổi họp Scrum được đặc biệt xây dựng để làm cho những giá trị này được phát huy. Buổi họp Scrum hàng ngày là thời điểm mà nhóm Scrum gặp nhau và tìm hiểu và cập nhật về tình trạng của Sprint đang thực hiện. Do đó mọi người trong nhóm có thể nắm được toàn bộ thông tin ít nhất mỗi ngày một lần.

Scrum cũng thúc đẩy sự giao tiếp, tính chủ động và lòng can đảm. Bạn không cần phải vào danh sách những người tham gia tư vấn. Tất cả các nhóm đều có thể tư vấn, và trên thực tế, các buổi họp Scrum thường nhật là một nơi tuyệt vời để nói lên và cung cấp những phản hồi (ngắn) cho đồng nghiệp của bạn khi cần thiết.

Với những hiểu biết sâu sắc về việc ứng dụng RACI trong scrum, một PM/PO có thể xây dựng một ma trận RACI và truyền đạt tới mọi người, để nhóm cùng nhau thảo luận, tranh cãi, trong một cuộc họp kickoff nơi nhóm Scrum sẽ cùng thiết lập và đi đến thống nhất về định nghĩa của dự án.

Một ma trận Scrum-RACI thể hiện các nhiệm vụ thực tế cho các thành viên trong nhóm Sprint, như trong phương pháp Waterfall?

Một ma trận Scrum-RACI như vậy nên được liệt kê dưới dạng hàng ngang chỉ có các hoạt động qua đó xác định được các nhiệm vụ thực tế trong Sprint Backlog. Trong Scrum, nhiệm vụ được giao cho mọi người, và những công cụ hỗ trợ triển khai Scrum sẽ thường cung cấp một bảng điện tử về nhiệm vụ, nơi thể hiện rõ ràng công việc và trách nhiệm hiện tại của mọi người đối với tất cả các nhiệm vụ đã được đưa vào Sprint. Trong trường hợp Nhóm Phát triển cần tổ chức lại chính ,và điều chỉnh các nhiệm vụ xung quanh đội ngũ phát triển, bảng hiển thị đó cần được cập nhật, để phản ánh trách nhiệm mới của mọi nhà phát triển trong nhóm.

Nguồn : Theo SAGA.VN