So sánh Agile, Scrum và Kanban: chọn cách làm nào cho đội phần mềm

Agile không phải một phương pháp cụ thể mà là tập hợp giá trị và nguyên tắc phát triển phần mềm theo vòng lặp ngắn, ưu tiên phản hồi sớm. Scrum và Kanban là hai cách hiện thực hóa Agile: Scrum tổ chức công việc theo sprint có độ dài cố định với vai trò rõ ràng, còn Kanban quản lý dòng chảy công việc liên tục bằng bảng trực quan và giới hạn số việc đang làm. Chọn cái nào phụ thuộc vào việc yêu cầu của bạn có ổn định trong vài tuần hay thay đổi từng ngày.

Agile: nền móng chung của cả hai

Tuyên ngôn Agile (Agile Manifesto) được công bố năm 2001 với 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 đủ; cộng tác với khách hàng hơn đàm phán hợp đồng; phản hồi với thay đổi hơn bám theo kế hoạch. Câu chữ "hơn" ở đây quan trọng: vế sau vẫn có giá trị, chỉ là vế trước được ưu tiên.

Trên thực tế, một đội "làm Agile" thường có các đặc điểm: giao phần mềm theo từng phần nhỏ, có buổi xem lại để rút kinh nghiệm, người đại diện khách hàng tham gia thường xuyên và kế hoạch được điều chỉnh liên tục. Scrum và Kanban là hai khung giúp biến những nguyên tắc chung này thành thói quen hằng ngày.

Scrum vận hành như thế nào

Scrum được mô tả trong Scrum Guide, tài liệu ngắn do Ken Schwaber và Jeff Sutherland duy trì. Các thành phần chính:

• Ba trách nhiệm: Product Owner quyết định thứ tự ưu tiên trong Product Backlog; Scrum Master giúp đội áp dụng Scrum và gỡ vướng mắc; Developers là những người tạo ra sản phẩm.
• Sprint: khung thời gian cố định tối đa một tháng, phổ biến là hai tuần. Mục tiêu sprint được chốt ở đầu và hạn chế thay đổi giữa chừng.
• Các sự kiện: Sprint Planning, Daily Scrum (tối đa 15 phút), Sprint Review để trình bày kết quả với bên liên quan, Sprint Retrospective để cải tiến cách làm.
• Artifact: Product Backlog, Sprint Backlog và Increment (phần sản phẩm hoàn thành, đạt Definition of Done).

Điểm mạnh của Scrum là tạo nhịp đều đặn: cứ hết sprint là có thứ để demo, có dịp để khách hàng góp ý và có buổi nhìn lại. Điểm yếu là khi yêu cầu khẩn liên tục chen ngang, ranh giới sprint trở nên giả tạo và đội tốn nhiều thời gian họp lập kế hoạch lại.

Kanban vận hành như thế nào

Kanban trong phần mềm bắt nguồn từ hệ thống sản xuất của Toyota và được David J. Anderson phát triển cho công việc tri thức. Kanban không quy định vai trò hay sự kiện cố định; nó bắt đầu từ cách bạn đang làm và cải tiến dần. Các thực hành cốt lõi:

• Trực quan hóa luồng việc: bảng với các cột như Cần làm, Đang phân tích, Đang làm, Review, Kiểm thử, Xong.
• Giới hạn WIP (work in progress): mỗi cột chỉ được chứa tối đa một số thẻ. Khi đầy, đội phải hoàn thành việc cũ trước khi kéo việc mới.
• Quản lý dòng chảy: theo dõi thời gian một thẻ đi từ lúc bắt đầu tới lúc xong (cycle time) và tìm nút thắt.
• Chính sách rõ ràng: thế nào là "xong" ở từng cột, ai được kéo thẻ, việc khẩn được xử lý ra sao.

Kanban hợp với công việc có yêu cầu đến liên tục và khó dự đoán, như đội vận hành, hỗ trợ kỹ thuật, bảo trì sản phẩm đã ra mắt. Điểm yếu là thiếu nhịp tự nhiên cho việc nhìn lại; nếu đội không chủ động đặt lịch review, cải tiến dễ bị bỏ quên.

