Vai trò, quyền và trách nhiệm của đội Disciplined Agile Delivery

“Nếu một mình chúng ta có thể đi nhanh, nhưng nếu cùng nhau chúng ta có thể đi xa hơn”

Trong bài viết này, chúng ta sẽ khám phá các quyền và trách nhiệm “có thể có” của những thành viên liên quan đến nhóm Disciplined Agile Delivery (DAD) (trong và ngoài nhóm) và các vai trò mà họ có thể chọn để đảm nhận. Nói “có thể có” vì chúng ta có thể phải điều chỉnh những điều này để phù hợp với môi trường văn hóa của tổ chức. Tuy nhiên, theo kinh nghiệm, nếu chúng ta càng đi lệch với những lời khuyên được đưa ra bên dưới, thì rủi ro mà mình phải gánh chịu sẽ càng lớn. Như các bài viết trước, hãy làm tốt nhất những gì chúng ta có thể làm trong tình huống mà mình phải đối mặt và cố gắng cải thiện theo thời gian. Hãy bắt đầu với các quyền và trách nhiệm tổng quát ngay bên dưới nhé!

Quyền và trách nhiệm

Thay đổi văn hóa trong tổ chức là cách giúp chúng ta trở nên nhanh nhẹn hơn, văn hóa tổ chức có các bộ quy định, quy tắc giúp cho mọi thành viên hiểu được những hành vi gì họ được phép sử dụng. Cách để xác định hành vi mong đợi là thương lượng các quyền và trách nhiệm mà mọi người đang đảm nhiệm. Thật thú vị là nhiều tư duy rất tốt về chủ đề này đã được thực hiện trong phương pháp XP Extreme Programming, dựa vào những ý tưởng này mà chúng ta đã phát triển cho Disciplined Agile (DA). Danh sách các quyền và trách nhiệm khả dĩ sau đây được coi là điểm khởi đầu tiềm năng cho nhóm của chúng ta.

Là một thành viên của nhóm Agile, chúng ta có quyền:

• Được đối xử tôn trọng
• Làm việc trong một “môi trường an toàn”
• Sản xuất và nhận công việc chất lượng dựa trên các tiêu chuẩn đã thỏa thuận
• Chọn và phát triển cách làm việc của chúng ta (WoW – Way of Working).
• Tự tổ chức và lập kế hoạch công việc, đăng ký các công việc mà chúng ta sẽ thực hiện
• Làm chủ việc ước tính – những người thực hiện công việc là những người ước tính công việc
• Xác định cách nhóm sẽ làm việc cùng nhau – những người thực hiện công việc là những người lập kế hoạch cho công việc
• Được cung cấp thông tin một cách thiện chí và các quyết định một cách kịp thời

Trích dẫn của Uncle Ben Parker, những quyền lớn lao đi kèm những trách nhiệm lớn lao. Thành viên của nhóm Agile có trách nhiệm:

• Tối ưu hóa cách làm việc của họ
• Sẵn sàng cộng tác sâu rộng trong nhóm
• Chia sẻ tất cả thông tin bao gồm cả “công việc đang làm, chưa xong”
• Huấn luyện người khác về kỹ năng và kinh nghiệm mà mình có
• Mở rộng kiến thức và kỹ năng ngoài chuyên môn của mình
• Xác thực công việc của mình càng sớm càng tốt, làm việc với những người có liên quan để công việc được thực hiện trôi chảy hơn
• Trực tiếp tham dự các cuộc họp phối hợp hoặc thông qua các phương tiện thông tin khác nếu không được ở cùng vị trí địa lý
• Chủ động tìm cách cải thiện hiệu suất của nhóm
• Đối với các nhóm thực hiện theo vòng đời Agile (Agile life cycle), tránh chấp nhận các công việc không thuộc phạm vi vòng lặp hiện tại mà không có sự đồng ý của cả nhóm
• Trực quan hóa tất cả công việc mọi lúc, thường thông qua bảng công việc, để năng lực và công việc hiện tại của nhóm được minh bạch

Vai trò tiềm năng

DAD đưa ra một tập hợp năm vai trò chính “một cách đột phá”, ba trong số đó tương tự như các vai trò của Scrum. Như chúng ta thấy trong Hình 1 – DAD sẽ có Team Lead (tương tự như Scrum Master), Product Owner và Team Members. DAD còn bổ sung thêm vai trò Stakeholder (các bên liên quan – một phần mở rộng của khách hàng) và một vai trò cực kỳ có giá trị trong môi trường doanh nghiệp – đó chính là Architecture Owner. Lý tưởng nhất là chúng ta sở hữu “whole team”, một nhóm có tất cả các kỹ năng cần thiết để hoàn thành công việc một cách tốt nhất. Tuy nhiên, mặc dù không phải là lý tưởng, nhưng trong những tình huống bình thường, việc yêu cầu các kỹ năng từ bên ngoài nhóm là điều phổ biến và như vậy DAD sẽ bao gồm một loạt các vai trò hỗ trợ có thể tham gia vào nhóm khi cần thiết.

Hình 1 – Các vai trò DAD tiềm năng

Chúng ta hãy bắt đầu khám phá các vai trò chính.

Stakeholder (Các bên liên quan)

