, việc theo dõi các chỉ số là vô cùng quan trọng, ảnh hưởng đến sự thành công hay thất bại của dự án.
Việc theo dõi, phân tích các chỉ số [
metrics ] trong các dự án IT giúp các nhà quản lý:
- Kịp thời đánh giá được hiệu quả của những quyết định được thực hiện trong quá trình phát triển và nhanh chóng phát hiện ra các vấn đề cần được xử lý, khắc phục.
- Đo lường hiệu quả của các nhóm làm việc và các thành viên trong đội.
- Điều chỉnh các chính sách, quy trình và quyết định để đạt được hiệu quả cao nhất.
Vậy đâu là các chỉ số quan trọng mà các nhà quản lý cần lưu ý trong quá trình phát triển dự án?
Hãy cùng DS Solution Vietnam tìm hiểu 5 chỉ số quan trọng trong dự án IT!
1 - Sprint burn-down
Biểu thị lượng công việc đã được hoàn thành trong một epic hoặc một sprint và công việc còn tồn đọng.
Mục đích sử dụng:
- Thường được dùng để dự đoán khả năng hoàn thành công việc của nhóm theo thời gian ước tính và giúp team ý thức về khối lượng công việc cần hoàn thành.
- Ngoài ra burn-down chart còn giúp nhìn chi tiết về các mà nhóm đang làm việc:
- Nếu bạn nhận thấy nhóm thường xuyên hoàn thành công việc sớm → Công việc của các thành viên trong nhóm ít.
- Nhóm thường trễ hạn → Công việc của các thành viên trong nhóm quá nhiều.
- Nếu biểu đồ burn-down cho thấy sự sụt giảm mạnh trong giai đoạn chạy nước rút thì có thể là dấu hiệu cho thấy công việc chưa được ước lượng chính xác hoặc chưa được chia nhỏ hợp lý.
Cách đọc sprint burn-down
- Trục x: Biểu thị thời gian
- Trục y: Biểu thị lượng công việc còn lại phải hoàn thành, thường được đo bằng story points hoặc hours
2- Epic / release burn-down
Biểu thị lượng công việc đã hoàn thành, công việc còn lại hoặc công việc được thêm vào trong nhiều sprint của một epic hoặc một version. Epic / Release burn-down là cái nhìn tổng quan về nhiều sprint burn-down.
Mục đích sử dụng:
- Thường được dùng để dự đoán khả năng hoàn thành công việc của nhóm theo thời gian ước tính và giúp team ý thức về khối lượng công việc cần hoàn thành trong epic hoặc version.
Ví dụ về mẫu đối lập:
- Dự báo epic hoặc release không được cập nhật bởi nhóm.
- Không có tiến triển nào qua nhiều vòng lặp.
- Mất kiểm soát phạm vi dự án [“Scope creep”] là dấu hiệu của việc PO không hiểu chính xác vấn đề mà nhóm đang cố gắng giải quyết.
- Nhóm không đưa ra được bản phát hành có chất lượng tốt hơn sau một epic.
3- Velocity [vận tốc]
Velocity trong bối cảnh quản lý dự án Agile được hiểu là lượng việc trung bình một nhóm Scrum hoàn thành trong một sprint. Velocity thường được đo bằng story point hoặc hour. Vào cuối mỗi vòng lặp, nhóm dự án cộng các ước tính [estimate] tương ứng với các user stories mà họ đã hoàn thành cho vòng lặp đó. Tổng kết quả đó chính là velocity.
Biết được velocity này, nhóm dự án có thể sử dụng để tính toán và ước tính thời gian cần để hoàn thành dự án. Dựa trên giá trị ước tính tương ứng với các user stories còn lại và giả sử rằng velocity là không đổi trong các vòng lặp tiếp theo, nhóm có thể đưa ra dự báo.
Ví dụ: PO muốn hoàn thành 500 story point trong backlog. Và nhận thấy rằng cả nhóm phát triển thường hoàn thành 50 story point cho mỗi vòng lặp. Khi đó, PO có thể kết luận rằng nhóm sẽ cần 10 vòng lặp để hoàn thành công việc được yêu cầu.
Bên cạnh đó, nhóm cũng sẽ nhìn được velocity được cải thiện như nào qua mỗi khoảng thời gian.
- Những nhóm mới thường mong muốn nhìn được sự tăng trưởng trong velocity khi nhóm tối ưu mối quan hệ và quá trình làm việc.
- Những nhóm làm việc cùng nhau đã lâu có thể nhìn vào velocity để đả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ột thay đổi cụ thể trong quy trình có tạo ra sự cải thiện hay không.
Velocity suy giảm là dấu hiệu của việc một phần của quá trình phát triển của nhóm đã không hiệu quả và cần được bàn luận.
Trong trường hợp nhận thấy velocity bất thường trong một thời gian dài, hãy kiểm tra việc ước lượng của nhóm và hỏi nhóm những câu hỏi sau:
- Có những thách thức hoặc khó khăn nào mà chúng ta không tính đến trong quá trình ước lượng thời gian cho task này không? Làm thế nào để có thể chia nhỏ công việc hoặc phát hiện ra những khó khăn này.
- Có áp lực kinh doanh nào bên ngoài khiến nhóm vượt quá giới hạn không? Việc tuân thủ các bước hướng dẫn thực hành có đem lại hiệu quả không?
- Với tư cách là một nhóm, chúng ta có đang quá sốt sắng cho việc dự báo sprint không?
Lưu ý:
- Velocity là một thước đo hình thành sau khi đã tiến hành công việc. Mặc dù velocity sẽ giúp ích cho việc lập kế hoạch sau đó, nhưng nó không phải là ngân sách hoặc dự báo mà là công cụ hỗ trợ cho việc lên ngân sách hoặc dự báo.
- Velocity thường được đo theo giá trị [user stories] thay vì đo theo công việc [task].
- Velocity không được dùng để so sánh giữa các nhóm dự án khác nhau. Việc so sánh này không có ý nghĩa gì vì bản chất ước tính [estimate] và phương pháp được sử dụng ở mỗi dự án agile là khác nhau.
- Để ứng dụng được velocity vào việc dự báo thời gian hoàn thành, thì phương pháp ước tính cho user stories phải nhất quán qua các vòng lặp. Điều này có thể thực hiện bằng cách: ước tính toàn bộ các user stories 1 lần trước khi dự án bắt đầu và các user stories phát sinh phải sử dụng cùng phương pháp và nhất quán với những phương pháp đã sử dụng trước đó.
4- Control chart [Biểu đồ kiểm soát]
Biểu thị chu kỳ [cycle time] của từng issue riêng lẻ, tức là tổng thời gian từ trạng thái “in-progress” sang “done”.
Nhóm có cycle time ngắn hơn thường có xu hướng có thông lượng cao hơn; trong khi đó, nhóm có thời gian chu kỳ nhất quán qua nhiều issue thường dễ dự đoán hơn trong phân phối công việc.
Lưu ý:
Control chart có thể xuất hiện nhiều thay đổi lúc đầu nhưng đừng quá quan tâm đến những trường hợp ngoại lệ. Hãy tìm ra xu hướng chung của biểu đồ. Đây là hai điểm nhà quản lý cần chú ý khi đọc biểu đồ kiểm soát:
- Chu kỳ tăng. Thời gian của một chu kỳ tăng làm mất sự linh hoạt của một nhóm. Tuy nhiên, trong trường hợp đinh nghĩa trạng thái “done” của task bị mở rộng thì việc chu kỳ tăng là một trường hợp ngoại lệ.
- Chu kỳ bất thường. Mục tiêu là có các chu kỳ nhất quán cho những công việc [issue] có giá trị story point tương tự nhau. Hãy lọc control chart theo từng giá trị story point để kiểm tra tính nhất quán. Nếu thời gian chu kỳ bất thường đối với các giá trị story point lớn và nhỏ, hãy dành thời gian kiểm tra các điểm sai sót và cải thiện việc ước lượng trong tương lai.
5- Cumulative flow diagram [Sơ đồ luồng tích lũy]
Giúp nhóm dễ dàng nhận thấy vấn đề trong quá trình phát triển. Cumulative flow diagram hiệu quả sẽ trông mịn màng từ trái qua phải. Bất kỳ bong bóng hoặc sự thiếu hụt trong màu nào cũng là biểu thị của sự thiếu hụt và tình trạng thắt cổ chai.
Lưu ý
- Những issue bị nghẽn lại sẽ tạo ra khoảng backup lớn trong một phần tiến độ.
- Mất kiểm soát sự tăng trưởng của backlog. Điều này là kết quả từ việc PO không kết thúc các issue đã quá cũ hoặc các issue có độ ưu tiên quá thấp để được triển khai.
Kết luận
Trên đây là 5 chỉ số quan trọng nhất trong dự án IT mà các nhà quản lý cần quan tâm và theo dõi.
Bên cạnh các chỉ số này, vẫn còn rất nhiều các chỉ số khác mà các nhà quản lý cần chú ý đến trong quá trình phát triển phần mềm. Các chỉ số [metrics] này được tích hợp sẵn trong Jira Software. Nhà quản lý có thể sử dụng các Agile report được tích hợp sẵn trên Jira Software để theo dõi và đánh giá hiệu quả của nhóm phát triển phần mềm chỉ trong một vài bước cài đặt đơn giản.
Burn Down chart là gì?
Burndown Chart là một công cụ quan trọng được sử dụng rộng rãi trong Agile và Scrum để theo dõi tiến độ công việc trong dự án cũng như phát triển sản phẩm.
Trong mô hình Agile Scrum ai là người chịu trách nhiệm đánh giá hiệu năng của dự án?
Product Owner [chủ sản phẩm]: Là người chịu trách nhiệm về sự thành công của dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm.
Burn Up chart là gì?
Burn up chart là một công cụ hỗ trợ quản lý và theo dõi tiến độ thực hiện nhiệm vụ, công việc thực tế so với kế hoạch ban đầu. Burn up chart được sử dụng phổ biến trong mô hình quản lý dự án linh hoạt – Agile và Scrum.
Tiến độ Sprint được theo dõi thông qua đâu?
Việc theo dõi tiến độ qua Burndown chart sẽ giúp Scrum Team phát hiện sớm các rủi ro, vấn đề có thể ảnh hưởng tới khả năng đạt được sprint goal, để từ đó đề ra phương án xử lý & cải thiện tình hình.