Vào thẳng nội dung

Các phần trong Thỏa thuận Làm việc (Sections of a Working Agreement)

Thỏa thuận làm việc (Working Agreement) là một tài liệu (hoặc tập hợp các tài liệu) mô tả cách toàn đội phối hợp làm việc cùng nhau, cũng như những kỳ vọng và nguyên tắc chung mà mọi thành viên cam kết tuân thủ.

Thỏa thuận làm việc được toàn đội cùng nhau xây dựng vào giai đoạn bắt đầu dự án, và được lưu trữ ngay trong kho mã nguồn (repository) để bất kỳ ai tham gia dự án đều có thể dễ dàng tiếp cận và tham khảo.

Dưới đây là các phần và điều khoản mẫu mà một thỏa thuận làm việc thường có. Mỗi đội ngũ nên tự biên soạn thỏa thuận riêng cho mình, điều chỉnh khung giờ, kênh liên lạc, quy ước đặt tên nhánh, v.v., sao cho phù hợp nhất với nhu cầu thực tế:

1. Nguyên tắc chung (General)

  • Chúng ta làm việc như một đội thống nhất hướng tới mục tiêu chung và phạm vi công việc rõ ràng.
  • Đảm bảo tiếng nói của mọi thành viên đều được lắng nghe và tôn trọng.
  • Đối xử bình đẳng và tôn trọng tất cả các thành viên trong đội.
  • Cùng nhau xây dựng các kỳ vọng kỹ thuật chung và ghi lại trong Tuyên ngôn Đội ngũ (Team Manifesto).
  • Luôn chia sẻ chuyên môn và kỹ năng trong đội ngũ, tránh để dự án bị phụ thuộc vào một cá nhân duy nhất nắm giữ một kỹ năng độc quyền.
  • Mọi mốc thời gian bên dưới đều được quy chiếu theo múi giờ làm việc chung của nhóm.

2. Giao tiếp & Liên lạc (Communication)

  • Mọi thông tin liên quan đến dự án được trao đổi qua kênh chung của dự án (kênh Microsoft Teams / Slack của dự án).
  • Toàn bộ các tài liệu nghiên cứu kỹ thuật (Technical Spikes), nghiên cứu đánh giá giải pháp (Trade Studies) và các tài liệu kỹ thuật khác đều được đưa vào kho mã nguồn dự án thông qua quy trình Async Design Reviews trong Pull Requests.

3. Cân bằng Công việc - Cuộc sống (Work-life Balance)

  • Khung giờ làm việc cốt lõi (thời gian có thể kỳ vọng cộng tác trực tiếp qua Teams, điện thoại hoặc gặp mặt) là từ Thứ Hai đến Thứ Sáu, từ 9:00 sáng đến 5:00 chiều.
  • Không ai bị bắt buộc phải trả lời email/tin nhắn sau 6:00 tối, vào cuối tuần hoặc khi đang trong kỳ nghỉ phép.
  • Tôn trọng sự khác biệt múi giờ của các thành viên, đặc biệt khi lên lịch cho các cuộc họp định kỳ.
  • Luôn ghi hình (record) các cuộc họp khi có thể để những thành viên không tham gia trực tiếp có thể xem lại sau.

4. Chất lượng hơn Số lượng (Quality and not Quantity)

5. Nhịp điệu Scrum (Scrum Rhythm)

Hoạt động (Activity) Thời điểm (When) Thời lượng Thành phần tham gia Người chịu trách nhiệm Mục tiêu chính (Goal)
Project Standup Thứ 3 - Thứ 6, 9:00 Sáng 15 phút Toàn bộ thành viên Process Lead Báo cáo việc đã làm, việc tiếp theo, các khó khăn (blockers)
Sprint Demo Thứ 2, 9:00 Sáng 1 giờ Toàn bộ thành viên Dev Lead Trình diễn kết quả công việc và nghiệm thu User Story
Sprint Retro Thứ 2, 10:00 Sáng 1 giờ Toàn bộ thành viên Process Lead Chia sẻ bài học kinh nghiệm và các điểm cần cải tiến
Sprint Planning Thứ 2, 11:00 Sáng 1 giờ Toàn bộ thành viên Product Owner (PO) Ước lượng kích thước và lên kế hoạch Story cho sprint mới
Task Creation Sau Sprint Planning Linh hoạt Dev Team Dev Lead Chia nhỏ story thành task cụ thể để xác định vận tốc
Backlog Refinement Thứ 4, 2:00 Chiều 1 giờ Dev Lead, PO PO Chuẩn bị cho sprint kế tiếp, đảm bảo story đạt chuẩn Ready