Stakeholder là người gây ảnh hưởng và bị ảnh hưởng bởi kết quả của giải pháp. Về vấn đề này, rõ ràng Stakeholder không chỉ là người dùng cuối hoặc khách hàng. Một Stakeholder có thể là:

• Người dùng trực tiếp
• Người dùng gián tiếp
• Người quản lý người dùng
• Lãnh đạo cấp cao
• Nhân viên vận hành
• Người tài trợ cho nhóm
• Nhân viên của bộ phận hỗ trợ dịch vụ khách hàng
• Kiểm toán viên
• Người quản lý chương trình / danh mục đầu tư
• Nhà phát triển làm việc trên các giải pháp khác tích hợp hoặc tương tác với chúng ta
• Chuyên gia bảo trì có khả năng bị ảnh hưởng bởi sự việc phát triển và / hoặc triển khai giải pháp phần mềm
• Nhiều vai trò khác

Product Owner (Chủ sở hữu sản phẩm)

Product Owner (PO) là người trong nhóm với tư cách là “tiếng nói của các stakeholder”. Như chúng ta thấy trong Hình 2 – PO đại diện cho nhu cầu và mong muốn của cộng đồng các Stakeholder đối với nhóm Agile Delivery. Do đó, PO sẽ phải làm rõ bất kỳ chi tiết nào liên quan đến mong muốn hoặc yêu cầu của các Stakeholder đối với giải pháp và cũng chịu trách nhiệm về công việc nào được ưu tiên mà nhóm sẽ thực hiện để cung cấp giải pháp. Mặc dù Product Owner có thể không trả lời được tất cả các câu hỏi, nhưng họ có trách nhiệm theo dõi câu trả lời kịp thời để nhóm có thể tập trung vào nhiệm vụ của họ.

Mỗi nhóm DAD, hoặc nhóm phụ trong trường hợp các chương trình lớn được tổ chức như một nhóm, sẽ có một Product Owner duy nhất. Mục tiêu thứ yếu đối với Product Owner là đại diện cho công việc của Agile Team trước cộng đồng các Stakeholder. Điều này bao gồm cả việc sắp xếp các cuộc trình bày về giải pháp khi nó phát triển và thông báo tình trạng của nhóm cho các Stakeholder chính.

• Là người chịu trách nhiệm nắm bắt thông tin về lĩnh vực liên quan tới giải pháp;
• Cung cấp thông tin và đưa ra quyết định kịp thời;
• Xác định độ ưu tiên tất cả công việc cho nhóm, bao gồm nhưng không giới hạn các yêu cầu (có thể được trình bày dưới dạng User Stories), các lỗi cần sửa và hơn thế nữa. Product Owner cần tham khảo ý kiến cả Stakeholder và nhóm khi làm như vậy;
• Liên tục định hướng lại và điều chỉnh phạm vi dựa trên nhu cầu ngày càng tăng của các Stakeholder;
• Là người tham gia tích cực vào việc lập mô hình và thử nghiệm chấp thuận;
• Giúp nhóm tiếp cận với các bên chuyên gia;
• Chấp thuận công việc của nhóm đã hoàn thành hoặc chưa hoàn thành;
• Tạo điều kiện thuận lợi cho các buổi lập mô hình yêu cầu;
• Đào tạo nhóm về lĩnh vực liên quan tới giải pháp; và
• Là một người có vai trò như cửa ngõ cho việc cấp vốn

• Là bộ mặt của nhóm đối với các Stakeholder;
• Demo giải pháp cho các Stakeholder quan trọng, hoặc có thể bao gồm việc huấn luyện các thành viên trong nhóm thực hiện demo;
• Thông báo các bản phát hành (releases);
• Theo dõi và thông báo trạng thái của nhóm cho các Stakeholder quan tâm, có thể bao gồm việc hướng dẫn các Stakeholder về cách truy cập và hiểu dashboard cập nhật thông tin tự động của nhóm;
• Tổ chức đánh giá các mốc quan trọng (càng đơn giản càng tốt);
• Giáo dục các Stakeholder về cách làm việc của nhóm giải pháp;
• Đàm phán độ ưu tiên, phạm vi, kinh phí và tiến độ.

Điều quan trọng cần lưu ý là Product Owner có xu hướng làm việc toàn thời gian trong nhóm và thậm chí có thể yêu cầu trợ giúp khi làm việc ở quy mô lớn, với các lĩnh vực phức tạp. Một thách thức phổ biến mà chúng ta có thể thấy ở các tổ chức mới làm quen với Agile là họ cố gắng phân công vai trò này với một người nào đó làm bán thời gian, không toàn tâm toàn ý cho nhóm.

Hình 2 – Product Owner làm cầu nối giữa nhóm và các Stakeholder.

Team Member (Thành viên trong nhóm)

