Thực tiễn áp dụng Burn Down Charts trong bối cảnh SAFe và Scrum

Trong bài viết này tôi dự định kể về cách trong thực tiễn của mình chúng tôi áp dụng biểu đồ đốt cháy (Burn Down Chart) trong quá trình làm việc theo phương pháp luận SAFe

Có lẽ tôi sẽ bắt đầu từ điều thú vị nhất. Cụ thể là việc sử dụng biểu đồ này trong SAFe không nên có bất kỳ đặc thù nào so với việc sử dụng biểu đồ này trong SCRUM. Hay là nên?

SAFe của chúng tôi khác biệt ở chỗ có vai trò như RTE, khác với SCRUM, nơi không có vai trò này. Burn Down Chart - đây là công cụ theo dõi khối lượng công việc trong sprint và nó cần thiết trước hết cho đội SCRUM, chứ không phải cho bất kỳ ai bên ngoài, phải không?

Như vậy, dù sao tôi vẫn sẽ chuyển sang việc chúng tôi sử dụng Burn Down Chart như thế nào, bất kể mọi thứ, và, vẫn đang ở bên trong framework SAFe.

Tôi đang ở vai trò Scrum Master và cố gắng làm nổi bật biểu đồ này hàng ngày cho toàn bộ Dev Team. Công cụ mà tôi sử dụng - đó là chat nhóm, nhắc đến toàn bộ đội qua "@", ảnh chụp màn hình trạng thái hiện tại của biểu đồ. Nhắc đến toàn bộ đội - đây là một công cụ khá tinh tế và quan trọng là phải sử dụng nó càng ít càng tốt (dù sao, chúng ta, các Scrum Master, phải giúp đội làm việc thoải mái và với mức độ xao nhãng tối thiểu có thể, phải không?)

Kết quả là đội hàng ngày nhìn thấy trạng thái hiện tại của sprint và có thể theo dõi các sự kiện sau

• Xuất hiện công việc không được lên kế hoạch
• Nhiệm vụ bị treo lâu ở trạng thái chưa hoàn thành
• Đưa vào rủi ro quá mức
• Hiểu - liệu công việc có đang diễn ra đúng nhịp độ

Tiếp theo tôi sẽ cố gắng làm rõ từng sự kiện trong số này và đưa ra ví dụ từ thực tiễn của mình.

Xuất hiện công việc không được lên kế hoạch

Trên biểu đồ này có thể thấy rất rõ cách công việc mới xuất hiện (vào thứ Ba thứ hai của sprint hai tuần).

Trường hợp từ thực tiễn: "Lập trình viên, với tư cách là thành viên của đội scrum chia sẻ các nguyên tắc agile, tương tác rất tốt với Product trực tiếp. Product nói với anh ấy rằng cái này cần phải làm nhanh gọn, bạn cũng tự hiểu mà, ở đây nhanh và rủi ro tối thiểu.

Lập trình viên giỏi, anh ấy biết tất cả về agile và về tầm quan trọng của việc mang lại giá trị kinh doanh, đi ném lên bảng một story từ backlog, đội đã ước lượng nó là 6 sp.

Phần còn lại của đội (ngoài lập trình viên và Product) nhận thấy điều này ở buổi cập nhật biểu đồ buổi sáng. Tại standup đội đưa ra quyết định xử lý tình huống này thế nào. Nhiều khả năng nhất, story bị loại khỏi sprint, đội cho Product và Lập trình viên hiểu rằng không thể làm như vậy, product có thể đưa story này vào sprint tiếp theo nếu cần.

Tất nhiên, lý tưởng nhất là đội phải nhận thấy sự xuất hiện của công việc mới tại standup và không cần biểu đồ. Nhưng biểu đồ là một chỉ báo tốt, giúp giảm thiểu rủi ro không nhận thấy thay đổi quan trọng như vậy đối với toàn đội.

