Daily Standup — khái niệm, quy tắc họp hàng ngày và lợi ích

Daily Standup là gì?

Daily Standup — một cuộc họp ngắn của nhóm Scrum diễn ra cùng thời gian và địa điểm mỗi ngày làm việc. Thời gian giới hạn — 15 phút. Nó được biết đến với nhiều tên gọi khác nhau: Daily Scrum (trong Hướng dẫn Scrum), đồng bộ hóa buổi sáng, morning circle, daily. Mục tiêu là đồng bộ hóa nhóm, xác định rào cản và điều chỉnh kế hoạch trong ngày. Daily không phải là báo cáo cho quản lý mà là công cụ tự tổ chức của nhóm. Nhóm quyết định cấu trúc cuộc họp, không phải quản lý.

Nguồn gốc của thuật ngữ “standup“ xuất phát từ thực tế là đứng trong suốt cuộc họp: các thành viên tập trung quanh bảng và không ngồi xuống. Điều này tạo cảm giác tạm thời — không ai muốn đứng quá 15 phút. Standup trực tiếp vẫn được 60% nhóm sử dụng (theo Scrum.org 2025), số còn lại đã chuyển sang hình thức từ xa qua Zoom, Slack Huddle hoặc Teams. Ở hình thức từ xa, điều quan trọng là duy trì kỷ luật: bật camera, không đa nhiệm, chuẩn bị trước câu trả lời.

Hướng dẫn Scrum 2025 định nghĩa Daily Scrum là sự kiện dành cho Developers (nhà phát triển). Product Owner và Scrum Master có thể tham dự nhưng không bắt buộc. Nếu PO hoặc SM tham dự, họ không điều hành cuộc họp. Nhóm tự chọn cấu trúc của mình: ba câu hỏi cổ điển hoặc board walk. Điểm mấu chốt: daily là để kiểm tra tiến độ hướng tới Sprint Goal, không phải trạng thái của từng tác vụ. Nếu cuộc họp biến thành liệt kê các tác vụ trên bảng, nhóm đã mất tập trung vào Sprint Goal.

Ba câu hỏi của Daily Standup

Câu hỏi 1: “Hôm qua tôi đã làm gì để đạt được Sprint Goal?“ — tóm tắt ngắn gọn các tác vụ đã hoàn thành. Không phải “tôi đã làm việc trên APP-123“ mà là “đã hoàn thành màn hình đăng nhập, PR đã gửi đi review“. Cụm từ “để đạt được Sprint Goal“ có chủ đích: nó kết nối công việc hàng ngày với mục tiêu tổng thể của sprint. Nếu nhà phát triển không thấy mối liên hệ giữa tác vụ của mình và Sprint Goal, đó là tín hiệu cho thấy tác vụ đó có thể không cần thiết trong sprint hiện tại. Trong phát triển di động, kết quả hôm qua không chỉ bao gồm mã mà còn có kiểm thử, tài liệu và cấu hình CI/CD.

Câu hỏi 2: “Hôm nay tôi dự định làm gì để đạt được Sprint Goal?“ — kế hoạch cho ngày hiện tại. Không quá 2-3 mục. Một nhà phát triển có thể nói: “Hôm nay tôi sẽ hoàn thành ViewModel cho màn hình hồ sơ, viết kiểm thử đơn vị và chạy build trên thiết bị thật.“ Nếu kế hoạch trùng với “hôm qua“, đó là tín hiệu tác vụ quá lớn và cần được phân rã. Quy tắc hai ngày: nếu một tác vụ không hoàn thành trong 2 ngày làm việc, nó nên được chia thành các tác vụ con, nếu không nó sẽ bị đình trệ trong In Progress hàng tuần.

Câu hỏi 3: “Những rào cản nào đang cản trở tiến độ của tôi?“ — câu hỏi quan trọng nhất. Rào cản là điều mà nhà phát triển không thể tự giải quyết: chờ review (nếu SLA review đã hết hạn), trình giả lập không hoạt động, API chưa sẵn sàng, cần quyền truy cập kho lưu trữ. Quan trọng: rào cản nên được nêu ra nhưng không giải quyết trong daily. Sau cuộc họp, nhà phát triển và Scrum Master / quản lý sắp xếp giải quyết rào cản. Theo Scrum.org (2025), 70% rào cản của nhóm di động liên quan đến: chờ review (30%), thiếu thiết bị kiểm thử (20%) và phụ thuộc vào backend (20%).

Cách tổ chức standup đúng cách