Team Members tập trung vào việc xây dựng giải pháp cho các Stakeholder. Team Members sẽ thực hiện kiểm tra, phân tích, xây dựng kiến ​​trúc, thiết kế, lập trình, lập kế hoạch, ước tính và nhiều hoạt động khác nếu thích hợp. Lưu ý rằng không phải mọi thành viên đều sẽ có tất cả những kỹ năng này, ít nhất là chưa có, nhưng sẽ có một vài kỹ năng và họ sẽ cố gắng đạt được nhiều kỹ năng hơn theo thời gian. Lý tưởng nhất khi các thành viên là Generalizing Specialists (các chuyên – tổng quát viên), người có nhiều chuyên môn (chẳng hạn như phân tích, lập trình, thử nghiệm, v.v.), có kiến ​​thức tổng quát về lĩnh vực mà họ đang làm việc, cũng như sẵn sàng tiếp thu các kỹ năng và kiến ​​thức mới từ những người khác. Hình 3 – So sánh bốn loại cấp độ kỹ năng:

• Specialists (Các chuyên viên): tập trung vào một chuyên môn duy nhất
• Generalists (Các tổng quát viên): có kiến ​​thức rộng, thường giỏi tổ chức và điều phối những người khác nhưng không có các kỹ năng chuyên môn cần thiết để thực hiện công việc
• Generalizing specialists (Các chuyên – tổng quát viên): là sự kết hợp giữa các tổng quát viên và chuyên viên.
• Experts (Các chuyên gia): có kiến thức và kỹ năng chuyên sâu trong nhiều chuyên môn

Trong thực tế, việc yêu cầu mọi người phải là các chuyên – tổng quát viên có thể gây khó khăn lúc đầu, đặc biệt là đối với những người mới làm quen với Agile, bởi vì điều này rất khác so với cách tiếp cận truyền thống là để các tổng quát viên quản lý các nhóm chuyên viên. Cách tiếp cận truyền thống có vấn đề vì cần có chi phí overhead để làm cho nó hoạt động – một số chuyên viên thực hiện công việc của họ, làm ra một vài thứ, sau đó chuyển giao sang cho một số chuyên viên khác làm phần việc còn lại. Cách tiếp cận này còn đòi hỏi nhiều công sức ghi chép và duy trì tài liệu bao gồm các thông tin từ giai đoạn này tới giai đoạn khác của công việc. Nói tóm lại, các chuyên viên đưa rất nhiều lãng phí, dư thừa vào quy trình làm việc. Mặt khác, các chuyên – tổng quát viên có nhiều kỹ năng hơn cho phép họ cộng tác hiệu quả hơn với những người khác, thực hiện nhiều công việc hơn và do đó tránh tạo ra các lãng phí. Thay vì làm việc một cách chăm chỉ, họ chuyển sang làm việc một cách thông minh hơn.

Hình 3 – Các cấp độ kỹ năng của thành viên trong nhóm.

Thách thức là nếu chúng ta chưa quen với Agile, thì rất có thể chúng ta sẽ có nhân viên là tổng quát viên hoặc chuyên viên, nhưng rất ít chuyên – tổng quát viên. Trong trường hợp nếu chúng ta hiện có những người là tổng quát viên hoặc chuyên viên, thì chúng ta hãy cứ tập hợp nhóm của mình với những người này. Sau đó, vì chúng ta muốn cải thiện năng suất của nhóm, chúng ta sẽ giúp các thành viên của mình trở thành những chuyên – tổng quát viên thông qua các kỹ thuật làm việc nonsolo, chẳng hạn như lập trình cặp (pair programming), lập trình nhóm (mob programming) và cùng lập mô hình với những người khác. Bằng cách đó, trong vài tháng, các chuyên viên sẽ thu thập được nhiều kỹ năng hơn và kết quả là trở thành các chuyên – tổng quát viên hiệu quả hơn.

Ngoài các quyền và trách nhiệm chung được mô tả trước đó, Team Member có một số trách nhiệm bổ sung. Họ sẽ:

• Tự tổ chức: họ sẽ xác định nhiệm vụ, ước tính nhiệm vụ, tự chọn cho nhiệm vụ thực hiện, thực hiện nhiệm vụ và theo dõi trạng thái nhiệm vụ cho tới khi hoàn thành.
• Bàn bạc với Product Owner để biết thông tin và quyết định về lĩnh vực mà họ đảm nhiệm: Mặc dù Team Members sẽ cung cấp thông tin đầu vào cho Product Owner, nhưng cuối cùng Product Owner sẽ là người chịu trách nhiệm cung cấp các yêu cầu và độ ưu tiên công việc chứ không phải Team Members. Nó đòi hỏi các Team Member phải có kỷ luật đáng kể để tôn trọng điều này và không thêm các tính năng dư thừa (được gọi là “scope creep”) hoặc tự phỏng đoán thông tin.
• Làm việc với Architecture Owner (AO) để phát triển kiến ​​trúc giải pháp: Architecture Owner chịu trách nhiệm hướng dẫn nhóm thông qua công việc kiến ​​trúc và thiết kế. Team Members sẽ làm việc chặt chẽ và cộng tác với Architecture Owner để xác định và phát triển chiến lược kiến ​​trúc. Khi nhóm không thể đi đến thống nhất về hướng đi, có thể Architecture Owner cần phải là người “phá băng”, đồng thời chọn những gì họ cảm thấy là lựa chọn tốt nhất, và Team Members được mong đợi sẽ hỗ trợ những quyết định này.
• Tuân theo các quy ước của doanh nghiệp, tận dụng và nâng cao cơ sở hạ tầng hiện có: Một trong những nguyên tắc Disciplined Agile (DA) là nhận thức doanh nghiệp. Hàm ý của điều này là Team Members sẽ áp dụng và có kỷ luật để điều chỉnh khi thích hợp, bất kỳ tiêu chuẩn viết code nào, quy ước thiết kế giao diện người dùng, hướng dẫn xây dựng cơ sở dữ liệu, v.v. Team Members cũng nên cố gắng sử dụng lại và nâng cao các nội dung hiện có của doanh nghiệp, có thể tái sử dụng như các dịch vụ dùng chung, thư viện, và ngay cả các nguồn dữ liệu kế thừa hiện có. Mục tiêu của tận dụng và nâng cao cơ sở hạ tầng hiện có được đề cập trong Nguyên tắc thứ 8 (Nhận thức về doanh nghiệp) ở bài viết Tám nguyên tắc Disciplined Agile (DA).
• Chủ trì các cuộc họp: Mặc dù các phương pháp Agile khác sẽ giao trách nhiệm này cho Team Lead, nhưng thực tế là bất kỳ ai trong nhóm cũng có thể lãnh đạo hoặc điều phối các cuộc họp. Team Lead chỉ chịu trách nhiệm đảm bảo rằng điều này xảy ra.

