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

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 (2)

2.3 Phân chia vai trò. (2)

・Development team

Agile development team được cấu thành bởi các Cross-functional members (member đa chức năng) , được tập hợp lại để biến những tính năng khách hàng mong muốn thành một phần mềm hoạt động tốt, và đáng tin cậy. Trong đó có các vai trò chính như là, Analyst, Programmer. tester, Database administrator...
Như bạn có thể thấy từ đầu tới giờ, tôi khá thích thú với ý định và mục tiêu của agile team là không gán ghép các vai trò trong team vào một khuôn mẫu gò bó.
Tuy nhiên, đối với những team đang vận hành theo phương thức truyền thống, giờ đột nhiên tôi nói rằng 「Nào, các quý vị. Chúng ta hãy thực hiện quy tắc Tự tổ chức hóa theo mô hình Agile nhé! 」, thì dĩ nhiên mọi người khó mà có thể thực hiện tốt ngay được.
Khi bạn thành lập team, bạn cần truyền đạt mọi thứ một cách rõ ràng, tránh nói vòng vo. Đối với Agile project, thì việc phân chia vai trò thì không rõ ràng lắm, vì ai cũng cần đảm nhận nhiều vai trò khác nhau. Nói là vậy nhưng, theo kinh nghiệm của tôi, bạn cần phải giải thích được bản chất của Agile bằng những từ ngữ dễ hiểu, thì qua đó, team mới có thể chuyển đổi sang kiểu 「Tự tổ chức hóa」một cách trơn tru.
Nếu bạn đang gặp khó khăn về việc giải thích các vai trò có trong agile team, thì các định nghĩa tôi đưa ra dưới đây sẽ giúp ích cho bạn nhiều đấy. Khi áp dụng "Tự tổ chức hóa" cho team, nó sẽ giúp bạn hiểu được việc phân chia vai trò trong team sẽ biến đối như thế nào. Nào, chúng ta cùng đi xem lần lượt từng vai trò nhé.
・Agile analyst

Khi implement một feature, phải thực hiện tìm hiểu tường tận, cặn kẽ xem feature đó sẽ được thực hiện như thế nào... thì đó chính là công việc của một Agile analyst. Có thể nói Agile analyst như là một thám tử sắc bén, và thông suốt. Họ đưa ra nhưng câu hỏi sâu sắc, luôn làm việc mật thiết với khách hàng, và làm sáng tỏ những yêu cầu cần thiết.
Và lượng công việc của một Agile analyst trong Agile Project thì khá là nhiều. Ví dụ như là,

• Trợ giúp viết User story
• Khi implement một story, họ cũng cùng đi sâu vào phân tích
• Trợ giúp tạo Mockup hay prototype ....

Agile analyst sẽ phải huy động mọi kiến thức, công cụ để trao đổi với khách hàng về bản chất của User story. Trong các chương tiếp theo, tôi sẽ mô tả chi tiết hơn nữa về phần này.
・Agile programmer

Thực tế là, chúng ta không thể lường trước hết được mọi thứ cho đến khi phải trực tiếp bắt tay vào việc viết code. Lúc này, các Agile programmer sẽ thể hiện vai trò của mình. Agile programmer luôn sục sôi tâm huyết để tạo ra những phần mềm có chất lượng cao. Một Agile programmer lý tưởng là không phải chỉ có say mê code, mà cũng phải là tester nhiệt tình, tâm huyết. Và phải luôn luôn tự hào về công việc của mình, hướng tới viết những đoạn code có chất lượng cao hơn nữa.
Để tạo ra những phần mềm chất lượng cao, đáng tin cậy, dưới đây là những việc dĩ nhiên với một agile programmer:

• Viết test thật nhiều. Thường xuyên tận dụng việc viết test để thúc đẩy, cải tiến design.
• Trong quá trình code, luôn luôn có ý thức cải tiến architectural design.
• Luôn giữ trạng thái codebase có thể release bất cứ lúc nào. Luôn chuẩn bị có thể deploy ngay lập tức nếu cần thiết.

Agile programmer cũng luôn làm việc, liên kết mật thiết với khách hàng, và các team khác. Đối với những thứ cần phải làm, thì làm nó một cách rõ ràng, đơn giản nhất có thể. Và coi việc deploy lên môi trường Production là công việc dĩ nhiên một Agile programmer phải làm được.
・Agile tester

