agent-agile-team
Trang chủ / Cách hoạt động
Cách hoạt động
Sáu bước, hai cổng người, sáu vai và ba tier, kiểm định độc lập — kèm một ví dụ từ lời giao tới đóng sprint.
Một sprint = một mục tiêu
Trước khi mở sprint, agent gom mục tiêu, câu hỏi và bậc việc trong một tin để bạn xác nhận. Sau đó bạn duyệt kế hoạch và nghiệm thu ở hai cổng.
Tiếp nhận
Đọc đầu bài; gom mục tiêu, câu hỏi, bậc và rủi ro. Chỉ ghi yêu cầu sau khi bạn xác nhận.
Bạn: chốt phạm vi và có mở sprint không
SPEC rồi PLAN
Làm gì, làm thế nào, kiểm ra sao, hoàn tác thế nào.
Bạn: duyệt / điều chỉnh
Thực thi
Code trên nhánh riêng; nhật ký kèm bằng chứng.
Bạn: không gì
Kiểm định
Agent khác kiểm. Còn lỗi thì quay lại bước 3 (khuyến nghị 3 vòng).
Bạn: không gì
REPORT
Kết luận, kết quả kiểm, cách dùng, cách hoàn tác.
Bạn: nghiệm thu
Bài học
Bài học tái dùng; nợ để lại thành yêu cầu mới.
Bạn: có nâng thành luật?
Trong sprint, agent chỉ dừng hỏi thêm ở bốn điều kiện
Không hoàn tác được
Hành động không đảo ngược.
Chạm bảo mật
Bảo mật hay secret.
Ra ngoài phạm vi
Push, deploy, gửi tin.
Kế hoạch hỏng
Vì giả định sai.
Chỗ kế hoạch chưa nói tới: agent tự quyết, ghi một dòng Phán quyết: <gì> — <vì sao> — <sai thì tốn gì>, không hỏi. Việc có sprint không viết code trước Cổng 1. Không push, không gộp nhánh chính trước Cổng 2 và khi bạn chưa gật.
Từ một câu giao việc tới đóng sprint
Bạn nói với agent trong thư mục dự án: “Dùng agent-agile-team: thêm chức năng tra cứu đơn theo mã cho dự án này.”
| Bước | Ai làm | Tạo ra gì | Bạn làm gì |
|---|---|---|---|
| 1. Tiếp nhận | Analyst | một tin gom mục tiêu, câu hỏi có đề xuất, bậc vừa vì là tính năng mới, rủi ro và đề nghị mở sprint; sau xác nhận mới ghi RQ-001 cùng câu trả lời vào REQUESTS | xác nhận hoặc sửa phạm vi, bậc và việc mở sprint trong một lượt |
| 2. SPEC rồi PLAN | Analyst viết SPEC; Architect viết PLAN; Tech Reviewer soát PLAN | thư mục sprint docs/plans/<ngày>-order-lookup/: SPEC (cần gì, kịch bản KHI… THÌ…, tiêu chí thành công) và PLAN (từng việc: ai làm, kiểm ra sao, hoàn tác thế nào) | Cổng 1: đọc tóm tắt vài dòng, trả lời “duyệt” hoặc “điều chỉnh: …” |
| 3. Thực thi | Implementer (code, test), QA (chạy test) | code trên nhánh riêng; PROGRESS ghi từng việc kèm bằng chứng và các dòng Phán quyết: | không gì |
| 4. Kiểm định | Business Reviewer, Tech Reviewer — agent khác người làm | phát hiện có mức và bằng chứng; còn Chặn / Phải sửa thì quay lại bước 3 (một vòng) | không gì; sau 3 vòng còn lỗi thì chọn làm tiếp hay dừng |
| 5. REPORT | Analyst | REPORT: kết luận một câu, tóm tắt cho người không chuyên, kết quả kiểm, cách dùng, cách hoàn tác, việc để lại; sau kết luận: spec sống cập nhật, sprint đóng trong sổ SPRINTS | Cổng 2: Đạt / Đạt có điều kiện / Không đạt; rồi chọn gộp nhánh, push + PR, hay giữ nguyên |
| 6. Bài học | Analyst | bài học tái dùng trong REPORT và nơi môi trường quy định; nợ để lại thành dòng RQ- mới | quyết có nâng bài học thành luật hay skill không |
Hồ sơ thật của đúng ví dụ này nằm ở samples/order-desk/: bốn sprint (một cỡ vừa, một cỡ nhỏ, hai cỡ rất nhỏ), ba sổ gốc, một spec sống.
Giao theo năng lực, không theo tên model
Sáu vai chia hai nhóm; mỗi vai có tier. Repo không chứa tên model thật.
Analyst · Thực thi
Điều phối. Tiếp nhận, viết SPEC, REPORT và bài học.
Architect · Thực thi
Viết PLAN.
Implementer · Thực thi
Viết code và test.
QA · Thực thi
Chạy test.
Business Reviewer · Kiểm định
Kiểm định từ cỡ vừa — agent khác người làm.
Tech Reviewer · Kiểm định
Soát PLAN và kiểm định; kéo thêm 4 thẻ chuyên đề security · data · backend · frontend khi rủi ro cao.
Ba tier
T1 tư duy · T2 thực thi · T3 việc vặt và chạy test.
Bảng tier → model
Nằm ngoài repo, trỏ bằng biến AGENT_AGILE_TIERS. Thiếu bảng: agent dùng chỉ định của bạn trong chat, không đoán.
Cạn hạn mức
Dừng tier đó, ghi vướng mắc, báo bạn — không tự hạ tier. Mỗi lần giao việc, hồ sơ ghi đủ vai · tier · model thực tế.
Đạt chỉ đến từ bằng chứng mới chạy, do agent khác ghi
Reviewer độc lập
- Nhận ngữ cảnh soạn riêng, không dán lịch sử phiên.
- Được trả 0 phát hiện, nhưng phải ghi phần không đánh giá.
- “Chưa chạy”, “chắc chạy được”, “đã test” không kèm lệnh — không bao giờ là Đạt.
Một thang chung
- Mức phát hiện: Chặn / Phải sửa / Nên sửa / Ghi chú.
- Kết luận: Đạt / Đạt có điều kiện / Không đạt.
- Thang cũ của mọi nguồn quy về một bảng duy nhất.
Hai reviewer khi chạm chỗ nhạy
Việc chạm file luật, secret hay xác thực → dual-review: hai reviewer độc lập cùng rubric, cả hai Đạt mới Đạt.
Cổng review bốn pha (từ cỡ vừa)
Review song song theo khía cạnh → gộp theo bằng chứng → kiểm đối kháng từng phát hiện Chặn / Phải sửa → lỗi thì đóng: khía cạnh nào không chạy thì không ghi Đạt.