Tại sao Cộng tác lại Quan trọng? (Why Collaboration)

1. Tầm quan trọng của Cộng tác

Trong các dự án kỹ thuật, chúng tôi luôn hướng tới mức độ cộng tác rất cao. Khi các kỹ sư cùng nhau lập trình (code together), chúng ta đạt hiệu suất cao hơn, vận tốc sprint (sprint velocity) lớn hơn và mức độ chia sẻ tri thức trong toàn đội ngũ diễn ra sâu rộng hơn.

Có hai mô hình cộng tác phổ biến mà chúng tôi áp dụng: Lập trình cặp (Pair programming) và Lập trình nhóm (Swarm programming).

Lập trình cặp (Pair programming - "Pairing"): Hai kỹ sư phần mềm được phân công cùng làm việc trên một User Story chung tại một thời điểm trong sprint. Dev Lead phân công một story cho hai kỹ sư: một người là kỹ sư chính (Story Owner) và một người là kỹ sư phối hợp (Pairing Assignee).
Lập trình nhóm (Swarm programming - "Swarming"): Ba hoặc nhiều kỹ sư phần mềm cùng tập trung hợp lực xử lý một hạng mục ưu tiên cao để đưa nó về trạng thái hoàn thành nhanh nhất.

2. Cách thực hành Lập trình cặp (How to Pair Program)

Mỗi story đều được chủ ý phân công cho một cặp kỹ sư. Kỹ sư phối hợp có thể đang trong quá trình nâng cao kỹ năng (upskilling), tuy nhiên họ luôn là những đối tác bình đẳng trong nỗ lực phát triển. Dưới đây là các hướng dẫn thực hành:

Khi nhận phân công Story / PBI, cặp kỹ sư cần chủ động thống nhất cách phối hợp cùng nhau và nắm chắc định nghĩa công việc cần hoàn thành. Thông tin này cần được thể hiện rõ ràng trong phần mô tả story và tiêu chí chấp nhận. Sự thống nhất này cần diễn ra trước khi bắt đầu các phiên làm việc thực tế.
Người phụ trách chính và người phối hợp không chỉ đơn thuần là chia đôi công việc rồi đồng bộ định kỳ — họ thực sự cùng làm việc trên cùng một task, có thể chia sẻ màn hình qua Microsoft Teams hoặc sử dụng các công cụ cộng tác trực tiếp như VS Code Live Share (thường hiệu quả hơn chia sẻ màn hình thông thường).
Trong các phiên cộng tác, một kỹ sư đóng vai trò cung cấp môi trường phát triển (Driver), người còn lại tích cực quan sát, phản biện và góp ý (Navigator).
Hai kỹ sư thường xuyên đổi vai cho nhau giữa các phiên để ai cũng có thời gian trực tiếp làm chủ bàn phím.
Tận dụng các nhánh tính năng (feature branches) để tạo ra các Pull Request nhỏ gọn (thay vì dồn lại thành một PR khổng lồ vào cuối sprint).
Mã nguồn được cả hai thành viên commit lên kho lưu trữ khi các task nhỏ hoàn thành.
Kỹ sư phối hợp (Pairing Assignee) sẽ là người đại diện phát biểu cho cả cặp trong buổi Daily Standup hàng ngày, với sự hỗ trợ của Story Owner.
Việc hiển thị tên của cả hai kỹ sư (Owner và Pair Assignee) trực tiếp trên thẻ công việc (PBI Card) giúp tăng tính minh bạch trong các nghi thức sprint và nâng cao tinh thần trách nhiệm của người phối hợp. Xem ví dụ cấu hình thẻ Azure DevOps tại đây.

3. Lợi ích của Lập trình cặp

Lập trình cặp thúc đẩy sự gắn kết bởi cả hai kỹ sư đều chia sẻ trách nhiệm bình đẳng đối với sự hoàn tất của story. Đây là mối quan hệ đôi bên cùng có lợi: Trong khi Story Owner có nhiều kinh nghiệm thực chiến hơn, thì người phối hợp lại mang đến góc nhìn mới mẻ, không bị lối mòn tư duy chi phối.

Các lợi ích nổi bật khác: - Ít lỗi hơn và nâng cao tinh thần trách nhiệm: Bốn mắt nhìn vào code luôn giúp phát hiện lỗi sớm hơn và không quên các tác vụ dễ bị bỏ sót như viết Unit Test và Integration Test. - Học hỏi liên tục qua phản hồi thời gian thực: Thay vì để một kỹ sư đơn độc đánh vật với vấn đề hóc búa hàng giờ liền dẫn đến kiệt sức, việc lập trình cặp giúp họ luôn có bạn đồng hành để trao đổi tức thì. - Tư duy thành tiếng: Đôi khi chỉ cần giải thích to vấn đề thành lời cho người khác nghe đã giúp tìm ra ngay lỗi logic (nguyên lý Rubber Duck Debugging). - Giúp brainstorming giải pháp kiến trúc tốt hơn và chuẩn hóa từng chi tiết nhỏ như cách đặt tên biến nhất quán.

4. Khi nào nên áp dụng Lập trình nhóm (Swarming)?

Không phải hạng mục nào cũng cần đến Swarming. Một số sprint thậm chí không cần áp dụng. Hãy kích hoạt Swarm khi:

Công việc đủ phức tạp đòi hỏi trí tuệ tập thể cùng giải quyết (chứ không phải vì khối lượng việc quá nhiều).
Task đó đã trở thành (hoặc có nguy cơ trở thành) điểm nghẽn nghiêm trọng (blocker) đối với các story khác.
Phát hiện một yếu tố kỹ thuật chưa từng biết (unknown) cần sự đồng thuận của tập thể để đưa ra quyết định kiến trúc.
Xuất hiện xung đột hoặc bất đồng quan điểm kỹ thuật kéo dài trong một phiên lập trình cặp cần toàn đội cùng tham gia tháo gỡ.

5. Cách tổ chức Lập trình nhóm (How to Swarm Program)

Ngay khi cặp lập trình nhận thấy story cần sự hỗ trợ của Swarm, họ sẽ nêu vấn đề với toàn đội (qua phần Parking Lot của Standup hoặc trao đổi bất đồng bộ). Các thành viên sẽ đồng thuận hoặc tình nguyện tham gia:

Người phụ trách story gửi lời mời họp Teams cho các bên liên quan để khóa lịch tập trung (focus time).
Trong phiên Swarm, một kỹ sư có thể tạm thời tách ra nghiên cứu một nhánh nhỏ trong khi nhóm chính xử lý vấn đề cốt lõi, sau đó quay lại báo cáo kết quả.
Phiên họp có thể tiếp tục cho đến khi tìm ra giải pháp triệt để hoặc thống nhất được hướng đi tiếp theo.

6. Khi nào nên Swarm, Pair hoặc Tách riêng (Split)?

Lập trình cặp (Pair): Hữu ích nhất khi các kỹ sư chưa hoàn toàn rõ ràng về việc cần phải làm hoặc làm như thế nào.
Tách riêng (Split): Hoàn toàn hợp lý khi toàn đội đã hiểu rõ cách triển khai và công việc mang tính chất thực thi lặp lại theo quy chuẩn rõ ràng.
Lập trình nhóm (Swarm): Khi hai kỹ sư cần thêm ý kiến chuyên gia hoặc cần sự đồng thuận của tập thể để vượt qua trở ngại lớn.

7. Tài nguyên tham khảo (Resources)

Cập nhật cuối cùng: 11 tháng 11, 2026