Báo cáo như một Hệ thống Ra quyết định

Báo cáo Jira chỉ hữu ích khi chúng làm thay đổi một quyết định. Biểu đồ burndown có thể cho thấy một sprint có đang tiến triển như dự kiến hay không, nhưng không giải thích được tại sao công việc bị hoàn thành muộn. Biểu đồ velocity có thể hỗ trợ lập kế hoạch năng lực, nhưng không phải là bảng xếp hạng hiệu suất. Biểu đồ cumulative flow và control chart cho thấy các mô hình flow, nhưng vẫn cần thảo luận với những người trực tiếp thực hiện công việc. Hãy xem mỗi báo cáo là bằng chứng cho một cuộc trao đổi kinh doanh, không phải một phán quyết tự động.

Hãy sử dụng một trình tự diễn giải nhất quán. Trước tiên, nêu rõ những gì biểu đồ thể hiện trực tiếp. Tiếp theo, xác định các nguyên nhân có thể xảy ra mà không khẳng định chắc chắn. Sau đó, kiểm tra bằng chứng ở cấp độ issue hoặc yêu cầu đội nhóm xác thực các nguyên nhân đó. Cuối cùng, quyết định có cần thay đổi phạm vi, năng lực, workflow hoặc các thỏa thuận làm việc hay không. Trình tự này giúp người quản lý không nhầm lẫn tương quan với quan hệ nhân quả và giữ cho các buổi review tập trung vào kết quả phân phối.

Một bộ báo cáo thực tiễn cần trả lời bốn câu hỏi: Chúng ta có khả năng đạt mục tiêu sprint hiện tại không? Chúng ta có thể dự báo một cách có trách nhiệm bao nhiêu công việc? Công việc đang bị chờ hoặc tồn đọng lâu ở đâu? Việc phân phối có đang trở nên dễ dự đoán hơn không? Các biểu đồ burndown, velocity, cumulative flow và control chart giải quyết những phần khác nhau của hệ thống này và nên được diễn giải cùng nhau.

Đọc Burndown và Velocity

Biểu đồ burndown của một sprint so sánh lượng công việc còn lại với thời gian còn lại trong sprint. Không bắt buộc đường biểu đồ phải giảm đều, vì công việc Agile hiếm khi hoàn thành với tốc độ không đổi mỗi ngày. Tuy nhiên, các mô hình lặp lại cần được chú ý. Một đường phẳng rồi giảm mạnh ở giai đoạn cuối có thể cho thấy story quá lớn, hoạt động kiểm thử bị trì hoãn, việc nghiệm thu diễn ra muộn hoặc Jira được cập nhật không thường xuyên. Đường biểu đồ đi lên có thể phản ánh việc bổ sung phạm vi hoặc thay đổi ước tính. Trước khi đưa ra kết luận, hãy kiểm tra sprint report và lịch sử issue để phân biệt thay đổi phạm vi với sự chậm trễ trong thực thi.

Velocity cho thấy lượng công việc đã được ước tính và hoàn thành qua các sprint. Khi dự báo, hãy sử dụng một số sprint gần đây do cùng một đội nhóm hoàn thành trong các điều kiện tương đương. Nếu velocity của năm sprint gần nhất lần lượt là 31, 34, 29, 33 và 18 story point, giá trị cuối cùng có thể phản ánh kỳ nghỉ, sự cố hoặc thay đổi nhân sự trong đội. Một dự báo hợp lý cần ghi nhận bối cảnh đó. Khi không có nguyên nhân đặc biệt, cam kết ở gần mức thấp hơn của khoảng gần đây thường an toàn hơn việc sử dụng kết quả cao nhất hoặc một giá trị trung bình đơn giản nhưng lạc quan.

Không sử dụng velocity để so sánh các đội nhóm hoặc đánh giá cá nhân. Story point là các ước tính được định nghĩa trong phạm vi riêng của từng đội, vì vậy 30 point của đội này không tương đương với 30 point của đội khác. Tổng số point tăng cũng có thể là kết quả của việc thổi phồng ước tính thay vì tạo ra nhiều giá trị hơn cho khách hàng. Trong buổi sprint review, hãy liên hệ velocity với các mục tiêu đã đạt được, các kết quả đã phát hành và mức độ tin cậy của dự báo. Hãy hỏi liệu đội nhóm có phân phối giá trị dự kiến một cách dễ dự đoán hay không, thay vì hỏi họ có tạo ra đủ point hay không.

