Sprint trong phát triển di động: bản chất, thời lượng và lập kế hoạch

Sprint trong phát triển là gì?

Sprint là một khung thời gian (timebox) có thời lượng cố định, khi kết thúc nhóm sẽ bàn giao một phần tăng trưởng sản phẩm sẵn sàng sử dụng. Khái niệm sprint là nền tảng của Scrum, nhưng cũng được sử dụng trong các khung Agile khác. Trong phát triển di động, phần tăng trưởng là một bản dựng ứng dụng có thể cài đặt trên thiết bị, kiểm thử và trình bày cho các bên liên quan. Sprint không thể kéo dài — nếu công việc chưa hoàn thành, chúng được chuyển sang sprint tiếp theo.

Đặc điểm chính của sprint là thời lượng cố định. Nhóm không thay đổi mục tiêu sprint sau khi phê duyệt. Điều này mang lại khả năng dự đoán: các bên liên quan biết khi nào họ sẽ nhận được kết quả. Trong sprint, nhóm tự quyết định cách phân bổ công việc. Scrum Master bảo vệ nhóm khỏi sự can thiệp từ bên ngoài — không có công việc mới nào được thêm vào sprint hiện tại. Theo Scrum Guide 2025, đây là cách duy nhất để duy trì nhịp độ phát triển bền vững.

Một sprint bao gồm bốn sự kiện bắt buộc: Sprint Planning, Daily Scrum (đồng bộ hàng ngày), Sprint Review (trình diễn kết quả), Sprint Retrospective (phân tích quy trình). Giữa chúng là công việc chính: triển khai tác vụ, kiểm thử, đánh giá mã. Thời lượng của mỗi sự kiện tỷ lệ thuận với độ dài sprint: với sprint 2 tuần, Planning 4 giờ, Review 2 giờ, Retro 1,5 giờ, Daily 15 phút. Tổng cộng các nghi thức mất khoảng 8 giờ mỗi sprint — 10% thời gian làm việc của nhóm.

Nghi thức Scrum của sprint

Nghi thức Scrum (buổi lễ/sự kiện) là các cuộc họp nhóm có cấu trúc trong sprint. Sprint Planning khi bắt đầu, Daily Scrum mỗi ngày, Sprint Review và Retrospective khi kết thúc. Tất cả các sự kiện đều có khung thời gian (timebox). Scrum Master đảm bảo tuân thủ khung thời gian và sự tập trung. Toàn bộ nhóm Scrum tham gia mỗi nghi thức: Product Owner, Scrum Master, các nhà phát triển. Ngoại lệ là Daily Scrum (chỉ nhà phát triển tham gia, PO và SM là tùy chọn).

Mối liên hệ giữa các nghi thức và giai đoạn sprint: Planning định hướng (làm gì và làm thế nào), Daily đồng bộ (ai đang làm gì, có rào cản gì), Review cho thấy kết quả (đã làm được gì, chưa làm được gì), Retrospective cải thiện quy trình (làm thế nào để sprint tiếp theo tốt hơn). Bỏ qua Retrospective là lỗi phổ biến nhất của nhóm: khi thời hạn gấp rút, Retro là thứ đầu tiên bị hy sinh. Điều này dẫn đến sự trì trệ của quy trình và lặp lại những sai lầm tương tự. Nghiên cứu của Scrum.org (2025) cho thấy các nhóm tổ chức Retro mỗi 2 tuần cải thiện vận tốc nhanh hơn 35%.

Sprint Planning: lập kế hoạch vòng lặp

Sprint Planning là cuộc họp nhóm vào đầu sprint để xác định sẽ làm gì và làm thế nào. Product Owner trình bày các tác vụ ưu tiên từ Product Backlog. Nhóm ước tính năng lực (thời gian khả dụng tính đến kỳ nghỉ, cuộc họp, nợ kỹ thuật) và chọn các tác vụ có thể hoàn thành trong sprint. Kết quả của Planning là Sprint Goal (mục tiêu sprint) và Sprint Backlog (danh sách tác vụ). Sprint Goal được xây dựng như một câu ngắn: “Triển khai màn hình đặt hàng và tích hợp thanh toán qua SBP.”