Team Lead (Trưởng nhóm)

Một khía cạnh quan trọng của các nhóm tự tổ chức là Team Lead sẽ tạo điều kiện hoặc hướng dẫn nhóm thực hiện các hoạt động quản lý kỹ thuật thay vì tự mình đảm nhận các trách nhiệm này. Team Lead là người lãnh đạo phục vụ cho nhóm (Servant Leader), tạo ra và duy trì các điều kiện cho phép nhóm thành công. Đây có thể là một vai trò khó hoàn thành – thái độ sẽ là chìa khóa thành công của họ.

Team Lead cũng là một Agile Coach, giúp giữ cho nhóm tập trung vào việc phân phối các hạng mục công việc, hoàn thành các mục tiêu của từng vòng lặp và cam kết của nhóm với Product Owner. Họ hoạt động như một nhà lãnh đạo thực sự, tạo điều kiện giao tiếp, trao quyền cho mọi người lựa chọn cách làm việc của mình (WoW), đảm bảo rằng nhóm có các nguồn lực cần thiết và loại bỏ mọi trở ngại đối với nhóm một cách kịp thời. Khi các nhóm tự tổ chức, sự lãnh đạo hiệu quả là yếu tố quyết định sự thành công của nhóm.

• Hướng dẫn nhóm lựa chọn và phát triển cách làm việc của họ;
• Tạo điều kiện cho sự hợp tác chặt chẽ trên tất cả các vai trò và chức năng;
• Đảm bảo rằng nhóm hoạt động đầy đủ và hiệu quả;
• Giữ cho nhóm tập trung trong bối cảnh của tầm nhìn và mục tiêu của họ;
• Chịu trách nhiệm loại bỏ các trở ngại đối với nhóm và sự leo thang của các trở ngại trong toàn tổ chức, cộng tác với ban lãnh đạo tổ chức để thực hiện;
• Bảo vệ nhóm khỏi sự gián đoạn và sự can thiệp từ bên ngoài;
• Duy trì giao tiếp cởi mở, trung thực giữa những người liên quan;
• Huấn luyện những người khác trong việc sử dụng và áp dụng các thực hành Agile;
• Nhắc nhóm thảo luận và suy nghĩ về các vấn đề khi chúng được tìm ra;
• Tạo điều kiện thuận lợi cho việc ra quyết định, nhưng không đưa ra quyết định hoặc bắt buộc nhóm phải thực hiện các hoạt động nào đó của nhóm;
• Đảm bảo rằng nhóm luôn tập trung vào việc đưa ra một giải pháp có thể sử dụng được.

Khi không có người quản lý dự án hoặc quản lý nguồn lực / quản lý phòng ban, Team Leads có thể được yêu cầu đảm nhận những trách nhiệm mà những người trong những vai trò này lẽ ra phải hoàn thành. Các trách nhiệm tùy chọn mà Team Lead có thể được yêu cầu để hoàn thành và những thách thức liên quan đến việc triển khai, bao gồm:

• Đánh giá Team Members: Có một số chiến lược để đánh giá hoặc cung cấp phản hồi cho mọi người, được mô tả bởi mục tiêu của quá trình phát triển Team Members, mà chúng ta có thể áp dụng. Đây là trách nhiệm của quản lý nguồn lực, nhưng đôi khi những người ở những vai trò này không có sẵn. Khi Team Lead chịu trách nhiệm đánh giá Team Members của họ, điều đó sẽ đặt họ vào vị trí có thẩm quyền đối với những người mà họ phải lãnh đạo và cộng tác. Điều này ngược lại có thể làm thay đổi đáng kể động lực của mối quan hệ mà Team Members có với Team Lead, làm giảm tâm lý an toàn của họ khi làm việc với Team Lead vì họ không biết làm như vậy sẽ ảnh hưởng đến đánh giá của họ như thế nào.
• Quản lý ngân sách của nhóm: Mặc dù Product Owner thường là một người có vai trò như cửa ngõ cho việc cấp vốn, nhưng họ có thể được yêu cầu theo dõi và báo cáo cách sử dụng tiền. Nếu Product Owner không làm điều này thì Team Lead thường phải chịu trách nhiệm làm điều đó.
• Báo cáo cho cấp quản lý: Đảm bảo rằng ai đó trong nhóm, có thể là chính họ, nắm được các chỉ số liên quan của nhóm và báo cáo tiến độ của nhóm cho lãnh đạo tổ chức. Hy vọng rằng loại báo cáo này được tự động hóa thông qua dashboard, còn không Team Lead thường phải chịu trách nhiệm tạo báo cáo bắt buộc theo cách thủ công.
• Tìm kiếm tài nguyên: Team Lead thường chịu trách nhiệm đảm bảo rằng các công cụ cộng tác có sẵn trong nhóm. Chẳng hạn như bảng công việc để phối hợp nhóm và bảng trắng giúp lập mô hình.
• Điều hành cuộc họp: Đảm bảo rằng một người nào đó trong nhóm, đôi khi là chính họ, điều hành các cuộc họp khác nhau.