Bảng so sánh Scrum và Kanban

Scrumban và các cách kết hợp

Nhiều đội không chọn một trong hai mà kết hợp: giữ Sprint Review và Retrospective của Scrum để có nhịp nhìn lại, nhưng dùng bảng Kanban với giới hạn WIP thay vì cam kết cứng số việc cho sprint. Cách này hay gọi là Scrumban.

Một mô hình kết hợp khác là tách luồng: đội phát triển tính năng chạy Scrum, còn một hoặc hai người luân phiên trực "luồng nóng" theo Kanban để xử lý lỗi production và yêu cầu khẩn. Như vậy sprint không bị phá vỡ mà sự cố vẫn được xử lý nhanh.

Gợi ý chọn mô hình theo tình huống

Startup xây sản phẩm đầu tiên

Scrum với sprint một hoặc hai tuần thường hợp lý: đội cần nhịp demo thường xuyên để kiểm chứng ý tưởng với người dùng và nhà đầu tư. Tuy nhiên đội nhỏ ba bốn người có thể bỏ bớt nghi thức, giữ lại planning ngắn và retrospective.

Đội phần mềm nội bộ của doanh nghiệp

Đội IT nội bộ thường vừa phát triển tính năng vừa hỗ trợ người dùng, ví dụ khi đang triển khai hệ thống ERP cho doanh nghiệp vừa và nhỏ. Kanban hoặc Scrumban giúp hiển thị mọi yêu cầu trên cùng một bảng và tránh tình trạng ai cũng đang làm dở năm việc.

Công ty outsource làm dự án theo hợp đồng

Khi hợp đồng có phạm vi và mốc bàn giao, Scrum với Sprint Review cùng khách hàng giúp hai bên thống nhất kỳ vọng từng giai đoạn. Cần thỏa thuận trước cách xử lý yêu cầu thay đổi để không ảnh hưởng đến sprint đang chạy.

Đội DevOps, SRE, vận hành hạ tầng

Kanban gần như là lựa chọn tự nhiên vì công việc chủ yếu đến từ sự cố, ticket và yêu cầu hạ tầng. Theo dõi cycle time giúp thấy việc nào hay bị kẹt, ví dụ chờ phê duyệt bảo mật.

Sai lầm thường gặp khi áp dụng

• Làm Scrum hình thức: họp đủ bốn sự kiện nhưng không bao giờ thay đổi gì sau retrospective, hoặc daily biến thành buổi báo cáo cho quản lý.
• Dùng velocity để so sánh các đội: story point là thước đo nội bộ của từng đội, so sánh giữa đội chỉ khiến điểm bị thổi phồng.
• Kanban không có giới hạn WIP: khi đó nó chỉ là một danh sách việc dạng bảng, mất đi cơ chế lộ ra nút thắt.
• Bỏ qua chất lượng: tốc độ giao hàng tăng nhưng Definition of Done không có test và review. Bài hướng dẫn viết unit test và integration test gợi ý cách đưa kiểm thử vào tiêu chí hoàn thành.
• Chọn công cụ trước, quy trình sau: Jira, Trello hay bảng giấy đều được; hãy thống nhất cách làm trước rồi mới cấu hình công cụ cho khớp.

Đo xem cách làm mới có hiệu quả không

Sau hai ba tháng áp dụng, hãy so với trước đó bằng những câu hỏi cụ thể: thời gian từ lúc nhận yêu cầu đến lúc lên production có ngắn lại không; số lỗi phát hiện sau khi release có giảm không; đội có cảm thấy ít bị ngắt quãng hơn không; bên kinh doanh có biết rõ hơn khi nào tính năng sẽ có không. Nếu câu trả lời phần lớn là không, vấn đề thường nằm ở việc ưu tiên backlog hoặc ở kỹ thuật (thiếu tự động hóa test, deploy), chứ không nằm ở việc chọn sai Scrum hay Kanban.