Vận tốc (Velocity) là tốc độ của nhóm được đo bằng điểm câu chuyện (story point) mỗi sprint. Trung bình của 3-5 sprint gần nhất. Theo Scrum.org (2025), một nhóm gồm 5 nhà phát triển di động (3 Android + 2 iOS) có vận tốc 25-40 SP cho sprint 2 tuần. Planning sử dụng vận tốc làm giới hạn trên — họ nhận ít hơn 10-15% để dự phòng cho các tác vụ bất ngờ (đánh giá mã, sự cố, hỗ trợ nhóm khác). Năng lực so với Vận tốc: năng lực là “giờ-người”, vận tốc là “điểm câu chuyện”. Năng lực tính đến kỳ nghỉ, nghỉ ốm, cuộc họp. Tỷ lệ mất điển hình là 25-30% thời gian làm việc dành cho các hoạt động không phải mã.

Planning được chia thành hai phần: “làm gì” (PO mô tả tác vụ, nhóm làm rõ) — 2 giờ, và “làm thế nào” (nhóm phân rã và ước tính) — 2 giờ. Đối với dự án di động, trong phần “làm thế nào” thảo luận: tương thích với phiên bản Android/iOS, nhu cầu về feature flag, tác động đến kích thước APK/IPA, quyền mới. Kỹ thuật Planning Poker được sử dụng để ước tính: mỗi nhà phát triển đưa ra ước tính bằng điểm câu chuyện (1, 2, 3, 5, 8, 13). Chênh lệch hơn 2 đơn vị sẽ kích hoạt thảo luận về lý do. Điều này phát hiện rủi ro tiềm ẩn ở giai đoạn lập kế hoạch, không phải giữa sprint.

Thực thi sprint: Daily Standup và theo dõi

Daily Scrum (Standup) là cuộc họp 15 phút hàng ngày để đồng bộ nhóm. Mỗi người tham gia trả lời ba câu hỏi: “Hôm qua đã làm được gì?”, “Hôm nay dự định làm gì?”, “Có rào cản gì không?” Daily không phải báo cáo trạng thái cho quản lý mà là công cụ tự tổ chức của nhóm. Nếu trong Daily phát hiện hai nhà phát triển đang làm cùng một tác vụ — đó là tín hiệu cần tổ chức lại. Quan trọng: Daily không giải quyết vấn đề mà xác định chúng — để giải quyết, một cuộc họp riêng được triệu tập sau Daily.

Scrum Board (bảng sprint) là hình ảnh trực quan của Sprint Backlog. Cột: To Do / In Progress / In Review / Done. Mỗi tác vụ di chuyển trên bảng. Biểu đồ Burndown là đồ thị công việc còn lại theo ngày sprint. Burndown lý tưởng là đường thẳng từ tổng SP đến 0. Burndown thực tế là đồ thị bậc thang phản ánh việc hoàn thành tác vụ. Burndown giảm (dưới đường lý tưởng) có nghĩa là chúng ta đang chậm tiến độ. Tín hiệu vấn đề: nếu giữa sprint mà hoàn thành dưới 30% tác vụ — cần điều chỉnh. Có thể rủi ro chưa được xem xét hoặc tác vụ bị đánh giá quá cao.

Đối với phát triển di động, việc theo dõi sprint bị ảnh hưởng bởi các yếu tố đặc thù: thời gian xây dựng (bản dựng Android trong CI có thể mất 30+ phút), chờ kiểm duyệt App Store / Google Play (nếu cần phát hành bản dựng cho người thử qua TestFlight), tương thích với nhiều thiết bị khác nhau (kiểm thử trên 10+ mẫu mất thời gian). Mẹo: dành 1 ngày đệm vào cuối sprint để kiểm thử cuối cùng và tạo bản dựng phát hành. Điều này giảm 40% rủi ro sprint không hoàn thành theo Mind the Product (2025).

Sprint Review và Retrospective

Sprint Review là buổi trình diễn phần tăng trưởng cho các bên liên quan. Nhóm trình bày bản dựng ứng dụng hoạt động, không phải slide. Thời lượng là 2 giờ cho sprint 2 tuần. Product Owner kiểm tra việc tuân thủ Acceptance Criteria. Các bên liên quan cung cấp phản hồi có thể ảnh hưởng đến Product Backlog. Review không phải báo cáo mà là đối thoại: các bên liên quan có thể đặt câu hỏi và đề xuất thay đổi. Nguyên tắc chính: Sprint Review nói về sản phẩm, không phải quy trình. Trình bày những gì đã đạt được, không phải cách thực hiện.

Sprint Retrospective là cuộc họp nội bộ của nhóm để phân tích sprint đã qua. Định dạng: Start Doing (bắt đầu làm gì), Stop Doing (ngừng làm gì), Continue Doing (tiếp tục làm gì). Thời lượng là 1,5 giờ cho sprint 2 tuần. Retrospective là không gian an toàn để thảo luận vấn đề. Nguyên tắc: trong Retro không thảo luận chi tiết kỹ thuật (có cuộc họp kỹ thuật cho việc đó). Chỉ quy trình, giao tiếp, công cụ, văn hóa. Scrum Master điều phối cuộc họp và đảm bảo mỗi người tham gia đều phát biểu.

