【Phần I - Nhập môn Agile】Chương 2 - GIới thiệu về Team Agile (2)

Trước khi đọc bài viết này, mời các bạn tham khảo: 【Phần I - Nhập môn Agile】Chương 2 - GIới thiệu về Team Agile (1)

2.2 Điểm mấu chốt giúp Team trở nên thật sự Agile. (2)

・Tự tổ chức hoá
Khi được giao mục tiêu, Agile Team luôn hạn chế cái tôi của bản thân, và luôn suy nghĩ một cách tích cực là làm sao để đạt được mục tiêu đó. Để có thể làm được như vậy, Agile team cần phải được tự tổ chức hoá.
Tự tổ chức hoá nghĩa là, mỗi member không đẩy cái tôi của mình lên quá nhiều, mà phải cùng hợp tác với nhau.
Khi đó mỗi member với vai trò là một thành viên của nhóm, vừa phát huy kĩ năng, niềm đam mê, và phẩm chất cá nhân, vừa suy nghĩ xem làm thế nào để có thể mang lại kết quả tốt nhất cho khách hàng. Vì vậy, đoạn hội thoại đặc trưng trong trong các team tự tổ chức hoá sẽ diễn ra như thế này:

... Tất nhiên, tôi nghĩ Bobby rất giỏi trong việc viết code ngắn gọn, súc tích. Và không chỉ có vậy, anh ấy còn rất am hiểu về design, cho nên hãy nhờ anh ấy tạo cho một mockup nhé

... Vâng, quả thực Suzy là Tester giỏi nhất, nhưng điều cô ấy thực sự thích là việc quản trị, đáp ứng kỳ vọng của khách hàng cơ. Tôi biết cố ấy thích điều đó, và luôn mong muốn làm công việc đó.

Để mọi người không hiểu nhầm í, tôi xin nhắc lại một chút, ở đây ý của tôi không phải là cứ Developer thì sẽ phải trở thành một chuyên gia về design hay một Tester phải có kỹ năng quản lý project. Vâng, không phải là như vậy.
Chúng ta không phân chia ai đó phải đóng một vai trò nào đó, mà chúng ta phải phân chia vai trò phù hợp với phẩm chất của mỗi người. Vậy thì, làm thế nào để team có thể tự tổ chức hoá nhỉ? Tôi sẽ cho bạn một số tips hay ho dưới đây:

• Mọi người tự xây dựng kế hoạch, và estimate khoảng thời gian thực hiện. Và luôn có ý thức rằng đây là project của chúng ta. Và không ngừng nâng cao tinh thần trách nhiệm.
• Luôn nỗ lực hết sức để cung cấp một sản phẩm hoạt động trơn tru, ổn định bất kỳ đang đảm nhiệm vai trò, chức danh nào.
• Mỗi người phải tự control công việc của mình. Luôn giữ tinh thần tự giác. Còn những người mà chỉ luôn trông chờ vào sự chỉ dẫn của người khác mới làm, thì thật sự những người đó không phù hợp với Agile Team.
  

Nói tóm lại, hãy tin tưởng giao công việc cho team member, và giao cho họ quyền hạn cần thiết để hoàn thành công việc. Và nguyên tắc của việc phát triển theo mô hình Agile cũng bắt nguồn từ đó.

Nguyên tắc mô hình Agile: Architecture, requirements hay design tốt nhất được tạo ra từ những team có tính tự tổ chức hoá.

Tuy nhiên, việc tự tổ chức hoá này mà nó tự diễn ra một cách tự nhiên thì chả có gì đáng nói ở đây đúng không nào. Đáng buồn là, trong thực tế rất ít team có tinh thần tự tổ chức hoá. Và để có thể tự tổ chức hoá thì chúng ta cần một phép thuật thật sự. Tên của phép thuật đó là Sự giao phó và Tinh thần trách nhiệm.

