Bài 4 — Planner: chia task tốt quyết định chất lượng cả đội

Kế hoạch tồi thì mọi agent phía sau đều khổ

Nếu Planner chia task quá to ("Xây toàn bộ hệ thống thanh toán") thì Coder ngợp, Reviewer không review nổi, Tester không biết bắt đầu từ đâu. Nếu chia quá nhỏ ("đặt tên biến"), pipeline chậm và ngập trong lượt gọi. Chất lượng đội đa agent bắt đầu từ chất lượng của Planner.

Đặc điểm của một task tốt

Một task tốt cần thỏa mãn tiêu chí INVEST (mượn từ Agile, rất hợp với agent):

• Independent: hạn chế phụ thuộc chéo.
• Negotiable: đủ linh hoạt để Coder chọn cách làm.
• Valuable: hoàn thành xong tạo ra giá trị kiểm chứng được.
• Estimable: đủ nhỏ để ước lượng.
• Small: gói gọn trong một context Coder xử lý được.
• Testable: có tiêu chí acceptance rõ ràng.

Ví dụ: chia task cho "Giỏ hàng"

Yêu cầu: "Làm giỏ hàng thêm/xóa sản phẩm và tính tổng".

{
  "tasks": [
    {"id":"T1","title":"Model Cart + CartItem","depends_on":[],
     "acceptance":"Tạo được cart rỗng, thêm item lưu qty>0"},
    {"id":"T2","title":"Hàm add_item(sku, qty)","depends_on":["T1"],
     "acceptance":"Thêm trùng sku thì cộng dồn qty"},
    {"id":"T3","title":"Hàm remove_item(sku)","depends_on":["T1"],
     "acceptance":"Xóa sku không tồn tại không lỗi"},
    {"id":"T4","title":"Hàm total()","depends_on":["T2"],
     "acceptance":"Tổng = Σ giá×qty, làm tròn 2 số"}
  ]
}

Mỗi task đều nhỏ, có acceptance kiểm chứng được, và ghi rõ phụ thuộc.

Các bước để Planner chia task tốt

• Yêu cầu Planner liệt kê giả định và câu hỏi mở trước khi chia task (để lộ chỗ mơ hồ).
• Bắt buộc mỗi task có acceptance viết dưới dạng có thể thành một test.
• Bắt buộc khai báo depends_on để orchestrator sắp xếp đúng thứ tự.
• Đặt trần kích thước: mỗi task "một Coder làm xong trong một lượt".
• Cho Planner tự đánh dấu task nào rủi ro cao để đội ưu tiên review kỹ.

Prompt mẫu cho Planner

Bạn là Planner. Chia yêu cầu thành các task nhỏ, độc lập nhất có thể.
Mỗi task: {id, title, depends_on[], acceptance, risk}.
- acceptance phải viết được thành test (điều kiện đúng/sai).
- Nếu yêu cầu mơ hồ, thêm mục assumptions[] và questions[].
- KHÔNG viết code. Chỉ lập kế hoạch.

Khung tư duy: "Task này có test được không?"

Trước khi chấp nhận một task từ Planner, hỏi: nếu tôi là Tester, tôi có viết được một test để nói task này xong hay chưa không? Nếu câu trả lời là không, acceptance chưa đủ rõ và cần Planner làm lại.

Xử lý yêu cầu mơ hồ

Planner tốt không im lặng đoán bừa. Khi gặp mơ hồ, nó nên trả về questions[] để orchestrator quyết định: hỏi người dùng, hay chọn giả định mặc định và ghi lại. Điều này ngăn cả đội xây nhầm thứ.

Sai lầm thường gặp

• Task quá to: Coder phải suy diễn nhiều, Reviewer không bao quát nổi.
• Acceptance mơ hồ kiểu "làm cho tốt": Tester không có mốc phán xét.
• Bỏ qua depends_on: task chạy sai thứ tự, sinh lỗi dây chuyền.
• Planner tự viết code thay vì lập kế hoạch, phá vỡ vai trò.
• Không đánh dấu rủi ro: đội dàn đều công sức review, bỏ sót chỗ nguy hiểm nhất.