Vai trò của Team Lead thường là bán thời gian, đặc biệt là đối với các nhóm nhỏ. Nghĩa là một Team Lead cần phải có các kỹ năng để trở thành một Team Member, hoặc có thể trong một số trường hợp là một Architecture Owner (chúng ta có thể hiểu thêm khái niệm này ngay bên dưới). Tuy nhiên, trong một nhóm mới làm quen với Agile, việc huấn luyện để trở thành Team Lead rất quan trọng đối với sự thành công của chúng ta khi áp dụng Agile. Đây là điều mà các tổ chức mới sử dụng Agile có thể gặp khó khăn về mặt khái niệm, bởi vì họ chưa bao giờ phải đầu tư tương tự vào sự phát triển của nhân viên.

Một giải pháp thay thế khác đó là để một người nào đó làm Team Lead ở hai hoặc ba nhóm, mặc dù điều đó yêu cầu các đội phải tổ chức các buổi họp như các buổi họp điều phối, các buổi demo và các buổi retrospective, để Team Lead có thể tham gia. Điều này có thể hoạt động với các nhóm có kinh nghiệm với tư duy và kỹ thuật Agile vì họ không yêu cầu huấn luyện nhiều. Hơn nữa, khi các nhóm thành lập và trở nên thành thạo trong việc tự tổ chức, thì không cần ai đó giữ vai trò Team Lead và theo thời gian, điều này còn có thể giúp họ tự xung phong giữ các trách nhiệm của một người Team Lead.

Architecture Owner (Chủ sở hữu kiến ​​trúc)

Architecture Owner (AO) là người hướng dẫn nhóm thông qua các quyết định về kiến ​​trúc và thiết kế, tạo điều kiện thuận lợi cho việc xác định và phát triển thiết kế giải pháp tổng thể. Ở các nhóm nhỏ, người giữ vai trò Team Lead thường cũng sẽ kiêm luôn vai trò Architecture Owner, giả sử họ có kỹ năng cho cả hai vai trò. Phải nói rằng, kinh nghiệm của chúng ta để tìm được ai đó đủ tiêu chuẩn đảm nhiệm một trong hai vai trò này là rất khó, chứ chưa nói đến cả hai.

Mặc dù Architecture Owner thường là nhà phát triển cấp cao trong nhóm và đôi khi có thể được gọi là Technical Architect (kiến ​​trúc sư kỹ thuật), Software Architect (kiến ​​trúc sư phần mềm) hoặc Solution Architect (kiến ​​trúc sư giải pháp) – cần lưu ý rằng đây không phải là vị trí phân cấp mà các thành viên khác trong nhóm báo cáo. Họ phải đăng ký và được giao các công việc liên quan đến nhiệm vụ giống như bất kỳ thành viên nào khác trong nhóm. Architecture Owners nên có nền tảng kỹ thuật và hiểu biết vững chắc về lĩnh vực kinh doanh mà họ phụ trách.

