Agile cho những dự án bảo trì

Chúng ta biết rằng Scrum và Kanban là hai phương pháp Agile được yêu thích. Scrum phù hợp nhất cho các dự án phát triển và các sản phẩm. Kanban thích hợp nhất cho hỗ trợ sản xuất. Chúng ta dùng Scrumban – kết hợp những đặc điểm tốt nhất của 2 phương pháp – cho những dự án bảo trì. Ngày nay Scrumban đang rất phổ biến trong các ngành dịch vụ, nơi mà chúng ta có cả các dự án bảo trì lẫn các dự án phát triển.

Tóm lược về Scrum

• Chia tổ chức thành các nhóm nhỏ, liên chức năng, tự tổ chức.
• Chia công việc thành danh sách các phần nhỏ, cụ thể có thể chuyển giao. Sắp xếp danh sách theo độ ưu tiên và ước lượng độ lớn tương đối.
• Chia thời gian thành những phân đoạn ngắn, độ dài cố định (thường từ 1-4 tuần/1 phân đoạn), sau mỗi phân đoạn mã nguồn của các chức năng đã sẵn sàng để trình diễn.
• Dựa vào thông tin thu được thông qua thanh tra sau mỗi phân đoạn và cộng tác với khách khách để tối ưu hóa kế hoạch phát hành và cập nhật độ ưu tiên.
• Tối ưu hóa quy trình bằng cách cải tiến sau mỗi phân đoạn.

Tóm lược về Kanban

Trực quan hóa luồng công việc

• Chia công việc thành các hạng mục, viết mỗi mục lên một tấm thẻ và đặt lên tường.
• Dùng các cột được đặt tên để phân biệt vị trí mỗi mục trong luồng công việc.

Giới hạn việc đang làm (Limit WIP): Đặt ra giới hạn rõ ràng về số lượng việc đang làm tại mỗi trạng thái luồng công việc.

Đo lường thời gian hoàn thành(thời gian trung bình để hoàn thành một hạng mục – cycle time), và tối ưu hóa quy trình để giảm thời gian hoàn thành càng nhỏ và càng dễ đoán càng tốt

Luồng công việc

Sự khác biệt về các quy tắc giữa 2 phương pháp tạo ra sự khác biệt trong cách hạng mục công việc được xử lý qua thời gian.

Trong Scrum, trước tiên bạn chọn công việc bạn sẽ làm cho Sprint tiếp theo. Sau đó bạn không được thay đổi công việc trong Sprint, sau khi hoàn thành tất cả công việc và kết thúc Sprint thì hàng đợi của bạn bị trống.

Trong Kanban, điều duy nhất bị giới hạn là cỡ của hàng đợi, được gọi là giới hạn WIP. Điều này nghĩa là bạn có thể thay đổi các hạng mục trong hàng đợi bất kỳ lúc nào, và không có “kết thúc Sprint”. Công việc liên tục chảy theo luồng.

Scrumban = Scrum + Kanban

• Dùng quy tắc của Scrum để trở nên Agile
• Dùng cách cải tiến quy trình của Kanban giúp nhóm liên tục cải tiến quy trình

Với hệ thống kéo của Kanban, luồng làm việc sẽ trở nên trơn tru hơn khi quy trình được cải tiến. Ta có thể dùng bộ đệm liên tiến trình và biểu đồ luồng để tìm ra những điểm yếu của quy trình và những cơ hội để Kaizen. Khi tiếp cận đến mức sản xuất, ta sẽ ít quan tâm đến burndown và để ý hơn đến thời gian hoàn thành, bởi vì một bên là kết quả còn bên kia là nguyên nhân. Thời gian tổng(lead time) và thời gian hoàn thành trung bình sẽ trở thành mục tiêu chính cần đạt được. Nếu thời gian hoàn thành trong tầm kiểm soát và khả năng của nhóm được cân bằng so với yêu cầu thì thời gian tổng cũng sẽ được kiểm soát. Nếu thời gian hoàn thành được kiểm soát thì những đường burndown có thể đoán được và không còn hấp dẫn nữa.

