5 Agile Metrics

Số liệu là một chủ đề nhạy cảm. Chúng ta hầu như đều ở trong một dự án mà không có dữ liệu nào được theo dõi, rất khó để nói được rằng không biết chúng ta có đang kịp tiến độ bàn giao hoặc là có đang làm việc hiệu quả hay không. Mặt khác, nhiều người trong chúng ta đã gặp phải bất hạnh khi tham gia vào các dự án mà các số liệu thống kê được sử dụng làm vũ khí để đánh giá. Vì vậy, không có gì ngạc nhiên khi hầu hết các đội đều có mối quan hệ yêu / ghét với các chỉ số.

Tuy nhiên theo dõi và chia sẻ các chỉ số Agile metric có thể giúp giảm thiểu những nhầm lẫn, làm sáng tỏ tiến độ của team trong suốt quá trình phát triển.

Hiểu về doanh nghiệp của bạn

Trạng thái "Done" chỉ cho thấy một phần. Đó là về việc xây dựng đúng sản phẩm, vào đúng thời điểm, cho đúng thị trường. Duy trì theo dõi trong suốt chương trình có nghĩa là thu thập và phân tích một số dữ liệu. Trong bất kỳ Agile program nào, điều quan trọng là theo dõi cả chỉ số kinh doanh (business metrics) và Agile metrics. Agile metrics tập trung vào việc liệu giải pháp có đáp ứng được nhu cầu của thị trường và có giúp đo các khía cạnh của quá trình phát triển hay không.

Có một số chỉ số hoạt động quan trọng như (KPIs) để hướng tới mục tiêu của dự án. Ngoài ra, bao gồm các tiêu chí thành công cho mỗi yêu cầu sản phẩm như tỷ lệ chấp nhận bởi end user hoặc tỷ lệ phần trăm code được kiểm tra tự động. Các tiêu chí thành công này được đưa vào Agile metrics. Và càng có nhiều đội dự án học, thì họ càng có khả năng thích ứng và phát triển.

Cách sử dụng số liệu nhanh để tối ưu hóa việc bàn giao

Các số liệu Agile metrics được thảo luận dưới đây tập trung vào việc bàn giao phần mềm. Cho dù nhóm bạn là một nhóm scrum hoặc kanban, mỗi một số liệu Agile metrics này sẽ giúp nhóm hiểu rõ hơn về quá trình phát triển của họ, làm cho việc bàn giao phần mềm dễ dàng hơn.

1. Sprint Burndown Các đội Scrum tổ chức phát triển thành các Sprint. Ngay từ khi bắt đầu sprint, nhóm dự định họ sẽ hoàn thành bao nhiêu công việc trong suốt sprint. Một sprint burndown report có thể giúp theo dõi việc hoàn thành công việc trong suốt sprint. Trục nằm ngang đại diện cho thời gian, và trục thẳng đứng đề cập đến số lượng công việc còn lại để hoàn thành. Mục đích là để có được tất cả các công việc được dự đoán hoàn thành vào cuối sprint. Một teamluôn tuân thủ kế hoạch của mình là sẽ là một hình mẫu tốt về Agile đối với tổ chức, công ty của họ. Nhưng đừng để điều đó khiến cho bạn gặp lúng túng khi cố gắng chạy theo các con số dự kiến. Nó có thể nhìn tốt trong ngắn hạn, nhưng về lâu dài chỉ cản trở việc học tập và cải tiến. Ví dụ về một kiểu mẫu đối lập

• Team hoàn thành sprint sớm vì không cam kết đủ số lượng công việc.
• Team bỏ qua kế hoạch sprint vì khối lượng công việc cam kết của họ quá nhiều
• Đường burndown chart giảm đột ngột chứ không phải giảm một cách từ từ, lý do là công việc không được chia nhỏ.
• Product owner thêm hoặc thay đổi scope giữa chừng, khi đang trong sprint.

2. Epic và Release Burndown Epic và Release Burndown theo dõi tiến độ phát triển của dự án trên một diện rộng hơn so với sprint burndown và nó sẽ là một hướng dẫn cho cả đội scrum và kanban team. Kể từ khi sprint (đối với scrum team) có thể chứa các công việc từ nhiều epic hoặc gồm các công việc trong nhiều version thì điều quan trọng là phải theo dõi cả tiến độ của từng sprint cũng như epic và version.

