Độ đo dự án được dùng để đo tiến bộ của dự án và chất lượng sản phẩm của nó. Độ đo cũng có thể được dùng để giám sát qui trình phát triển như tính ổn định của yêu cầu (Bao nhiêu lần chúng thay đổi) hay tính hiệu quả của qui trình giám định phần mềm (Bao nhiêu lỗi đã được nhận diện). Bằng việc có độ đo, người quản lí dự án có thể cải tiến việc phát triển phần mềm; nhận diện nhược điểm vì dữ liệu đo có thể cảnh báo về những vấn đề có thể, cho nên các thành viên tổ phát triển có thể lấy hành động sửa chữa.

Lí do các độ đo dự án thường thất bại bởi vì quan niệm sai về độ đo. Một số người phát triển tin độ đo có thể chỉ ra lỗi của họ vì họ bị đo. Khi người phát triển cảm thấy bị đe doạn, họ thường che giấu sai lầm của họ và không chia sẻ thông tin. Không có thông tin sự kiện, người quản lí dự án không biết về vấn đề hay chỗ họ tới mãi cho tới khi quá muộn. Khi vấn đề trở thành quá lớn, dễ dàng lâm vào tình huống trách móc khi mọi người bắt đầu đổ lỗi cho nhau và sự hài hoà của tổ bị tan vỡ.

Người quản lí dự án có kinh nghiệm biết cách giải thích rằng dữ liệu đo không bao giờ được dùng để đổ lỗi, đe doạ, hay phán xét người phát triển mà CHỈ để nhận diện vấn đề và sửa chúng sớm trước khi chúng trở thành quá lớn. Khi người phát triển hiểu độ đo có thể giúp cho họ nhận diện vấn đề sớm hơn, họ sẽ cộng tác. Đó là lí do tại sao điều quan trọng là bắt đầu giáo dục về độ đo trước khi bất kì chương trình độ đo nào xảy ra để tránh tình huống mà người lập trình không cộng tác.

Nhiều dự án tạo ra chương trình độ đo sau khi dự án bắt đầu hay khi số lỗi là cao, hay khi dự án bị muộn. Về căn bản điều đó là quá trễ bởi vì thiệt hại đã bị gây ra rồi. Bắt đầu đo khi dự án có vấn đề sẽ tạo ra không thoải mái trong những người phát triển. Chương trình độ đo nên bắt đầu vào lúc bắt đầu dự án như một cơ chế quản lí dự án tốt. Điều quan trọng là có hành động phòng ngừa hơn là phản ứng. Cách tốt nhất để làm giảm lỗi là có giám định phần mềm chính thức. Bằng việc có danh sách kiểm chi li, các vai trò và trách nhiệm được xác định rõ ràng cho kiểm điểm, người quản lí có thể theo dõi số lượng và kiểu lỗi được tìm ra và có hành động sửa chữa từ sớm hơn.

Cách đo và độ đo cung cấp cách nhìn khách quan về tiến bộ của dự án, trạng thái, vấn đề, thành công và thất bại. Bằng việc có mọi sự kiện và dữ liệu này, người quản lí dự án có thể ra quyết định nhanh hơn chỉ là phỏng đoán. Thông tin sự kiện này cũng cung cấp cái nhìn rõ ràng mà không cần thảo luận hay tranh cãi nào trong các thành viên tổ. Như một thành viên thường nói: “Nếu bạn phạm sai lầm, bạn sửa nó.”

—-English version—-

Project metrics

Project metrics are used to measure the progress of a project and the quality of its products. Metrics also can be used to monitor the development process such as the stability of the requirements (How many times they change) or the effectiveness of the software inspection process (How many defects have been identified). By having metrics, project managers can improve the software development; identify weaknesses as measurement data can warn of possible problems, so development team members can take corrective action.

The reason project metrics program often fail because the misconception about metrics. Some developers believe metrics can point to their faults since they are being measured. When developers feel threatened, they often hide their mistakes and do not share information. Without factual information, project managers do not know about the problems or where they come from until it is too late. When the problem become too big, it is easy to get into the blaming situation when people begin to blame each other and the team’s harmony is shattered.

Experienced project managers know how to explain that measurement data are never used for blame, threats, or judge developers but ONLY to identify potential problems and fix them earlier before they become too big. When developers understand metrics can help them to identify problem earlier, they will collaborate. That is why it is important to start metrics education before any metrics program take place to avoid the situation when developers do not cooperate.

Many projects create metrics program after the project start or when the number of defects is high, or when the project is late. Basically it is too late because the damages are done. Starting to measure when the project is having problems will create uncomfortable among developers. Metrics program should start at the beginning of the project as a good project management control mechanism. It is important to have preventive rather than reactive actions. The best way to reduce defects is having formal software inspection. By having extensive checklists, clearly defined roles and responsibilities for the review, managers can track the numbers and the types of defects found and take corrective actions earlier.

Measurements and metrics provide an objective view of the project’s progress, status, problems, successes, and failures. By having all these facts and data, project managers can make decision faster than just guessing. This factual information also provides a clear view that does not need any discussion or debate among team members. As one member often said: “If you make the mistake, you fix it.”