Agile tester hiểu rõ rằng, việc build một phần mềm thì chỉ là một khía cạnh cần thiết, còn việc phần mềm đó chạy thực sự ổn định thì mới thật sự có ý nghĩa. Đó cũng là lý do, Agile tester luôn tham gia project từ giai đoạn rất sớm. Agile tester sẽ tham gia đóng góp, định nghĩa thế nào là một user story có giá trị thực tiễn, để sau đó, ngay sau khi code được viết xong thì có thể bắt tay ngay vào việc test.
Trong Agile project, mọi thứ đều cần phải được test. Do đó, chúng ta sẽ thấy bóng dáng Agile tester ở mọi nơi.
Đôi khi ta thấy họ ngồi cạnh khách hàng, viết những yêu cầu của khách hàng thành những testcase khác nhau.
Đôi khi ta thấy họ ngồi cạnh programmer, giúp thực hiện test tự động hóa, hay cùng nhau tìm ra bug. Và họ cũng thực hiện tìm mọi cách khác nhau để có thể làm crash ứng dụng, qua đó giúp nâng câo chất lượng của phần mềm.
Agile tester luôn quan tâm tới chức năng tổng thể của toàn bộ dự án. Để cung cấp phần mềm có chất lượng cao, họ không bao giờ bỏ sót những thứ cần thiết như là: stress test hay scalability ...
Tác phầm 「Agile Testing: A Practical Guide for Testers and Agile Teams」 của tác giả Lisa Crispin Janet Gregory là một tài liệu rất tốt để tham khảo về Agile testing. Trong các chương sau, tôi sẽ giải thích chi tiết hơn nữa về tầm quan trọng của Agile tester trong project.

Khi bắt đầu dự án mới, bạn thử đặt ra những câu hỏi dưới đây xem sao nhé.
Dưới đây là 4 câu hỏi nên đặt ra trong team, khi bắt đầu dự án mới

• Bản thân giỏi điều gì nhất?
• Bản thân dự định cống hiến cho team như thế nào?
• Điều mà bản thân coi là quan trọng, và đánh giá cao nhất?
• Đối với mỗi team member kỳ vọng kết quả như thế nào đối với bản thân?

Nào mỗi thành viên trong team hãy thử trả lời những câu hỏi này, và chia sẻ với nhau nhé. Những câu hỏi này dựa trên 「The Drucker Exercise」- Đây là một bài tập rất tốt khi mới thành lập team.
「The Drucker Exercise」tuy đơn giản nhưng nó là một phương pháp xây dựng team cực kỳ tốt và mạnh mẽ. Thông qua việc trả lời những câu hỏi này, nó sẽ hình thành được tinh thần đối thoại, sự tin tưởng lẫn nhau trong team. Qua đó, nó giúp tăng performmance của mọi người trong dự án, vì vậy bạn nhất định hãy thử xem sao nhé.
Bạn có thể tham khảo chi tiết hơn về bài tập này ở đây: The Drucker Exercise

・Agile project manager

Các Agile project manager luôn hiểu rõ rằng cách duy nhất để làm cho dự án thành công là làm cho development team thành công. Đó là lý do tại sao các manager có năng lực có thể đi đến tận cùng trái đất để loại bỏ những trở ngại cản trở sự thành công của development team.
「Loại bỏ trở ngại」bao gồm thực hiện một cách liên tục các công việc như là: Lập kế hoạch, đánh giá lại kế hoạch, và sẵn sàng điều chỉnh phương hướng của dự án nếu cần thiết. Ngoài ra, công việc của Agile manager còn là quản trị sự kỳ vọng đối với development team xảy ra từ các bên liên quan tới dự án ở vị trị cao hơn. Và còn, báo cáo tình trạng công việc cho các Stakeholder, làm cho mối quan hệ giữa người với người trong nội bộ công ty trở nên tốt đẹp hơn. Bên cạnh đó, Agile manager còn như một tấm khiên chắn bảo vệ team từ những áp lực bên ngoài. Những công việc như vậy, thì bất kỳ một manager có năng lực nào đều làm nó một cách thường xuyên, bất kỳ họ có phải là một Agile project manager hay là không.
Một Agile project manager ưu tú sẽ không ra lệnh cho development team phải làm gì. Nói đúng hơn, là những việc như thế là không cần thiết. Manager chỉ chuẩn bị một môi trường tốt cho development team làm việc. Để khi manager có vắng mặt đi chăng nữa, thì development team vẫn có thể làm việc một cách độc lập như bình thường, và đem lại kết quả tốt đẹp cho khách hàng. Nói một cách cụ thể hơn là, dù manager có vắng bóng khỏi công tyc cả tuần lễ đi chăng nữa, thì điều đó cũng không gây trở ngại, khó khăn cho dự án.
Những điều khác về Agile project manager, tôi sẽ mô tả chi tiết hơn ở các chương sau.
・Agile UX Designer