Với Scrumban, do nhóm kéo công việc vào các hàng đợi nhỏ trước khi kéo vào cột đang làm, nhóm cần điều chỉnh backlog làm sao để nó luôn gồm những thứ đáng để làm tiếp. Do vậy, chúng ta nên dùng cơ chế ít lãng phí nhất để thỏa mãn điều kiện đơn giản đó.

Một cơ chế đơn giản làm được việc đó là giới hạn kích cỡ backlog của  phân đoạn. Thay vì phải ước tính khối lượng công việc cho mỗi phân đoạn, ta chỉ cần cố định cỡ của backlog, dù cho backlog thi thoảng có thể bị hết hạng mục trước khi phân đoạn kết thúc. Đây là một cách làm đơn giản.

Trong Scrumban, chúng ta có thể lập kế hoạch Sprint sau một khoảng thời gian cố định, đồng bộ cùng phiên Sơ kết và Cải tiến, nhưng mục đích của lập kế hoạch là thêm công việc vào các hạng mục còn trống chứ không phải thêm vào tất cả các hạng mục và tất nhiên là không dùng để quyết định số lượng hạng mục trong Sprint. Điều này giảm số lượng các buổi họp. Số thời gian họp này có thể dùng cho việc kiểm tra chất lượng các công việc trong mục sẵn sàng. Nếu một hạng mục chưa đạt tiêu chuẩn thì trả về để người làm phân tích tìm ra nguyên nhân chính.

*Ưu điểm

• Chất lượng
• Chỉ-khi-cần (ra quyết định chỉ khi cần)
• Thời gian tổng ngắn
• Kaizen (cải tiến liên tục)
• Giảm thiểu tối đa lãng phí (những thứ mà không tạo giá trị cho khách hàng)
• Cải tiến quy trình bằng cách thêm các giá trị của Scrum trong trường hợp cần thiết

Khi nào nên dùng Scrumban

• Các dự án bảo trì
  • Công việc hướng sự kiện
  • Trợ giúp/Hỗ trợ
• Giai đoạn đóng gói/phát hành
• Những dự án thường có những User story đột xuất hay nhiều lỗi lập trình
• Nhóm phát triển sản phẩm mới dùng khi
  • Làm những Sprint trước Sprint phát triển (làm backlog, R&D)
  • Làm những Sprint sau Sprint phát triển (kiểm thử hệ thống, đóng gói, triển khai)
• Nếu Scrum khó triển khai do các vấn đề luồng công việc, nguồn lực và quy trình
• Để quản lý các cộng đồng cải tiến trong/sau khi triển khai Scrum

Scrumban Backlog

• Tránh tạo/phân tích quá nhiều User story (về yêu cầu/lỗi) – giảm lãng phí
• Đảm bảo phân tích đầy đủ trước khi bắt đầu phát triển
• Backlog nên hướng sự kiện cùng điểm thứ tự
• Xếp độ ưu tiên theo yêu cầu – quy trình lập kế hoạch công việc lý tưởng nên cung cấp cho nhóm công việc tốt nhất để làm tiếp, không hơn không kém

Bảng Scrumban

Kanban vs. Scrumban

Scrum vs. Scrumban

Tóm tắt

Về phương pháp quản trị dự án, Kanban tương thích với Scrum. Kanban bổ sung giới hạn công việc đang làm và trực quan hóa cho Scrum (ví dụ Scrumban), giúp cải tiến hiệu suất được cam kết của Sprint. Tuy nhiên, giới hạn WIP cũng tạo ra cơ chế kích hoạt những thay đổi tăng dần. Giới hạn WIP giúp thay đổi xảy ra mà không cần cam kết để thúc đẩy, giảm phụ thuộc vào các nỗ lực cá  nhân, và cải tiến tư duy toàn hệ thống trong khi xem xét các cải tiến tiềm tàng. Scrumban giống Scrum trong các hoạt động cụ thể nhưng ở cấp độ văn hóa nó lại giống Kanban – tiến hóa nhẹ nhàng thay vì thay đổi mạnh mẽ và đột phá.

Nguồn: Agile Alliance

Người dịch: Nguyễn Trung Tuyến