Thời gian và địa điểm. Daily diễn ra cùng một thời điểm mỗi ngày — thường là đầu giờ làm việc (9:00-10:00). Đối với nhóm phân tán, chọn thời gian phù hợp cho tất cả các múi giờ. Thời lượng — nghiêm ngặt 15 phút. Bộ đếm thời gian là bắt buộc. Nếu nhóm không kịp thời gian, vấn đề không phải ở daily mà ở quy trình: hoặc có quá nhiều người tham gia, hoặc các tác vụ đang được thảo luận thay vì chỉ được nêu tên. Quy tắc ping-pong: mỗi người tham gia nói không quá 60 giây. Sau khi trả lời, chuyển lượt cho người tiếp theo.

Hình thức Board Walk. Một lựa chọn thay thế cho ba câu hỏi: nhóm lần lượt di chuyển các tác vụ trên bảng Scrum và nhận xét về các thay đổi. Nhà phát triển lấy tác vụ của mình từ To Do, chuyển nó sang In Progress và nói: “Tôi nhận APP-123 — màn hình đặt hàng, thêm trường mã khuyến mãi.“ Board Walk cung cấp sự hiểu biết trực quan về tiến độ và tiết lộ các tác vụ “bị lãng quên“ — những tác vụ không di chuyển trong 3+ ngày. Board Walk được ưa chuộng cho các nhóm phân tán sử dụng Jira/Linear — mọi người đều thấy bảng thay vì nghe độc thoại.

Đối với nhóm từ xa: camera phải bật — theo Microsoft Research (2025), bật camera giúp tăng mức độ tương tác lên 40%. Sử dụng màn hình chia sẻ với bảng tác vụ (Jira, Linear, Miro). Viết rào cản vào chat — điều này tạo ra bản ghi bằng văn bản. Khuyến khích biểu tượng cảm xúc phản ứng (ngoại trừ khi có hướng dẫn của người dùng — không sử dụng biểu tượng cảm xúc) — like tin nhắn của đồng nghiệp. Sau daily, dành 2-3 phút cho parking lot: các chủ đề cần thảo luận riêng được ghi vào danh sách cuộc họp theo dõi. Kỹ năng chính của Scrum Master: dừng thảo luận trong daily và chuyển nó sang parking lot.

Những lỗi điển hình trong cuộc họp

Lỗi 1: báo cáo trạng thái cho quản lý. Các nhà phát triển lần lượt đọc những gì được viết trong Jira, quản lý đặt câu hỏi làm rõ, cuộc họp kéo dài 45 phút. Giải pháp: nhắc nhở rằng daily là dành cho nhóm, không phải cho quản lý. Quản lý có thể xem trạng thái trên bảng. Nếu quản lý đặt câu hỏi, hãy chuyển chúng sang các cuộc họp 1:1. Một nhóm biến daily thành báo cáo trạng thái mất 2-3 giờ mỗi tuần trên tất cả người tham gia. Với 8 nhà phát triển, đó là 16-24 giờ-công mỗi tháng — mất một sprint hoàn chỉnh trong một năm.

Lỗi 2: giải quyết vấn đề tại chỗ. Một nhà phát triển nói “Tôi có lỗi với gRPC — dự án không build được“ và toàn bộ nhóm dành 20 phút thảo luận giải pháp. Giải pháp: ghi lại rào cản vào parking lot và tiếp tục daily. Sau cuộc họp, tập hợp những người liên quan (nhà phát triển + người có thể giúp) để thảo luận 10 phút. Theo Basecamp (Shape Up), chỉ 20% vấn đề phát hiện trong daily cần thảo luận toàn nhóm. Phần còn lại do hai nhà phát triển giải quyết trong 10 phút.

Lỗi 3: đi trễ và vắng mặt. Ai đó đến sau 5 phút kể từ khi bắt đầu và phải lặp lại mọi thứ. Giải pháp: thiết lập quy tắc “daily bắt đầu đúng giờ, người đến trễ không tham gia“ hoặc “người đến trễ phải nộp phạt“ (cà phê cho nhóm). Nghiêm ngặt hơn: daily diễn ra vào giờ cố định; nếu ai đó thường xuyên đến trễ, đó là vấn đề kỷ luật được giải quyết trong 1:1. Daily là sự đồng bộ hóa trong ngày. Nếu nhà phát triển bỏ lỡ, họ không được đồng bộ và có nguy cơ làm sai công việc cho nhóm.