Chẩn đoán dòng công việc bằng Biểu đồ Dòng tích lũy

Biểu đồ dòng tích lũy hiển thị số lượng issue ở mỗi trạng thái trong workflow theo thời gian. Độ dày theo chiều dọc của một dải biểu thị khối lượng công việc ở trạng thái đó. Nếu dải Đang thực hiện mở rộng trong khi dải Đã hoàn tất tăng chậm, công việc đang đi vào giai đoạn phát triển nhanh hơn tốc độ hoàn tất. Điều này thường báo hiệu có quá nhiều công việc được thực hiện song song, các issue bị chặn, năng lực review bị hạn chế hoặc việc kiểm thử bị trì hoãn. Một tập hợp các dải tương đối song song và ổn định cho thấy hệ thống cân bằng hơn.

Hãy diễn giải biểu đồ dựa trên tốc độ đến, tốc độ hoàn tất, công việc đang thực hiện và lead time. Ví dụ, nếu đội phát triển bắt đầu mười issue mỗi tuần nhưng bộ phận kiểm thử chỉ hoàn tất sáu issue, hàng đợi kiểm thử sẽ tăng lên ngay cả khi mọi chuyên gia đều có vẻ bận rộn. Bắt đầu thêm công việc sẽ khiến vấn đề kinh doanh nghiêm trọng hơn vì phản hồi và việc hiện thực hóa giá trị bị trì hoãn. Quyết định phù hợp có thể là tạm dừng bắt đầu công việc mới, hỗ trợ giải phóng trạng thái đang bị nghẽn hoặc thiết lập giới hạn công việc đang thực hiện.

Cấu hình workflow rất quan trọng. Nếu issue vẫn ở trạng thái Đang thực hiện trong khi chờ phê duyệt từ bên ngoài, biểu đồ không thể phân biệt công việc đang được xử lý với công việc đang chờ. Đội có thể cần một trạng thái chờ hoặc bị chặn hiển thị rõ ràng, một cờ bị chặn hoặc các quy tắc chuyển trạng thái rõ ràng hơn. Mọi điều chỉnh workflow nên cải thiện khả năng quan sát để ra quyết định thay vì tạo thêm sự phức tạp hành chính. Hãy xác nhận rằng các trạng thái phản ánh những điểm bàn giao có ý nghĩa và Đã hoàn tất thể hiện chính sách hoàn tất đã được thống nhất.

Đánh giá khả năng dự đoán bằng Biểu đồ Kiểm soát

Biểu đồ kiểm soát hiển thị cycle time của các issue đã hoàn tất. Trong Jira, các đội có thể xem công việc mất bao lâu từ một trạng thái bắt đầu được chọn đến một trạng thái kết thúc được chọn. Trung vị cho biết kết quả điển hình, còn phân phối và các giá trị ngoại lệ cho thấy mức độ biến động. Một đội có cycle time trung vị là năm ngày và phần lớn issue được hoàn tất trong khoảng từ bốn đến tám ngày có thể dự báo tự tin hơn một đội có cùng giá trị trung vị nhưng thường xuyên có issue mất đến hai mươi ngày.

Hãy phân đoạn dữ liệu trước khi hành động. Bug, yêu cầu dịch vụ nhỏ và các product story lớn có thể có những đặc điểm cycle time khác nhau. Việc thay đổi đội ngũ, thay đổi workflow hoặc áp dụng Definition of Done mới cũng có thể khiến dữ liệu cũ khó so sánh hơn. Hãy sử dụng bộ lọc theo loại issue, component, resolution, khoảng thời gian hoặc lớp dịch vụ để mẫu dữ liệu phù hợp với loại công việc đang được dự báo. Đừng xóa các giá trị ngoại lệ bất tiện; hãy điều tra chúng vì chúng thường cho thấy các phụ thuộc, yêu cầu chưa rõ ràng hoặc sự chậm trễ trong phê duyệt.

Để dự báo cho doanh nghiệp, hãy thể hiện xác suất và khoảng thời gian thay vì đưa ra một ngày hoàn tất được đảm bảo. Nếu 85 phần trăm các issue tương đương được hoàn tất trong vòng mười ngày, đội có thể giải thích rằng một issue có quy mô tương tự và không có dependency trong lịch sử có xác suất cao sẽ được hoàn tất trong khoảng thời gian đó. Đây không phải là một lời hứa. Phạm vi, thay đổi ưu tiên, thời gian bị chặn và chất lượng dữ liệu vẫn là những giả định cần được nêu rõ.