Agile UX Designer luôn nỗ lực mang đến cho khách hàng một trải nghiệm hấp dẫn, một phần mềm tiện lợi, dễ sử dụng.
Nếu là một member quan tâm tới Usability, thì bạn luôn quan tâm tới việc thấu hiểu nhu cầu của khách hàng, làm việc nhiệt tình với các thành viên khác trong team, để đem đến những điều tốt đẹp nhất cho khách hàng.
Thật là tốt, khi hầu hết các chuyên gia về Usability đều quen thuộc , và đồng tình với tinh thần của mô hình Agile đó là 「Luôn mang đến giá trị cho khách hàng」. Họ luôn chú trọng đến giá trị mà họ cung cấp, tích cực lắng nghe những feedback, và tạo ra những product tốt nhất cho khách hàng. Và đây cũng là suy nghĩ chung của cả cộng đồng Agile và cộng động UX.
Hơn nữa, về cách tiến hành design, thì Agile UX Designer luôn tích lũy, design từng chút một thông qua các iteration. Họ sẽ không design trước một lúc tất cả các màn hình, mà họ sẽ design một chút một sao cho phù hợp với thời điểm implement các feature.
Nếu dự án của bạn có một thành viên chuyên trách nghiên cứu về Usability, bạn nên cảm thấy biết ơn vì sự xa hoa như vậy được cho phép trong dự án.
Các UX designer sẽ mang lại những hiểu biết hữu ích cho dự án theo nhiều cách khác nhau và sẽ rất hữu ích trong các lĩnh vực phân tích và thiết kế UX.
・Các vai trò khác
Có một số vai trò quan trọng khác mà tôi chưa đề cập đến như là, database administrator, system administrator, technical writer, trainer, business improvement staff, infrastructure administrator, network administrator, etc.
Tât cả các vai trò này đều thuộc development team, và đều được đối xử công bằng như các vai trò khác.
Có một vai trò quan trọng khác tôi muốn đề cập đến ở đây là vai trò của Scrum Master.
Scrum Master giống như là một sự hợp nhất của Agile coach và project manager tuyệt vời. Nếu có Scrum Master thì đó là một sự hữu ích tuyệt với giúp một team mới đi đúng quỹ đạo. Scrum Master sẽ hỗ trợ member trong việc giải thích và giúp thấu hiểu về nguyên tắc Agile, cách suy nghĩ của Agile. Và việc giúp team luôn phát triển và luôn hoàn thành công việc tới cùng đó cũng là công việc của Agile coach.
Để làm được điều đó, team cần tránh quay lại những thói quen xấu ngày trước. Và có một cuốn sách rất hay về Agile coaching đó là cuốn 「Agile Coaching」 của tác giả Rachel Davies và Liz Sedley bạn nên tham khảo.
Nếu là một team có kỹ năng tốt, thì không có một Agile coach chuyên trách cũng không sao. Tuy nhiên, là một team với nhiều thành viên mới ít kinh nghiệm, thì nếu có một Agile couach chuyên trách sẽ mang lại nhiều hiệu quả rõ rệt.
Giả sử bạn muốn áp dụng các vai trò trong mô hình Agile vào nơi làm việc của bạn, có những điều tôi muốn bạn hiểu rõ và cần confirm thật kỹ. Đó là, trong Agile project mỗi member cần đội rất nhiều "mũ trách nhiệm" khác nhau, đôi khi cần đội cả "mũ trách nhiệm" đến từ môi trường bên ngoài nữa. Liệu mỗi member có thấu hiểu được điều đó không?!.
Tóm lại, kể cả Analyst hay programmer đều cần có khả năng giao tiếp, trao đổi trực tiếp với khách hàng.
Đối với các tester, thì cần có khả năng viết những mã test tự động hóa. Và hơn nữa, dù trong team không có UX designer chuyên trách thì không có nghĩa là không làm design Usability, khi đó trong team cần một ai đóng có khả năng đóng vai trò của UX designer, để hoàn thành công việc.
Cuối cùng, bạn cần tổng hợp trước những yếu tố cần quan tâm khi tìm kiếm thành viên mới cho team.

