Tuyên ngôn Đội ngũ (Team Manifesto)
1. Giới thiệu (Introduction)
Các đội ngũ ISE thường xuyên làm việc với một đội ngũ phát triển hoàn toàn mới trong mỗi dự án với khách hàng. Điều này đòi hỏi một giai đoạn làm quen, phá vỡ khoảng cách (ice-breakers) và chuyển giao tri thức trước khi bắt đầu chính thức.
Việc hoàn tất giai đoạn làm quen và thảo luận về các tiêu chuẩn làm việc tuy mất một khoảng thời gian ban đầu, nhưng là điều bắt buộc để nhanh chóng nâng cao đường cong học hỏi (learning curve) của đội ngũ mới.
Tuyên ngôn đội ngũ (Team Manifesto) là một tài liệu Agile gọn nhẹ chỉ trên một trang giấy giữa các thành viên trong nhóm, tóm tắt các nguyên tắc cơ bản và giá trị cốt lõi của đội. Tuyên ngôn nhằm mục đích tạo ra sự đồng thuận về các kỳ vọng kỹ thuật từ mỗi thành viên để cùng nhau tạo ra sản phẩm đầu ra chất lượng cao nhất khi kết thúc dự án.
Mục tiêu của tuyên ngôn là giảm thiểu thời gian thiết lập kỳ vọng mà không cần phải tổ chức những buổi họp "đọc tài liệu nhóm" dài dòng, đồng thời tạo sự đồng thuận trả lời cho câu hỏi: "Đội ngũ mới của chúng ta sẽ phát triển phần mềm như thế nào?" — bao quát tất cả các chủ đề nền tảng kỹ thuật và chuẩn mực xuất sắc như quy trình phát hành, viết code sạch (clean code), chiến lược kiểm thử.
Một mục tiêu quan trọng khác của việc soạn thảo tuyên ngôn là khơi gợi cuộc thảo luận cởi mở trong "buổi xây dựng tuyên ngôn", giúp sớm phát hiện và dung hòa bất kỳ sự khác biệt nào về quan điểm làm việc trong nhóm.
Nó cũng phát huy giá trị tương tự khi có thành viên mới gia nhập đội. Người mới có thể nhanh chóng nắm bắt và bắt kịp các tiêu chuẩn đã được toàn đội cam kết.
2. Cách xây dựng Tuyên ngôn Đội ngũ (How to Build a Team Manifesto)
Thời điểm tốt nhất để xây dựng tuyên ngôn là ở giai đoạn rất sớm của dự án, khi các nhóm gặp nhau lần đầu để làm quen hoặc trong giai đoạn chuẩn bị (preparation phase).
Khuyến nghị là nên giữ tuyên ngôn đội ngũ càng đơn giản càng tốt. Định dạng lý tưởng nhất là một tài liệu tóm tắt trong 1 trang duy nhất và không chứa các liên kết hay tài liệu tham khảo rườm rà. Nếu cần đào sâu kiến thức ở các chủ đề chuyên biệt, hãy tổ chức các buổi chia sẻ trưa (brown-bag sessions), technical katas, thực hành nội bộ hoặc tài liệu hướng dẫn chuyên sâu sau này.
Một vài điểm quan trọng về Tuyên ngôn đội ngũ: - Do chính đội ngũ phát triển tự tay xây dựng. - Bao quát cả các yêu cầu kỹ thuật chuẩn mực lẫn tư duy văn hóa làm việc linh hoạt mà toàn đội cảm thấy cần thiết. - Tạo tiếng nói chung về chuyên môn, thực hành và tư duy trong đội ngũ. - Có thể linh hoạt điều chỉnh trong suốt dự án dựa trên nhu cầu thực tế và kết quả các buổi Retrospective.
Tại ISE, chúng tôi hướng tới chất lượng hơn số lượng, tạo ra những phần mềm được trau chuốt tỉ mỉ (well-crafted software) trong một môi trường làm việc minh bạch, thoải mái để mỗi cá nhân phát huy tối đa tiềm năng của mình.
Bảng các chủ đề tham khảo để thảo luận
Dưới đây là một số chủ đề tiêu biểu mà nhiều đội ngũ thường đưa vào tuyên ngôn:
| Chủ đề (Topic) | Nội dung thảo luận chính |
|---|---|
| Sở hữu tập thể (Collective Ownership) | Toàn đội cùng sở hữu mã nguồn hay phân chia theo cá nhân? Kỳ vọng cụ thể là gì? |
| Tôn trọng (Respect) | Tuyên bố cam kết tôn trọng lẫn nhau như một giá trị văn hóa bắt buộc. |
| Cộng tác (Collaboration) | Toàn đội muốn phối hợp làm việc với nhau như thế nào hàng ngày? |
| Minh bạch (Transparency) | Tính minh bạch được duy trì qua các kênh nào (cuộc họp, retro, cơ chế phản hồi...)? |
| Kỹ nghệ lập trình (Craftspersonship) | Sử dụng các công cụ nào (Git, Visual Studio Live Share...)? Tiêu chuẩn sử dụng hiệu quả ra sao? |
| Kích thước Pull Request (PR sizing) | Quy định kích thước PR thế nào là lý tưởng (nhỏ gọn, tập trung)? |
| Chiến lược phân nhánh (Branching) | Tiêu chuẩn và chiến lược phân nhánh mã nguồn của nhóm (ví dụ: Trunk-based, Gitflow). |
| Quy chuẩn Commit (Commit standards) | Định dạng thông điệp commit (ví dụ: Conventional Commits), quy tắc commit mã nguồn. |
| Code sạch (Clean Code) | Đội có áp dụng các nguyên tắc Clean Code và SOLID không? |
| Lập trình cặp / Lập trình nhóm (Pair/Mob Programming) | Đội có áp dụng Pair/Mob programming không? Phong cách nào phù hợp với nhóm? |
| Quy trình phát hành (Release Process) | Các nguyên tắc xoay quanh quy trình phát hành (rào chắn chất lượng, quy trình review...). |
| Code Review | Quy tắc review code: số lượng reviewer tối thiểu, thời gian phản hồi, văn hóa góp ý. |
| Mức độ sẵn sàng (Action Readiness) | Cách thức làm mịn backlog? Làm sao để đảm bảo rõ ràng DoD và DoR? |
| TDD (Test-Driven Development) | Nhóm có áp dụng phát triển hướng kiểm thử (TDD) không? |
| Độ bao phủ kiểm thử (Test Coverage) | Có đặt ra chỉ số tỷ lệ bao phủ kiểm thử (percentage) cụ thể nào không? |
| Các cấp độ kiểm thử (Dimensions in Testing) | Các loại kiểm thử bắt buộc: Unit, Integration, Functional, Performance, Regression, E2E. |
| Quy trình Build (Build process) | Điều kiện để build thành công? Sự phụ thuộc vào môi trường, hệ điều hành, công cụ. |
| Quy trình sửa lỗi (Bug fix) | Quy tắc sửa lỗi: ai là đầu mối, cách liên kết PR với Issue báo lỗi. |
| Nợ kỹ thuật (Technical debt) | Nhóm theo dõi, ghi nhận và lên kế hoạch xử lý nợ kỹ thuật như thế nào? |
| Tái cấu trúc (Refactoring) | Khi nào và làm thế nào để nhóm thực hiện tái cấu trúc mã nguồn? |
| Tài liệu Agile (Agile Documentation) | Ưu tiên dùng sơ đồ, hình vẽ và bảng biểu thay cho các bài viết tài liệu dài dòng. |
| Tài liệu hiệu quả (Efficient Documentation) | Khi nào tài liệu là bắt buộc trước khi hoàn tất task/PR? |
| Định nghĩa Niềm vui (Definition of Fun) | Nhóm sẽ thư giãn, gắn kết tinh thần đồng đội qua những hoạt động nào? |
| Công cụ AI (AI tools) | Nhóm có sử dụng các công cụ hỗ trợ AI (như GitHub Copilot) không? Có quy tắc hoặc hướng dẫn nào khi áp dụng? |
3. Công cụ hỗ trợ (Tools)
Thông thường, một buổi thảo luận cởi mở giữa toàn đội là đủ để tạo ra tuyên ngôn và đạt được sự đồng thuận. Nếu cần cấu trúc hóa buổi thảo luận, bạn có thể sử dụng bất kỳ công cụ bảng vẽ hoặc công cụ retrospective trực tuyến nào (như Miro, Mural, RetroTool).