• Hướng dẫn việc tạo và phát triển kiến ​​trúc của giải pháp mà nhóm đang làm việc (Lưu ý rằng Architecture Owner không chịu trách nhiệm duy nhất về kiến ​​trúc; thay vào đó, họ dẫn dắt các cuộc thảo luận về kiến ​​trúc và thiết kế);
• Cố vấn và huấn luyện các thành viên khác trong nhóm về các vấn đề và thực hành kiến ​​trúc;
• Hiểu định hướng và tiêu chuẩn kiến ​​trúc của tổ chức và giúp đảm bảo rằng nhóm tuân thủ chúng một cách thích hợp;
• Làm việc chặt chẽ với các kiến ​​trúc sư doanh nghiệp (enterprise architects) nếu có, hoặc thậm chí họ có thể là kiến ​​trúc sư doanh nghiệp (Lưu ý rằng đây có thể là một thay đổi thú vị đối với các tổ chức lớn nơi các kiến ​​trúc sư doanh nghiệp của họ hiện không tham gia tích cực với các nhóm. Đối với các tổ chức nhỏ hơn thì điều này là khá phổ biến.);
• Làm việc chặt chẽ với Product Owner để giúp họ hiểu nhu cầu của các Stakeholder về kỹ thuật, tác động của nợ kỹ thuật (technical debt), sự cần thiết phải đầu tư để trả bớt nợ kỹ thuật và trong một số trường hợp để hiểu, tương tác với Team Members một cách hiệu quả hơn;
• Hiểu các tài sản doanh nghiệp hiện có như frameworks, thư viện, mẫu tài liệu, hệ thống con và đảm bảo rằng nhóm sử dụng chúng khi thích hợp;
• Đảm bảo rằng giải pháp sẽ dễ dàng hỗ trợ bằng cách khuyến khích thiết kế tốt và tái cấu trúc để giảm thiểu nợ kỹ thuật;
• Đảm bảo rằng giải pháp được tích hợp và thử nghiệm một cách thường xuyên, lý tưởng nhất là thông qua chiến lược tích hợp liên tục (Continuous Integration – CI);
• Có tiếng nói cuối cùng liên quan đến các quyết định kỹ thuật, nhưng cố gắng tránh chỉ định hướng kiến ​​trúc theo hướng tiếp cận cộng tác, dựa trên nhóm (Architecture Owner nên làm việc một cách chặt chẽ với nhóm để tìm ra và xác định các chiến lược nhằm giảm thiểu các rủi ro kỹ thuật);
• Dẫn dắt nỗ lực xây dựng kiến ​​trúc ban đầu khi bắt đầu một bản phát hành và hỗ trợ nỗ lực thiết lập các yêu cầu ban đầu (đặc biệt khi nói đến việc hiểu và phát triển các yêu cầu phi chức năng cho giải pháp).

Các vai trò hỗ trợ tiềm năng

Để thành công thì tất cả những gì chúng ta cần chính là năm vai trò chính được mô tả ở trên. Thực tế là các vai trò chính này sẽ không đảm bảo được nhóm của chúng ta sẽ có tất cả các kiến thức chuyên môn kỹ thuật mà nhóm cần. Product Owner của chúng ta không thể có kiến thức chuyên môn về tất cả các khía cạnh của lĩnh vực mà nhóm đang làm và ngay cả khi tổ chức của mình có các chuyên gia ở tất cả các khía cạnh cung cấp giải pháp, thì từng nhóm của chúng ta cũng không thể có các nhân viên với đầy đủ chuyên môn được yêu cầu. Nhóm của chúng ta có thể cần thêm một số hoặc tất cả các vai trò sau:

1. Domain expert – Chuyên gia lĩnh vực (hay Subject matter expert – SME): Product Owner đại diện cho nhiều Stakeholder, không chỉ người dùng cuối, vì vậy sẽ không hợp lý khi mong đợi họ trở thành chuyên gia trong mọi lĩnh vực, điều này đặc biệt đúng trong các lĩnh vực phức tạp. Product Owner đôi khi sẽ mời các chuyên gia lĩnh vực để làm việc với nhóm (ví dụ: chuyên gia thuế cần giải thích chi tiết về yêu cầu có liên quan đến thuế hoặc giám đốc điều hành sẽ chịu trách nhiệm đưa ra tầm nhìn cho doanh nghiệp).
2. Specialist – Chuyên viên: Mặc dù hầu hết Team Members đều là các chuyên – tổng quát viên, nhưng đôi khi, đặc biệt ở quy mô lớn, các chuyên viên sẽ được yêu cầu. Ví dụ: trong các nhóm lớn hoặc trong các lĩnh vực phức tạp, một hoặc nhiều nhà phân tích kinh doanh Agile (Business Analyst) có thể tham gia nhóm để giúp khám phá các yêu cầu cho những gì chúng ta đang xây dựng. Đối với các nhóm rất lớn, Program Manager có thể được yêu cầu điều phối Team Leads trong các đội / nhóm khác nhau. Chúng ta cũng sẽ thấy các chuyên viên trong nhóm khi chưa có các chuyên – tổng quát viên – khi tổ chức của chúng ta mới sử dụng Agile, tổ chức có thể có các chuyên viên chưa thực hiện chuyển đổi sang chuyên – tổng quát viên.
3. Technical expert – Chuyên gia kỹ thuật: Đôi khi nhóm cần sự trợ giúp của các chuyên gia kỹ thuật, chẳng hạn như một quản trị viên cơ sở dữ liệu agile sẽ giúp thiết kế và kiểm tra cơ sở dữ liệu của họ hoặc một chuyên gia bảo mật sẽ đưa ra lời khuyên về việc viết một giải pháp an toàn. Các chuyên gia kỹ thuật được cử đến trên cơ sở tạm thời, khi cần thiết sẽ giúp nhóm vượt qua một vấn đề khó khăn và chuyển giao kỹ năng của họ cho một hoặc nhiều thành viên trong nhóm. Các chuyên gia kỹ thuật thường làm việc trong các nhóm chuyên chịu trách nhiệm về các vấn đề kỹ thuật cấp doanh nghiệp hoặc đơn giản họ chỉ là các chuyên viên đến từ các nhóm giải pháp khác.
4. Independent tester – Người kiểm thử độc lập: Mặc dù phần lớn việc kiểm tra được thực hiện bởi chính những người trong nhóm DAD, nhưng một số nhóm có thể được hỗ trợ bởi một nhóm kiểm tra độc lập làm việc song song, những người sẽ xác nhận công việc của họ trong suốt vòng đời giải pháp. Nhóm kiểm tra độc lập này thường cần thiết cho các trường hợp quy mô mở rộng trong các lĩnh vực phức tạp, sử dụng công nghệ phức tạp hoặc giải quyết các vấn đề về tuân thủ quy định (an toàn, tính mạng, môi trường,…).
5. Integrator – Tích hợp viên: Đối với các nhóm DAD lớn đã được tổ chức bao gồm các đội con, các nhóm con thường chịu trách nhiệm về một hoặc nhiều hệ thống con hoặc tính năng. Nhóm tổng thể càng lớn thì giải pháp được xây dựng càng lớn và phức tạp hơn. Trong những tình huống này, nhóm tổng thể có thể yêu cầu một hoặc nhiều người trong vai trò tích hợp viên chịu trách nhiệm xây dựng toàn bộ giải pháp từ các hệ thống con khác nhau của mình. Trong các nhóm nhỏ hơn hoặc trong các tình huống đơn giản hơn, Architecture Owner thường chịu trách nhiệm đảm bảo việc tích hợp, một trách nhiệm do các nhà tích hợp thực hiện đối với các môi trường phức tạp hơn. Tích hợp viên thường làm việc chặt chẽ với nhóm kiểm tra độc lập (nếu có), để thực hiện kiểm tra tích hợp hệ thống thường xuyên trong suốt một bản phát hành. Vai trò tích hợp này thường chỉ cần thiết ở quy mô lớn đối với các giải pháp kỹ thuật phức tạp.