2.4 Tips tìm kiếm team member

Dưới đây một số mẹo khi tìm kiếm member cho các Agile project.
・Generalist
Các Generalist sẽ rất phù hợp với các Agile Project. Bời vì, Những yêu cầu trong Agile project họ đều có thể đáp ứng và phát huy năng lực của bản thân từ đầu đến cuối. Ví dụ, nếu là một programmer thì họ có thể đảm nhiệm từ các task FrontEnd đến các task BackEnd. Nếu là Analysts hay testers thì đều có thể hoàn thành công việc testing hay phân tích yêu cầu.
Một Generalist sẽ đội rất nhiều chiếc "mũ" khác nhau, có những ngày họ sẽ tham gia viết code, ngày tiếp theo họ làm tài liệu phân tích yêu cầu, thậm chí một ngày khác, họ có thể đảm nhiệm cả công việc của tester.

・Người không sợ hãi sự mơ hồ
Trong Agile project, không phải là tất cả mọi thứ đều được chuẩn bị từ trước. Yêu cầu, specs không phải luôn luôn hiện rõ ngay ra trước mặt (công việc của bạn là phải tìm ra nó), các plan cũng có thể thường xuyên bị thay đổi. Do đó, chúng ta buộc phải thích nghi với những tình trạng như thế. Nói một cách đơn giản, chúng ta mong muốn tìm kiếm một người không hoảng sợ khi bị một quả bóng ném vào, mà hãy tìm cách đánh trả lại quả bóng. Một người mà dù đoàn tàu có đột nhiên bị trật đường ray, thì cũng phải bình tĩnh leo lên chiếc tàu khác để hoàn thành mục tiêu.

・Không phải là người ích kỷ
Có thể điều này ai cũng biết, nhưng tôi muốn nhấn mạnh rằng, Agile project chỉ thành công khi nó được cấu thành từ những member không ích kỳ, luôn coi team là một tập thể gắn kết.
Thực ra không phải ai cũng thích sự mập mờ phân chia vai trò trong Agile project, và luôn chỉ biết đến công việc của bản thân mình.
Hay tìm một người đủ rộng lượng chấp những những gì bản thân mình đang có, không ngần ngại chia sẻ với người khác, và luôn mong muốn cùng người khác học hỏi, phấn đấu để thành công.

Đồ đệ: Thưa thầy, chỗ này khó hiểu quá ạ! Nếu trong Agile project, chúng ta không phân chia vai trò rõ ràng trước thì làm thế nào có thể hoàn thành công việc được ạ?

Sư phụ : Nếu có một việc cần phải hoàn thành, cả team hãy góp sức hoàn thành nó.

Đồ đệ: Vâng, con hiểu rồi ạ. Tuy nhiên, giả sử nếu không có một tester chuyên trách riêng, thì làm sao để xác nhận được rằng việc testing đang được làm một cách cẩn thận ạ ?

Sư phụ : Testing là công việc bắt buộc phải làm trong mỗi project. Do vậy, nó phải là công việc của cả team. Phạm vi test, test tới mức độ nào thì cả team phải thống nhất để đưa ra quyết định.

Đồ đệ: Nhưng giả sử trong team không ai muốn làm công việc test thì phải làm thế nào ạ? Ai cũng chỉ muốn viết code thôi thì phải làm thế nào ạ?

Sư phụ : Hãy tìm những người nhiệt huyết với công việc test, hiểu được tầm quan trọng của công việc test. Hay chào đón những người như thế, coi họ là những member không thể thay thế, giúp họ phát huy tối đa năng lực của bản thân.

Đồ đệ: Cảm ơn Sự phụ, con hiểu rồi ạ.

Hết. Mời các bạn tham khảo tiếp ở các bài viết lần tới

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