A. Kế thừa các yếu tố từ Scrum#

• Sprint:
  • Với Scrum: một Sprint sẽ kéo dài từ 2-4 tuần, phụ thuộc vào quy mô của mục tiêu trong Sprint.
  • Với Scrumban: thời gian của Sprint hoặc là Iteration sẽ ngắn hơn (2 tuần). Thời gian Sprint sẽ được fixed, không push thêm ticket khi chưa hoàn thành. Điều này nhằm đảm bảo target Continuos Delivery.
• Daily Standup: thời lượng < 10 phút. Team sẽ xoay quanh 3 câu hỏi: Đã hoàn thành chi? Đang thực hiện chi? Có trở ngại chi không?
• Sprint Planning: xác định rõ target của Sprint và lượng ticket phù hợp với Sprint time.
  • Với Scrum: planning phase nhằm đưa ra estimate time cần thiết cho target, từ đó lựa chọn Sprint time phù hợp.
  • Với Scrumban: trong planning phase cần chốt được số lượng ticket có thể done trong Iteration với một fixed time.
    => Tăng độ chính xác của estimate time vì chỉ plan trong khoảng thời gian đủ nhỏ.
• Role (optional): Scrumban sẽ không chia nhiều vai trò, thông thường sẽ có: Dev Team, Project Manager (optional). Vai trò của PM trong Scrumban giúp target đề ra sát với nhu cầu của project nhất.
• Retrospective (optional): thông thường retro sẽ được thực hiện vào cuối mỗi end sprint. Tuy nhiên, kinh nghiệm của mình với tần suất retro như vậy, hầu như chỉ có thể cải thiện nhanh những vấn đề nhỏ lẻ của Sprint. Đa phần với phát triển phần mềm, mình thấy issue cốt lỗi nằm ở yếu tố con người là chính và việc này không thể thay đổi nhanh được. Cá nhân mình suggest tần suất khoảng 2-3 Sprint/lần.

B. Kế thừa các yếu tố từ Kanban #

• Kanban board: Scrumban kế thừa Visualize Work của Kanban, có thể tổng quát hóa quy trình làm việc với các trạng thái dễ hình dung hơn (không thuần technical),
• Pull system: Lượng ticket được đẩy vô board sẽ phù hợp với dung lượng có thể chứa hơn là pull nhiều nhất có thể.

IMPORTANT

Với mình, việc team có control được lượng work load hoặc development process có smooth hay không. Phụ thuộc rất nhiều vào mindset của người control (với Scrum là Scrum Master, Scrumban là Project Management)
Không chỉ đơn thuần là đưa ra quyết định những gì sẽ thực hiện trong Sprint, người control cần hiểu được khó khăn mà team đang gặp phải, ngữ cảnh của Sprint, cùng với những thay đổi liên tục trong quá trình vận hành để có thể take action đúng lúc.
Sứ mệnh của người control là giúp cho quá trình vận hành được suôn sẻ nhất có thể và giảm thiếu áp lực cho các bên.

• Work-in-progress (WIP) limit: set limit progress ở từng phase, vì Kanban là visualize quy trình sản suất -> các trạng thái của ticket sẽ được đảm nhiệm ở từng vai trò. Khi số lượng ticket ở vai trò đó quá nhiều, sẽ gây hiện tượng nghẽn cổ chai. Về lâu dài sẽ ảnh hưởng tới mental health của member.

• Continuous workflow: với Scrum cần hoàn thành hết các ticket trong Sprint, Scrumban cho phép quy trình được thực thi liên tục. Nghĩa là, khi kết thúc Sprint không buộc toàn bộ ticket phải đi hết tới quy trình cuối cùng. Có thể ở Sprint đó vẫn còn một số Ticket đang chờ delivery…

• Focus on cycle time: mục tiêu hướng tới của Kanban, không phải là hoàn thành nhiều ticket, cũng không phải là hoàn thành target đề ra. Mà là tối ưu cycle time (thời gian ticket được lên plan -> delivery). Nói nôm na là tối ưu từng quy trình sản suất. Từ đó dễ dàng đạt được target hơn, giảm tải áp lực thực thi hơn.

C. Overview#

Ở part 2, mình sẽ chia sẻ về cách thực thi Scrumban, những lưu ý trong quá trình vận hành và ưu/khuyết điểm của quy trình này. See u ^^~.