Scrumban là gì?

Scrumban thật ra là gì

Scrumban giữ lại những phần của Kanban và Scrum thật sự gánh việc, còn lại thì bỏ. Từ Kanban, nó lấy cái bảng trực quan, quy trình theo cột, và một giới hạn rõ ràng cho lượng việc đang làm — những thứ làm cho dòng chảy nhìn ra được. Từ Scrum, nó lấy sprint giới hạn thời gian — thứ biến một danh sách tồn đọng thành một kế hoạch.

Cái nó bỏ qua: họp đứng hằng ngày, họp chải backlog, nghi thức story point, họp rút kinh nghiệm làm cho có. Những thứ đó chạy được với mười kỹ sư trong một tổ chức đã lên dây; chúng không chạy được với một nhà sáng lập đang cố đưa sản phẩm ra vào ngày thứ Bảy.

Cái tên đến từ Corey Ladas, người có bài tiểu luận và sau đó là cuốn sách Scrumban mô tả cách các đội Scrum có thể chuyển từ các vòng lặp cố định sang dòng chảy kiểu kéo việc.

So sánh Scrumban, Kanban và Scrum

Ba phương pháp khác nhau chủ yếu ở hai điểm: công việc có được lên kế hoạch theo khung thời gian hay không, và quanh cái bảng có bao nhiêu quy trình.

Nguồn: Scrum Guide cho sprint, vai trò và sự kiện; Kanban Guide cho dòng chảy và giới hạn việc đang làm.

Bảng Scrumban trông như thế nào?

Bảng Scrumban là một bảng Kanban có một sprint phủ lên trên. Các cột cho biết công việc đang ở đâu; sprint cho biết tuần này xoay quanh phần nào của backlog. Một bảng tối giản có bốn cột:

• Backlog — mọi thứ bạn có thể sẽ làm. Phía dưới không cần sắp xếp, phía trên thì có thứ tự.
• Todo — những gì bạn đã quyết định làm tiếp theo. Cố ý giữ nhỏ: khi nó sắp cạn, đó là tín hiệu để lên kế hoạch.
• Doing — những gì ai đó (một người hoặc một tác tử AI) đang làm ngay lúc này.
• Done — việc đã xong. Được dọn đi hoặc lưu trữ khi sprint kết thúc.

Cách dựng một bảng Scrumban

1. Tạo bốn cột: Backlog, Todo, Doing, Done.
2. Đưa mọi thứ bạn biết vào Backlog. Đừng sắp xếp tất cả — chỉ sắp xếp phần trên cùng.
3. Quyết định cùng lúc được có bao nhiêu việc trong Doing. Với một người, một hoặc hai việc; với một đội nhỏ, khoảng một việc mỗi người.
4. Chọn độ dài sprint — một hoặc hai tuần — và viết cho nó một mục tiêu trong một câu. Chỉ kéo vào Todo những gì phục vụ mục tiêu đó.
5. Làm việc bằng cách kéo: khi một việc trong Doing xong, lấy thẻ tiếp theo ở đầu Todo. Không ai đẩy việc sang cho ai.
6. Lên kế hoạch khi Todo sắp cạn, không theo lịch. Cuối sprint, xem việc gì đã xong và việc gì chưa, rồi bắt đầu sprint tiếp theo.

Vì sao Weft chọn Scrumban

Weft tồn tại vì phần lớn trình quản lý công việc được nắn theo một trong hai cực: hoặc là ứng dụng danh sách việc cần làm đơn độc (danh sách vô tận, không có nhịp), hoặc là một bộ Agile cho năm mươi người (chi phí quy trình đè lên một nhà sáng lập một mình). Scrumban nằm đúng khoảng giữa — đủ cấu trúc để buộc ra sản phẩm mỗi tuần hoặc hai tuần, mà không nhiều tới mức ngày ra sản phẩm bạn ngồi làm thủ tục cho nó.

Weft hiện thực nó thế nào

• Bốn cột mặc định: Backlog, Todo, Doing, Done. Việc đang làm được giới hạn bởi những gì đang chờ bạn, không phải bởi một con số cho từng cột. Kanban Guide coi một chính sách rõ ràng để giới hạn việc đang làm là một phần của định nghĩa quy trình, để việc mới chỉ được kéo vào khi có năng lực trống.
• Mỗi lần một sprint đang chạy, kèm một mục tiêu tùy chọn. Sprint là tùy chọn — bỏ qua nó nếu Kanban thuần hợp với bạn. Scrum Guide định nghĩa Sprint là sự kiện có độ dài cố định, tối đa một tháng, và Sprint mới bắt đầu ngay sau khi Sprint trước kết thúc.
• Công việc có mức ưu tiên, ước lượng, hạn chót, và có thể gắn vào một sprint. Không epic, không luồng quy trình, không trường tùy biến.
• Thời gian chu kỳ bắt đầu khi một công việc chuyển vào cột có semantic="doing" và kết thúc ở "done". Những con số đó đến từ việc dùng thật, không phải từ phép tính story point.

Scrumban với tác tử AI

Chính cơ chế kéo việc làm cho Scrumban cũng chạy được với tác tử AI. Một tác tử kết nối với Weft qua MCP tự lấy thẻ tiếp theo: start_task nhận thẻ, nên tác tử thứ hai không thể lấy cùng thẻ đó, và complete_task đóng nó lại kèm những gì đã làm và bằng chứng. Khi tác tử cần một quyết định, nó hỏi bạn thay vì đoán — và khi có quá nhiều việc đã xong đang chờ bạn, tác tử ngừng bắt đầu việc mới. Đó là giới hạn việc đang làm của Kanban, áp lên đúng nguồn lực duy nhất không thể mở rộng: sự chú ý của bạn.

Khi nào Scrumban không phải phương pháp đúng

• Bạn vận hành nhiều đội Scrum song song. Scrum Guide đặt quy mô một Scrum Team thường là 10 người trở xuống, và nói rằng sản phẩm lớn hơn nên được tổ chức thành nhiều Scrum Team dùng chung một Product Goal và một Product Backlog. Báo cáo cấp chương trình, vận tốc dùng chung, phụ thuộc chéo giữa các đội — Scrum đầy đủ trên Jira xứng với chi phí của nó. Nexus Guide được viết cho đúng tình huống đó: nhiều Scrum Team cùng làm từ một Product Backlog duy nhất, với các thực hành bổ sung để làm lộ ra và gỡ các phụ thuộc chéo giữa các đội.
• Bạn làm hỗ trợ thuần túy / vận hành liên tục. Không cần nhịp sprint — Kanban thuần hoặc một hệ thống ticket hợp hơn.
• Bạn cần biểu đồ Gantt và dòng thời gian. Scrumban xoay quanh sprint, chứ không xoay quanh đồ thị phụ thuộc.

Câu hỏi về Scrumban