Áp dụng Kết quả trong các Buổi Review và Retrospective

Sprint review nên sử dụng các báo cáo để làm rõ trạng thái bàn giao và hỗ trợ stakeholder ra quyết định. Trước tiên, hãy trình bày kết quả của sprint goal, sau đó là các outcome đã được chấp nhận, những thay đổi phạm vi đáng kể và dự báo được cập nhật. Chỉ sử dụng burndown hoặc velocity khi chúng giúp giải thích mức độ tin cậy hoặc rủi ro. Ví dụ, việc hoàn tất trễ lặp đi lặp lại có thể là cơ sở để chia milestone của bản phát hành tiếp theo thành các increment nhỏ hơn hoặc đưa một tính năng có giá trị thấp hơn ra khỏi dự báo ngắn hạn.

Retrospective nên chuyển các pattern thành những cải tiến có thể kiểm chứng. Hãy tách biệt sự kiện và diễn giải: sự kiện có thể bao gồm mười chín issue đang thực hiện và cycle time trung vị tăng từ bốn lên bảy ngày; diễn giải có thể là năng lực review đang bị hạn chế. Hãy kiểm chứng diễn giải bằng cách xem xét thời gian issue ở mỗi trạng thái, thời gian bị chặn, lịch sử issue và kinh nghiệm của đội. Sau đó, chọn một hoặc hai thay đổi mà đội có thể thực tế đánh giá trong sprint tiếp theo.

Một thử nghiệm tốt bao gồm vấn đề, hành động, người phụ trách, phép đo và ngày review. Một ví dụ là giới hạn công việc phát triển đang thực hiện ở mức tám issue trong một sprint, với delivery lead theo dõi các lần vượt giới hạn hằng ngày; thành công có nghĩa là số lượng issue tồn đọng lâu giảm xuống và throughput không suy giảm. Một ví dụ khác là chia các story đã lập kế hoạch để mỗi story thường có thể đạt trạng thái Đã hoàn tất trong vòng bốn ngày làm việc; thành công có nghĩa là dưới 15 phần trăm story đã hoàn tất có cycle time vượt quá tám ngày. Các phép đo này kiểm tra việc cải thiện hệ thống mà không biến metric thành chỉ tiêu cá nhân.

Checklist Dự báo và Cải tiến

Trước khi công bố một dự báo, hãy xác nhận rằng dữ liệu phản ánh các hạng mục công việc có thể so sánh, ngày tháng trong workflow là đáng tin cậy và những thay đổi gần đây về năng lực đã được ghi nhận. Hãy sử dụng công việc đã hoàn thành thay vì công việc đã cam kết làm cơ sở lịch sử. Khi mức độ biến động đáng kể, hãy đưa ra một khoảng dự báo, nêu rõ các giả định và giải thích mức độ tin cậy bằng ngôn ngữ kinh doanh dễ hiểu. Dự báo phải giúp các bên liên quan đưa ra đánh đổi; không được che giấu sự không chắc chắn đằng sau một con số chính xác.

Trong mỗi chu kỳ review, hãy kiểm tra xem phạm vi sprint có thay đổi không, công việc có bị tích tụ ở một status nào không, độ phân tán của cycle time có tăng không và các giá trị ngoại lệ có cùng một nguyên nhân không. Hãy so sánh các tín hiệu từ báo cáo thay vì chỉ dựa vào một biểu đồ. Burndown trễ kết hợp với vùng In Progress mở rộng và cycle time tăng là bằng chứng thuyết phục hơn về vấn đề trong flow so với bất kỳ quan sát riêng lẻ nào trong số đó.

Cải tiến liên tục chỉ hoàn tất khi team đánh giá lại thử nghiệm. Trong buổi retrospective tiếp theo, hãy so sánh chỉ số đã thống nhất với đường cơ sở, ghi nhận những gì đã thay đổi và quyết định áp dụng, điều chỉnh hoặc dừng thực hành đó. Duy trì các chỉ số ở cấp độ team và hệ thống, kết hợp báo cáo định lượng với kết quả dành cho khách hàng và bảo toàn bối cảnh. Mục tiêu không phải là một biểu đồ hoàn hảo. Mục tiêu là một hệ thống delivery tạo ra kết quả có giá trị với mức độ có thể dự đoán ngày càng cao và phát hiện rủi ro đủ sớm để doanh nghiệp có thể ứng phó.