Vấn đề với loại định lượng này là hầu như không thể có được dữ liệu đủ tốt về hiệu quả của các thực hành kỹ thuật phần mềm để đưa ra bất kỳ kết luận có ý nghĩa nào.
Quan trọng nhất, mối tương quan không ngụ ý nhân quả - ví dụ, có thể là các lập trình viên giỏi nhanh chóng nhảy vào và thực hiện các ý tưởng mới, vì vậy bạn thấy một mối tương quan chung giữa thành công dự án và áp dụng các kỹ thuật kỹ thuật phần mềm mới. Nhưng điều đó không chứng minh được gì về hiệu quả của các kỹ thuật, vì toàn bộ hiệu ứng có thể được giải thích bằng mức độ tài năng cao hơn của các lập trình viên áp dụng chúng.
Và sau đó thật khó để kiểm soát các biến độc lập . Làm thế nào để bạn đảm bảo một thử nghiệm công bằng trừ khi bạn có thể kiểm soát tất cả những điều sau đây?
- Kinh nghiệm / kỹ năng / mức độ động lực của đội
- Mức độ thực tế của việc áp dụng phương pháp được yêu cầu (họ có thực sự làm TDD đúng cách không?)
- Sự hiện diện / vắng mặt của các lỗi thiết kế chính không liên quan đến phương pháp kỹ thuật phần mềm (ví dụ: những lỗi đòi hỏi phải tái cấu trúc chính trong dự án)
- Mức độ khó của các dự án được so sánh
- Tác động của các vấn đề bên ngoài (ví dụ: thay đổi yêu cầu chính)
- Lựa chọn thiên vị (ví dụ mọi người có xu hướng chia sẻ dữ liệu thường xuyên hơn về các dự án thành công?)
- Sự xác nhận thiên vị (ví dụ như mọi người đã phóng đại sự thành công của các dự án sử dụng phương pháp yêu thích của họ?)
Ngay cả khi bạn quyết định giải quyết vấn đề trên bằng cách đưa ra nhiều nhóm được chọn cẩn thận cho cùng một vấn đề trong cùng điều kiện được kiểm soát cẩn thận thì thử nghiệm của bạn có thể sẽ rất tốn kém nếu bạn muốn tạo đủ dữ liệu có ý nghĩa thống kê.
Và cuối cùng, gần như không thể đo lường thành công :
- Một số liệu như số dòng mã nguồn (SLOC) cực kỳ tệ. Ưu đãi cho các nhà phát triển là tạo ra sự quái dị hàng triệu dòng với mã hóa sao chép / dán để trông "hiệu quả" hơn
- Số liệu về thời gian / ngân sách phụ thuộc chủ yếu vào mức độ tham vọng trong các ước tính được sử dụng để tạo kế hoạch / ngân sách
- Một số liệu loại ROI phụ thuộc nhiều vào tình hình thị trường và quản lý thương mại của sản phẩm cũng như chất lượng của sản phẩm kỹ thuật (nhìn vào lịch sử của Microsoft Windows!)
- Điểm câu chuyện rất hữu ích để có được cảm giác vận tốc trong một đội nhanh nhẹn nhưng không thực sự có thể so sánh giữa các đội
- Các số liệu dựa trên chức năng như Điểm chức năng hoặc Điểm trường hợp sử dụng có lẽ là điểm tốt nhất của nhóm xấu, nhưng chúng quan liêu để thu thập và không phản ánh sự khác biệt trong nỗ lực kỹ thuật cần thiết để tạo ra mỗi đơn vị chức năng.
- Các số liệu chất lượng như lỗi trong tính sẵn có của sản xuất / ứng dụng rất khó tính toán và so sánh trên cơ sở bình đẳng - nó phụ thuộc đáng kể vào những thứ như nền tảng được chọn, quy mô cơ sở người dùng và các yếu tố vận hành / triển khai khác nhau.
Tóm lại: cố gắng định lượng tác động của các nhiệm vụ phát triển phần mềm là một nhiệm vụ cực kỳ khó khăn và mặc dù nhiều năm sau chủ đề này vẫn chưa có ai đưa ra một cách tiếp cận thực sự hiệu quả. Kết quả là, đánh giá các phương pháp phát triển phần mềm vẫn là một nghệ thuật hơn là một khoa học , và có lẽ sẽ vẫn còn như vậy trong nhiều năm tới.
Thật thú vị, có một cách tiếp cận mà tôi nghĩ đã hứa: áp dụng các nguyên tắc tinh gọn . Đây không phải là thuốc chữa bách bệnh và sẽ không trực tiếp giải quyết vấn đề đánh giá các phương pháp phát triển phần mềm, nhưng nó có một cái nhìn sâu sắc: Một quy trình với một yếu tố chất thải cụ thể là kém hiệu quả hơn so với quy trình tương tự mà không có yếu tố lãng phí đó, tất cả mọi thứ khác là như nhau . Vì vậy, nếu bạn tập trung vào việc loại bỏ lãng phí trong quy trình phát triển phần mềm, ít nhất bạn có thể chắc chắn rằng mình đang đi đúng hướng. Ngoài ra, chất thải thường có thể định lượng được, do đó bạn cũng nên biết một chút về hiệu quả của mình, ít nhất là về tỷ lệ phần trăm thô.