Thuật ngữ
Sprint là gì? Vòng đời một sprint 2 tuần từ Planning đến Retro
Sprint là khung thời gian cố định 1–4 tuần trong Scrum, đội cam kết một tập việc để ra phần sản phẩm dùng được. Vòng đời sprint, độ dài nên chọn, ví dụ, lỗi hay gặp.
Khoảng 6 phút đọc
Trả lời ngắn
Định nghĩaSprint là khung thời gian cố định (time-box) từ 1 đến 4 tuần trong Scrum, trong đó đội cam kết hoàn thành một tập việc đã chọn để tạo ra một phần sản phẩm dùng được. Sprint có mục tiêu, ngày bắt đầu và ngày kết thúc. Hết giờ là kết thúc, dù việc chưa xong; không kéo dài sprint để làm nốt.
Chữ “sprint” (chạy nước rút) hay gây hiểu nhầm là giai đoạn làm gấp. Thực tế ngược lại: sprint là nhịp đều, lặp lại, sprint nào cũng dài như nhau, để đội làm bền và dự báo được. Một số phương pháp gọi cùng khái niệm này là iteration (vòng lặp).
Vì sao phải đóng khung thời gian
Không có sprint, dự án phần mềm hay rơi vào trạng thái “sắp xong” kéo dài hàng tháng: việc nào cũng làm được 80%, không việc nào bàn giao được, và yêu cầu mới liên tục chen vào. Sprint chữa điều đó bằng bốn cách.
Bốn thứ sprint đem lại
- Điểm dừng bắt buộc. Cứ hai tuần đội phải có thứ cho người dùng xem và phải ngồi lại nhìn cách làm. Không ai trốn được buổi Review.
- Việc phải nhỏ. Việc không xong trong một sprint thì phải tách. Điều này ép đội chia nhỏ, và việc nhỏ thì ước lượng đúng hơn, kẹt ít hơn.
- Phạm vi được bảo vệ. Trong sprint, việc đã chốt không bị thay đổi tùy tiện. Yêu cầu mới chờ sprint sau, trừ khi khẩn thật sự và phải đổi việc khác ra.
- Số đo so sánh được. Sprint dài như nhau nên số điểm xong mỗi sprint (velocity) so sánh được, từ đó dự báo ngày hoàn thành cả dự án.
Vòng đời một sprint
| Chặng | Khi nào | Làm gì | Đầu ra |
|---|---|---|---|
| Chuẩn bị | Tuần trước sprint | Backlog refinement: làm rõ mô tả, tiêu chí chấp nhận, chấm điểm, sắp ưu tiên các việc sắp tới. | Khoảng 1,5 lần velocity việc ở đầu backlog đã sẵn sàng |
| Lập kế hoạch | Sáng ngày đầu, tối đa 2 giờ | Thống nhất mục tiêu sprint; chọn việc từ backlog theo velocity; giao người, tách task con. | Sprint Backlog và mục tiêu sprint |
| Làm | Mỗi ngày | Daily 15 phút trước bảng; kéo thẻ khi bắt đầu và kết thúc; nhìn burndown; gỡ vướng trong ngày. | Việc lần lượt đạt Done |
| Kết thúc | Ngày cuối | Review: cho người dùng xem phần đã xong, ghi phản hồi vào backlog. Retro: đội chọn 1–2 việc sẽ làm khác. Hoàn thành sprint, chuyển việc dở. | Increment, phản hồi, hành động cải tiến, velocity của sprint |
Bốn buổi họp của sprint, thời lượng và cách chủ trì có trong chương Sprint và các sự kiện; lịch từng ngày cho đội mới ở Quy trình sprint 2 tuần. Nếu bạn chưa rõ khung lớn hơn, đọc Scrum là gì? trước.
Ba thứ mỗi sprint phải có
Thiếu một trong ba là sprint chỉ còn cái tên
- Mục tiêu sprint (Sprint Goal) — một câu nói sprint này làm ra cái gì cho ai, ví dụ “sinh viên đăng nhập và xem được danh sách học phần”. Không phải danh sách việc. Khi giữa sprint phải bỏ bớt việc, mục tiêu là thứ quyết định bỏ việc nào.
- Sprint Backlog — các việc đội đã chọn để đạt mục tiêu, có người làm, có điểm, có hạn. Chốt ở Planning; thêm việc thì phải bớt việc tương đương.
- Increment đạt “Xong” — phần sản phẩm chạy được cuối sprint, đạt định nghĩa Done chung của đội (đã merge, đã test, đã lên staging…). Việc làm 90% không tính vào increment.
Sprint nên dài bao lâu
| Độ dài | Hợp với | Được | Mất |
|---|---|---|---|
| 1 tuần | Yêu cầu đổi rất nhanh; sản phẩm mới, cần phản hồi liên tục | Sửa hướng cực nhanh; việc buộc phải rất nhỏ | Họp chiếm tỉ lệ lớn; khó làm việc cần tích hợp |
| 2 tuần | Phần lớn đội 5–9 người làm sản phẩm hoặc dự án cho khách | Đủ dài để xong việc có ý nghĩa, đủ ngắn để phản hồi kịp; velocity ổn định sau 3 sprint | Ít; đây là lựa chọn mặc định của hầu hết đội |
| 3–4 tuần | Việc cần nhiều tích hợp, kiểm thử dài; khách chỉ gặp được mỗi tháng | Ít họp hơn; xong được việc lớn | Phát hiện sai muộn; dễ trượt thành “sắp xong”; cần 3 tháng mới có 3 số velocity |
Chọn rồi thì giữ cố định
Ví dụ: sprint 3 của đội 6 người
Ví dụ
Đội 6 người làm cổng đăng ký học phần chạy sprint 2 tuần, thứ hai đến thứ sáu tuần sau. Sprint 3 tên “Đăng ký học phần”, mục tiêu “sinh viên đăng ký được học phần và nhận thông báo kết quả”, 9 việc, 38 điểm, chọn theo velocity 35 của hai sprint trước cộng chút dư vì sprint này không ai nghỉ.
Ngày 4: phòng Đào tạo báo lỗi in bảng điểm, mức Cao, cần trong tuần. Điều phối không nhét thêm: đưa việc lỗi (5 điểm) vào sprint, đồng thời kéo việc “gửi email nhắc lịch” (5 điểm) về backlog, báo PM. Mục tiêu sprint không đổi vì email nhắc lịch không nằm trong mục tiêu. Ngày 8: burndown còn 14 điểm, lý tưởng còn 8; daily phát hiện việc “thanh toán học phí” chờ cổng thanh toán của trường, đội quyết định làm phần giao diện trước, phần nối cổng sang sprint 4.
Ngày 10: Review với hai cán bộ Đào tạo trên môi trường staging, 7 việc xong, 31 điểm. Hai việc dở (7 điểm) chuyển sang sprint 4 khi hoàn thành sprint. Velocity ghi nhận 31. Retro chốt một hành động: hỏi lịch bàn giao của các hệ thống bên ngoài ngay ở refinement, không đợi đến Planning.
Sprint khác phát hành, giai đoạn và Kanban ở đâu
Sprint không phải phát hành (release). Đội có thể phát hành nhiều lần trong một sprint, hoặc gom ba sprint mới phát hành một bản; sprint là nhịp làm việc, phát hành là quyết định kinh doanh. Sprint không phải giai đoạn dự án. Giai đoạn “phân tích”, “thiết kế”, “lập trình” chia theo loại việc; sprint chia theo thời gian và mỗi sprint có đủ mọi loại việc để ra một phần chạy được. Đội đặt tên “Sprint 1: phân tích, Sprint 2: thiết kế” thực ra đang làm thác nước có gắn nhãn Scrum.
Kanban không có sprint. Việc chảy liên tục qua bảng, đo bằng thời gian hoàn thành từng việc. Đội vận hành, hỗ trợ, việc đến bất chợt, thường hợp Kanban hơn; xem Kanban là gì?. Đội xây sản phẩm theo từng phần thì sprint cho nhịp và điểm dừng mà Kanban không ép được.
Năm lỗi hay gặp
Đội mới chạy sprint hay mắc
- Kéo dài sprint cho xong việc. Làm một lần là sprint mất tính cố định, velocity vô nghĩa. Việc dở sang sprint sau, ghi nhận ở Retro vì sao dở.
- Thêm việc giữa sprint mà không bớt. Burndown đi lên, đội mất niềm tin vào cam kết. Việc khẩn thì nhận, nhưng đổi việc tương đương ra và người quản lý phải đồng ý.
- Mục tiêu sprint là “làm hết danh sách”. Khi phải bỏ bớt, không biết bỏ gì. Mục tiêu phải nói được kết quả cho người dùng.
- Bỏ Review vì “chưa có gì để demo”. Đó chính là tín hiệu việc quá to hoặc chưa đạt Done; Review vẫn họp, nói thật, và Retro bàn cách chia nhỏ.
- Sprint 0 kéo dài mãi. Sprint chuẩn bị hạ tầng, thiết kế kéo hai tháng không có phần chạy được. Ngay sprint đầu nên có một luồng nhỏ đầu cuối, dù xấu.
Danh sách đầy đủ hơn ở Lỗi thường gặp và cách tránh; cách đọc burndown khi sprint lệch kế hoạch ở Burndown chart là gì?.
Chạy sprint trên Pentara
Sprint có ba trạng thái: Kế hoạch → Đang chạy → Đã hoàn thành, và mỗi dự án chỉ có một sprint đang chạy. Quản lý hoặc Điều phối dự án tạo sprint với tên, mục tiêu và ngày, kéo việc từ backlog vào, rồi bấm Bắt đầu; hộp thoại tự điền ngày kết thúc bằng ngày bắt đầu cộng 14 ngày, sửa được. Tab Board mặc định lọc theo sprint đang chạy, nên Daily chỉ cần mở Board.
Trang Chi tiết sprint hiện số việc, điểm đã xong trên cam kết, tiến độ, thời gian còn lại, biểu đồ Burndown và Velocity. Khi bấm Hoàn thành sprint, Pentara hỏi chuyển việc chưa xong về backlog hay sang sprint kế hoạch tiếp theo, rồi chốt số điểm cam kết và hoàn thành để tính velocity; sprint đã hoàn thành không sửa được nữa. Thành viên tạo được việc mới trong sprint đang chạy, còn chuyển việc có sẵn vào hoặc ra là quyền của Quản lý và Điều phối dự án, để phạm vi sprint được kiểm soát. Muốn chạy thử một sprint trọn vẹn: đăng ký gói Miễn phí rồi làm theo Bắt đầu nhanh.
Hỏi đáp nhanh
- Việc chưa xong khi hết sprint thì làm sao?
- Sprint vẫn kết thúc đúng ngày. Việc dở chuyển về backlog hoặc sang sprint sau, không tính vào velocity sprint này dù đã làm 90%. Ở Retro, đội hỏi vì sao dở: việc quá to, bị chặn, hay cam kết quá sức, rồi sửa ở sprint kế. Không kéo dài sprint để làm nốt.
- Có được thêm việc vào sprint đang chạy không?
- Có, nhưng phải đổi việc tương đương ra và người quản lý dự án đồng ý, để tổng cam kết không đổi. Lỗi khẩn thật sự thì nhận ngay; việc “tiện thể làm luôn” thì chờ sprint sau. Trên Pentara, thành viên tạo được việc mới trong sprint, còn chuyển việc có sẵn vào hoặc ra là quyền của Quản lý và Điều phối dự án.
- Sprint và phát hành (release) có phải là một?
- Không. Sprint là nhịp làm việc cố định; phát hành là quyết định đưa bản mới đến người dùng. Đội có thể phát hành nhiều lần trong một sprint hoặc gom vài sprint mới phát hành. Chỉ cần cuối mỗi sprint có phần chạy được, đã đạt định nghĩa Done, sẵn sàng phát hành khi cần.
- Mục tiêu sprint (Sprint Goal) có bắt buộc không?
- Nên có, và là một câu nói kết quả cho người dùng, ví dụ “sinh viên đăng ký được học phần”, không phải danh sách việc. Mục tiêu giúp đội quyết định bỏ việc nào khi phải bỏ bớt giữa sprint, và cho khách biết sprint này họ sẽ thấy gì ở buổi Review. Pentara có trường mục tiêu khi tạo sprint.