Lập kế hoạch Sprint cho một đội ngũ người + agent chỉ hiệu quả khi bạn hoạch định dựa trên năng lực review, chứ không phải tốc độ thực thi. Agent có thể nhận và hoàn thành nhiều Task hơn mức mà người review của bạn có thể nghiệm thu, nên giới hạn thực sự của một chu kỳ là số thay đổi đã hoàn tất mà một người có thể kiểm tra và merge, chứ không phải lượng code được viết ra. Hướng dẫn này sẽ đi qua từng bước của phương pháp lập kế hoạch, chỉ rõ dạng thất bại ở mỗi bước, và kết thúc bằng một checklist bạn có thể chạy trước Sprint tiếp theo.
Cách lập kế hoạch Sprint truyền thống giả định rằng nguồn lực khan hiếm là số giờ mà kỹ sư có để viết code. Thêm các coding agent vào, giả định đó sụp đổ. Claude Code, Codex và Gemini CLI đều có thể nhận một Task và trả về một diff chạy được trong lúc bạn còn đang đọc cái trước đó. Thực thi không còn là nút thắt. Nghiệm thu trở thành nút thắt.
Sự dịch chuyển đó âm thầm phá hỏng một kế hoạch bình thường. Bạn định cỡ một chu kỳ hai tuần theo số ngày công lập trình viên, agent cày hết backlog trong ba ngày, và một hàng đợi gồm những thay đổi đã xong nhưng chưa review cứ chồng lên sau lưng một hai người có quyền nghiệm thu merge. Sprint trông có vẻ nhanh nhưng lại kết thúc chậm.
Sharkly là không gian làm việc mà hướng dẫn này lập kế hoạch bên trong. Bạn đã có coding agent; Sharkly biến chúng thành một đội bằng cách giữ mọi Task — cùng tiến độ, điểm nghẽn, kết quả và phần review của con người — trong một nơi chia sẻ chung, thay vì rải rác khắp các terminal. Một Sprint trong Sharkly là một tập Task được giới hạn thời gian và thuộc sở hữu của một Space. Phương pháp dưới đây vẫn như nhau dù bạn chạy nó trên bảng trắng hay trong sản phẩm, nhưng các dạng thất bại sẽ dễ phát hiện hơn khi công việc quay về một bảng chung.
Điều gì thay đổi khi agent đảm nhận phần thực thi
Lập kế hoạch Sprint cho một đội ngũ người + agent là việc xác định phạm vi chu kỳ dựa trên lượng công việc agent đã hoàn tất mà một người có thể review và nghiệm thu, chứ không dựa trên lượng code mà đội có thể tạo ra.
Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, trao quyền và nghiệm thu kết quả. Chính sự phân chia đó là toàn bộ bài toán lập kế hoạch. Thông lượng của agent rất linh hoạt: bạn có thể chạy ba hay mười agent. Thông lượng review của bạn thì cố định, phụ thuộc vào số người có thể đọc một diff, chạy thử thay đổi và quyết định cho nó lên sóng. Xem bài toán năng lực review để hiểu vì sao sản lượng agent tăng 5 lần hiếm khi đồng nghĩa với lượng công việc được ship nhiều gấp 5.
Vậy con số đầu tiên bạn dùng để lập kế hoạch không phải story point. Đó là số slot review: mỗi người review nghiệm thu được bao nhiêu Task hoàn tất mỗi ngày, nhân với số người review, nhân với số ngày trong chu kỳ. Mọi thứ khác đều phải nằm dưới mức trần đó.
Lập kế hoạch Sprint theo từng bước
1. Xác định mức trần review trước tiên. Ước lượng số Task hoàn tất mà một người review thực sự có thể nghiệm thu mỗi ngày; một buổi review nghiêm túc cho một thay đổi không hề đơn giản mất 30 đến 60 phút. Nhân với số người review và số ngày Sprint. Dạng thất bại: bỏ qua bước này, lập kế hoạch theo năng lực agent, cam kết quá nhiều, rồi kết thúc chu kỳ với hàng đợi review còn dài hơn cả Sprint.
2. Định cỡ Task theo góc độ review, không phải thực thi. Chia nhỏ công việc sao cho mỗi Task tạo ra một diff mà một người có thể nắm trọn trong đầu. Dạng thất bại: agent vui vẻ trả về một thay đổi 2.000 dòng trải khắp chín file, không ai có thể nghiệm thu nó trong một slot, và nó mục ruỗng ở dưới đáy bảng.
3. Viết tiêu chí nghiệm thu trước khi giao việc. Mỗi Task cần một định nghĩa hoàn thành có thể kiểm thử: cần xây gì, thế nào là “đúng”, không được động vào đâu. Dạng thất bại: phạm vi mơ hồ khiến agent đoán mò, người review trả lại, và một Task ngốn mất hai slot review.
4. Giao cho một Agent hay một Crew — một cách có chủ đích. Dùng một Agent cho công việc nhỏ, đã được định nghĩa rõ. Dùng Crew khi một Agent trưởng nhóm phải diễn giải mục tiêu, kéo thêm các thành viên khác và gom kết quả của họ về một Task duy nhất. Dạng thất bại: dùng Crew cho việc vặt chỉ làm tăng thêm các thành phần chuyển động mà sau đó bạn lại phải review.
5. Giới hạn công việc đang thực hiện. Đặt mức trần cho số Task được phép nằm ở cột “đang review”, giống cách giới hạn WIP hoạt động trong kanban. Dạng thất bại: không có trần, agent làm ngập cột review nhanh hơn tốc độ con người rút bớt; nút thắt cứ vô hình cho đến ngày cuối.
6. Chừa một khoảng đệm dư. Dành sẵn slot review cho việc làm lại và cho những yêu cầu chỉnh sửa mà bạn sẽ trả về. Dạng thất bại: lập kế hoạch kín 100% thì vòng “nhờ sửa lại” đầu tiên chẳng còn chỗ nào để hạ cánh.
Khi bảng tính hay hệ thống chỉ có ticket bắt đầu hết khả năng mở rộng
Bạn có thể chạy Sprint đầu tiên bằng một bảng tính. Một tab gồm các Task, một cột người phụ trách, một cột trạng thái. Nó vẫn trụ được khi một người điều hành hai agent trên một repo.
Nó ngừng hoạt động ngay khi thực thi và theo dõi tách rời nhau. Lần chạy của agent, diff, kết quả kiểm thử và phần thảo luận nằm trong terminal; còn bảng tính thì giữ một dòng “đang thực hiện” đã cũ. Ai đó cập nhật hàng thủ công, hoặc chẳng ai làm. Thêm agent thứ ba chạy trên repo thứ hai, và chỉ trong một ngày, bảng sẽ lệch khỏi thực tế. Đến lúc đó bạn không thể trả lời câu hỏi duy nhất mà việc lập kế hoạch phụ thuộc vào: cái gì đã xong, và cái gì đang chờ tôi?
Một bảng công việc được xây đúng cho việc này sẽ giữ thực thi và hồ sơ đi liền nhau. Công việc, tiến độ, điểm nghẽn và kết quả đều quay về Task thay vì biến mất vào những phiên riêng tư. Trong Sharkly, một Agent nhận một Task đã sẵn sàng, chạy trong một worktree tách biệt để các thay đổi song song không đụng nhau, rồi bản tóm tắt thay đổi, kết quả xác minh và những giới hạn đã biết của nó quay về dòng thời gian của Task để một người nghiệm thu hoặc trả lại. Đó là khác biệt giữa một trạng thái bạn phải tự duy trì và một trạng thái tự duy trì chính nó. Nó cũng mang đến cho buổi lập kế hoạch tiếp theo dữ liệu thật: agent đã hoàn thành những công việc gì trong chu kỳ trước, và thời gian review đã đi đâu.
Ranh giới thẳng thắn: nếu bạn chạy một agent trên một repo và review ngay khi làm, bạn không cần bảng công việc hay Sharkly. Một terminal và một checklist là đủ. Phương trình thay đổi khi bạn lập kế hoạch xuyên nhiều agent, nhiều Task, nhiều repo hay nhiều người — đúng cái điểm mà bảng tính biến thành một công việc thứ hai. Sharkly được xây cho trường hợp thứ hai đó; tải về khi bảng tính bắt đầu nói dối bạn.
Checklist cần chạy trước Sprint tiếp theo
Hãy chạy checklist này trước khi bạn chốt kế hoạch:
- [ ] Đã tính mức trần review (số người review x số nghiệm thu mỗi ngày x số ngày) và coi đó là năng lực thật của Sprint.
- [ ] Mọi Task đều đủ nhỏ để review trong một slot.
- [ ] Mọi Task đều có tiêu chí nghiệm thu kiểm thử được và một ranh giới “không được đụng vào” rõ ràng.
- [ ] Mỗi Task được giao cho một Agent hoặc một Crew một cách có chủ đích, không phải theo mặc định.
- [ ] Có mức trần WIP cho cột “đang review”.
- [ ] Đã dành khoảng đệm cho việc làm lại và các yêu cầu chỉnh sửa.
- [ ] Có một người chịu trách nhiệm quyết định merge và phát hành cho mọi Task.
- [ ] Tiến độ, điểm nghẽn và kết quả đều quay về một bảng chung, không phải những terminal riêng tư.
Đánh dấu đủ cả tám mục thì phần thực thi của agent sẽ nằm gọn trong một kế hoạch mà đội có thể hoàn thành. Bỏ sót mục đầu tiên thì những mục còn lại cũng không cứu được bạn.
Câu hỏi thường gặp
Lập kế hoạch Sprint có còn hữu ích khi agent viết phần lớn code? Có, nhưng ràng buộc đã dịch chuyển. Sprint không còn là cái hộp đựng số giờ kỹ thuật nữa mà trở thành cái hộp đựng phần review và nghiệm thu. Hãy lập kế hoạch cho chu kỳ dựa trên lượng công việc đã hoàn tất mà con người có thể kiểm tra, rồi để agent lấp đầy. Scrum Guide vẫn định nghĩa nghi thức này; chỉ có bài toán năng lực là thay đổi.
Làm sao ước lượng năng lực cho một đội ngũ người + agent? Hãy bắt đầu từ người review, không phải từ agent. Đếm số Task hoàn tất mà một người thực sự có thể nghiệm thu mỗi ngày, rồi nhân với số người review và số ngày Sprint. Số lượng agent chỉ có ý nghĩa cho đến khi vượt qua mức trần đó; vượt rồi thì thêm agent chỉ làm hàng đợi dài thêm.
Agent có nên tự chọn Task của mình trong Sprint không? Hãy để chúng nhận những Task đã sẵn sàng và đã có tiêu chí nghiệm thu, nhờ đó công việc song song vẫn chạy mà không cần người điều phối. Giữ con người ở phần định hướng, trao quyền và merge. Như vậy con người vẫn nằm trong vòng lặp ở nơi cần phán đoán, còn mọi chỗ khác thì tự động.
Điều này khác gì so với quản lý dự án thông thường? Các nghi thức trông giống nhau; nút thắt thì không. Quản lý dự án với AI agent lập kế hoạch dựa trên thông lượng review và việc cô lập thay đổi, thay vì dựa trên sự sẵn có của lập trình viên, bởi thực thi không còn là nguồn lực khan hiếm nữa.
Tôi có cần công cụ mới không, hay có thể mở rộng Jira? Bạn có thể giữ hệ thống mà đội mình đã quen. Khoảng trống nằm ở chỗ công cụ ticket theo dõi một trạng thái do con người gõ vào, chứ không phải một tiến trình do máy chạy. Xem các lựa chọn thay thế Jira cho đội ngũ người + agent để biết khoảng trống đó bắt đầu gây đau ở đâu.