"Scope creep" là việc thêm nhiều yêu cầu vào phạm vi một dự án đã được xác định trước. Ví dụ: nếu nhóm đang cung cấp một trang web mới cho công ty, "Scope creep" sẽ yêu cầu các tính năng mới sau khi các yêu cầu ban đầu đã được đưa ra. Trong khi chấp nhận “scope creep” trong sprint là một hoặt động xấu thì việc thay đổi scope là một hệ quả tự nhiên của agile developement. Khi nhóm tiếp tục làm thì PO có thể quyết định tiếp nhận hoặc xóa bỏ các yêu cầu thêm mới này tùy theo tình trạng hiện tại. Epic và release burndown chart giúp mọi người nhận thức được luồng công việc bên trong epic và version. Ví dụ về một kiểu mẫu đối lập

• Kế hoạch cho epic và realease không được cập nhật khi nhóm làm việc.
• Không có tiến đô nào được thực hiện trong một khoảng thời gian lặp đi lặp lại.
• “ scope creap” là một dấu hiệu cho thấy PO không hiểu hết vấn đề mà dự án đang cố gắng giải quyết.
• Scope dự án tăng nhanh hơn so với khả năng giải quyết của team.
• Team không bàn giao các phần tăng trưởng trong suốt quá trình phát triển epic.

3. Tốc độ (Velocity) Velocity là lượng công việc trung bình mà đội scrum hoàn thành trong sprint, được đo bằng story point hoặc là thời gian (giờ) và rất hữu ích cho việc dự báo. PO có thể sử dụng velocity để dự đoán tốc độ làm việc của team thông qua backlog, vì report được theo dõi những dự báo và công việc hoàn thành thông qua các vòng lặp (sprint), qua càng nhiều sprint thì việc dự báo càng trở nên chính xác hơn. Giả sử PO muốn hoàn thành 500 story point trong backlog. Chúng ta biết rằng development team thường hoàn thành 50 story point trong mỗi sprint. PO có thể biết được team sẽ mất khoảng 10 sprint để hoàn thành công việc trong backlog.

Điều quan trọng là theo dõi tốc độ phát triển theo thời gian. Một team mới có thể mong đợi để nhìn thấy sự tăng trưởng về velocity khi team tối ưu hóa các mối quan hệ và quá trình làm việc. Các team hiện tại có thể theo dõi velocity của họ để đảm bảo hiệu suất nhất quán theo thời gian và có thể xác nhận rằng mỗi khi có sự thay đổi trong quy trình làm việc thì thay đổi đó có hiệu quả hay không. Giảm velocity trung bình thường là một dấu hiệu cho thấy một phần của quá trình phát triển của nhóm đã trở nên không hiệu quả và nên được đưa ra tại buổi retrospective tiếp theo. Ví dụ về một kiểu mẫu đối lập

Khi velocity không ổn định trong một khoảng thời gian dài, hãy luôn nhắc lại các phương pháp estimate của nhóm. Trong buổi retrospective của nhóm, hãy hỏi những câu hỏi sau:

• Có hay không những thách thức phát triển mà không tính đến khi ước tính công việc? Làm thế nào chúng ta có thể chia nhỏ công việc để tìm ra các điểm khó khăn này?
• Có áp lực kinh doanh bên ngoài đẩy team vượt quá giới hạn không?
• Chúng ta có đang quá vội cho việc dự báo cho sprint không? Velocity của mỗi team là khác nhau. Nếu team A có velocity 50 và team B có velocity 75 thì điều đó không có nghĩa là team B có năng suất cao hơn. Vì cách thức ước tính của mỗi team là duy nhất.

