Scrum Framework là gì? Scrum là một framework (khung làm việc) Agile nhẹ, phổ biến nhất để phát triển, bàn giao và duy trì các sản phẩm phức tạp. Scrum không quy định chi tiết “làm thế nào” (how) về mặt kỹ thuật, mà cung cấp cấu trúc: Vai trò, Sự kiện, Sản phẩm và Quy tắc để đội ngũ tự tổ chức, giải quyết vấn đề phức tạp một cách thích ứng.
3 Vai trò trong Scrum (Scrum Team)
- Product Owner (PO) – Chủ sở hữu sản phẩm: Chịu trách nhiệm tối đa hóa giá trị sản phẩm. Quản lý Product Backlog (Sắp xếp ưu tiên, làm rõ mục tiêu, chấp nhận kết quả). Là “Cái miệng” của khách hàng/ bên liên quan.
- Scrum Master (SM) – Chủ trì Scrum: Chịu trách nhiệm thiết lập Scrum, đào tạo, hướng dẫn (Coach) Scrum Team và tổ chức. Loại bỏ chướng ngại (Impediments), tạo môi trường cho đội ngũ hiệu quả. Là “Người phục vụ – Lãnh đạo” (Servant Leader).
- Developers (Nhóm phát triển) – Nhóm lập trình/ thực hiện: Tự tổ chức (Self-organizing), đa chức năng (Cross-functional). Chịu trách nhiệm tạo ra Increment (Sản phẩm tăng giá trị) “Done” mỗi Sprint. Kích thước khuyến nghị: 3-9 người (không tính PO, SM).
5 Sự kiện trong Scrum (Events) – Tất cả đều Time-boxed (Giới hạn thời gian)
- Sprint (Sprint): Container chứa tất cả các sự kiện khác. Độ dài cố định ≤ 1 tháng (thường 2 tuần). Mục tiêu: Tạo ra Increment “Done” có giá trị.
- Sprint Planning (Lập kế hoạch Sprint): Time-box: 8h (Sprint 1 tháng). Câu trả lời: “Sprint này làm gì?” (PO trình bày ưu tiên -> Dev chọn việc -> Lập kế hoạch cách làm). Kết quả: Sprint Goal & Sprint Backlog.
- Daily Scrum (Họp hàng ngày): Time-box: 15 phút. Chỉ cho Developers. Mục đích: Kiểm tra tiến độ về Sprint Goal, điều chỉnh kế hoạch ngay. 3 câu hỏi phổ biến: Đã làm gì? Sẽ làm gì? Chướng ngại gì?
- Sprint Review (Xem xét Sprint): Time-box: 4h (Sprint 1 tháng). Scrum Team + Stakeholders. Kiểm tra Increment, thu thập phản hồi, cập nhật Product Backlog. Là buổi “Show & Tell”.
- Sprint Retrospective (Hồi顾 Sprint): Time-box: 3h (Sprint 1 tháng). Chỉ Scrum Team. Suy nghĩ: Người, Quy trình, Công cụ, Definition of Done. Tạo ra Improvement Backlog cho Sprint sau. Là “Trái tim” của cải tiến liên tục.
3 Sản phẩm trong Scrum (Artifacts) – Cung cấp sự minh bạch
- Product Backlog: Danh sách có thứ tự ưu tiên mọi thứ cần thiết cho sản phẩm. Luôn thay đổi. Đơn vị: Product Backlog Item (PBI) – thường viết dạng User Story.
- Sprint Backlog: Kế hoạch của Developers cho Sprint hiện tại. Bao gồm: Sprint Goal, PBIs được chọn, Kế hoạch thực hiện (Tasks). Chỉ Developers mới sửa đổi.
- Increment (Sản phẩm tăng giá trị): Tổng tất cả PBIs “Done” trong Sprint hiện tại + các Sprint trước. Phải đáp ứng Definition of Done (DoD) – tiêu chuẩn chất lượng chung.
Definition of Done (DoD) – Tiêu chuẩn “Xong”
Một checklist đồng thuận của Scrum Team (và tổ chức) xác định khi nào một PBI/ Increment được coi là “Hoàn thành”. Ví dụ: Code complete -> Code review passed -> Unit test passed -> Integration test passed -> Deployed to Staging -> PO accepted -> Document updated. DoD tạo ra sự minh bạch và chất lượng.
Tại sao Scrum quan trọng?
- Cấu trúc nhẹ, dễ hiểu, khó thành thạo: Bắt đầu nhanh, cải tiến mãi mãi.
- Tự tổ chức & Chủ sở hữu: Đội ngũ quyết định “Làm thế nào” -> Cam kết cao, sáng tạo cao.
- Minh bạch & Kiểm soát thực tế: Mọi thứ nhìn thấy được (Artifacts), kiểm tra thường xuyên (Events).
- Cải tiến liên tục có hệ thống: Retrospective mỗi Sprint.
Ví dụ thực tế
Một đội ngũ 7 người (1 PO, 1 SM, 5 Devs) xây dựng App Mobile Banking.
- Sprint 1 (2 tuần): PO trình bày ưu tiên: “Đăng nhập”, “Xem số dư”. Dev chọn 2 PBI, lập kế hoạch task. Daily Scrum 15p/ ngày. Sprint Review demo cho khách hàng/ stakeholder. Retrospective cải tiến: “Cần viết Unit test trước khi code (TDD)”.
- Sprint 2: Áp dụng TDD. Sprint Goal: “Chuyển tiền nội bộ”. Done: Đã test, deploy, PO accept.
Lợi ích cụ thể
- Tăng 20-40% khả năng dự báo ngày giao hàng (Predictability).
- Giảm 30-50% lỗi phát hiện muộn (Escaped Defects).
- Tăng 15-25% sự hài lòng của đội ngũ (Team Morale).
- Rút ngắn 2-3x chu kỳ phản hồi từ khách hàng.
Câu hỏi thường gặp
Q: Scrum Master có là Project Manager không?
A: KHÔNG. PM thường “Quản lý/ Chỉ đạo” (Command & Control). SM “Phục vụ/ Hướng dẫn/ Loại bỏ chướng ngại” (Servant Leadership). SM không phân công việc, không chịu trách nhiệm giao hàng – Developers tự tổ chức và chịu trách nhiệm.
Q: Scrum có bắt buộc phải 2 tuần một Sprint không?
A: Không. ≤ 1 tháng. 2 tuần phổ biến. Sprint ngắn (1 tuần) -> Phản hồi nhanh hơn, áp lực cao hơn. Sprint dài (3-4 tuần) -> Ổn định hơn, phù hợp môi trường ít thay đổi.