Ở đây quan trọng là phải hiểu rằng kịch bản có thể diễn ra khác nhau tùy thuộc vào trình độ của đội. Trong những đội giỏi, Product Owner khó có thể làm như vậy, mà nếu có làm, thì sẽ lập luận không phải bằng việc «cái này có thể làm nhanh gọn», mà bằng việc «tôi đánh giá xác suất 55% rằng nếu làm cái này ngay bây giờ, thì có thể tăng lợi nhuận của chúng ta thêm 20% trong tháng tới» hoặc một chỉ số đo lường được nào đó.

Nhiệm vụ bị treo lâu ở trạng thái chưa hoàn thành

Ở đây chúng ta thấy rằng công việc không được hoàn thành dù chỉ một phần trong thời gian rất dài. Điều này có thể báo hiệu nhiều vấn đề khác nhau, tôi sẽ liệt kê một số trong đó

• Phân rã công việc kém

  Rất thường xuyên các đội mới nói về việc không thể phân rã. Mọi thứ của họ cháy vào ngày cuối cùng, công việc không được song song hóa, v.v. Tất nhiên, Scrum Master cần phải làm việc với điều này và giải thích giá trị của việc phân rã cho đội.

• DOD được xây dựng không tối ưu

  DOD (Definition of Done) - mô tả các tiêu chí hoàn thành của User Story trong sprint. Đôi khi chúng hoàn toàn không có hoặc được mô tả rất trừu tượng. Đây hoàn toàn có thể là vấn đề, mà tất nhiên, Scrum Master phải giúp giải quyết

Đặt rủi ro quá mức

Trong trường hợp này chúng ta thấy tình huống đội đã đặt rủi ro quá mức.

Có thể một câu chuyện nào đó đã được đánh giá lại. Có thể đây là vấn đề mang tính hệ thống hơn và cần tăng khối lượng công việc khi lập kế hoạch sprint. Trong mọi trường hợp, tình huống này không chính xác. Vì doanh nghiệp đã lên kế hoạch rằng sẽ được triển khai chính xác các nhiệm vụ của sprint và chính xác vào cuối sprint. Tùy thuộc vào cách các phụ thuộc được lập kế hoạch, ở đây rất có thể sẽ phải tổ chức các cuộc họp để điều chỉnh kỳ vọng.

Trong kinh nghiệm của tôi, điều này đã xảy ra khi tìm được một giải pháp nhanh hơn so với những gì đã thảo luận khi đánh giá. Cả đội đã thảo luận xem câu chuyện nào có thể đóng trước cuối sprint và tại buổi retrospective đã thống nhất rằng sẽ cố gắng xem mã khi grooming. Hóa ra chỉ cần nhìn vào mã là đủ để hiểu rằng giải pháp đơn giản hơn nhiều.

Hiểu biết - công việc có đang diễn ra đúng nhịp độ không

Ở đây tôi muốn thu hút sự chú ý đến các cách hiển thị đồ họa không thành công của Burn Down Chart

Ở phần trên của hình ảnh là ví dụ về một cách triển khai đồ họa không mấy thành công vì hai lý do mà tôi sẽ trình bày dưới đây.

• Không thấy rõ việc các SP mới rơi vào sprint

  Ở đây, trên biểu đồ phía trên, gần như không thấy rõ rằng đã thêm công việc không được lập kế hoạch. Ở biểu đồ phía dưới điều này rõ ràng hơn.

• Hiển thị phần công việc còn lại tương đối không chính xác

  Theo biểu đồ phía trên thì còn phải làm việc thêm 3 ngày nữa. Trên thực tế chỉ còn 2, vào ngày nghỉ, có thể ai đó dự định nghỉ ngơi.

Tất nhiên, với ai đó những chi tiết nhỏ như vậy có thể có vẻ không đáng kể. Nhưng cần hiểu rằng mỗi thành viên của đội chỉ liếc qua biểu đồ này và nó phải truyền đạt tối đa thông tin hữu ích.