Scrumban- tối ưu hoá 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.

scrumban table- workflow

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-wip

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 đó.

scrumban-examples

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

scrumban

Kanban vs. Scrumban

Kanban Scrumban
Vai trò Không định rõ vai trò Có nhóm và các vai trò cần thiết
Scrum hàng ngày Không có Để đảm bảo công việc liên tục đúng yêu cầu và giảm thời gian nhàn rỗi của thành viên nhóm
Lập kế hoạch Sprint Không có Có thể lập kế hoạch khi cần thêm hạng mục
Họp Sơ kết và Cải tiến Không định rõ Có thể làm khi cần cải tiến quy trình và chia sẻ kiến thức
Luồng công việc Liên tục Giống Kanban, thêm giới hạn hạng mục để quy trình kéo dễ dàng hơn

Scrum vs. Scrumban

Scrum Scrumban
Bảng/Tạo tác Bảng, backlog, burndown Chỉ có bảng
Sự kiện Scrum Hằng ngày, Lập kế hoạch Sprint, Sơ kết Sprint, Cải tiến Sprint Scrum Hằng ngày (Nếu cần có thể họp Lập kế hoạch, Sơ kết, Cải tiến)
Phân đoạn Có (Sprint) Không (luồng liên tục)
Ước tính Không (cỡ tương tự)
Nhóm Phải là liên chức năng Có thể chuyên môn hóa
Vai trò ScrumMaster, Product Owner, Nhóm phát triển Nhóm phát triển + các vai trò cần thiết khác
Làm việc nhóm Cộng tác khi cần Cùng làm để đạt được mục tiêu
Limit WIP Tùy theo công việc của Sprint Tùy theo trạng thái của luồng công việc
Thay đổi Phải chờ đến Sprint sau Khi cần thì thêm vào bảng (cột To Do)
Product Backlog Danh sách các User story đã được ước tính và xếp ưu tiên Gồm các thẻ hạng mục công việc được thêm vào khi cần
Trở ngại Xử lý trở ngại Phòng tránh

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

phản hồi

Leave a Reply

Your email address will not be published.