Thực hành áp dụng Cumulative Flow trong bối cảnh Scrum và SAFe
Trong bài viết này, tôi dự định kể về cách trong thực tế của chúng tôi, chúng tôi áp dụng Cumulative Flow Chart trong Scrum trong quá trình làm việc theo framework SAFeBlog cá nhân.
Không thể tải ảnh này.Trong bài viết này, tôi dự định kể về cách trong thực tế của chúng tôi, chúng tôi áp dụng Cumulative Flow Chart trong Scrum trong quá trình làm việc theo framework SAFe
Có lẽ tôi sẽ bắt đầu bằng liên kết đến bài viết này - theo tôi, ở đây mục đích của nó ở dạng chuẩn được mô tả tốt, tôi khuyên nên nghiên cứu trước khi đọc bài viết của tôi. Dưới đây tôi sẽ mô tả cách chúng tôi đã điều chỉnh nó cho quy trình Scrum (ban đầu nó được sử dụng trong Kanban) và những vấn đề nào nó giúp chúng tôi giải quyết khi làm việc theo sprint.
Trước đó, trong bài viết về Burn Down Charts tôi đã nói rằng ở đó chúng ta thấy sự xuất hiện của công việc mới và sự cháy đi của công việc cũ. Vấn đề của Burn Down Chart là, khác với Cumulative Flow Chart, trên đó chúng ta không thấy sự di chuyển của User Story theo các trạng thái. Khi chúng ta bắt đầu quan sát sự di chuyển theo các trạng thái trong Cumulative Flow Chart, chúng ta bắt đầu thấy những thay đổi hàng ngày (Burn Down Chart có thể không thay đổi trong vài ngày và trong một số bối cảnh điều này có thể hoàn toàn bình thường) và có thể nhận ra những vấn đề tinh tế hơn.
Đây là cách nó có thể trông trong động thái (trong hình là biểu đồ được xây dựng trên dữ liệu thực tế).
Trong ví dụ này chúng ta thấy như sau
- 7 ngày đầu tiên của sprint có rất ít khối lượng công việc trong kiểm thử và nó không thay đổi
- Từ DOR (ở đây là bản nháp) các User Story chuyển sang công việc khá đều đặn - điều này tốt.
- Cũng như trên Burn Down, chúng ta thấy rằng theo xu hướng các User Story sẽ không được hoàn thành vào cuối sprint
Ba quan sát này cùng nhau dẫn đến kết luận sau. Ở đây rõ ràng ngay từ giai đoạn đầu (khoảng ngày thứ hai-thứ ba của sprint) Scrum Master cần chú ý đến lớp "Kiểm thử", lớp này quá nhỏ và không thay đổi đủ lâu (xác minh nguyên nhân). Có thể giả định rằng khối lượng công việc sẵn sàng cho kiểm thử không thể được kiểm thử vì một số lý do nào đó, nhưng khi đó điều này có nghĩa là các tester đang nhàn rỗi, và do đó, ít nhất nên lắng nghe họ cẩn thận hơn tại buổi standup gần nhất.
Nếu nói về thực hành áp dụng, thì ví dụ tôi công bố hàng ngày trong chat của đội tất cả các chỉ số trước standup với việc nhắc đến toàn bộ đội.
Nhìn chung, không nên quên rằng dù sao các chỉ số cũng cần được diễn giải đúng. Biết nhìn thấy thực sự những vấn đề hệ thống nếu có và không coi là vấn đề những gì trong bối cảnh của bạn thậm chí có thể là dấu hiệu tích cực
