Lập kế hoạch Sprint từ trước đến nay luôn dựa trên một giả định thầm lặng: năng lực bằng số người bạn có nhân với khung thời gian. Bạn ước lượng khối lượng công việc, so sánh với những gì đội ngũ hoàn thành ở chu kỳ trước, rồi cam kết một phạm vi vừa vặn.
Nhưng khi đưa các AI coding Agent vào đội ngũ, phương trình đó không còn phản ánh thực tế nữa. Một Agent có thể nhận Task ngay khi Task sẵn sàng, chạy song song với mọi Agent khác, và mang về một diff cùng kết quả kiểm thử trước cả buổi standup mà bạn định dùng để bàn về nó. Năng lực thực thi tăng vọt. Phản ứng dễ thấy nhất là cam kết thêm phạm vi, và những đội làm vậy thường phát hiện ra kiểu thất bại này ngay cuối chu kỳ đầu tiên: Sprint khép lại với rất nhiều code đã xong cùng một bức tường thay đổi chưa được review mà không ai có thời gian nghiệm thu.
Đó chính là luận điểm của bài viết này: khi có Agent trong đội, thực thi không còn là ràng buộc của Sprint nữa — review của con người mới là ràng buộc. Hãy lập kế hoạch dựa trên thông lượng nghiệm thu, chứ không dựa trên lượng code có thể tạo ra. Chúng ta sẽ dùng Sprint trong Sharkly như cơ chế cụ thể, đồng thời tách bạch rõ ràng lập luận về lập kế hoạch với các dữ kiện về sản phẩm.
TL;DR
Sprint trong Sharkly là một tập Task được giới hạn trong khung thời gian, thuộc sở hữu của một Space; Task vẫn là nguồn thực thi và thảo luận, còn Sprint bổ sung thêm lịch trình, phạm vi và báo cáo. Sprint là tùy chọn và hoạt động theo một trong hai chế độ: Automatic cadence, trong đó Sharkly duy trì lịch trình và chuyển công việc dang dở sang Sprint tiếp theo; hoặc Manual, trong đó con người tự tạo, bắt đầu và hoàn thành Sprint. Báo cáo bao gồm phạm vi, công việc đã bắt đầu và đã hoàn thành, tỷ lệ hoàn thành, năng lực và lịch sử burnup. Với các đội kết hợp người và Agent, điểm thay đổi trong lập kế hoạch là thế này: Agent làm năng lực thực thi tăng vọt, nhưng khâu nghiệm thu vẫn thuộc về con người, nên cam kết Sprint trung thực bị giới hạn bởi lượng công việc đã xong mà reviewer của bạn có thể nghiệm thu, chứ không phải bởi lượng mà Agent có thể tạo ra.
Sprint trong Sharkly là gì
Một Sprint là một tập Task được giới hạn trong khung thời gian, thuộc sở hữu của một Space. Nó giúp đội ngũ lập kế hoạch cho một phạm vi tập trung, theo dõi tiến độ và quyết định điều gì sẽ xảy ra với công việc dang dở khi hết khung thời gian. Task vẫn là nguồn thực thi và thảo luận; Sprint chỉ bổ sung thêm lịch trình, phạm vi và báo cáo.
Tài liệu dùng thuật ngữ Sprint theo đúng nghĩa mà ngành hiểu. Scrum Guide mô tả Sprint là những khung có độ dài cố định, nơi ý tưởng chuyển thành giá trị, và phiên bản của Sharkly vẫn giữ nguyên gốc đó. Điều Sharkly thay đổi là ai đang thực thi bên trong khung thời gian ấy.
Ba ranh giới giúp khái niệm này luôn rõ ràng:
- Một Sprint chỉ thuộc về đúng một Space. Việc đặt một Task vào Sprint không làm thay đổi quyền sở hữu của Task đó.
- Sprint là tùy chọn, được bật riêng cho từng Space. Một Space vận hành theo luồng liên tục có thể không bao giờ bật chúng.
- Sprint không phải là Project và cũng không phải View. Hãy dùng Sprint khi câu hỏi đặt ra là cần hoàn thành những gì trong một khung thời gian cụ thể. Dùng Project cho một kết quả đầu ra có thể trải dài qua nhiều Sprint hoặc nhiều Space. Dùng View cho một cách xem Task đã được lưu lại.
Sự phân biệt cuối cùng đó thực sự có giá trị trong một đội kết hợp: Project nắm giữ kết quả đầu ra, Sprint nắm giữ cam kết ngắn hạn, còn View nắm giữ những lát cắt mà mỗi người cần trong công việc hằng ngày.
Nhịp tự động hay chế độ Thủ công
Khi bật Sprint cho một Space, bạn chọn một trong hai chế độ vòng đời. Lựa chọn này thay đổi hành vi vòng đời, không thay đổi quyền sở hữu Task.
Automatic cadence giao toàn bộ lịch trình cho Sharkly. Bạn cấu hình thời lượng Sprint, khoảng nghỉ (cooldown) tùy chọn, ngày bắt đầu trong tuần, số Sprint tương lai cần duy trì, múi giờ, và các quy tắc tự động thêm Task khi chúng chuyển sang những nhóm trạng thái đã chọn. Sau đó Sharkly sẽ tạo các Sprint trong tương lai, bắt đầu và kết thúc chúng theo lịch, và chuyển công việc dang dở sang Sprint tiếp theo. Nếu bắt đầu sớm một Sprint sắp tới, Sprint hiện tại sẽ được hoàn thành trước và công việc dang dở của nó được đưa vào Sprint đang được bắt đầu.
Chế độ Manual để quyền kiểm soát vòng đời lại cho đội ngũ. Con người tạo các Sprint đã lên kế hoạch khi cần, bắt đầu chúng mà không thay đổi ngày đã cấu hình, chạy song song nhiều Sprint đang hoạt động, và chọn nơi các Task dang dở sẽ đi khi hoàn thành. Việc tạo tự động, chuyển tiếp, cooldown và các quy tắc thêm theo trạng thái đều không hoạt động trong chế độ Manual.
| Nhịp tự động | Chế độ thủ công | |
|---|---|---|
| Lịch trình | Sharkly tạo, bắt đầu và hoàn thành Sprint theo nhịp đã cấu hình | Con người chủ động tạo, bắt đầu và hoàn thành Sprint |
| Công việc dang dở | Tự động chuyển sang Sprint tiếp theo | Được định tuyến khi hoàn thành: không Sprint, sang Sprint khác, hoặc sang Sprint mới |
| Sprint hoạt động song song | Mỗi nhịp chỉ có một Sprint hiện tại | Cho phép nhiều hơn một Sprint đang hoạt động |
| Tiếp nhận Task | Các quy tắc theo nhóm trạng thái có thể thêm Task trong khung thời gian | Task do con người thêm qua lập kế hoạch, danh sách, hoặc trường Sprint |
| Phù hợp nhất với | Nhịp đều đặn mà đội muốn được duy trì tự động, không cần thao tác thủ công | Chu kỳ không đều, khung thời gian gắn với bản phát hành, hoặc các công việc chồng lấn |
Cách quyết định thẳng thắn: dùng Automatic cadence khi đội bạn vận hành theo nhịp đều và muốn hệ thống tự duy trì cơ chế đó. Dùng Manual khi chu kỳ của bạn không đều, khi bản phát hành thay vì lịch mới định hình khung thời gian, hoặc khi bạn cần hai Sprint hoạt động cùng lúc. Chuyển sang Manual sẽ giữ nguyên các Sprint hiện có nhưng dừng lập lịch tự động. Tắt hẳn Sprint sẽ hoàn thành các Sprint đang hoạt động, xóa các Sprint tương lai và giữ lại dữ liệu đã hoàn thành để báo cáo.
Cách Task đi vào, rời khỏi và bỏ qua Sprint
Sprint hiển thị ở năm trạng thái: Current (hiện tại), Upcoming (sắp tới), Planned (đã lên kế hoạch), Completed (đã hoàn thành) và Canceled (đã hủy). Sprint đã hoàn thành và đã hủy sẽ được chuyển vào kho lưu trữ của Space thay vì làm rối danh sách lập kế hoạch đang hoạt động.
Bạn thêm hoặc di chuyển Task thông qua trường Sprint của nó, từ danh sách Task, hoặc trong lúc lập kế hoạch Sprint. Có hai quy tắc quan trọng hơn vẻ ngoài của chúng.
Thứ nhất, một Task có thể không thuộc Sprint nào cả. Đó là trạng thái bình thường của công việc trong Backlog và của những Task không được cam kết vào bất kỳ khung thời gian nào.
Thứ hai, thêm một Task vào Sprint không làm thay đổi trạng thái của nó. Đây là quy tắc mà các đội kết hợp cần khắc cốt ghi tâm, bởi trong Sharkly, nhóm trạng thái Backlog là một trạng thái tạm giữ: tạo một Task hay gán một Agent khi Task còn nằm trong Backlog sẽ không khởi động thực thi. Chỉ khi chuyển Task ra khỏi Backlog sang một trạng thái sẵn sàng thì Agent được gán mới có thể bắt đầu chạy. Vì vậy, lập kế hoạch Sprint và giải phóng thực thi là hai đòn bẩy riêng biệt. Bạn có thể lập kế hoạch cho cả Sprint vào thứ Hai, với Agent đã được gán sẵn, và không có gì chạy cho đến khi từng Task được chủ động chuyển sang trạng thái sẵn sàng. Sau đó, các Automation theo thay đổi trạng thái có thể đảm nhận những bước chuyển mà bạn muốn chuẩn hóa.
Còn một quy tắc nữa bảo vệ lịch sử của bạn: chỉ những Task đã hoàn thành mới có thể được thêm vào một Sprint trước đó. Điều này cho phép chỉnh sửa dữ liệu lịch sử mà không bao giờ đưa công việc dang dở vào một giai đoạn đã khép lại.
Về ngày tháng, Sprint đã lên kế hoạch cho phép chỉnh sửa cả ngày bắt đầu lẫn ngày kết thúc, còn Sprint đang hoạt động thì ngày bắt đầu cố định nhưng ngày kết thúc có thể thay đổi.
Báo cáo Sprint cho bạn biết điều gì
Báo cáo Sprint bao gồm số lượng Task và, khi Space đã bật ước lượng, tổng điểm ước lượng theo sáu chỉ số: phạm vi, công việc đã bắt đầu, công việc đã hoàn thành, tỷ lệ hoàn thành, năng lực và lịch sử burnup.
Năng lực đáng để xem xét kỹ hơn vì đây chính là con số mà mọi cuộc thảo luận lập kế hoạch bám vào. Sharkly suy ra nó từ vận tốc của các Sprint hoàn thành gần đây khi có đủ dữ liệu lịch sử, nếu không thì dùng ước lượng dựa trên quy mô Space. Tài liệu khuyến nghị coi đây là dữ liệu đầu vào cho lập kế hoạch chứ không phải một bảo đảm, và với một đội kết hợp thì lưu ý đó không phải câu nói cho có: vận tốc đo trên một nhóm chỉ toàn người sẽ ngừng dự đoán được bất cứ điều gì ngay tuần bạn thêm ba Agent. Lịch sử burnup thường tiết lộ nhiều hơn. Nếu phạm vi hoàn thành vọt lên trong giai đoạn đầu rồi đường biểu diễn phẳng dần, nghĩa là Agent của bạn đã thực thi xong và reviewer phải dành phần còn lại của Sprint để đuổi theo.
Ràng buộc của đội kết hợp: lập kế hoạch cho review, không phải cho thực thi
Mọi nội dung trong phần này là lập luận về lập kế hoạch, không phải tính năng sản phẩm. Sharkly cung cấp cho bạn các cơ chế Sprint ở trên; việc bạn chất tải Sprint như thế nào là một quyết định mang tính phán đoán.
Hãy bắt đầu từ việc phân chia lao động. 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ả. Trong agentic coding, mọi thứ nằm giữa định hướng và nghiệm thu đều có thể giao phó, nhưng khâu nghiệm thu vẫn thuộc về con người. Một Agent hoàn thành Task chưa có nghĩa là Task đó đã xong theo bất kỳ nghĩa nào mà Sprint của bạn nên tính: diff, kết quả xác minh và những giới hạn đã biết đều quay về Task, và vẫn phải có một người đọc chúng rồi nghiệm thu, yêu cầu chỉnh sửa, hoặc quyết định merge.
Giờ hãy làm phép tính. Giả sử một đội năm người thêm Agent và thông lượng thực thi tăng gấp ba. Thông lượng review thì không tăng gấp ba; vẫn năm con người đó gánh nó, và mỗi thay đổi được nghiệm thu đều tiêu tốn sự tập trung thực sự. Nếu lập kế hoạch Sprint dựa trên năng lực thực thi thì phần dư ra không trở thành giá trị được bàn giao. Nó trở thành một hàng đợi công việc chưa review, và một thay đổi chưa review là hàng tồn kho, không phải tiến độ. Tệ hơn, một Sprint đang khép lại sẽ đẩy reviewer đến đúng cái lối tắt khiến phát triển dựa nhiều vào Agent trở nên nguy hiểm: nghiệm thu kết quả mà không đọc.
Vậy hãy đảo ngược câu hỏi lập kế hoạch. Thay vì hỏi đội có thể thực thi bao nhiêu việc trong hai tuần, hãy hỏi con người của bạn có thể nghiệm thu bao nhiêu công việc Agent đã hoàn thành trong hai tuần. Trên thực tế, điều này thay đổi bốn thói quen:
- Ước lượng chi phí review, không chỉ chi phí xây dựng. Một Task mà Agent thực thi dễ như trở bàn tay vẫn có thể tốn kém để nghiệm thu.
- Đặt trần cho lượng công việc đã hoàn thành nhưng chưa được nghiệm thu cùng lúc. Hãy xác định mỗi reviewer thực sự có thể nghiệm thu bao nhiêu Task mỗi Sprint rồi dừng lập kế hoạch khi vượt tổng đó. Đây là một thỏa thuận làm việc chứ không phải một cài đặt trong Sharkly, nhưng các chỉ số hoàn thành sẽ cho bạn biết khi bạn đã vượt ngưỡng.
- Giải phóng thực thi một cách có chủ đích. Vì Backlog tạm giữ thực thi, bạn có thể giãn cách thời điểm bắt đầu để công việc hoàn thành đến với nhịp độ mà reviewer hấp thụ được, thay vì ập đến cùng lúc vào ngày thứ hai.
- Đọc tỷ lệ hoàn thành như một con số về review. Khi đường burnup phẳng dần trong lúc Agent ngồi không, ràng buộc đã tự lộ diện. Đó là tín hiệu để thêm reviewer hoặc cam kết ít hơn, chứ không phải để thêm Agent.
Không điều nào ở trên làm Agent chậm lại. Nó chỉ giúp nhắm đúng hướng. Một Sprint được lập kế hoạch dựa trên thông lượng nghiệm thu sẽ bàn giao được mọi thứ đã cam kết, và không bao giờ buộc ai đó phê duyệt đoạn code mà họ không có thời gian đọc.
Lập kế hoạch cho một Sprint kết hợp, từng bước một
- Bật Sprint cho Space và chọn một chế độ. Nhịp làm việc đều đặn gợi ý dùng Automatic cadence; công việc gắn với bản phát hành gợi ý dùng Manual.
- Định hình phạm vi. Kéo các Task tiềm năng vào Sprint sắp tới thông qua lập kế hoạch Sprint hoặc trường Sprint. Giữ những công việc chưa cam kết ở trạng thái không thuộc Sprint nào.
- Gán cả hai nửa của mỗi Task. Sharkly tách biệt trách nhiệm của con người với phần thực thi của Agent: con người nằm trong tập người được gán, còn Agent hoặc Crew nằm ở ô thực thi duy nhất. Thay đổi cái này không bao giờ làm thay đổi cái kia.
- Viết Task theo cách Agent có thể hành động được. Phần mô tả cần nêu rõ mục tiêu, các ràng buộc và tiêu chí nghiệm thu mà một người mới hay một Agent cần để bắt tay vào việc.
- Giải phóng công việc theo nhịp review. Chuyển Task ra khỏi Backlog khi năng lực của reviewer được giải phóng.
- Kết thúc một cách có chủ đích. Ở chế độ Manual, hãy chọn nơi mọi Task dang dở sẽ đi. Ở Automatic cadence, hãy kiểm tra xem những gì đã được chuyển tiếp và tự hỏi liệu phạm vi có quá lớn hay khâu review có quá chậm.
Kỷ luật rộng hơn của cách vận hành công việc này được trình bày trong bài trụ cột của chúng tôi về quản lý dự án bằng AI agent; Sprint chỉ là lát cắt được giới hạn thời gian của hệ thống đó.
Nếu Sprint của bạn hiện đang nằm trong Jira
Bạn không cần xây dựng lại toàn bộ quy trình chỉ để thử những điều này. Tích hợp Jira của Sharkly có thể nhập dữ liệu Sprint từ Jira, và khi bật tính năng nhập Sprint, Space đích có thể được chuyển sang chế độ Jira Sprint, để nhịp mà đội bạn đang vận hành được giữ nguyên thay vì bắt đầu lại từ con số không. Bài hướng dẫn về gán một Jira ticket cho AI Agent trình bày ý tưởng tương tự ở cấp độ một ticket, và tài liệu Sharkly đi sâu vào cấu hình Sprint cũng như tích hợp Jira.
Hãy bắt đầu ở quy mô nhỏ hơn một cuộc di trú: bật Sprint trong một Space, lập kế hoạch cho một khung hai tuần dựa trên năng lực nghiệm thu thực tế của reviewer, rồi so sánh đường burnup với chu kỳ chỉ có con người gần nhất.
Câu hỏi thường gặp
Tôi có bắt buộc phải dùng Sprint trong Sharkly không?
Không. Sprint là tùy chọn và được bật riêng cho từng Space. Một Space ưu tiên luồng liên tục có thể để chúng tắt hoàn toàn, và ngay cả khi đã bật Sprint, một Task vẫn có thể không thuộc Sprint nào — đó là trạng thái bình thường của công việc trong Backlog.
Điều gì xảy ra với các Task dang dở khi Sprint kết thúc?
Ở Automatic cadence, Sharkly hoàn thành Sprint theo lịch và chuyển công việc dang dở sang Sprint kế tiếp. Ở chế độ Manual, luồng hoàn thành sẽ hỏi bạn muốn đưa các Task dang dở đi đâu: không thuộc Sprint nào, sang một Sprint đang hoạt động hoặc sắp tới khác, hay sang một Sprint mới được tạo.
Agent có thể tự động làm các Task trong Sprint không?
Một Agent hoặc Crew được đặt làm đơn vị thực thi của Task có thể chạy công việc đó, nhưng chỉ là thành viên của Sprint thì không bao giờ khởi động được gì. Backlog là một trạng thái tạm giữ, nên gán một Agent cho Task còn nằm trong Backlog sẽ không bắt đầu thực thi; chuyển Task sang trạng thái sẵn sàng mới có thể khởi chạy. Sự tách biệt này cho phép bạn lập kế hoạch trọn vẹn cho Sprint trước, rồi giải phóng thực thi theo nhịp mà reviewer của bạn hấp thụ được.
Sharkly tính năng lực Sprint như thế nào?
Năng lực được tính từ vận tốc của các Sprint hoàn thành gần đây khi có đủ dữ liệu lịch sử, nếu không thì dùng ước lượng dựa trên quy mô Space. Tài liệu khuyến nghị coi đó là dữ liệu đầu vào cho lập kế hoạch chứ không phải một bảo đảm — điều này càng quan trọng gấp đôi với các đội kết hợp, nơi vận tốc đo toàn bộ hệ thống chứ không đo nút thắt cổ chai ở khâu review bên trong nó.
Tôi có thể thêm Task vào một Sprint đã kết thúc không?
Chỉ những Task đã hoàn thành mới có thể được thêm vào một Sprint trước đó. Điều này hỗ trợ việc chỉnh sửa dữ liệu lịch sử, chẳng hạn ghi nhận công việc đã xong trong khung thời gian nhưng chưa từng được lưu lại, mà không bao giờ đưa công việc dang dở vào một giai đoạn đã khép lại.