4. Control Chart Control chart tập trung vào thời gian chu kỳ(cycle time) của các vấn đề riêng lẻ-tổng thời gian từ khi status là "inprogress" đến "done". Các team với cycle time ngắn hơn có thể sẽ có năng suất cao hơn, và các team có cycle time nhất quán trong nhiều vấn đề có thể dự đoán được trong việc điều chỉnh và phân bổ công việc. Trong khi cycle time là chỉ số chính cho nhóm kanban, scrum team cũng có thể áp dụng. đo lường cycle time là một cách hiệu quả và linh hoạt để cải tiến quy trình của nhóm vì kết quả của những thay đổi có thể nhận định gần như ngay lập tức, cho phép họ thực hiện bất kỳ điều chỉnh nào ngay lập tức. Mục đích cuối cùng là phải có cycle time nhất quán và ngắn, bất kể loại công việc (tính năng mới, kỹ thuật, v.v.). Ví dụ về một kiểu mẫu đối lập

Control chart có thể xuất hiện thay đổi trong thời gian đầu. Đừng quá lo lắng, nhìn vào xu hướng. Dưới đây là hai khu vực cần lưu ý: Cycle time thất thường - Mục tiêu là có cycle time nhất quán cho các iteam có giá trị story point tương tự nhau. Filter control chart cho mỗi giá trị story point để kiểm tra tính nhất quán. Nếu cycle time thất thường trên các giá trị story point lớn, nhỏ thì hãy dành thời gian để xem xét lại những sai sót và cải thiện estimate trong tương lai.

5. Cumulative Flow Diagram Sơ đồ luồng tích lũy là một nguồn lực chính cho các team Kanban, giúp họ đảm bảo luồng công việc trong toàn team là nhất quán. Với số lượng các vấn đề trên trục Y, thời gian trên trục X, và màu sắc để biểu thị các trạng thái công việc khác nhau, nó chỉ ra sự thiếu hụt và tắc nghẽn. Sơ đồ luồng tích lũy (Cumulative Flow Diagram) nên trông mịn từ trái sang phải. Bong bóng hoặc các khoảng trống ở bất kỳ màu nào cho thấy tình trạng thiếu hụt và thắt cổ chai, vì vậy khi bạn nhìn thấy các biểu hiện đó thì hãy tìm cách làm mịn các dải màu trên biểu đồ. Ví dụ về một kiểu mẫu đối lập

• Các blocker tạo ra các khoảng backup lớn trong một phần của tiến độ
• Unchecked backlog không được kiểm soát theo thời gian. Điều này xuất phát từ PO không close các issue quá cũ hoặc đơn giản là đưa vào các issue với low priority

Nhiều chỉ số khác

Các good metric không chỉ giới hạn ở các metric được liệt kê bên trên. Ví dụ: chất lượng là một thước đo quan trọng cho các nhóm agile và có một số metric truyền thống có thể được áp dụng vào agile development.

• Có bao nhiêu defects được tìm thấy ...
• trong quá trình phát triển?
• sau khi phát hành cho khách hàng?
• bởi những người bên ngoài của nhóm?
• Có bao nhiêu defects được hoãn lại để bàn giao trong tương lai?
• Có bao nhiêu yêu cầu hỗ trợ khách hàng đến?
• Tỷ lệ phủ sóng kiểm tra tự động là bao nhiêu? Nhóm Agile cũng nên xem xét tốc độ bàn giao và tốc độ phân phối. Vào cuối mỗi sprint, nhóm sẽ release trên production. Bao lâu thì điều đó thực sự xảy ra? Hầu hết các phiên bản phát hành đều được vận chuyển, phải mất bao lâu để team tìm ra giải pháp khắc phục khẩn cấp? Liệu việc release có dễ dàng cho team không? Chỉ số chỉ là một phần trong việc xây dựng văn hoá của một team. Chúng đưa ra cái nhìn sâu sắc về số lượng hoạt động của team và cung cấp các mục tiêu đo lường cho team. Mặc dù chúng quan trọng nhưng đừng bị ám ảnh. Lắng nghe phản hồi của team trong buổi retrospective cũng không kém phần quan trọng trong việc tăng sự tin tưởng trong nhóm, chất lượng sản phẩm và tốc độ phát triển thông qua quá trình bàn giao. Sử dụng cả phản hồi định tính và định tính để thúc đẩy sự thay đổi.

Nguồn: https://www.atlassian.com/agile/metrics