KPI chính trong dự án phần mềm
- 10/14/2022
- Posted by: admin
- Category: Tin nhanh
KPI chính trong dự án phần mềm
Bộ KPI chính đo lường hiệu suất, kết quả đội nhóm thường được sử dụng kiểm soát hoạt động dự án phần mềm bạn không nên bỏ qua bao gồm:1. Các chỉ số đo lường tiến trình công việc
1.1. Vận tốc đội nhóm (Team Velocity)
Các dự án thường được chia thành các giai đoạn nước rút (Sprint), thường tập trung vào các nhiệm vụ cụ thể. Mỗi Sprint có một lượng công việc phải được hoàn thành vào cuối ngày. Trong mỗi Sprint, bạn có thể sử dụng chỉ số vận tốc đội nhóm. Có nhiều cách để đo vận tốc, chẳng hạn như điểm Story. Điểm Story đo lường khối lượng công việc đã hoàn thành đối với một sản phẩm phần mềm.
Bảng team velocity
Biết được các điểm Story của một dự án giúp bạn ước tính thời gian xây dựng và hoàn thành dự án. Làm như vậy cho phép bạn hiểu rõ về các mục tiêu của nhóm.Các mẹo quan trọng để đo vận tốc:
- Nếu vận tốc vẫn không thay đổi sau nhiều Sprint, hãy xem xét kết hợp các yếu tố khác vào đo lường.
- Khi nhiều nhiệm vụ được thêm vào hoặc xóa khỏi tính toán, vận tốc nhóm có thể được tính theo cách khác phù hợp hơn.
- Nếu bạn muốn dự báo hiệu quả dự án dựa trên vận tốc nhóm - hãy tính trung bình cộng vận tốc nhóm trong 3 sprint liên tiếp.
1.2. Sprint Burndown
Hầu hết các công ty phần mềm sử dụng Scrum như một phương pháp tổ chức phát triển sản phẩm chia nó thành các khoảng thời gian cố định, được gọi là Sprint. Vì vậy, biểu đồ sprint burndown thể hiện một cách trực quan quy trình làm việc của nhóm.
Biểu đồ Sprint burndow
Nó cho biết tổng khối lượng công việc đã được hoàn thành và còn bao nhiêu phần việc nữa phải hoàn thành. Tốt nhất, nó nên được tính trung bình để có giá trị tính toán tốt nhất. Sử dụng sprint burndown làm thước đo giúp các nhóm theo dõi hiệu suất của họ khi nó không phù hợp với mong đợi của họ.
1.3. Chỉ số Release Burndown
Biểu đồ Release Burndow tương tự như biểu đồ Sprint Burndow ở chỗ nó hiển thị trạng thái của dự án liên quan đến ngày phát hành sản phẩm. Nó có thể được sử dụng để thông báo cho khách hàng và nhân viên về sự chậm trễ trong dự án hoặc thời điểm các phiên bản sản phẩm ban đầu của dự án được phát hành. Nói cách khác, nó có thể giúp người dùng xác định xem dự án có thể đáp ứng được tiến độ hay không hoặc liệu nó có sự chậm chễ tiến độ hơn nữa hay không.
Biểu đồ Release Burndow
Một biểu đồ Release Burndown tốt cũng giúp người quản lý xác định số Sprint cần thiết để hoàn thành công việc dự án
2. Sức khỏe tiến trình và các điểm tắc nghẽn
2.1. Thời gian chu kỳ (Cycle Time)
Biểu đồ thời gian chu kỳ thường là thời gian mà một nhiệm vụ có nhiều khả năng được hoàn thành nhất. Biết nhóm của bạn đang làm việc nhanh như thế nào có thể giúp bạn cải thiện hiệu suất của nhóm. Nó cũng có thể giúp bạn xác định khối lượng công việc phù hợp để giao cho nhóm làm trong thời gian tới.
Biểu đồ Cycle time
2.2. Luồng tích lũy (Cumulative Flow)
Luồng tích lũy (Cumulative Flow - CF) là một sơ đồ trực quan cho thấy trạng thái của tất cả các nhiệm vụ đang được thực hiện. Nó sử dụng một bảng màu thể hiện các giai đoạn khác nhau của dự án. Mục tiêu của biểu đồ này là cung cấp một báo cáo trực quan về cách các nhiệm vụ được phân phối qua các giai đoạn khác nhau.Biểu đồ cho thấy mối quan hệ giữa thời gian và số lượng nhiệm vụ trên dự án. Nó nêu bật các giai đoạn khác nhau của quá trình làm việc và hiển thị phần trăm nhiệm vụ đã được hoàn thành và đang được xem xét.
Biểu đồ luồng tích lũy
Một biểu đồ luồng tích lũy có thể giúp bạn theo dõi kết quả công việc của nhóm và giữ cho họ có trách nhiệm về hiệu suất của nhóm. CF là một công cụ tuyệt vời cho các nhóm tập trung vào việc theo dõi tất cả các nhiệm vụ đang thực hiện và đã hoàn thành.Biểu đồ cũng có thể xác định khi nào vượt quá giới hạn công việc đang thực hiện. Tính năng này giúp phát triển thói quen cố gắng hoàn thành công việc và giảm thiểu đa nhiệm trong đội nhóm.
2.3. Hiệu suất luồng (Flow efficiency)
Hiệu suất luồng - Flow efficiency là số liệu cho biết thời gian còn lại để hoàn thành. Nó cho thấy sự khác biệt giữa thời gian còn lại và khối lượng công việc đang thực hiện. Hiệu suất luồng được xác định bằng cách chia thời gian bạn làm việc cho tổng thời gian chu kỳ dự án (cycle time). Nó có thể được sử dụng để xác định các khu vực yếu kém hoặc thực hiện các thay đổi đối với cách quản lý dự án.
Biểu đồ Flow efficiency
Nó cũng có thể cung cấp thông tin chi tiết về việc phân bổ công việc giữa các khoảng thời gian chờ đợi khác nhau. Đôi khi, một đoạn code có nhiều phụ thuộc vào các đoạn code khác và bạn không thể bắt đầu làm việc khi đoạn code liên quan chưa hoàn thành. Điều này có thể hữu ích để theo dõi lượng thời gian bạn đang đợi hoàn thành công việc.
3. Chất lượng mã code
3.1. Mức độ kiểm soát mã code (Code coverage)
Một số liệu về mức độ kiểm soát mã code đo lường số lượng dòng mã được thực thi trong khi quá trình kiểm thử đang chạy. Nó thường được sử dụng để đánh giá quá trình phân phối liên tục và thực tiễn phát triển theo hướng thử nghiệm.Đừng đánh giá quá cao số dòng code đã được kiểm soát. Ngoài ra, việc gọi một dòng mã code nhiều lần không phải lúc nào cũng đủ để kết thúc một bài kiểm thử. Thay vào đó, nó nên được sử dụng để làm nổi bật đoạn mã code mà người thử nghiệm quan tâm.
Mặc dù đạt được độ kiểm soát mã code 100% không có nghĩa là mã code đã được kiểm tra kỹ lưỡng, nhưng điều đó cho thấy rằng bạn đã ưu tiên các tính năng quan trọng nhất đối với sự phát triển của dự án.
3.2. Sự ổn định mã code
Độ ổn định của mã code rất khó đo lường. Mã ổn định có nghĩa là có rất ít thay đổi đối với sản phẩm phần mềm có thể gây hại cho doanh nghiệp hoặc dự án. Một số nhà phát triển quyết định lập biểu đồ tần suất thay đổi mã code.3.3. Mức độ đơn giản mã code
Độ đơn giản của mã code là một KPI tổng quát hơn có thể được đo lường thông qua các số liệu khác nhau. Một trong số này là số lượng đường dẫn mà mã của bạn phải thực hiện để hoàn thành. Độ đơn giản của mã cũng là một thước đo hữu ích để đo lường rủi ro từ các vấn đề khác nhau gây ra trong quá trình phát triển và thử nghiệm. Nó cũng có thể giúp xác định thành phần nào của mã code có nhiều lỗi nhất.Sự đơn giản của mã là sự cân bằng giữa máy móc và nhận thức của con người về độ phức tạp. Vấn đề với nó là Nếu bạn buộc các nhà phát triển cấu trúc lại mã của họ thành nhiều phương thức con, chúng có thể khiến con người khó hiểu hơn. Có mã dễ đọc sẽ giảm rủi ro khi tham gia lâu dài cho các nhà phát triển mới.
3.4. Code Churn
Code churn là một số liệu đo lượng mã thay đổi theo thời gian. Nếu mã phải được viết lại để phù hợp với một tính năng mới, nó có thể gây ra tình trạng bảo trì cao.Mặc dù là cách tiếp cận truyền thống, nhưng mã churn có thể được sử dụng để đánh giá tính ổn định của mã của bạn. Nó cũng có thể cho bạn biết giai đoạn phát triển nào là không ổn định nhất và giai đoạn nào là ổn định nhất.
Tìm kiếm các quy định về thay đổi mã để xác định các vấn đề có thể do phương pháp tạo tác vụ gây ra. Nếu mã có đột biến trong các thay đổi mã, điều quan trọng là phải điều tra tác vụ nào đã gây ra đột biến. Làm như vậy có thể giúp tránh tạo ra mã không ổn định.
Tính ổn định của sản phẩm của bạn là rất quan trọng trước khi phát hành. Xu hướng ngày càng tăng của code churn có thể chỉ ra rằng mã rất có thể sẽ được viết lại trước ngày phát hành, điều này có thể gây ra sự không ổn định.
Nếu thấy bài viết thú vị, đừng ngại ấn LIKE - SHARE - COMMENT để ủng hộ VNPMI nhé!
Các bài viết liên quan:
Số 229 Tây Sơn, Đống Đa, Hà Nội