・Sự giao phó và Tinh thần trách nhiệm
Một Agile team được đào tạo bài bản là một team luộn chịu trách nhiệm đối với kết quả bản thân đã tạo ra. Có trách nhiệm trong việc nhận thức rõ là, chúng ta đang đón nhận sự tin tưởng từ khách hàng, và luôn nỗ lực tạo ra kết quả tốt ngay từ ngày đầu tiên.
Một điều dĩ nhiên đó là để team member có tinh thần trách nhiệm thì bạn cần giao quyền cho team một cách phù hợp. Bạn cần giao quyền cho member sao cho họ có quyển tự mình phán đoán, và thực hiện những điều bản thân cho là đúng. Nếu làm được như vậy, member sẽ tiến hành công việc một cách chủ động hơn. Qua đó, với những vấn đề của bản thân, họ có thể tự giải quyết mà không mất thời gian chờ đợi sự cho phép của ai đó.
Nếu đã quyết định giao phó, chắc hẳn sẽ có tình trạng member làm việc đó một cách khá cẩu thả. Tuy nhiên, lợi ích nó đem lại là lớn hơn, cho nên chúng ta sẽ chấp nhận sự rủi ro này.

Nguyên tắc mô hình Agile: Xây dựng dự án bằng cách tập hợp những con người có đủ động lực làm việc. Cung cấp sự hỗ trợ và môi trường làm việc tốt, và luôn tin tưởng họ tới tận khi công việc hoàn thành.

Chà, thật dễ để nói "Hãy tạo ra một team có đủ tinh thần trách nhiệm để có thể giao phó quyền quyết định xử lý công việc". Tuy nhiên, để đưa nó vào trong thực tế thì thật sự khó khăn. Vì không phải ai cũng muốn được uỷ quyền quyết định. Thật vậy đấy, có rất nhiều người chỉ muốn đến công ty làm những công việc đơn giản như là "Cắm hoa bồ công anh vào món sashimi", hay chỉ đơn giản làm lần lượt từ trên xuống dưới những việc được giao cho nhẹ nhàng, thảnh thơi. Chứ cần gì phải suy nghĩ nhiều về trách nhiệm kết quả công việc, hay phải nhận giao phó việc lớn lao làm gì cho đau đầu. Vâng, thực tế đáng buồn là rất nhiều người đang nghĩ như vậy.
Giả sử, thời điểm hiện tại, bản thân mỗi member vẫn thấy chưa có đủ tinh thần trách nhiệm đối công việc. Bạn có thể giải quyết đơn giản bằng cách, hãy yêu cầu member demo sản phẩm đang làm cho khách hàng xem.
Bằng cách demo sản phẩm ngay trước mặt khách hàng, mỗi member trong team sẽ nhận thức rõ hơn về trách nhiệm đối với công việc mà bản thân đang làm.
Bằng cách này, member sẽ nhận ra là thực sự có người đang chờ đợi sản phẩm của họ. Vấn đề họ đang giải quyết là vấn đề có thực trong thực tế.
Giả sử việc demo có thất bại đi chăng nữa, thì chắc chắn họ sẽ có ý thức hơn trong việc làm ra một phần mềm ổn định, và luôn sẵn sàng nhận feedback từ mọi phía. Cứ lặp lại như vậy, dần dần mội member trong team sẽ càng ngày càng có trách nhiệm hơn, làm cho khách hàng tin tưởng vào kết quả họ tạo ra, và chính bản thân họ cũng tin vào điều đó hơn. Ngược lại, nếu tinh thần trách nhiệm trong team mãi mà không được cải thiện, thì đó thực sự là vấn đề đấy!
・Cross-Functional Team
Cross-Functional Team là một team phát triển, có thể đáp ứng từ đầu đến cuối đối với mỗi nhu cầu của khách hàng. Để làm được điều này, team phải có những kỹ năng, và được trang bị những kiến thức chuyên môn cần thiết.
Giả sử tôi đang tìm kiểm member mới cho team, thì tôi luôn mong muốn tìm kiếm 1 người mà có thể hoàn thành một loạt công việc khác nhau, ở phạm vi khác nhau. Ví dụ, nếu là programer thì tôi mong muốn một người có nên tảng kỹ thuật tốt, có thể làm được cả frontend và backend. Nếu là Tester hay Analyst thì tôi mong muốn người đó đồng thời có thể thực hiện được 2 công việc là test và phân tích yêu cầu. Trong thực tế, bạn sẽ cần Specialist (chuyên gia) trong trường hợp team bạn không có đủ kỹ năng để giải quyết vấn đề phát sinh. (Ví dụ như vấn đề tối ưu hoá database... ). Tuy nói vậy nhưng, về cơ bản trong quá trình làm dự án, team của bạn sẽ phải tự hợp tác, giải quyết vấn đề với nhau là chính.
Có thể bạn chưa biết, nhưng giá trị cốt lõi của Cross-Functional Team chính là tốc độ hoàn thành công việc. Tự bản thân team có thể giải quyết được vấn đề, mà không cần tốn nhiều công sức trao đổi, hay đàm phán với bộ phận khác. Vì vậy team có thể tập trung vào công việc, không lo bị bộ phận nào đó gây trở ngại.

