Scrum cơ bản, vai trò và các sự kiện
Scrum sinh ra để làm gì?
Hiểu Agile xong thì sẽ nảy ra câu hỏi: Agile bảo phản hồi nhanh, thích nghi, cải tiến liên tục, nhưng làm thật thì tổ chức công việc kiểu gì? Scrum ra đời để trả lời câu đó.
Theo Scrum Guide 2020, Scrum là framework (khung làm việc) giúp con người, team và tổ chức tạo ra giá trị bằng những giải pháp thích ứng cho các vấn đề phức tạp. Nó không bắt buộc từng thao tác kỹ thuật phải làm thế nào, mà chỉ đưa ra mấy thành phần cốt lõi để team tự tổ chức, kiểm tra kết quả và điều chỉnh.
Scrum chạy theo một vòng lặp
Product → Product Backlog → Sprint Planning → Sprint → Increment → Sprint Review → Adaptation → quay lại cập nhật Product Backlog cho Sprint tiếp theo.
Nói gọn đây là vòng Inspect → Adapt (kiểm tra → thích nghi). Làm một chút, nhìn kết quả thật, rồi chỉnh hướng đi.
Nền tảng: Empiricism
Empiricism là ra quyết định dựa trên quan sát thực tế và những gì đã học được, không dựa vào đoán. Scrum đứng trên 3 trụ cột:
- Transparency (minh bạch): thông tin quan trọng phải được hiển thị rõ, ai cũng hiểu.
- Inspection (kiểm tra): thường xuyên xem tiến độ, kết quả và những thứ có thể ảnh hưởng mục tiêu.
- Adaptation (thích nghi): thấy chỗ nào lệch thì chỉnh quy trình hoặc sản phẩm.
Ví dụ team làm Product Search: kiểm tra thấy kết quả tìm kiếm không chính xác, chỉnh lại logic search, test lại, rồi tiếp tục cải thiện.
Ba vai trò trong Scrum
Scrum Team gồm Product Owner + Scrum Master + Developers, cùng hướng tới một Product Goal (mục tiêu dài hạn của sản phẩm). Theo Scrum Guide, đây là một team thống nhất, tự quản lý, chịu trách nhiệm tạo ra Increment có giá trị mỗi Sprint. Không chia thành mấy team con tách biệt cứng nhắc.
Product Owner (PO)
Người chịu trách nhiệm tối đa hóa giá trị sản phẩm. PO không phải ông sếp chỉ biết giao task. PO phải để ý: user cần gì, business cần gì, cái gì tạo ra giá trị, việc nào ưu tiên trước. Cụ thể PO lo việc quản lý Product Backlog: phát triển và truyền đạt Product Goal, tạo và làm rõ các item, sắp xếp thứ tự, và giữ cho backlog minh bạch, dễ hiểu.
Scrum Master
Người giúp team hiểu và áp dụng Scrum đúng. Giúp team làm việc hiệu quả hơn và gỡ mấy cái vướng trong quá trình làm. Scrum Master không phải trưởng nhóm đi ra lệnh cho dev. Vai trò này còn hỗ trợ cả tổ chức hiểu Scrum và giúp team tập trung tạo ra Increment có giá trị.
Developers
Những người trực tiếp làm ra Increment dùng được. Tùy sản phẩm mà có thể gồm FE, BE, QA, Designer, DevOps, Data Engineer… Scrum không bắt buộc chia team thành nhóm FE, BE, QA riêng. Quan trọng là cả nhóm có đủ kỹ năng để làm ra Increment đạt Definition of Done.
Các sự kiện trong Scrum
Có một Sprint là cái “vỏ” chứa tất cả, và bên trong có 4 sự kiện:
- Sprint Planning: lập kế hoạch Sprint
- Daily Scrum: họp hằng ngày của Developers
- Sprint Review: kiểm tra kết quả Sprint
- Sprint Retrospective: nhìn lại và cải thiện cách làm việc
Mấy sự kiện này sinh ra để tạo cơ hội kiểm tra và thích nghi thường xuyên.
Sprint
Chu kỳ làm việc có độ dài cố định, trong đó team làm những gì cần để đạt Sprint Goal và ra Increment có giá trị. Mấy điểm cần nhớ:
- Độ dài cố định, tối đa 1 tháng
- Các Sprint nối tiếp nhau, Sprint mới bắt đầu ngay khi Sprint trước kết thúc
- Không bắt buộc 1 hay 2 tuần, team chọn độ dài hợp lý miễn không quá 1 tháng và giữ nhất quán
Ví dụ Sprint 2 tuần: tuần 1, tuần 2, rồi Sprint Review (kiểm tra kết quả, nhận phản hồi), Sprint Retrospective (cải thiện cách làm), xong qua Sprint mới.
Sprint Planning
Sự kiện mở đầu Sprint, cả Scrum Team cùng chốt mục tiêu và kế hoạch. Nó xoay quanh 3 câu hỏi:
- WHY (tại sao): Sprint này có ý nghĩa gì? Team xác định Sprint Goal.
- WHAT (làm gì): Developers chọn các Product Backlog Item sẽ làm trong Sprint.
- HOW (làm thế nào): Developers lên kế hoạch biến các item đã chọn thành Increment đạt Definition of Done.
Ví dụ project E-commerce:
- WHY: tăng khả năng tìm kiếm sản phẩm cho người dùng
- WHAT: Search, Filter, Sort
- HOW: FE làm Search UI, BE làm Search API, DB tạo index, rồi test Search/Filter
Đây chỉ là ví dụ cách phân tích việc. Trong Scrum, chia nhỏ và tổ chức công việc kỹ thuật là trách nhiệm của Developers.
Daily Scrum
Sự kiện hằng ngày của Developers để xem tiến độ hướng tới Sprint Goal và chỉnh Sprint Backlog khi cần.
- Diễn ra mỗi ngày làm việc trong Sprint
- Tối đa 15 phút
- Dành cho Developers
- Tổ chức kiểu gì cũng được miễn đạt mục tiêu
Ví dụ: Dev A nói Login API xong, Dev B nói Login UI xong nhưng API contract đang lệch, Dev C nói testing chưa bắt đầu. Cả team thống nhất sửa API contract trước. Daily Scrum không phải buổi báo cáo cho sếp, mà là chỗ để dev tự kiểm tra tình hình và chủ động chỉnh kế hoạch.
Sprint Review
Sự kiện cuối Sprint, Scrum Team và các stakeholder phù hợp cùng kiểm tra kết quả và bàn hướng đi tiếp. Stakeholder là những người có lợi ích hoặc chịu ảnh hưởng từ sản phẩm.
Mục tiêu không chỉ là demo. Team với stakeholder cùng:
- Xem Increment đã làm ra
- Xem tiến độ hướng tới Product Goal
- Bàn về thay đổi của môi trường, thị trường, nhu cầu
- Thu thập phản hồi
- Điều chỉnh Product Backlog nếu cần
Ví dụ team demo Product Search, khách phản hồi “Search được rồi nhưng user cần tìm theo brand nữa”. Team ghi nhận, xem độ ưu tiên và cập nhật backlog. Sprint Review không phải buổi nghiệm thu cứng nhắc kiểu đạt hay không đạt, mà là buổi cộng tác để quyết định hướng tiếp theo.
Sprint Retrospective
Sự kiện nhìn lại cách làm việc của Scrum Team để tìm cải tiến. Chỗ này dễ nhầm với Sprint Review nên phân biệt luôn:
- Sprint Review: sản phẩm có đang tạo giá trị không? Tập trung vào Increment, tiến độ và phản hồi stakeholder.
- Sprint Retrospective: cách team làm việc có hiệu quả không? Tập trung vào con người, tương tác, quy trình, công cụ, chất lượng.
Ví dụ: Review thì khách thích chức năng Search. Retro thì team thấy PR review đang quá chậm. Sprint 1 phát hiện: PR review chậm, thiếu API documentation, FE/BE phối hợp tốt. Retro chốt: PR phải review trong 24 giờ, BE phải document API, giữ cách FE/BE đang phối hợp. Sprint 2 thử áp dụng rồi kiểm tra kết quả.
Bài viết khác
SDLC&STLC
1. Tổng quan nền tảng về quy trình phát triển và kiểm thử phần mềm Trong bất kỳ một dự án công nghệ thông tin nào, dù là ứng dụng di động nhỏ hay hệ thống phần mềm doanh nghiệp khổng lồ, việc để sản phẩm đi đến thành công không thể dựa vào sự […]
Kanban vs Scrum, Scrumban và phần nâng cao
Kanban vs Scrum, Scrumban và phần nâng cao So sánh Kanban và Scrum Tiêu chí Kanban Scrum Bản chất Phương pháp quản lý dòng chảy liên tục Framework phát triển theo chu kỳ Nhịp làm việc Dòng chảy liên tục Khung thời gian cố định (Sprint 1-4 tuần) Cam kết phạm vi Theo khả năng […]
Kanban từ đâu ra và nó thực chất là gì
Kanban từ đâu ra và nó thực chất là gì Chuyện bắt đầu ở Nhật Sau Thế chiến 2 (1945), kinh tế Nhật tan hoang: thiếu vốn, thiếu tài nguyên, hạ tầng bị phá nát. Ngành ô tô Nhật lúc đó gặp bài toán sống còn: thị trường cần nhiều mẫu mã nhưng mỗi mẫu […]
Backlog Refinement, ước lượng, công cụ thực tế
Backlog Refinement, ước lượng, công cụ thực tế Backlog Refinement Là hoạt động làm rõ Product Backlog: chia nhỏ, làm rõ, ước lượng, sắp xếp lại các item khi cần. Ví dụ ban đầu backlog có một mục “Product Search” quá to. Sau khi refine thì tách thành: Search UI, Search API, Search by name, […]
12 nguyên tắc, feedback loop và mấy khái niệm liên quan
12 nguyên tắc, feedback loop và mấy khái niệm liên quan 12 nguyên tắc Agile Nếu 4 giá trị là tư tưởng thì 12 nguyên tắc là cách biến tư tưởng đó thành hướng đi thực tế. Giao hàng sớm và liên tục (Early and continuous delivery) Đưa phần mềm có giá trị đến tay […]
Agile là gì, và 4 giá trị cốt lõi
Agile là gì, và 4 giá trị cốt lõi Agile thực sự là gì? Agile nghĩa là linh hoạt, thích nghi. Nó là một bộ giá trị và nguyên tắc để định hướng cách làm phần mềm, chứ không phải một framework cố định, cũng không phải quy trình bắt mọi team phải làm y […]
Khoá học lập trình game con rắn cho trẻ em 
