Agile là triết lý, không phải quy trình cụ thể
Agile ra đời từ năm 2001 khi 17 kỹ sư phần mềm ký bản Tuyên ngôn Agile, đặt bốn giá trị: con người và tương tác hơn quy trình và công cụ, phần mềm chạy được hơn tài liệu đầy đủ, hợp tác với khách hàng hơn đàm phán hợp đồng, và phản hồi với thay đổi hơn bám sát kế hoạch ban đầu. Bản tuyên ngôn không quy định bước làm cụ thể nào, vì vậy nhiều khung làm việc khác nhau đều tự nhận là Agile: Scrum, Kanban, Extreme Programming, Lean.
Vì Agile chỉ là triết lý, một doanh nghiệp có thể áp dụng tinh thần Agile mà không theo một khung nào cụ thể, miễn là đội ngũ làm việc theo chu kỳ ngắn, kiểm tra kết quả thường xuyên và sẵn sàng đổi hướng khi có phản hồi mới từ người dùng.
Scrum cụ thể hoá Agile bằng ba vai trò và các sự kiện lặp lại
Scrum chia công việc thành các sprint dài từ một đến bốn tuần, mỗi sprint kết thúc bằng một phần sản phẩm dùng được. Ba vai trò cố định gồm Product Owner (quyết định làm gì trước, quản lý product backlog), Scrum Master (giữ cho đội tuân thủ khung làm việc, gỡ vướng mắc) và Development Team (những người trực tiếp làm ra sản phẩm).
- Sprint Planning: đầu sprint, đội chọn việc từ product backlog đưa vào sprint backlog.
- Daily Scrum: họp đứng khoảng 15 phút mỗi ngày, mỗi người nói đã làm gì, sẽ làm gì, có vướng gì.
- Sprint Review: cuối sprint, demo phần đã làm cho các bên liên quan xem và góp ý.
- Sprint Retrospective: đội tự nhìn lại cách làm việc, chọn một hai điểm để cải thiện ở sprint sau.
Vì sao hai khái niệm hay bị nhầm thành một
Scrum là khung Agile phổ biến nhất nên nhiều người nói Agile khi thực ra đang mô tả Scrum. Sự nhầm lẫn này gây rắc rối khi doanh nghiệp tuyển vị trí Scrum Master nhưng mô tả công việc lại chỉ đòi hỏi tư duy Agile chung chung, hoặc ngược lại, đội ngũ tự nhận đang làm Agile nhưng thực chất đang chạy đúng quy trình Scrum sách vở mà không hiểu vì sao từng bước tồn tại.
| Tiêu chí | Agile | Scrum |
|---|---|---|
| Bản chất | Tập giá trị và nguyên tắc | Khung làm việc cụ thể |
| Vai trò quy định | Không quy định | Product Owner, Scrum Master, Development Team |
| Nhịp làm việc | Không cố định | Sprint cố định độ dài, thường 1 đến 4 tuần |
| Ví dụ khung khác cùng triết lý | Kanban, Lean, XP | Chính Scrum là một trong các khung đó |
Cách Alodev dùng Scrum khi triển khai phần mềm cho khách hàng
Với các dự án phần mềm quản lý nội bộ mà Alodev triển khai cho doanh nghiệp vừa và nhỏ, đội dùng sprint hai tuần. Sprint Planning làm cùng người đại diện khách hàng để chọn đúng tính năng cần trước, tránh làm những phần chưa cấp thiết. Sprint Review là buổi demo trực tiếp cho khách xem phần đã chạy được, thay vì chỉ gửi báo cáo tiến độ bằng văn bản. Cách làm này giúp khách hàng thấy sản phẩm hình thành dần, phát hiện sai lệch yêu cầu sớm thay vì đợi đến lúc bàn giao mới nhận ra phần mềm không đúng ý.
Điểm khác với sách vở là quy mô đội nhỏ nên vai trò Scrum Master và một phần Product Owner đôi khi do cùng một người phụ trách theo dõi tiến độ đảm nhiệm, miễn là công việc tách bạch quyết định làm gì và cách làm ra sao vẫn được giữ rõ ràng.
Doanh nghiệp muốn áp dụng Scrum cho đội dự án nội bộ có thể tham khảo dịch vụ tư vấn quy trình của Alodev tại /dich-vu.
Ví dụ một sprint hai tuần cụ thể
Để hình dung rõ hơn, một sprint hai tuần triển khai module quản lý chấm công cho khách hàng có thể chia như sau. Ngày đầu tiên là Sprint Planning, đội chọn ba việc từ backlog: xây màn hình chấm công bằng vân tay, xử lý trường hợp quên chấm công, và xuất báo cáo công lao động cuối tháng. Product Owner giải thích rõ vì sao xử lý trường hợp quên chấm công được ưu tiên trước xuất báo cáo, vì khách hàng đang gặp vướng mắc thực tế ở khâu đó mỗi tuần.
| Ngày | Hoạt động | Mục tiêu |
|---|---|---|
| Ngày 1 | Sprint Planning | Chốt ba hạng mục đưa vào sprint, ước lượng khối lượng công việc |
| Ngày 2 đến ngày 9 | Phát triển, Daily Scrum mỗi sáng 15 phút | Từng thành viên báo tiến độ, nêu vướng mắc để Scrum Master gỡ ngay trong ngày |
| Ngày 10 | Kiểm thử nội bộ | Rà lỗi trước khi demo cho khách hàng |
| Ngày 10 buổi chiều | Sprint Review | Demo trực tiếp ba hạng mục cho người đại diện khách hàng, ghi nhận góp ý |
| Cuối ngày 10 | Sprint Retrospective | Đội tự đánh giá, ví dụ nhận ra ước lượng thời gian xử lý trường hợp quên chấm công bị thiếu do chưa tính ca đêm |
Điểm khách hàng thường ấn tượng nhất khi làm việc theo Scrum là được xem sản phẩm chạy thật sau mỗi hai tuần, thay vì phải đợi vài tháng mới thấy bản demo đầu tiên. Nhờ vậy các sai lệch về yêu cầu, ví dụ khách hàng thực ra cần chấm công theo ca thay vì theo ngày như đội phát triển hiểu ban đầu, được phát hiện và sửa ngay trong sprint kế tiếp thay vì dồn đến cuối dự án.
Câu hỏi thường gặp
Doanh nghiệp nhỏ có cần Scrum đầy đủ không?
Không bắt buộc. Đội dưới năm người có thể chỉ cần Kanban board đơn giản kèm họp ngắn hằng ngày, giữ tinh thần Agile mà không cần đủ ba vai trò và bốn sự kiện của Scrum. Scrum phát huy giá trị rõ nhất khi đội đủ lớn để cần quy tắc phối hợp chính thức.
Sprint nên dài bao lâu?
Phổ biến nhất là hai tuần vì đủ ngắn để phản hồi nhanh, đủ dài để hoàn thành một khối việc có ý nghĩa. Dự án yêu cầu thay đổi liên tục có thể chọn sprint một tuần, dự án ổn định hơn có thể kéo tới bốn tuần.
Ai quyết định tính năng nào làm trước trong Scrum?
Product Owner. Đây là người hiểu rõ nhất giá trị kinh doanh của từng hạng mục và chịu trách nhiệm sắp xếp thứ tự trong product backlog, không phải đội phát triển hay Scrum Master.
Scrum có phù hợp với dự án có deadline cố định không?
Có, nhưng cần điều chỉnh: cố định phạm vi theo số sprint có thể chạy trước hạn, thay vì cố nhồi toàn bộ yêu cầu ban đầu vào một mốc thời gian không đổi. Đây là lý do Scrum khuyến khích ước lượng lại backlog sau mỗi sprint.
Có thể kết hợp Scrum với Kanban không?
Có, gọi là Scrumban. Đội giữ sprint và các vai trò của Scrum nhưng dùng bảng kéo thả kiểu Kanban để theo dõi trạng thái công việc, phù hợp khi công việc vừa có phần lập kế hoạch trước vừa có phần việc phát sinh cần xử lý ngay.