Một điểm thú vị đối với các tổ chức mới làm quen với Agile là các nhóm Agile có thể tiếp cận với những người đảm nhiệm các vai trò hỗ trợ này sớm hơn trong vòng đời so với các nhóm truyền thống. Và thời gian tiếp cận/tương tác cũng ít dự đoán được hơn, do bản chất tiến hóa của Agile so với phát triển truyền thống. Chúng ta có thể nhận thấy rằng những người trong những vai phụ này sẽ cần phải linh hoạt hơn.

Ba vai trò lãnh đạo

Chúng ta thường gọi Team Lead, Product Owner và Architecture Owner là bộ ba lãnh đạo của nhóm. Như chúng ta có thể thấy trong Hình 4 – Product Owner sẽ tập trung vào việc làm ra đúng sản phẩm, Architecture Owner sẽ giúp nhóm xây dựng sản phẩm đúng theo yêu cầu và Team Lead sẽ giúp nhóm xây dựng sản phẩm nhanh chóng. Tất cả ba ưu tiên này phải được cân bằng thông qua sự cộng tác chặt chẽ của những người đảm nhiệm các vai trò này. Hình 4 cũng chỉ ra điều gì sẽ xảy ra khi một trong những ưu tiên này bị bỏ qua. Khi các nhóm mới làm quen với Agile, vị trí trung tâm có thể khá nhỏ lúc đầu, nhưng theo thời gian, những người trong ba vai trò lãnh đạo này và quan trọng hơn là toàn bộ nhóm sẽ giúp phát triển nó.

Hình 4 – Quan điểm của ba vai trò lãnh đạo.

Chúng ta có cần các vai trò Scrum không?

Vào những năm 1990 khi Scrum ra đời, nó trở thành một thế giới khác. Chúng ta đã quen làm việc độc lập cùng với chuyên môn của mình, xây dựng phần mềm từ các tài liệu và không thực sự biết cách thức cũng như thời điểm cộng tác với các thành viên khác, do đó cần có một Scrum Master để buộc Team Members làm việc với nhau, thống nhất họ vì một mục tiêu của nhóm. Ngày nay, các thành viên trong nhóm không cần một vai trò được chỉ định để đảm bảo sự cộng tác diễn ra hiệu quả. Tương tự, tại sao chúng ta cần một Product Owner đứng giữa nhóm và các Stakeholder còn lại? Mức độ tách biệt này làm tăng khả năng thông tin sai lệch và hạn chế cơ hội của các nhóm để phát triển sự thấu hiểu với những người mà họ đang xây dựng giải pháp. Trong những ngày đầu của Scrum, rất khó để tiếp cận với các Stakeholder vì vậy Product Owner “bắt buộc” phải có. Ngày nay, thông lệ được chấp nhận rộng rãi hơn đó là nhóm tiếp cận trực tiếp với tất cả các Stakeholder và hy vọng từ sự tham gia tích cực của các Stakeholder.

Trong Disciplined Agile, chúng ta cần nhắc nhở các nhóm liên tục rằng giải quyết theo ngữ cảnh là quan trọng và lựa chọn là tốt (xem thêm 8 nguyên tắc của Disciplined Agile). Giống như mọi thứ trong DA, các vai trò mà chúng ta vạch ra là “những ý tưởng hay” có thể có hợp lý hoặc không hợp lý đối với nhóm. Nếu chúng ta chưa quen với Agile và có ít sự phản đối của tổ chức đối với sự thay đổi, thì chúng ta có thể áp dụng các vai trò cổ điển của DAD. Nếu khả năng và sự trưởng thành trong Agile của chúng ta ngày càng nâng cao hoặc nếu việc áp dụng các vai trò mới quá khó khăn, thì chúng ta có thể điều chỉnh các vai trò sao cho phù hợp.

