Kanban: Next Moves from Scrum

Summary/Tổng kết

Bài viết sau nói về lý do, cách tiến hành chuyển đổi khung làm việc từ Scrum sang Kanban đối với dự án phát triển sản phẩm ở thời điểm có tính quyết định: Mọi chức năng chính, có giá trị cao, bắt buộc mà khách hàng yêu cầu đã được hoàn thành (gần) hết.

Tình huống/The Situation

Dự án phát triển dịch vụ S đã đi hết 9 sprint, mỗi sprint 2 tuần. Sau thời gian này, nhóm dự án, đã hoàn thành hết những chức năng (story) có giá trị cao mà khách hàng yêu cầu bắt buộc phải có.

Tại thời điểm này, những story đem lại giá trị về mặt chức năng (khá lớn) đã gần như biến mất hết khỏi backlog.

Cũng trong thời gian của cả 9 sprint, nhóm phát triển thực hiện Agile testing (gối đầu) và nhận được một số feedback ở dạng change request, improvement, lỗi… thường ở dạng tác vụ (task) không quá lớn hay những story bổ sung (nhỏ) được tích tụ dần trong backlog qua các buổi demo với khách hàng và kiểm thử nội bộ trong đội phát triển.

Ở thời điểm này, nhóm đã đạt được độ thuần thục nhất định, có thể tự quản lý mà không cần nhiều sự giúp đỡ từ ScrumMaster hay người quản lý khác.

Dự định tiếp theo được thống nhất giữa khách hàng, chủ sản phẩm và nhóm phát triển quyết định những mốc quan trọng tiếp theo của dự án:

1. Kiểm thử và hoàn thiện trong vòng 2 tới 4 tuần,
2. Sử dụng thử nghiệm quy mô nhỏ ở phía khách hàng (test driver, field test) trong vòng 2 tới 4 tuần,
3. Triển khai thực tế diện rộng ở phía khách hàng,
4. Sau đó, việc thêm mới chức năng, sửa lỗi, bảo trì sản phẩm sẽ diễn ra liên tục (cho tới khi dừng dịch vụ).

Từ thời điểm này trở đi, tùy thuộc vào tình hình kinh doanh, tổ chức… nhóm dự kiến không có những thay đổi, yêu cầu lớn từ khách hàng một cách đột ngột.

Nhóm quyết định sử dụng Kanban thay vì Scrum kể từ thời điểm chuyển tiếp này. Lý do và các điểm cần lưu ý được trình bày trong các phần sau.

Chi tiết Thay đổi/Details of Changes

Nhịp Phát triển/Development Cadence

Nhịp phát triển mới là liên tục thay vì nhịp sprint 2 tuần.

Nhịp Phát hành/Release Cycle

Nhịp phát hành mới là liên tục thay vì nhịp demo/phát hành 2 tuần cuối mỗi sprint.

Sự thay đổi về nhịp bắt nguồn từ nhu cầu thực tế là các tác vụ và story trong backlog đều không lớn. Một số lỗi cần sửa và đưa ngay lên máy production (quy trình xử lý hotfix)

Vai Trò trong Nhóm/Team Members’ Roles

Do nhóm đã tự quản tốt hơn và thuần thục hơn, chỉ cần chỉ định các vị trí “dàn hàng ngang” có tên “thành viên nhóm” có vai trò ngang nhau, tốt nhất là liên chức năng có thể bổ sung, thay thế lẫn nhau.

Các vai trò chủ sản phẩm, ScrumMaster (có thể) không cần thiết, hoặc thu hẹp về dạng bán thời gian, chỉ xuất hiện hỗ trợ khi thực sự cần thiết.

Đo Metrics/Metrics

Velocity (tốc độ) – bao nhiêu điểm (point) nhóm “ăn” (burn) được trong một sprint là metric chính trong khung làm việc Scrum.

Khi chuyển đổi sang Kanban, nhịp (phát hành), có thể tính bằng ngày hay thời gian thực là yếu tố đo trở nên không quá quan trọng.

Với Kanban, chúng ta làm nhanh, tập trung vào làm sao cho xong việc chứ không tự bó hẹp mình trong khung thời gian của sprint (và đợi).

