Số liệu linh hoạt là các phép đo được sử dụng để theo dõi tiến độ và thành công của một nhóm dự án linh hoạt.
Các số liệu, nếu được xác định đúng cách, sẽ cung cấp cái nhìn sâu sắc về hiệu suất, chất lượng, hiệu suất kiểm tra hoặc hiệu quả tổng thể của nhóm cũng như cách nó phát triển theo thời gian.
Mục tiêu cuối cùng của số liệu linh hoạt là giúp các nhóm xác định các lĩnh vực cần cải thiện và đưa ra quyết định dựa trên dữ liệu nhằm tạo ra sản phẩm tốt hơn khi nhóm phát triển.
Hầu hết các công ty xác định số liệu là số liệu ảo hoặc số thô, tăng dần từ trái sang phải. Chúng có thể trông đẹp trên một số trang tổng quan nhưng thường vô dụng đối với bản thân nhóm.
Mục tiêu của họ không phải là giúp đỡ nhóm bằng bất kỳ cách nào mà là hoàn thành một số báo cáo cho ban quản lý và sau đó đưa ra các quyết định chiến lược. Thật không may, đây là lúc nhóm không hiểu tại sao lại có một quyết định cụ thể như vậy.
Trong hàng rào, để đáp ứng các số liệu tồi tệ như vậy, các nhóm sau đó sẽ sắp xếp các quy trình của riêng họ để làm cho các số liệu trông đẹp mắt. Nhưng hiệu suất của đội không được cải thiện chút nào.
Số liệu cơ bản
Có nhiều cách để sắp xếp số liệu. Có lẽ cơ bản nhất là từ trên xuống và từ dưới lên.
➡️ Ý nghĩa từ trên xuống: Những người lãnh đạo chúng tôi sẽ tạo ra cho bạn những thước đo mà chúng tôi muốn tất cả các bạn đáp ứng và mục tiêu cuối cùng của bạn là hòa nhập vào những không gian xanh này. Chúng tôi không quan tâm ban nhạc của bạn có thích họ hay không; đây là những gì chúng tôi muốn theo dõi.
➡️ Từ dưới lên có nghĩa là: Chúng tôi – nhóm cần cải thiện những lĩnh vực này và để làm được điều này, chúng tôi cần tập trung vào chúng. Đó là lý do tại sao chúng tôi xác định các số liệu cho phép chúng tôi theo dõi tiến trình hướng tới mục tiêu của nhóm và chúng tôi có thể cho bạn thấy, ban quản lý, chính xác điều này đã cải thiện công việc của chúng tôi như thế nào theo thời gian.
Định nghĩa về một thước đo tốt
Vậy một số liệu tốt nên chứa những gì hoặc làm thế nào để mô tả nó?
Thuộc tính quan trọng nhất là sự thay đổi hành vi. Điều này có nghĩa là mỗi khi bạn nhìn vào điểm số, bạn sẽ thấy rõ những gì cần thay đổi trong nhóm để đạt được sự cải thiện.
Thế thì nó phải đơn giản. Nếu bạn không thể giải thích nó bằng một vài câu đơn giản để tất cả những người nghe quan tâm có thể hiểu được thì có điều gì đó không ổn.
Một thước đo tốt có thể so sánh được theo thời gian. Chụp nhanh kết quả trong thời gian ngắn, sau đó thực hiện lại. Đặt chúng cạnh nhau. Nếu không thể so sánh hai điểm số, bạn nên suy nghĩ lại về số liệu này.
Cuối cùng, tốt hơn những con số thuần túy, hãy biến nó thành tỷ lệ hoặc phần trăm nếu có thể. “10 lỗi mới mở trong quá trình chạy nước rút” sẽ không nói lên được gì nhiều. Nó phụ thuộc vào việc bạn thường có một hay 100.
Dưới đây là một số ví dụ về các chỉ số mà tôi tin rằng đáp ứng tất cả các tiêu chí định nghĩa này. Họ đặc biệt chú trọng đến các nhóm Agile. Có ba loại chính: hiệu quả, chất lượng và tinh thần.
Danh mục số liệu
Chỉ số hoạt động
Mục đích là để hiểu mức độ hiệu quả của nhóm trong việc bắt kịp các câu chuyện đã cam kết trong giai đoạn chạy nước rút. Để đánh giá xem liệu việc cam kết quá mức có phải là việc bình thường hay không hay liệu các câu chuyện chuyển giao có phải là tiêu chuẩn từ nước rút này sang nước rút khác hay không.
Từ góc độ hiệu suất linh hoạt, nhóm nên đặt mục tiêu cung cấp nội dung chạy nước rút theo kế hoạch mà họ đã cam kết khi bắt đầu chạy nước rút.
Điều đó không có nghĩa là chúng ta sẽ không linh hoạt trong việc trao đổi câu chuyện trong sprint. Nhưng nó phải luôn là một cuộc đàm phán dẫn đến sự thay thế chứ không phải bổ sung. Năng lực của nhóm sẽ không tăng chỉ vì ai đó đã thêm những câu chuyện mới trong một lần chạy nước rút.
Chúng tôi giới thiệu số liệu này để chú ý đến những trường hợp như vậy và hướng dẫn tất cả các thành viên trong nhóm bảo vệ khả năng chạy nước rút của họ.
Điều này xây dựng độ tin cậy và khả năng dự đoán của nhóm.
# 1. Hiệu suất chạy nước rút so với điểm lịch sử được phân phối
Xem lịch sử năng lực chạy nước rút so với nội dung Điểm câu chuyện (SP) được phân phối trong các lần chạy nước rút.
- Những sai lệch nhỏ giữa các lần chạy nước rút đều ổn. Những bước nhảy lớn theo bất kỳ hướng nào đều báo hiệu rằng có điều gì đó không ổn.
- Tổng công suất chạy nước rút – Ngày khả dụng của một thành viên trong nhóm sẽ cộng thêm một ngày vào tổng công suất. Ví dụ: nếu nhóm có 10 người và mọi người đều sẵn sàng cho một lần chạy nước rút đầy đủ thì tổng năng lực chạy nước rút là 100.
Kiểm tra hiệu suất chạy nước rút so với các SP đã hoàn thành từ lần chạy nước rút này đến lần chạy nước rút khác. Nếu nhóm (trong quá trình lập kế hoạch) cam kết thực hiện nhiều SP hơn đáng kể so với mức bình thường, thì rủi ro đó sẽ được chuyển cho nhóm.
Mục tiêu phải là có tổng SP dự kiến bằng hoặc nhỏ hơn tổng SP hoàn thành trong mỗi lần chạy nước rút.
Bạn vẫn có thể hoàn thành nhiều SP hơn dự kiến nếu nhóm đã hoàn thành (khi kết thúc giai đoạn chạy nước rút) tất cả các câu chuyện đã lên kế hoạch và nhóm vẫn có thể làm việc trên một câu chuyện bổ sung.
- Nếu một nhóm liên tục cung cấp ít SP hơn kế hoạch, nhóm phải thay đổi kế hoạch và lấy ít SP hơn trong lần chạy nước rút tiếp theo.
Các công cụ như monday.com, Atlassian Jira và Asana cung cấp một cách đơn giản để lưu và trích xuất các điểm câu chuyện cho mỗi câu chuyện trong các lần chạy nước rút của bạn. Họ thậm chí có thể tự động tạo nó cho bạn sau mỗi lần lập kế hoạch chạy nước rút.
#2. đồ thị đốt cháy
Đây là một trong những số liệu mà có lẽ hầu hết các nhóm scrum đã ẩn ở đâu đó trên bảng điều khiển của họ. Tôi đồng ý rằng nó thậm chí có vẻ như là một thứ vô dụng. Nhóm hiếm khi tính đến điều này. Người quản lý thích chỉ ra các câu chuyện nhìn từ cấp độ cao như thế nào và chúng tiến triển không tốt như thế nào (vì tất cả chúng đều được mở trong suốt sprint).
Tôi muốn nhấn mạnh rằng bất chấp điều này, các bạn với tư cách là một đội nên đi kiểm tra biểu đồ kiệt sức vì lợi ích của chính mình. Nếu tất cả các câu chuyện được mở trong suốt sprint và chỉ đóng vào ngày cuối cùng của sprint, điều này sẽ tạo ra sự không chắc chắn trong nhóm và hướng tới việc đạt được các mục tiêu của sprint.
- Xem lại bảng chạy nước rút của bạn để biết những câu chuyện đã hoàn thành.
- Làm việc với nhóm để xác định lý do tại sao các câu chuyện nhỏ vẫn được mở, ngay cả khi chúng bắt đầu sớm trong sprint.
- Làm việc với nhóm của bạn để xây dựng tư duy này và không để câu chuyện mở lâu hơn mức cần thiết.
- Biểu đồ kiệt sức lý tưởng thường là trạng thái lý thuyết. Tuy nhiên, càng tiến gần đến điều đó, chúng ta càng điều hành câu chuyện hiệu quả hơn.
Các công cụ quản lý linh hoạt như Asana có thể tự động tạo biểu đồ burndown cho mỗi lần chạy nước rút.
nguồn: asana.com
#3. Hoàn thành mục tiêu chạy nước rút
Theo dõi phần trăm Mục tiêu Sprint bạn đạt được trong mỗi lần chạy nước rút.
Bạn ghi lại các mục tiêu của Sprint một cách riêng biệt, ví dụ: trên trang web Confluence/Jira, cho mỗi lần chạy nước rút. Trạng thái sẽ được cung cấp bất kể chúng có được đáp ứng trong lần chạy nước rút hay không.
Ngay cả khi một nhóm chưa hoàn thành tất cả các câu chuyện trong sprint, nhóm đó vẫn có thể đáp ứng Mục tiêu Sprint (ví dụ: chỉ thiếu các câu chuyện phụ).
Chúng tôi sẽ cố gắng đạt được 100% Mục tiêu Sprint trong mỗi lần chạy nước rút. Nếu không, hãy tìm hiểu xem nhóm đang ngăn cản điều gì.
- Nếu có quá nhiều chủ đề song song trong mỗi sprint, hãy giảm số lượng.
- Nếu có quá nhiều câu chuyện đặc biệt được thêm vào trong một lần chạy nước rút, hãy giảm bớt để không ảnh hưởng đến mục tiêu ban đầu của lần chạy nước rút.
- Nếu mục tiêu chạy nước rút quá lớn hoặc quá khó, hãy đơn giản hóa chúng. Dù thế nào đi nữa, chẳng ích gì khi đặt ra các mục tiêu lớn cho nước rút và không đạt được chúng vào cuối nước rút.
Chỉ số chất lượng mã
Điều này sẽ theo dõi mức độ tốt của mã của bạn theo thời gian. Nó giúp duy trì các quá trình phát triển lành mạnh và giảm thời gian dành cho việc giải quyết vấn đề. Hoặc nhà phát triển có thời gian nhàn rỗi do phải chờ thực thi mã trong các hoạt động phát triển và thử nghiệm.
Nguồn: azuredevpslabs.com
# 1. Kiểm tra tự động
Tạo các bài kiểm tra đơn vị tự động của nhà phát triển cho mọi thay đổi họ thực hiện.
- Đo lường mức độ bao phủ của mã bằng các thử nghiệm tự động – sử dụng Azure Pipelines hoặc SonarCloud để chạy thử nghiệm của bạn. Đặt mục tiêu bao phủ 85%. Trên 90% chưa thực sự hiệu quả.
- Đảm bảo rằng việc tự động tạo các bài kiểm tra đơn vị là một phần trong định nghĩa về mức độ hoàn thành của các câu chuyện mới.
- Bắt kịp quá trình kiểm tra mã cũ như một phần của hồ sơ kỹ thuật tồn đọng của bạn.
#2. Độ phức tạp của mã
Đánh giá những phức tạp không cần thiết mà mã của bạn trở nên phức tạp theo thời gian và chủ động khắc phục nó bằng lịch sử nợ kỹ thuật. Hoặc ngăn chặn chúng xảy ra nếu có thể.
Xác định các tiêu chuẩn và hướng dẫn về mã để hướng dẫn các nhà phát triển tuân theo chúng. Đảm bảo rằng họ tuân theo các quy tắc mã hóa để giảm thiểu sự gia tăng không chính đáng về độ phức tạp của mã. Tôi cập nhật các nguyên tắc thường xuyên dựa trên kinh nghiệm của nhóm.
Xác định mùi mã – chỉ báo về các vấn đề tiềm ẩn trong mã của bạn, chẳng hạn như mã trùng lặp, phương thức dài và các biến không được sử dụng.
Đánh giá ngang hàng đảm bảo rằng các tiêu chuẩn mã được áp dụng cho mã mới được tạo.
Sử dụng các công cụ như bảng thông tin và báo cáo Azure Ado hoặc SonarCloud để phát hiện các vấn đề về mã.
#3. Các bước triển khai thủ công
Theo dõi lượng công việc thủ công mà nhóm của bạn cần thực hiện để phát hành mã trong môi trường thử nghiệm hoặc sản xuất.
- Mục tiêu của chúng ta sẽ là đạt được ở đây 0 đúng giờ.
- Tạo lịch sử nợ kỹ thuật khi cần để điều chỉnh quy trình triển khai/phát hành cho phù hợp với kế hoạch tự động hóa của bạn. Giảm dần các bước thủ công còn lại trong các quy trình từ sprint này sang sprint khác.
Chỉ số tinh thần
Đây là số liệu để theo dõi cách nhóm nghĩ về công việc của họ và các quy trình họ giải quyết hàng ngày.
# 1. Triển khai hồi cứu Sprint
Bạn có thể theo dõi số lượng mục hành động đã thực sự được hoàn thành trong lần chạy nước rút tiếp theo.
- Scrum Master thu thập kết quả của các cuộc họp hồi cứu trên trang của nhóm để theo dõi các hành động đã được thống nhất.
- Sau đó nhóm sẽ theo dõi tiến độ.
- Sau đó, ban quản lý dự án có thể xem liệu các mục hành động có đang tiến triển hay không hoặc điều gì đang ngăn cản nhóm hoàn thành chúng. Sau đó sửa đổi môi trường để cho phép nhóm tiến triển dựa trên các yếu tố hành động đã được thống nhất.
Ít nhất 33% hoặc 1 (tùy theo mức nào cao hơn) các hoạt động từ lần chạy nước rút trước sẽ được chuyển sang các lần chạy nước rút tiếp theo.
Nếu ít hơn, cần có những thay đổi để cho phép nhóm thực hiện các cải tiến đã thống nhất.
Các công cụ quản lý dự án bao gồm các mẫu được tạo sẵn cho các hoạt động hồi cứu nước rút. Đây là một ví dụ từ monday.com:
nguồn: monday.com
#2. Làm việc theo nhóm
Lập trình cặp đường dẫn
- Tạo một cặp đôi tự nhiên để mỗi câu chuyện phối hợp với nhau, chia sẻ quan sát, kiến thức và thành công. Tạo nhiệm vụ phụ trong các câu chuyện thuộc sở hữu của các thành viên khác trong nhóm.
Thực hiện theo các đánh giá mã từ các sáng kiến ngang hàng.
- Đồng nghiệp được yêu cầu hoặc chủ động thực hiện các bước xem xét kết quả câu chuyện của người khác.
Số liệu này có thể được trích xuất từ bảng monday.com/Asana/Jira từ các nhiệm vụ con.
Ít nhất 50% câu chuyện trong một sprint phải được các thành viên trong nhóm chia sẻ. Nếu ít hơn, hãy điều tra nguyên nhân và thực hiện hành động phù hợp.
Để đánh giá ngang hàng tự nguyện, hãy theo dõi các câu chuyện bằng các nhiệm vụ phụ chuyên dụng. Đối với những người mới bắt đầu, 20% câu chuyện về mã được đánh giá theo cách này là một khởi đầu tốt. Dần dần qua các lần chạy nước rút, bạn sẽ khuyến khích và thúc đẩy nhóm cộng tác nhiều hơn và tăng mục tiêu lên 50% lịch sử mã cho mỗi lần chạy nước rút.
#3. Nợ kỹ thuật và câu chuyện về các chức năng mới
Nguồn: atlassian.com
Trao cho nhóm cơ hội giải quyết lịch sử nợ nần của chính họ sẽ làm tăng sự hài lòng của nhóm đối với công việc của họ.
- Ngược lại, việc tích tụ các vấn đề nợ công nghệ mà không có kế hoạch giải quyết dần dần theo thời gian sẽ khiến cả nhóm mất động lực. Và giải pháp sẽ trở nên không ổn định, phức tạp và khó giải quyết hơn nếu không thực hiện lại đáng kể.
Nhóm biết rõ nhất điều gì không hiệu quả với giải pháp, ngay cả khi các bên liên quan hoặc người dùng cuối không nhìn thấy điều đó. Những câu chuyện như thế này có tác động lớn nhất đến chính nhóm phát triển. Họ có thể vô hình đối với các bên liên quan. Vì vậy, điều quan trọng là cho nhóm của bạn cơ hội làm việc dựa trên những câu chuyện giúp họ cấu trúc các nỗ lực phát triển của mình.
Mục đích là để theo dõi xem có bao nhiêu câu chuyện nợ kỹ thuật đã được giải quyết theo thời gian và liệu lượng tồn đọng của những câu chuyện đó có tăng lên hay không.
Nhóm có thể đánh dấu các câu chuyện là TechDebt trong hồ sơ tồn đọng và ưu tiên chúng từ nhóm đứng đầu và được chọn trong các lần chạy nước rút.
Tùy thuộc vào trạng thái của dự án và số lượng khoản nợ công nghệ được xác định trong hồ sơ tồn đọng, bạn có thể muốn đảm bảo rằng hồ sơ tồn đọng của TechDebt không tăng quá 10% từ nước rút này đến nước rút khác.
Ưu tiên lịch sử nợ công nghệ và đưa chúng vào các lần chạy nước rút để kiểm soát sự tăng trưởng của nợ công nghệ để nhóm có thể làm việc với lịch sử nợ công nghệ trong 10-20% thời gian của mỗi lần chạy nước rút.
những từ cuối
Mỗi dự án cuối cùng sẽ yêu cầu một số số liệu, cho dù đó là vì ban quản lý muốn chúng hay vì nhóm quyết định đo lường thành công của chính mình.
Điều tốt nhất bạn có thể làm là bắt đầu xây dựng thư viện số liệu sẵn sàng để thu thập và sử dụng; Càng sớm càng tốt. Và khi làm như vậy, hãy đảm bảo bạn luôn ưu tiên các chỉ số thay đổi hành vi.
Sau đó kiểm tra các quy trình không lành mạnh có thể làm hỏng cuộc chạy nước rút của bạn.