Kết quả của Retrospective là 1-3 cải tiến cho sprint tiếp theo. Nếu nhóm xác định vấn đề “Đánh giá mã mất quá nhiều thời gian” — action item: “Đặt SLA cho đánh giá — 4 giờ. Nếu đánh giá không được thực hiện đúng hạn — nhà phát triển nhắc nhở trong Slack.” Action Items phải cụ thể, đo lường được và giao cho một người cụ thể. Theo Atlassian (2025), các nhóm thực hiện action items của Retro cải thiện vận tốc 15-25% trong 3-4 sprint. Những nhóm không thực hiện sẽ bị trì trệ.

Cách chọn thời lượng sprint

2 tuần là tiêu chuẩn cho phát triển di động. Sự cân bằng tối ưu giữa khả năng dự đoán và linh hoạt. Đủ thời gian để: lập kế hoạch, triển khai 3-5 tính năng trung bình, kiểm thử, trình bày kết quả. 1 tuần dành cho các nhóm có độ chín quy trình cao và CI/CD. Yêu cầu quyết định nhanh, tối thiểu quan liêu. Phù hợp cho startup giai đoạn đầu cần thử nghiệm nhanh. Nhược điểm: chi phí nghi thức cao (Planning + Review + Retro mỗi tuần = 7,5 giờ).

3-4 tuần dành cho các dự án phức tạp có tích hợp phần cứng (wearables, IoT, thiết bị BLE), kiểm duyệt cửa hàng lâu hoặc di chuyển lớn (ví dụ: chuyển từ RxJava sang Coroutines). Sprint dài cho nhiều thời gian kiểm thử hơn nhưng tăng rủi ro “hiệu ứng thác nước” — nhóm mất tính linh hoạt của Agile. Khuyến nghị của Scrum Guide: không vượt quá 1 tháng. Nếu sprint dài hơn, sẽ có quá nhiều ngữ cảnh tại Review và các bên liên quan không thể đưa ra phản hồi chất lượng.

Các vấn đề điển hình của sprint

Vấn đề 1: Scope Creep. Giữa sprint, Product Owner thêm một tác vụ mới “cấp bách và quan trọng”. Nhóm đồng ý — và sprint thất bại. Giải pháp: Sprint Goal là một hợp đồng. Bất kỳ thay đổi nào cũng yêu cầu xem xét lại Sprint Goal, điều này chỉ khả thi trong trường hợp khẩn cấp. Tác vụ mới được chuyển vào Product Backlog và sprint tiếp theo. Nếu tác vụ thực sự quan trọng — Sprint Goal cũ bị hủy, sprint được lập kế hoạch lại, nhưng đây là ngoại lệ, không phải thông lệ. Tần suất scope creep hơn một lần trong 3 sprint là dấu hiệu của Product Owner yếu.

Vấn đề 2: Tác vụ chưa hoàn thành. Cuối sprint, 50% tác vụ ở trạng thái In Progress, 20% In Review, chỉ 30% Done. Nguyên nhân: đánh giá quá cao năng lực, đánh giá thấp độ phức tạp, lỗi không kế hoạch. Giải pháp: phân tích nguyên nhân tại Retro. Nếu bạn không thể theo kịp một cách có hệ thống — đừng tăng số lượng tác vụ trong Planning, hãy giảm chúng. Các nhóm nhận ít hơn 20% tác vụ cho thấy tỷ lệ hoàn thành cao hơn (80%+ so với 50-60%). Danh sách kiểm tra cho Planning: với mỗi tác vụ, kiểm tra Acceptance Criteria, Definition of Ready và sự phụ thuộc với các tác vụ khác.

Vấn đề 3: Retro hình thức. Nhóm tổ chức Retro chỉ để đối phó — 15 phút, cụm từ chung chung, không có action item. Giải pháp: thay đổi định dạng mỗi Retro. Phương pháp: Sailboat (cái gì làm chậm, cái gì tăng tốc), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Giao action item với thời hạn và người chịu trách nhiệm. Đầu Retro tiếp theo, kiểm tra việc hoàn thành các action item trước đó. Theo Atlassian (2025), các nhóm sử dụng định dạng Retro khác nhau tạo ra nhiều hơn 50% thông tin chi tiết hữu ích.