Với Kanban, nhịp có thể chuyển thành ngày (24h) hoặc 2 ngày (48h) (khuyến nghị), hay liên tục.

Quan Điểm về Quản lý Thay đổi/Change Management Approaches

Kanban khuyến khích thay đổi, giống Scrum, theo triết lý Agile. Nhưng, sự thay đổi ở Kanban được hiểu là nhỏ và nhanh.

Những (yêu cầu) thay đổi được khuyến khích và đưa thẳng vào hàng đợi (cột TODO) và chuyển dần sang cột DOING dựa trên sự đồng thuận về thứ tự ưu tiên giữa nhóm và khách hàng.

Mỗi tác vụ đều được đăng ký bằng một ticket (issue) trên Jira. Trên bảng trắng vật lý (kanban) dán một thẻ ghi số của ticket này và mô tả ngắn gọn nếu cần.

Họp Scrum/Scrum Events

Các cuộc họp Scrum được giảm thiểu bằng chỉ daily standup. Các sự kiện lên kế hoạch đầu sprint, grooming giữa sprint và review, retrospective cuối sprint được hủy (nếu rất cần thiết và rất muốn, nhóm có thể thực hiện). Nhóm tổ chức họp theo mục đích cụ thể khi cần thiết. (không khuyến khích)

Giá trị Chính của Kanban/Kanban’s Key Values

Giá trị, nguyên tắc chính của Kanban như sau:

Giới hạn Công việc/Limit WIP

Trong một thời điểm, Kanban giới hạn lượng công việc đang làm (WIP: Work in Progress) tối thiểu và tối đa một người làm.

Số lượng tác vụ tối thiểu là một (cho một người): Lúc nào thành viên cũng có việc để làm.

Số lượng tác vụ tối đa là ba (nhóm có 3 lập trình viên): Đừng nhiều quá, đừng ít quá.

Limit WIP có lợi ích gì?

1. Giúp thành viên tập trung,
2. Giảm thiểu thời gian chuyển đổi giữa các việc (task switching và multi tasking),
3. Tránh trình trạng nhiều tác vụ làm đồng thời nhưng bị “treo” – không “done” (trọn vẹn),
4. Người tiếp theo (ví dụ, kiểm thử, bởi tester) không phải đợi quá lâu, không bị tồn tác vụ hay quá tải bởi đầu vào (input) từ công đoạn trước (ví dụ, việc lập trình, bởi lập trình).

Triết lý phía sau Limit WIP là gì?

1. TPS: Toyota Production Systems,
2. Pull/push uyển chuyển,
3. Cải tiến liên tục (continuous improvement). Hãy thử hình dung tốc độ phát triển tăng 3% (rất nhỏ) sau mỗi cycle 2 tuần. Sau 1 năm (24 cycle), tốc độ phát triển tăng với con số kỳ diệu: 200%.

Bạn nên tìm hiểu thêm khái niệm pull, push trong Kanban và TPS.

Lãm Rõ Luồng Công việc/Workflow Visualization

Điều này không mới với nhóm đã sử dụng Jira Agile board.

Thực ra, bảng (かんばん, whiteboard) trong Kanban đơn giản (một cách có chủ đích) hơn rất nhiều so với bảng trong Scrum.

Ở dạng đơn giản nhất, luồng công việc chia làm ba cột: Todo (sắp làm), Doing (đang làm) và Done (đã hoàn thành)

Tùy theo nghiệp vụ và nhu cầu công việc, việc thêm cột là có thể, nhưng lưu ý không quá phức tạp. Ví dụ:

1. Todo, Doing, Verify (Kiểm tra), Done
2. Phân tích, thiết kế, lập trình, kiểm thử, triển khai
3. Thiết kế, lập trình, staging, production (server)
4. …

Câu hỏi Mở/Open Questions

Tôi chưa tìm hiểu và so sánh giữa Scrum, Scrumban và Kanban. Mong các bạn comment và đóng góp ý kiến.

Kết luận/Conclusions

Scrum và Kanban đều tuyệt vời.

Sử dụng đúng công cụ đúng thời điểm là lựa chọn đôi khi khó.

Agile khuyến khích sự đơn giản và cả Scrum, Kanban đều tuân theo nguyên tắc này.