Trong quá trình phát triển sản phẩm, làm việc cross-team (kết hợp giữa các nhóm) là điều không thể tránh khỏi để tối ưu hóa chuyên môn và tăng hiệu quả công việc. Tuy nhiên, việc phối hợp giữa các team cũng không thiếu thử thách. Các vấn đề như sự khác biệt trong sprint goal, thiếu giao tiếp rõ ràng, hay thiếu sự đồng nhất về chiến lược có thể gây ra những trở ngại lớn. Bài viết này trình bày các thách thức khi làm việc cross-team tại Eco và đề xuất một quy trình chuẩn để tối ưu hóa hiệu quả.
1.Thách thức khi làm việc cross-team
1.1 Thiếu sự đồng bộ giữa các team
Các Scrum team hoạt động độc lập với Sprint riêng, dẫn đến khó khăn trong việc căn chỉnh tiến độ, yêu cầu hoặc mục tiêu khi phối hợp, gây hiểu lầm hoặc chậm trễ.
1.2. Khó khăn trong việc chia sẻ và thông tin
Mỗi team có mức độ chuyên môn khác nhau, khiến việc truyền đạt kiến thức hoặc thông tin trong các dự án phức tạp trở nên kém hiệu quả.
1.3. Mâu thuẫn trong ưu tiên công việc
Các team có thể có Sprint goal khác nhau, dẫn đến xung đột về ưu tiên tính năng hoặc yêu cầu khi làm việc trên cùng sản phẩm.
1.4. Khó khăn trong việc đồng bộ hóa môi trường phát triển và kiểm thử
Sự khác biệt về công cụ hoặc môi trường giữa các team gây trở ngại trong tích hợp mã nguồn và kiểm thử sản phẩm.
1.5. Vấn đề trong việc chia sẻ tài nguyên
Các team Scrum có thể gặp phải vấn đề khi phải chia sẻ tài nguyên (nhân lực, phần mềm, phần cứng, v.v.) gây ra sự thiếu hụt hoặc chậm trễ trong công việc của đội này hoặc đội kia.
2. Quy trình phối hợp cross-team
Việc phối hợp giữa các team là rất quan trọng và để tránh gặp phải những khó khăn và thách thức ở trên, một quy trình làm việc chung là vô cùng cần thiết. Trong tài liệu này, team 7 nụ xin đề xuất một quy trình phối hợp công việc liên team, được thiết kế nhằm đảm bảo luồng công việc xuyên suốt, minh bạch và hiệu quả. Từng bước trong quy trình sẽ được xác định cụ thể về trách nhiệm, đầu vào – đầu ra, cũng như các công cụ hoặc tài liệu hỗ trợ cần thiết.
Bước 1: Chuẩn bị
Trong bất kỳ quy trình phát triển phần mềm nào, bước chuẩn bị đóng vai trò nền tảng nhằm đảm bảo các yêu cầu được chuyển giao một cách rõ ràng, đầy đủ và dễ hiểu. Đây là giai đoạn cần thiết để thu thập và chuẩn hóa thông tin trước khi gửi request đến các bên liên quan (như backend, frontend, hoặc UI/UX). Việc chuẩn bị kỹ lưỡng giúp giảm thiểu sai sót trong giao tiếp, tiết kiệm thời gian chỉnh sửa và đẩy nhanh tiến độ phát triển.
Các trường hợp cụ thể:
- Nếu request API
Team yêu cầu cần chuẩn bị tài liệu API(mock API) hoặc design của tính năng. Nếu chưa hoàn thiện được ở mức design thì có thể dùng mockup thay thế. Những yếu tố này giúp backend hiểu rõ logic, dữ liệu vào/ra và cách API sẽ hoạt động trong ngữ cảnh hệ thống.
2. Nếu request giao diện (UI)
Trong trường hợp yêu cầu thiết kế giao diện, cần chuẩn bị luồng xử lý và thông tin cần hiển thị.
Người phụ trách: BA (Business Analyst) và PO (Product Owner) team yêu cầu
Bước 2: Tổ chức họp
Sau khi đã chuẩn bị rõ yêu cầu, tiến hành tổ chức họp giữa hai team để truyền đạt yêu cầu tới team nhận yêu cầu, làm rõ nội dung công việc và thống nhất các phương án triển khai. Buổi họp này đóng vai trò quan trọng nhằm đảm bảo không có sự hiểu lầm hoặc thiếu sót trong quá trình phát triển.
- Mục tiêu buổi họp
- Làm rõ nhu cầu, mong muốn của team yêu cầu.
- Thảo luận về giải pháp thực hiện, phạm vi công việc và tài nguyên cần thiết.
- Ước lượng thời gian triển khai và due date cho công việc được yêu cầu
2. Thành phần tham gia
- PO (Product Owner) và BA (Business Analyst) từ cả hai team là người chủ chốt tham gia họp để thống nhất yêu cầu và giải pháp.
- Các thành viên kỹ thuật hoặc chuyên môn khác được mời tham gia nếu cần thiết để làm rõ các vấn đề chuyên sâu.
3. Lưu ý quan trọng
- Cần có invite đầy đủ các thành viên liên quan trước buổi họp.
- Kết quả buổi họp cần được ghi chép lại, bao gồm nội dung đã thống nhất, timeline và người phụ trách từng hạng mục.
Người phụ trách: PO team yêu cầu
Bước 3: Tạo ticket
Sau khi các team đã thống nhất yêu cầu trong buổi họp, tiến hành tạo ticket để quản lý và theo dõi trạng thái công việc. Các công việc cụ thể bao gồm:
- Tạo Epic trên Jira
PO của team yêu cầu tạo một Epic mới trên Jira. Việc sử dụng Epic chung giúp gom nhóm toàn bộ công việc liên quan và tạo sự minh bạch trong quá trình phối hợp.
2. Tạo nhóm chung giữa hai team
Một nhóm làm việc chung giữa hai team sẽ giúp các thành viên từ cả hai bên có thể trao đổi, theo dõi và xử lý công việc dễ dàng, không bị phân tán hoặc thiếu thông tin. Việc tạo nhóm làm việc chung cũng thuộc phụ trách của PO team yêu cầu.
3. Tạo task cho phần được request trong Epic chung
Task cụ thể cho phần việc được yêu cầu sẽ được PO team nhận yêu cầu tạo trên board jira của team nhận và gắn vào Epic chung. Task này cần đảm bảo:
- Có mô tả rõ ràng nội dung được yêu cầu.
- Gắn đúng vào Epic chung để tiện theo dõi.
- Được assign đúng người thực hiện bên team nhận yêu cầu.
Bước 4: Triển khai ticket
Sau khi PO team nhận đã tiếp nhận yêu cầu và tạo task, việc triển khai task giống như cách team vẫn làm với những tính năng khác nhận từ stakeholder.
- Mô tả chi tiết yêu cầu của task
Trước khi đội phát triển bắt tay vào thực hiện, điều kiện tiên quyết là các task phải được mô tả chi tiết, rõ ràng. Một ticket tốt là ticket mà bất kỳ ai đọc vào cũng hiểu được “phải làm gì”, “để làm gì” và “khi nào được xem là xong”.
Việc mô tả càng cụ thể, quá trình triển khai càng trơn tru, giảm thiểu tối đa tình trạng “hiểu sai – làm lại” gây lãng phí thời gian và công sức.
Người phụ trách: BA team nhận yêu cầu
2. Refine ticket cho team phát triển
Sau khi BA team nhận yêu cầu làm rõ đề bài, mô tả chi tiết, dựa vào sự sắp xếp ưu tiên của PO, BA truyền đạt lại thông tin yêu cầu tới team phát triển để thực hiện công việc.
Trong một số trường hợp, PO hoặc BA từ phía team yêu cầu sẽ trực tiếp tham gia để đảm bảo hiểu biết giữa các bên được đồng nhất ngay từ đầu.
Người phụ trách: BA team nhận yêu cầu
3. Phát triển tính năng
Khi mọi thông tin đã rõ ràng, team phát triển sẽ chính thức triển khai việc lập trình tính năng. Mọi vấn đề phát sinh trong quá trình phát triển, team cần nhanh chóng trao đổi trong nhóm làm việc chung để thống nhất cách giải quyết và cả 2 team cùng nắm được
Người phụ trách: Team phát triển của team nhận yêu cầu
4. Kiểm thử tính năng, đảm bảo chất lượng đầu ra
Thông thường team nhận yêu cầu sẽ cần thực hiện bước này để đảm bảo chất lượng sản phẩm trước khi bàn giao của team.
Tuy nhiên, tùy theo nguồn lực và độ ưu tiên, 2 team có thể thỏa thuận để team yêu cầu đảm nhận việc kiểm thử
Bước 5: Bàn giao kết quả
Sau khi hoàn tất quá trình phát triển và kiểm thử, bước bàn giao kết quả chính là điểm kết thúc chính thức của một chu trình xử lý yêu cầu. Đây là giai đoạn thể hiện rõ nhất tính cam kết, trách nhiệm và chất lượng phối hợp giữa các bên tham gia. Ở bước này, team phát triển sẽ tiến hành các phần sau:
- Thông báo bàn giao các tính năng
PO team nhận yêu cầu thông báo các tính năng đã được xây dựng, kiểm thử và hoàn thiện tới PO team yêu cầu
2. Nếu là request API => team yêu cầu thực hiện tích hợp API
Xác nhận rằng API hoạt động ổn định, đầy đủ các đầu ra như cam kết trong tài liệu thiết kế ban đầu. Việc bàn giao không chỉ đơn thuần là gửi kết quả, mà còn bao gồm việc cung cấp hướng dẫn sử dụng, thông tin cấu hình (nếu cần), hoặc tài liệu kỹ thuật liên quan giúp team nhận bàn giao có thể tiếp cận và sử dụng hiệu quả.
3. Verify tính năng được request
PO và BA team yêu cầu chịu trách nhiệm verify tính năng đã đáp ứng đúng yêu cầu ban đầu, đúng mục tiêu nghiệp vụ và đạt chất lượng như kỳ vọng. Việc này có thể bao gồm kiểm thử chấp nhận (User Acceptance Testing – UAT) hoặc các buổi demo ngắn để đối chiếu thực tế triển khai với mong muốn ban đầu. Nếu có sai lệch hoặc chưa đạt, PO có thể phản hồi để team xử lý nhanh chóng trong phạm vi sprint hoặc ghi nhận cải tiến cho giai đoạn sau.
KẾT LUẬN
Trong môi trường phát triển phần mềm hiện đại, nơi sự thay đổi liên tục là điều tất yếu, mô hình Agile – đặc biệt là Scrum – đã chứng minh được tính hiệu quả nhờ khả năng thích nghi nhanh và tối ưu hóa quy trình làm việc. Tuy nhiên, khi quy mô sản phẩm mở rộng và số lượng Scrum Team tăng lên, thì vấn đề phối hợp giữa các team trở thành một thách thức lớn. Quy trình phối hợp giữa các Scrum Team vì thế không chỉ đơn thuần là sự kết nối kỹ thuật hay hành chính, mà còn là một phần cốt lõi quyết định thành công chung của toàn bộ hệ thống phát triển.
Quy trình được trình bày bao gồm năm bước chính – từ chuẩn bị, tổ chức họp, tạo ticket, triển khai đến bàn giao kết quả – đã làm rõ cách các team cần phối hợp để đảm bảo luồng công việc xuyên suốt, liền mạch và có trách nhiệm rõ ràng. Trong đó, mỗi vai trò (PO, BA, team phát triển) đều được định nghĩa cụ thể về nhiệm vụ trong từng giai đoạn, tạo nên một cơ chế tương tác liên tục, minh bạch và linh hoạt. Bằng cách đó, mọi yêu cầu đều được tiếp nhận, phân tích, phát triển và nghiệm thu theo một chuẩn thống nhất, giúp giảm thiểu rủi ro, tăng tốc độ xử lý và đảm bảo chất lượng đầu ra.
Đặc biệt, quy trình này còn thúc đẩy sự cộng tác chủ động giữa các nhóm Scrum – vốn thường có xu hướng làm việc độc lập theo sprint riêng của mình. Thông qua các buổi họp tổ chức chung, việc chia sẻ thông tin, thống nhất thời gian và điều phối nguồn lực trở nên hiệu quả hơn, tránh được tình trạng “đứt gãy” trong truyền thông hoặc hiểu sai yêu cầu. Đồng thời, quá trình kiểm thử, bàn giao và xác nhận kết quả cũng là lúc các team cùng nhau nhìn lại, đánh giá kết quả thực hiện để cải tiến trong những chu kỳ tiếp theo.
Có thể nói, một quy trình phối hợp rõ ràng và linh hoạt giữa các Scrum Team không chỉ giúp tổ chức vận hành trơn tru hơn trong bối cảnh phát triển đa nhóm mà còn nâng cao hiệu suất làm việc và sự hài lòng của các bên liên quan. Trong thời đại mà khả năng phản ứng nhanh với nhu cầu thay đổi của thị trường là yếu tố sống còn, thì việc xây dựng và duy trì một cơ chế phối hợp chuyên nghiệp giữa các team chính là chìa khóa để các tổ chức công nghệ giữ vững lợi thế cạnh tranh và phát triển bền vững.
