Backlog của bạn từng là một danh sách mà bạn và vài đồng đội cùng rút việc ra làm. Bạn đọc mục trên cùng, hiểu nó, rồi làm. Khâu triage diễn ra nhanh gọn vì câu hỏi duy nhất là "ai có thời gian?". Giờ đây, một số mục trong đó có thể được giao cho coding agent thay vì con người, và hàng đợi êm ả ngày nào biến thành nguồn của những sai lầm nhỏ mà đắt đỏ: một agent bắt tay vào task chưa ai viết xong, hai agent giành nhau phần việc chồng lấn, và cột "done" đầy ắp những kết quả chẳng ai yêu cầu.
Vấn đề không nằm ở các agent. Mà là ở chỗ một backlog được thiết kế cho con người đã lặng lẽ đổi vai. Nó không còn là danh sách việc cần làm nữa mà trở thành hàng đợi điều phối có khả năng kích hoạt thực thi. Một khi một dòng mục có thể khởi động công việc thật, thì thời điểm bạn chuyển một task và thời điểm bạn quyết định ai sở hữu nó đều mang theo những hậu quả mà trước đây chúng chưa từng có.
Đây chính là tầng mà Sharkly ngồi vào. Bạn đã có coding agent; Sharkly biến chúng thành một đội bằng cách cho backlog một ý nghĩa chung. Task là đơn vị công việc chính, Backlog là nơi công việc chưa cam kết chờ đợi, và Triage là hàng đợi tiếp nhận chuyên biệt nơi các mục mới đến nằm chờ cho tới khi có người quyết định. Bài viết này sẽ đi qua cách triage một backlog hỗn hợp người-agent mà không để những hàng đợi đó biến thành hỗn loạn, và kết thúc bằng một checklist bạn có thể áp dụng ngay hôm nay.
Backlog và Triage mang ý nghĩa gì khi agent đã có thể làm việc
Ở đây có hai định nghĩa gánh phần lớn nội dung, nên cần nắm cho thật chính xác.
Backlog là tập hợp công việc chưa cam kết: những task đã tồn tại nhưng chưa ai quyết định bắt đầu. Triage là quyết định tiếp nhận đối với những mục mới hoặc còn mơ hồ: chấp nhận, từ chối, đánh dấu trùng lặp, hoặc tạm hoãn lại sau. Con người vẫn luôn làm cả hai một cách không chính thức. Điều thay đổi là ở chỗ, trong một đội người-agent, kết quả của triage giờ bao gồm cả "agent nào sẽ chạy việc này", và hành động cam kết một task có thể khởi động một lượt chạy.
Đây là ranh giới đầu tiên khiến nhiều người vấp phải: gán một Agent vào task trong Backlog không làm nó chạy. Backlog là bãi đỗ nơi công việc được chuẩn bị trước khi thực thi. Lượt chạy chỉ bắt đầu khi task rời Backlog sang một trạng thái sẵn sàng làm việc, đồng thời có Computer và Runtime khả dụng. Vậy nên "gán agent" và "khởi động agent" là hai sự kiện tách biệt, với trạng thái backlog nằm ở giữa như một cổng chặn.
Còn một ranh giới nữa cần nói thẳng: agent không giữ backlog riêng. Không có hàng đợi ẩn nào mà một Agent tự mình cày xới. Mọi mục mà Agent sẽ chạm vào đều nằm trên bảng chung, và chính điều đó khiến triage trở nên khả thi thay vì phỏng đoán.
Cách làm tự phát (DIY) hết khả năng mở rộng ở đâu
Một bảng tính cộng một bảng Kanban cộng vài terminal là đủ dùng cho một người và hai agent. Nó sẽ hết khả năng mở rộng tại những điểm có thể đoán trước, và mỗi điểm lại biểu hiện thành một kiểu thất bại cụ thể.
Cột trạng thái chẳng có ý nghĩa gì với các agent. Trên một bảng thủ công, kéo thẻ sang "In Progress" chỉ là lời nhắn cho đồng đội; không có gì được thực thi cả. Thế là bảng và công việc thật dần lệch nhau: thẻ ghi "In Progress" trong khi agent đã xong từ một tiếng trước, hoặc ghi "To Do" trong khi agent đã đi được ba commit vì ai đó đã khởi động nó trong terminal. Không ai còn tin bảng nữa, nên cũng chẳng ai buồn dùng.
Các quyết định triage chỉ nằm trong đầu một người. Người tiếp nhận yêu cầu đến thì nhớ rằng bug đó đã được báo rồi, rằng tính năng kia đã bị từ chối quý trước, rằng task này cần đầu vào từ design trước đã. Khi người đó vắng mặt, các mục trùng lặp lại được tạo ra và agent bắt đầu làm những việc lẽ ra phải bị từ chối ngay từ khâu tiếp nhận. Hàng đợi không có ký ức.
Việc gán người và phạm vi công việc bị quyết định trong cùng một khoảnh khắc vội vàng. Phạm vi mơ hồ thì còn sống được khi một người nhận task và đặt câu hỏi. Agent thì không dừng lại để hỏi; nó chạy với đúng những gì bạn đưa và trả về một kết quả sai lầm nhưng đầy vẻ tự tin. Cái giá của một khâu triage sơ sài đã chuyển từ "đồng đội hơi bối rối một chút" thành "một agent đốt mất một lượt chạy và một vòng review vào nhầm thứ".
Triage một backlog hỗn hợp, từng bước một
Đây là trình tự giúp một backlog người-agent luôn minh bạch. Mỗi bước đều nêu rõ lỗi mà nó ngăn chặn.
1. Dọn sạch hàng đợi tiếp nhận trước khi động vào backlog. Yêu cầu mới sẽ đáp xuống Triage, chứ không đi thẳng vào backlog. Xử lý từng mục bằng một trong bốn quyết định: chấp nhận, từ chối, đánh dấu trùng lặp, hoặc tạm hoãn. Triage là hàng đợi tiếp nhận, không phải bộ lọc đã lưu cũng không phải công cụ dựng form, nên quyết định là rõ ràng và được ghi lại. Lỗi mà bước này ngăn chặn: công việc bị từ chối và công việc trùng lặp lặng lẽ trở thành task thật để rồi sau đó một agent nhặt lên làm.
2. Định hình task trước khi nó đủ điều kiện giao cho agent. Một mục được chấp nhận sẽ trở thành Task, nhưng nó vẫn nằm trong Backlog trong lúc bạn viết tiêu chí nghiệm thu, gắn repository và ghi chú các ràng buộc. Đây chính là bước mà người ta hay bỏ qua khi bị ép thời gian. Lỗi mà bước này ngăn chặn: agent chạy trên một cái tiêu đề vỏn vẹn một dòng rồi trả về kết quả đúng về mặt câu chữ nhưng lệch hẳn ý định.
3. Quyết định người nhận việc, và coi "chọn agent nào" là một lựa chọn thực sự. Có task cần con người. Có task cần agent, và trong số các agent thì agent phù hợp phụ thuộc vào chính task đó: một lượt refactor, một lượt viết test, và một lượt cập nhật tài liệu không phải cùng một loại việc. Hãy định tuyến một cách có chủ đích thay vì mặc định giao cho agent nào đang rảnh. Hướng dẫn định tuyến cho coding agent của chúng tôi nói rõ cách đưa ra quyết định đó. Lỗi mà bước này ngăn chặn: sai runtime cày xới một task mà nó vốn không phù hợp.
4. Giữ task trong Backlog cho tới khi nó thực sự sẵn sàng. Đây là cổng chặn. Một task có thể đã được gán đầy đủ mà vẫn nằm trong Backlog với không lượt chạy nào khởi động. Hãy tận dụng điều đó. Đừng chuyển nó đi cho tới khi phạm vi đã rõ và bạn thực sự muốn công việc bắt đầu. Lỗi mà bước này ngăn chặn: một task viết dở dang bỗng khởi động một lượt chạy chỉ vì ai đó kéo nó nhầm cột.
5. Cam kết task, và để lượt chạy bắt đầu. Chuyển task sang trạng thái sẵn sàng, hoặc kéo nó vào một Sprint. Khi một task đã có Agent sẵn sàng rời Backlog và có Computer cùng Runtime khả dụng, quá trình thực thi bắt đầu. Lúc này, việc đổi trạng thái và việc công việc chạy là cùng một sự kiện — đó chính là toàn bộ mục đích.
Với những đội làm việc theo chu kỳ, Lập kế hoạch Sprint cho đội người-agent cho thấy cùng một bước cam kết đó định hình phạm vi cho một khung thời gian thay vì một task đơn lẻ.
Trạng thái backlog trở thành cổng thực thi
Sự chuyển dịch trong tư duy là thế này: trên một bảng dành cho con người, trạng thái là một nhãn mô tả thực tế. Trên một bảng người-agent, trạng thái là một đòn bẩy thay đổi thực tế. Chuyển một task ra khỏi Backlog chính là hành động khởi động agent, nên kỷ luật triage của bạn giờ trở thành cơ chế an toàn của bạn.
Cũng chính cổng chặn đó là nơi giao kèo người-agent thuộc về. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người quyết định cái gì vào backlog, cái gì được cam kết, và cái gì được phát hành. Tự động hóa dừng lại ở đúng chỗ cần đến phán đoán của đội ngũ. Chế độ xem Plan giữ Backlog, Sprint và Project ở cùng một chỗ để quyết định cam kết được nhìn thấy rõ thay vì bị chôn vùi trong một terminal, đồng thời quá trình thực thi, các điểm tắc nghẽn, kết quả và việc review đều quay về Task thay vì phân tán khắp các phiên riêng lẻ.
Đó là lý do vì sao giữ backlog gọn gàng lại càng quan trọng khi có agent, chứ không phải ít đi. Một backlog lộn xộn của con người thì chỉ là bừa bộn. Một backlog lộn xộn có agent thì là bừa bộn mà thỉnh thoảng lại tự chạy. Bảng giữ cho ngữ cảnh, quyền sở hữu, tiến độ, kết quả và việc review của con người luôn hiển thị từ khâu tiếp nhận đến khâu phát hành — đó là khác biệt giữa một hàng đợi mà bạn quản lý và một hàng đợi quản lý bạn. Khi khâu review ùn ứ chứ không phải khâu tiếp nhận, đó lại là một nút thắt khác, được bàn trong vì sao review của con người mới là ràng buộc thật sự.
Bạn vẫn có thể chạy quy trình này bằng bảng tính kèm kỷ luật thủ công nếu lưu lượng còn thấp. Nếu bạn đã phải tiếp nhận yêu cầu đều đặn và vận hành nhiều agent, Sharkly mang đến cho bạn hàng đợi Triage, cổng chặn Backlog và một bảng chung duy nhất để những quyết định đó không còn sống trong đầu bạn nữa. Để có cái nhìn rộng hơn về cùng quy trình này, hãy xem hướng dẫn của chúng tôi về quản lý task cho AI agent và sự khác biệt giữa Triage và Inbox cá nhân của bạn.
Checklist triage bạn có thể áp dụng ngay hôm nay
Hãy chạy checklist này trên bảng hiện tại của bạn. Mỗi câu trả lời "không" là một chỗ mà agent sẽ khiến bạn bất ngờ.
- Yêu cầu mới có đáp xuống một nơi nào đó trước khi vào backlog không? Nếu khâu tiếp nhận đi thẳng vào "To Do", bạn không có bước chấp nhận/từ chối/đánh dấu trùng lặp nào cả và các mục trùng lặp là điều không thể tránh khỏi.
- Phạm vi của mọi task trong backlog có đủ rõ để giao cho một người lạ không? Nếu nó chưa đủ rõ với một nhân viên mới, thì nó cũng chưa đủ rõ với một agent.
- Việc chuyển một task có thực sự khởi động điều gì không? Nếu việc đổi trạng thái chỉ là gắn nhãn, bảng và công việc thật sẽ dần lệch nhau.
- Việc gán người có phải là một quyết định thực sự, bao gồm cả việc chọn agent nào không? Mặc định giao cho agent đang rảnh không phải là định tuyến.
- Ngay lúc này, bạn có nói được mỗi agent đang làm gì và cái gì đang chờ review không? Nếu câu trả lời nằm trong ký ức của ai đó hay trong màn hình cuộn của terminal, thì triage không có nguồn sự thật chung.
- Công việc đã xong có quay về task, chứ không phải về một phiên riêng lẻ không? Kết quả, điểm tắc nghẽn và diff đều thuộc về bản ghi chung để khâu review có cái mà xử lý.
Hãy sửa hai mục đầu trước khi mở rộng số lượng agent. Một khâu tiếp nhận sạch sẽ và phạm vi task trung thực sẽ ngăn được phần lớn những thất bại đắt đỏ; mọi thứ còn lại chỉ là tinh chỉnh thêm trên một backlog vốn đã có ý nghĩa.