Điều chỉnh vai trò DAD Team cho tổ chức của chúng ta

Như đã đề cập trước đó, chúng ta có thể xây dựng các nhóm của mình từ những người mà mình có. Có nhiều tổ chức không thể sắp xếp nhân sự tương ứng một số vai trò, hoặc một số vai trò của DAD chỉ đơn giản là không phù hợp với văn hóa hiện tại của họ. Kết quả là họ cần phải điều chỉnh các vai trò để phản ánh tình huống mà họ thấy mình trong đó. Điều chỉnh vai trò có thể là gây tác dụng ngược bởi vì như chúng ta đã thấy các vai trò của DAD làm việc rất tốt trong thực tế, vì vậy bất kỳ điều chỉnh nào cũng có khả năng làm tăng rủi ro phải đối mặt với nhóm. Bảng 1 – Ghi lại các điều chỉnh tùy chọn cho các vai trò chính và các rủi ro liên quan đến việc đó.

Bảng 1 – Điều chỉnh các tùy chọn tiềm năng cho các vai trò chính.

DAD và vai trò truyền thống

Nhiều người theo chủ nghĩa Agile thuần túy sẽ nhấn mạnh rằng các vai trò truyền thống như quản lý dự án, nhà phân tích kinh doanh, quản lý nguồn lực và nhiều vai trò khác sẽ không đồng hành với Agile. Việc loại bỏ các vai trò truyền thống khi bắt đầu chuyển đổi Agile (Agile transformation) là cách mạng, nhưng thường dẫn đến việc tăng khả năng chống đối và từ đó lại làm giảm hiệu quả trong việc áp dụng Agile. Chúng ta thích cách tiếp cận tiến hóa hơn, ít gây rối hơn, tôn trọng mọi người và khát vọng nghề nghiệp của họ. Trong khi Agile đòi hỏi những cách làm việc khác nhau, các kỹ năng và sự nghiêm ngặt đặc trưng của truyền thống vẫn vô cùng có giá trị. Các nhà quản lý dự án hiểu quản lý rủi ro, chiến lược ước tính và lập kế hoạch phát hành. Các nhà phân tích kinh doanh truyền thống được đào tạo hoặc được chứng nhận cung cấp một bộ công cụ phong phú của các tùy chọn mô hình hóa.

Phải nói rằng, các vai trò chính của DAD là vô cùng hiệu quả trong thực tế. Khi chúng ta làm việc với các tổ chức để cải thiện cách làm việc của họ, chúng ta sẽ giúp nhiều người nhất có thể để chuyển từ các vai trò truyền thống hiện tại sang vai trò của DAD. Hình 5 – mô tả các tùy chọn chung cho một số vai trò truyền thống. Ở đây chỉ đưa ra cái nhìn tổng quan và điều quan trọng là mọi người sẽ chọn con đường sự nghiệp của riêng họ dựa trên sở thích và mong muốn của chính mình. Mọi người đều có thể tìm thấy một nơi cho mình trong một tổ chức Agile nếu họ sẵn sàng học một cách làm việc mới và chuyển sang vai trò mới.

Hình 5 – Chuyển đổi thông thường từ vai trò truyền thống sang DAD.

Tóm tắt

Bài viết này hi vọng sẽ giúp bạn đọc khám phá các quyền và trách nhiệm tiềm năng của những người liên quan đến nhóm DAD, cũng như các vai trò mà họ có thể chọn để đảm nhận. Chúng ta đã có thể hiểu rõ hơn về:

• DAD định nghĩa năm vai trò chính – Team Lead, Product Owner, Team Member, Architecture Owner và Stakeholder xuất hiện trên tất cả các nhóm.
• Trong nhiều tình huống, các nhóm sẽ dựa vào những người trong vai trò hỗ trợ khi thích hợp và cần thiết như các chuyên viên, các chuyên gia lĩnh vực, các chuyên gia kỹ thuật, người kiểm tra độc lập hoặc tích hợp viên.
• Các vai trò của DAD giống như một điểm khởi đầu được đề xuất. Chúng ta có thể có lý do hợp lệ để điều chỉnh các vai trò cho tổ chức của mình.
• Với các vai trò, cũng như với mọi thứ khác, hãy làm tốt nhất những gì chúng ta có thể làm trong tình huống mà mình phải đối mặt và phấn đấu để cải thiện theo thời gian.

Sự kết thúc của Agile? Không, là sự kết thúc của Undisciplined Agile.

Disciplined Agile là gì? Tại sao nên áp dụng Disciplined Agile?

Hệ tư duy của Disciplined Agile – Disciplined Agile Mindset

8 nguyên tắc trong Disciplined Agile

Tổng quan về Disciplined Agile Delivery – Một phần thiết yếu của Disciplined Agile

Vai trò, quyền và trách nhiệm của đội Disciplined Agile Delivery

DASM ONLINE PRO – CHƯƠNG TRÌNH LUYỆN THI DASM HIỆU QUẢ

DASSM ONLINE PRO – CHƯƠNG TRÌNH LUYỆN THI DASSM HIỆU QUẢ