Sebuah studi komprehensif yang menganalisis hampir 12.000 kontributor di lebih dari 200 organisasi telah mengungkapkan bahwa mengukur kinerja developer individual melalui metrik cycle time pada dasarnya cacat. Riset ini menantang praktik yang tersebar luas dalam menggunakan metrik produktivitas individual untuk mengevaluasi software engineer, menunjukkan bahwa variabilitas yang melekat dalam pengembangan perangkat lunak membuat pengukuran semacam itu sebagian besar tidak bermakna.
Ruang Lingkup Studi: Hampir 12.000 kontributor di lebih dari 200 organisasi dianalisis untuk faktor waktu siklus dan pola variabilitas
Mitos Kinerja Developer yang Konsisten
Studi ini meneliti cycle time - durasi antara saat tiket dibuka dan ditutup - yang dianggap banyak pemimpin engineering sebagai metrik produktivitas paling berguna. Namun, riset menemukan bahwa variasi dalam satu developer dari bulan ke bulan sangat besar sehingga membandingkan developer menjadi hampir tidak bermakna. Temuan ini secara langsung menantang konsep populer 10x developer, yang mengasumsikan ada perbedaan yang stabil dan dapat diukur antara developer.
Data mengungkapkan bahwa meskipun faktor-faktor seperti lebih banyak pull request yang di-merge, peningkatan hari coding per minggu, dan kolaborasi yang lebih besar memang mempengaruhi cycle time dengan cara yang diharapkan, efek ini sangat kecil dibandingkan dengan variabilitas yang sangat besar dalam data. Ketidakpastian yang melekat dalam pengembangan perangkat lunak - dari perubahan requirements hingga bug yang tidak terduga - menciptakan noise yang mengalahkan sinyal bermakna apa pun dari metrik individual.
Faktor Kunci yang Mempengaruhi Waktu Siklus:
- Lebih banyak PR yang digabung: mengurangi waktu siklus (ukuran efek: -0.0083)
- Lebih banyak hari coding per minggu: mengurangi waktu siklus
- Kolaborasi yang lebih besar: mengurangi waktu siklus
- Lebih banyak komentar per PR: meningkatkan waktu siklus
- Lebih banyak defek: meningkatkan waktu siklus
Masalah Memperlakukan Software Seperti Manufacturing
Diskusi komunitas menyoroti kesalahpahaman fundamental dalam cara pengembangan perangkat lunak diukur. Tidak seperti manufacturing atau sales, software engineering melibatkan pembangunan dan penyesuaian sistem yang saling terhubung yang tidak dapat direduksi menjadi unit kerja yang seragam. Tugas-tugas secara inheren berbeda dalam kompleksitas dan cakupan, dan upaya untuk menstandarkannya sering menciptakan lebih banyak gesekan daripada meningkatkan efisiensi.
Software itu rumit karena seorang software engineer sebenarnya adalah arsitek, engineer dan builder pada saat yang bersamaan.
Kompleksitas ini diperparah oleh fakta bahwa developer bekerja di atas fondasi yang terus berubah - library, framework, dan sistem yang berkembang secara independen. Kendala-kendalanya tidak tetap seperti yang terjadi dalam proyek engineering tradisional di mana material dan tools tetap konsisten sepanjang siklus hidup proyek.
Faktor Arsitektur
Satu wawasan kunci dari diskusi komunitas berpusat pada peran arsitektur perangkat lunak dalam produktivitas. Peningkatan kinerja yang paling signifikan - berpotensi 10x atau bahkan 100x perbaikan - berasal dari keputusan arsitektur daripada kecepatan coding individual. Seorang developer terampil yang bekerja pada sistem yang diarsitektur dengan buruk mungkin sebenarnya tampak kurang produktif karena mereka dibatasi oleh masalah desain fundamental.
Banyak perusahaan telah menghilangkan peran software architect khusus, yang mengarah pada sistem yang semakin kompleks yang memerlukan puzzle-solver yang lebih terampil untuk memelihara. Ini menciptakan siklus di mana kompleksitas dibangun di atas kompleksitas, membuat sistem lebih sulit untuk dimodifikasi dan di-debug dari waktu ke waktu.
Pendekatan Tingkat Sistem
Riset menunjukkan bahwa meningkatkan velocity delivery perangkat lunak memerlukan pemikiran tingkat sistem daripada intervensi yang berfokus pada individual. Alih-alih mencoba mengukur dan mengoptimalkan kinerja individual, organisasi harus fokus pada tren tingkat tim selama berbulan-bulan, menerima bahwa variabilitas adalah normal, dan berinvestasi dalam perbaikan sistem yang menguntungkan semua orang.
Pendekatan ini memperlakukan produktivitas developer lebih seperti cuaca - sangat bervariasi, dipengaruhi oleh faktor yang tak terhitung jumlahnya, dan hanya dapat diprediksi secara agregat dalam periode waktu yang lama. Rata-rata bulanan cycle time individual memberikan sedikit wawasan tentang kinerja masa depan, tetapi pola tingkat tim selama periode yang diperpanjang dapat mengungkapkan tren yang bermakna.
Temuan menunjukkan bahwa organisasi harus memasangkan metrik kuantitatif dengan sinyal kualitatif dan fokus pada menciptakan lingkungan yang mendukung kolaborasi efektif dan keputusan arsitektur yang baik. Daripada berusaha menghilangkan variabilitas, tim yang sukses belajar bekerja di dalamnya sambil membangun sistem yang dapat beradaptasi dengan requirements yang berubah dan tantangan yang tidak terduga.
Referensi: Measuring Engineering