Trên đây, là những thứ kỳ vọng đổi với một member khi ở trong Agile Team. Khi thành lập team, để có thể đáp ứng được những tiêu chí này, ắt hẳn sẽ có nhiều khó khăn. Thế thì, tôi sẽ giải thích tiếp cho bạn những vai trò chính sẽ xuất hiện trong Agile team nhé!

Câu chuyện: Miếng pho mai đã đi đâu rồi?
「Miếng pho mai đã đi đâu rồi?」 là một câu chuyện ngụ ngôn nổi tiếng về kinh doanh. Nội dung câu chuyện là có một lũ chuột vô tình phát hiện ra những miếng phô mai rất lớn, từ đó trở đi nhờ những miếng pho mai đó mà lũ chuột có cuộc sống vô cùng thảnh thơi, thoải mái. Tuy nhiên, vào một ngày nọ, một ai đó đã lấy hết những miếng phô mai đó đi. Thế là lũ chuột trở nên rất hỗn loạn, lo lắng không biết phải làm gì.
Đối với chúng ta cũng vậy, khi làm theo mô hình Aigle, đôi khi cũng có cảm giác như là miếng phô mai của mình đi đâu mất tiêu rồi vậy. Project manager thì phải đối mặt với tình thế khắc nghiệt rằng specs thường xuyên bị thay đổi. Các Analyst thì phải đổi mặt với việc rằng là các Agile project thì công việc phân tích yêu cầu không bao giờ kết thúc. Các Developer thì bị kỳ vọng là không chỉ hoàn thành việc viết code, mà cần phải hoàn thành cả công việc viết test nữa.
Tóm lại, khi cách làm việc bị thay đổi, nó cũng giống như tình huống miếng phô mai tự nhiên bị ai lấy đi trong câu chuyện của lũ chuột vậy. Tuy nhiên, tôi tin rằng nhờ nó, chúng ta có thể tìm ra những miếng phô mai mới, thơm ngon hơn.

2.3 Phân chia vai trò.

Cho dù là Scrum, Extreme programming hay gọi chung là thủ pháp Agile thì trong dự án thường không phần chia ra quá nhiều vai trò.
Tạm thời ta chia ra ở đây có Khách hàng (Người hiểu phải làm những gì) và Development team (Người có thể thực hiện điều đó). Đọc tới đây, nhiều độc giả sẽ tự hỏi thế thì vai trò programmers, testers, analysts, ...? sẽ như thế nào? Cái này thì các bạn không cần lo lắng. Trong Agile Team thì vẫn tồn tại các vai trò đó, nhưng chúng ta không quá quan tâm đến việc ai cần đảm nhiệm vai trò gì. Mà chúng ta thường quan tâm tới việc ai có thể hoàn thành tốt công việc đó.
Vậy thì đầu tiên, chúng ta cùng đi tìm hiểu về một vai trò tuyệt đối không thể thiếu trong bất kỳ Agile project nào - đó chính là Khách hàng.
・Thế nào một khách hàng thật sự Agile

