Scrum là một khung làm việc (framework) theo triết lý Agile, trong đó công việc của một dự án được chia thành các chu kỳ ngắn, cố định thời gian (thường hai tới bốn tuần) gọi là sprint, kết thúc mỗi sprint đội phải giao ra một phần sản phẩm dùng được, thay vì làm âm thầm nhiều tháng rồi mới trình bày kết quả cuối cùng. Nhận định của bài: giá trị lớn nhất của Scrum với một dự án phần mềm không phải ở việc chia nhỏ công việc, mà ở việc cho phép khách hàng và đội dự án nhìn thấy sản phẩm thật sau mỗi vài tuần, từ đó phát hiện sai hướng sớm thay vì tới cuối dự án mới biết đã làm sai yêu cầu.
Ba vai trò và ba loại tài liệu chính trong Scrum
| Thành phần | Vai trò |
|---|---|
| Product Owner | Người đại diện phía khách hàng hoặc doanh nghiệp, quyết định thứ tự ưu tiên công việc cần làm |
| Scrum Master | Người hỗ trợ đội làm đúng quy trình Scrum, gỡ các cản trở trong quá trình làm việc |
| Development Team | Đội trực tiếp thực hiện công việc kỹ thuật trong mỗi sprint |
| Product Backlog | Danh sách toàn bộ công việc, tính năng cần làm cho cả dự án, xếp theo thứ tự ưu tiên |
| Sprint Backlog | Phần việc được chọn ra từ Product Backlog để làm trong sprint hiện tại |
| Increment | Phần sản phẩm hoàn chỉnh, dùng được, giao ra sau mỗi sprint |
Vì sao Scrum phù hợp với dự án phần mềm hơn cách quản lý truyền thống
Quản lý dự án truyền thống (mô hình thác nước) yêu cầu xác định toàn bộ yêu cầu ngay từ đầu, rồi làm tuần tự qua từng giai đoạn thiết kế, xây dựng, kiểm thử, chỉ tới cuối mới có sản phẩm hoàn chỉnh để xem. Với phần mềm, yêu cầu của khách hàng thường thay đổi trong quá trình làm khi họ nhìn thấy sản phẩm thật và có phản hồi mới. Scrum giải quyết vấn đề này bằng cách cho phép Product Backlog được cập nhật liên tục giữa các sprint, và mỗi sprint đều có một buổi xem lại sản phẩm (Sprint Review) để khách hàng góp ý trực tiếp trên phần đã làm xong.
Khi nào Scrum không phù hợp
Scrum đòi hỏi khách hàng hoặc người đại diện (Product Owner) tham gia thường xuyên để góp ý sau mỗi sprint; nếu phía khách hàng không có ai đủ thời gian tham gia đều đặn, Scrum sẽ khó phát huy đúng giá trị của nó. Những công việc có yêu cầu cố định tuyệt đối, không thay đổi trong suốt quá trình làm, như một số dự án xây dựng hạ tầng vật lý, cũng ít cần tới sự linh hoạt mà Scrum mang lại.
Các sự kiện định kỳ trong một sprint
Ngoài Sprint Review đã nhắc ở trên, một sprint theo Scrum chuẩn còn có ba sự kiện định kỳ khác: Sprint Planning, một buổi họp đầu sprint để cả đội thống nhất phần việc sẽ làm trong sprint đó; Daily Scrum, một buổi họp ngắn hằng ngày (thường mười lăm phút) để mỗi thành viên cập nhật tiến độ và nêu vướng mắc; và Sprint Retrospective, một buổi họp cuối sprint để cả đội nhìn lại cách làm việc và tìm cách cải thiện cho sprint tiếp theo, tách biệt với việc xem lại chính sản phẩm ở Sprint Review. Với doanh nghiệp thuê ngoài làm phần mềm theo Scrum, việc được mời tham gia đều đặn vào Sprint Review là quyền lợi quan trọng nhất cần giữ, vì đây là cơ hội trực tiếp để góp ý và điều chỉnh hướng làm trước khi đi quá xa.
Công cụ theo dõi Scrum: từ bảng giấy tới phần mềm chuyên dụng
Một đội mới bắt đầu áp dụng Scrum có thể chỉ cần một bảng dán giấy note chia ba cột (cần làm, đang làm, đã xong) để theo dõi Sprint Backlog, cách làm đơn giản, trực quan, phù hợp khi cả đội ngồi cùng văn phòng. Khi đội làm việc từ xa hoặc dự án có nhiều người tham gia, các phần mềm quản lý dự án chuyên dụng cho phép theo dõi Sprint Backlog trực tuyến, tự động tính toán tiến độ còn lại, và lưu lại lịch sử các sprint trước để tham khảo. Doanh nghiệp thuê ngoài làm phần mềm nên hỏi đơn vị thi công đang dùng công cụ nào để theo dõi tiến độ, và có thể yêu cầu được cấp quyền xem (dù không cần thao tác) để tự theo dõi tiến độ dự án của chính mình theo thời gian thực, thay vì chỉ chờ báo cáo định kỳ.
Câu hỏi thường gặp
Scrum và Agile có phải là một không?
Không. Agile là một triết lý, một tập hợp giá trị và nguyên tắc chung về cách làm việc linh hoạt. Scrum là một khung làm việc cụ thể áp dụng triết lý Agile, và là khung phổ biến nhất, nhưng không phải khung duy nhất.
Một sprint kéo dài bao lâu là hợp lý?
Phổ biến nhất là hai tuần, đủ ngắn để phản hồi nhanh nhưng cũng đủ dài để làm ra một phần việc có ý nghĩa. Một số đội chọn một tuần hoặc bốn tuần tuỳ đặc thù dự án. Đổi độ dài sprint giữa chừng dự án cũng được, nhưng nên hạn chế vì làm xáo trộn nhịp làm việc đã quen của cả đội.
Doanh nghiệp nhỏ thuê ngoài làm phần mềm có cần hiểu Scrum không?
Nên hiểu ở mức cơ bản, ít nhất là vai trò Product Owner cần ai đảm nhận và lịch xem lại sản phẩm sau mỗi sprint, vì đây chính là cơ hội để phát hiện và sửa hướng sai sớm thay vì đợi tới lúc bàn giao cuối cùng. Doanh nghiệp không cần thuộc lòng toàn bộ thuật ngữ Scrum, chỉ cần nắm được nhịp độ này để chủ động tham gia đúng lúc.
Ai trong doanh nghiệp nên đảm nhận vai trò Product Owner khi thuê ngoài làm phần mềm?
Nên là người hiểu rõ nhất nghiệp vụ cần số hoá và có đủ thẩm quyền quyết định thứ tự ưu tiên công việc, thường là chủ doanh nghiệp hoặc trưởng bộ phận trực tiếp sử dụng phần mềm, không nên giao cho người không nắm rõ nghiệp vụ thực tế. Giao vai trò này cho một người không đủ thẩm quyền quyết định sẽ khiến mọi ưu tiên đưa ra trong các buổi họp sprint đều phải xin ý kiến thêm, làm chậm toàn bộ tiến độ dự án.
Nếu đội thi công không tổ chức Sprint Review, doanh nghiệp nên làm gì?
Nên chủ động yêu cầu có buổi xem lại sản phẩm định kỳ, dù đội thi công không gọi đúng tên Sprint Review, vì đây là cơ chế quan trọng để tránh tình trạng chỉ biết kết quả cuối cùng sau nhiều tháng làm việc, và nên ghi rõ tần suất buổi xem lại này ngay trong hợp đồng thay vì chỉ thoả thuận miệng.