6. Trưởng điều phối quy trình (Process Lead)

Process Lead chịu trách nhiệm dẫn dắt và điều phối các thực hành Scrum/Agile giúp dự án luôn tiến về phía trước:

  • Điều phối các buổi họp Standup và nhắc nhở các thành viên tham gia đầy đủ, đúng giờ.
  • Giữ nhịp độ cuộc họp diễn ra gãy gọn như hướng dẫn trong trang Họp dự án (Project Standup).
  • Đảm bảo mọi hạng mục hành động (action items) đều được ghi chép, có người phụ trách cụ thể, có thời hạn hoàn thành và theo dõi sát sao.
  • Ghi chép các ghi chú cần thiết sau các buổi Planning / Standup.
  • Chuyển các chủ đề dài dòng sang "bãi đỗ xe" (Parking Lot) và theo dõi giải quyết sau cuộc họp.
  • Duy trì bảng theo dõi tiến độ chung của đội và chủ động tháo gỡ các trở ngại (impediments) cản bước nhóm.
  • Đôn đốc toàn đội chịu trách nhiệm về kết quả với tinh thần hỗ trợ, đồng hành.
  • Đảm bảo tài liệu dự án và chương trình luôn được cập nhật mới nhất.
  • Đảm bảo theo dõi/thực hiện các hành động cải tiến từ buổi Retrospective và các buổi Standup hàng ngày.
  • Đóng vai trò huấn luyện viên (coach) hỗ trợ Product Owner và đội ngũ về quy trình làm việc khi cần.

7. Quản lý Backlog (Backlog Management)

  • Cùng nhau xây dựng Định nghĩa Sẵn sàng (Definition of Ready); mọi User Story đưa vào sprint đều phải đạt chuẩn này.
  • Mọi thành viên thông báo công việc mình đang làm thông qua bảng Kanban/Sprint board.
  • Chỉ tự gán task cho mình khi đã thực sự sẵn sàng bắt tay vào làm (không nhận trước hàng loạt) và chuyển trạng thái sang Active/In Progress.
  • Mọi công việc liên quan đến dự án đều phải được ghi lại thành User Story hoặc Task.
  • Chỉ đóng (close) task/story khi đã thực sự thỏa mãn Định nghĩa Hoàn thành (Definition of Done).
  • Trao đổi chặt chẽ với PM nếu muốn thêm bất kỳ User Story mới nào vào giữa sprint.
  • Khi thêm task mới vào bảng, phải đảm bảo nó phục vụ đúng tiêu chí chấp nhận (Acceptance Criteria) của story để tránh phình phạm vi (scope creep). Nếu không khớp tiêu chí, cần thảo luận với PM xem có cần tạo một story mới hay điều chỉnh lại tiêu chí chấp nhận.

8. Quản lý Mã nguồn (Code Management)

  • Tuân thủ quy ước đặt tên nhánh theo git-flow và kèm theo mã số task, ví dụ: feature/123-add-working-agreement.
  • Mọi mã nguồn đưa vào nhánh chính đều phải thông qua Pull Request (PR).
  • Mỗi PR bắt buộc phải được review bởi ít nhất một kỹ sư từ phía đối tác/khách hàng và một kỹ sư từ phía Microsoft (nhằm chuyển giao tri thức và đảm bảo các tiêu chuẩn kỹ thuật & bảo mật).
  • Luôn ưu tiên review các PR đang chờ trước khi bắt tay làm task mới.
  • Rà soát các PR đang mở vào cuối mỗi buổi Standup để đảm bảo mọi PR đều có người review.
  • Coi tài liệu như mã nguồn (Docs as Code) và áp dụng cùng các tiêu chuẩn chất lượng Markdown như đối với code.
Cập nhật cuối cùng: 11 tháng 11, 2026
Back to top