- Tỷ lệ biến động yêu cầu · Requirements Volatility
- Tỷ lệ yêu cầu được thêm, sửa hoặc bỏ trong một kỳ so với số yêu cầu trong đường cơ sở. Biến động cao không tự nó là xấu ở dự án thích ứng, nhưng ở phần đã chốt hợp đồng hoặc gần ngày bàn giao, nó báo hiệu phạm vi chưa ổn định và rủi ro làm lại.
- Phình phạm vi · Scope Creep
- Sự mở rộng phạm vi sản phẩm hoặc dự án không được kiểm soát, tức là thêm việc mà không điều chỉnh tương ứng về thời gian, chi phí, nguồn lực và không được phê duyệt chính thức. Nguyên nhân thường là yêu cầu không rõ, khách hàng đề nghị trực tiếp với đội, PM thiếu quy trình kiểm soát thay đổi. Phòng ngừa bằng đường cơ sở phạm vi rõ ràng, quy trình kiểm soát thay đổi tích hợp và ma trận truy xuất yêu cầu.
- Ma trận truy xuất yêu cầu · Requirements Traceability Matrix (RTM)
- Bảng liên kết mỗi yêu cầu sản phẩm từ nguồn gốc (mục tiêu kinh doanh, bên đề xuất) tới sản phẩm bàn giao đáp ứng nó, và thường tới thiết kế, ca kiểm thử. RTM giúp bảo đảm mọi yêu cầu được phê duyệt đều tạo ra giá trị, đều được thực hiện và kiểm thử, đồng thời hỗ trợ phân tích tác động khi có thay đổi.
- Kiểm định và thẩm định yêu cầu · Requirements Verification vs Validation
- Kiểm định yêu cầu (verification) trả lời "yêu cầu có được viết đúng không?" — rõ ràng, nhất quán, kiểm thử được, đúng chuẩn tài liệu; thường qua rà soát, thanh tra. Thẩm định yêu cầu (validation) trả lời "đây có đúng là yêu cầu cần thiết không?" — có thực sự đáp ứng nhu cầu kinh doanh và mục tiêu không; thường qua xác nhận với bên liên quan, nguyên mẫu, truy xuất về mục tiêu.
- Hiệu quả loại bỏ lỗi · Defect Removal Efficiency (DRE)
- Tỷ lệ lỗi được phát hiện trước khi bàn giao trên tổng số lỗi (trước bàn giao cộng lỗi người dùng tìm thấy sau bàn giao trong một khoảng thời gian thống nhất). Chỉ số cho biết quy trình kiểm định chặn được bao nhiêu phần lỗi ở "trong nhà".
- Lỗi lọt · Escaped Defects
- Lỗi không được phát hiện trong quá trình phát triển và kiểm thử của đội mà chỉ lộ ra sau khi đã bàn giao, thường do người dùng hoặc bộ phận vận hành báo. Số lỗi lọt (hoặc tỷ lệ so với tổng số lỗi tìm thấy) là chỉ số chất lượng quan trọng trong agile vì nó phản ánh độ hiệu quả của Definition of Done và kiểm thử. Khi chỉ số này tăng, đội nên phân tích nguyên nhân gốc ở buổi cải tiến thay vì chỉ sửa từng lỗi.
- Chỉ số chất lượng · Quality Metrics
- Mô tả cụ thể một thuộc tính của sản phẩm hay quy trình và cách đo nó, kèm ngưỡng chấp nhận. Ví dụ: tỷ lệ lỗi, mật độ lỗi, thời gian phản hồi hệ thống, tỷ lệ đạt kiểm thử lần đầu, điểm hài lòng. Chỉ số tốt phải đo được, có nguồn dữ liệu rõ và gắn với yêu cầu thật của khách hàng.