Có thể coi khách hàng là nguồn gốc của mọi yêu cầu chảy trong project. Và phần mềm được tạo ra là cho khách hàng. Và chúng ta mong muốn khách hàng là một chuyên gia về [Problem Area]. Khách hàng sẽ tham gia sâu vào công việc nghiệp vụ, quyết định phần mềm sẽ làm cái gì, giao diện như thế nào, và hoạt động cụ thể như thế nào. Khách hàng sẽ cung cấp kim chỉ nam vững chắc, và đưa ra các feedback hữu ích cho development team, bên cạnh đó cũng trả lời những câu hỏi mà team đặt ra. Thì đó chính là một khách hàng thật sự Agile.
Ngoài ra, khách hàng cũng thiết lập độ ưu tiên cho mỗi task, quyết định phải làm cái gì, và ưu tiên cái gì trước. Mặc dù vậy, khách hàng sẽ không quyết định một cách độc đoán về độ ưu tiên của mỗi task, mà có sự tham khảo ý kiến của development team. Ví dụ như, vì lý do kỹ thuật thì task này nên thực hiện trước task kia thì project sẽ tiến triển thuận lợi hơn, thì development team cần giải thích rõ và đề xuất cho khách hàng. (hoặc là vì, có những lý do kỹ thuật cần phải được trước.)
Nói chung thì, độ ưu tiên của các task sẽ được quyết định dựa vào quan điểm kinh doanh của khách hàng. Và sau đó, khách hàng sẽ làm việc mật thiết với development team để thực hiện kế hoạch theo độ ưu tiên của mỗi task đã quyết định trước đó.
Sau đó, khách hàng sẽ phải làm một việc không được vui vẻ cho lắm. Đó là deadline thì đến gần, nguồn lực tài chính cho các task cũng trở cạn kiệt, khi đó công việc của khách hàng là phải quyết định làm task nào, hoặc là tạm dừng task nào.
Có một điều không cần phải nói chắc khách hàng cũng biết, đó là nếu muốn tất cả mọi việc được diễn ra trơn tru thì khách hàng càng gần gũi, sát sao với development team càng tốt.
Trong Extreme programming thì họ gọi công việc này là On-site customer. Còn trong Scrum thì họ gọi công việc này là trách nhiệm của Product owner. Tuy nhiên, nếu khách hàng của bạn không chuyên trách toàn thời gian ở dự án bạn đang làm thì bạn cũng không cần quá lo lắng. Vì thực tế thì, rất nhiều team không có sự đóng góp, chuyên trách toàn thời gian của khách hàng. Và chúng ta hoàn toàn có thể tiến hành project theo mô hình Agile, làm cho project đạt được thành công. Do vậy, chúng ta có một kết luận rằng, không phải tất cả project đều cần phải có sự chuyên trách toàn thời gian của khách hàng.
Nhưng nói chung, một dự án khách hàng tham gia cùng với team càng nhiều, thì dự án càng dễ đạt được thành công hơn. Và đây cũng cội nguồn sinh ra phương pháp Agile.
Do đó, chúng ta càng thuyết phục, lôi kéo, hay làm cách nào đó để khách hàng tham gia phát triển project với team càng nhiều càng tốt. Chúng ta phải hiểu được rằng, vai trò của khách hàng trong dự án là cực kỳ quan trọng.

Hết. Mời các bạn tham khảo tiếp về các vai trò cơ bản trong development team các bài viết lần tới.

Nguồn:  アジャイルサムライ