Lỗi 4: quá nhiều người tham gia. Nhóm 15+ người, mỗi người nói một phút — tổng cộng 20+ phút. Giải pháp: chia nhóm thành các nhóm nhỏ theo tính năng/mô-đun. Mỗi nhóm nhỏ tổ chức daily riêng (5-7 người). Một đại diện từ mỗi nhóm nhỏ có thể tham dự standup liên nhóm (nếu cần đồng bộ hóa giữa các nhóm). Lựa chọn thay thế: standup không đồng bộ qua Slack/GeekBot, nơi mọi người viết những gì họ đã làm / dự định / rào cản.

Standup không đồng bộ: các lựa chọn thay thế

Standup không đồng bộ — hình thức mà người tham gia viết câu trả lời vào chat (Slack, Telegram, Teams) hoặc qua bot chuyên dụng (GeekBot, Standuply, Status Hero) thay vì họp trực tiếp. Phù hợp cho nhóm phân tán với chênh lệch múi giờ 3+ giờ. Mỗi người tham gia trả lời ba câu hỏi giống nhau trước một thời điểm nhất định (ví dụ: trước 11:00). Bot thu thập câu trả lời và đăng bản tóm tắt trong kênh chung. Ưu điểm: linh hoạt, có ghi chép bằng văn bản, không có vấn đề đi trễ.

Nhược điểm của hình thức không đồng bộ: không có tương tác trực tiếp — mất tín hiệu phi ngôn ngữ, khó xác định rào cản hơn (nhà phát triển có thể không viết về vấn đề). Một rào cản được viết trong chat có thể không được chú ý cho đến cuối ngày. Theo GitLab (2025), 40% nhóm chuyển sang standup không đồng bộ đã quay lại hình thức nói trong vòng 3 tháng. Khuyến nghị: sử dụng kết hợp — 3 ngày standup nói (T2, T4, T6), 2 ngày không đồng bộ (T3, T5). Hoặc: standup nói 1-2 lần mỗi tuần, không đồng bộ vào những ngày còn lại.

Công cụ cho standup không đồng bộ: GeekBot (Slack) — đặt ba câu hỏi và đăng bản tóm tắt; Standuply — tích hợp với Jira và cung cấp theo dõi tự động; Status Hero — thu thập trạng thái và tạo báo cáo hàng tuần cho quản lý. Việc chọn công cụ phụ thuộc vào văn hóa nhóm: ở startup, bot Slack là đủ; trong môi trường doanh nghiệp, có thể cần Standuply với tích hợp quy trình doanh nghiệp. Quy tắc quan trọng: bất kể hình thức nào, câu trả lời phải hiển thị cho toàn bộ nhóm, không chỉ cho quản lý. Minh bạch là giá trị cốt lõi của Agile.

Đặc thù của daily cho nhóm di động

Nhóm di động phải đối mặt với các rào cản cụ thể trong daily. Chính: build dự án trong CI (build Gradle có thể mất 20+ phút — nếu hỏng, nhà phát triển mất một giờ để gỡ lỗi), chờ TestFlight / Firebase App Distribution (xuất bản build cho người kiểm thử mất 30-60 phút), vấn đề với trình giả lập và mô phỏng (Android Emulator yêu cầu KVM/HAXM, iOS Simulator chỉ trên Mac). Daily của nhóm di động nên bao gồm kiểm tra nhanh trạng thái build: “Build có pass không? Tất cả kiểm thử đều xanh?“

Đối với dự án đa nền tảng (Flutter, React Native), daily có thể bao gồm câu hỏi về trạng thái mã dùng chung. Nếu hai nhà phát triển đồng thời chỉnh sửa cùng một tệp Dart và một người hợp nhất thay đổi, người kia sẽ gặp xung đột. Lời khuyên: sử dụng Board Walk với bảng được phân chia theo nền tảng (Android / iOS / Shared). Điều này giúp hình dung ai đang làm việc ở đâu và liệu các thay đổi có chồng chéo không. Đối với dự án Flutter, sử dụng bảng với các cột Platform Channel, BLoC/Cubit, UI và Tests.

Sẵn sàng phát hành là một điểm đặc thù khác của phát triển di động trong daily. 3-5 ngày trước khi phát hành, hãy thêm câu hỏi: “Build đã sẵn sàng phát hành chưa? Tất cả siêu dữ liệu (biểu tượng, ảnh chụp màn hình, mô tả) đã được cập nhật chưa?“ Điều này ngăn chặn tình huống các nhà phát triển kết thúc viết mã vào ngày phát hành trong khi build và xuất bản mất thêm 3-4 giờ. Trình theo dõi phát hành — một bảng riêng với danh sách kiểm tra: cập nhật versionCode/versionName, kiểm tra ProGuard, ký AAB, tải lên bảng điều khiển nhà phát triển, viết ghi chú phát hành.