Meskipun keterampilan praktis dan pengetahuan tentang bahasa, alat, dan teknologi pemrograman tertentu adalah kunci untuk mendapatkan pekerjaan penuh waktu sebagai pengembang perangkat lunak, ada indikator berharga lainnya yang dalam banyak hal dapat dilihat sebagai praanggapan untuk sukses dalam profesi ini: produktifitas. Pengukuran produktivitas adalah sesuatu yang perlu dipahami dan diperhitungkan oleh semua pengembang perangkat lunak profesional karena metrik kinerja secara inheren penting untuk tim pengembangan perangkat lunak mana pun di lingkungan bisnis saat ini.
Mengapa produktivitas Anda sebagai pengembang penting?
Di era pengembangan Agile, DevOps, dan siklus rilis perangkat lunak yang menyusut, ketika pengembang perlu mengirimkan versi produk baru secepat mungkin, perusahaan menggunakan beberapa metrik produktivitas berbeda untuk mengevaluasi kinerja pemrogram individu dan tim secara keseluruhan. Melihat hal ini dari sudut pandang pengembang, pengukuran kinerja dapat melayani beberapa tujuan yang berharga, membantu Anda melacak kemajuan keterampilan pemrograman Anda, yang memungkinkan Anda mencapai pertumbuhan profesional yang konsisten. Pembuat kode yang sangat produktif adalah mereka yang akhirnya menerima tawaran gaji yang mencengangkan dan mulai mengerjakan proyek yang paling menarik. Tetapi bahkan jika Anda bukan orang yang berprestasi tinggi dan hanya menginginkan pekerjaan apa pun dalam pengembangan perangkat lunak dan cukup berhasil di dalamnya, Anda masih harus memiliki setidaknya pemahaman dasar tentang indikator kinerja dan bagaimana indikator tersebut digunakan untuk mengukur produktivitas input Anda di tempat kerja. Itulah yang akan kita bicarakan hari ini.
Metrik pengukuran produktivitas pengembangan perangkat lunak
Apa itu metrik produktivitas pengembangan perangkat lunak?
Metrik pengembangan perangkat lunak adalah bidang pekerjaan pemrograman di mana pengukuran kuantitatif dapat diterapkan untuk melacak kinerja, kualitas kerja, dan produktivitas pengembang. Setiap metrik produktivitas didasarkan pada pengambilan data dari proses pengembangan dan menggunakannya untuk mengukur produktivitas. Karena hampir tidak ada yang terkait dengan pengembangan perangkat lunak yang mudah dan langsung, Anda dapat mengatakan bahwa mengukur produktivitas pemrograman juga cukup tidak konsisten dan terfragmentasi di seluruh industri. Atau, sederhananya, berbagai tim dan perusahaan dapat menggunakan indikator kinerja yang sangat berbeda dan mendekati masalah ini dari berbagai sudut. Jadi Anda tidak perlu repot mempelajari setiap metrik yang mungkin digunakan oleh tim pengembangan perangkat lunak.
Apa jenis metrik produktivitas pengembangan perangkat lunak yang ada?
Secara alami, ada beberapa metrik produktivitas berbeda yang mendekati pengukuran kinerja pada berbagai tingkat dan sudut. Berikut adalah jenis metrik produktivitas yang paling umum:
Metrik yang berfokus pada ukuran formal.
Metrik ini difokuskan untuk mengukur ukuran hasil kerja programmer, seperti baris kode (LOC), panjang instruksi kode, kompleksitas kode, dll. Metrik ini semakin dianggap ketinggalan zaman dalam industri pengembangan perangkat lunak saat ini.
Metrik produktivitas yang berfokus pada waktu dan fungsi.
Ada pilihan metrik produktivitas tradisional yang digunakan dalam pengembangan perangkat lunak air terjun, seperti hari aktif, cakupan fungsionalitas yang dikirimkan dalam jangka waktu tertentu, laju churn kode, jumlah tugas yang ditetapkan, dll.
Metrik proses pengembangan yang gesit.
Metrik proses pengembangan tangkas, seperti sprint burndown report, kecepatan, waktu tunggu, waktu siklus, dan lainnya, mungkin merupakan metrik yang paling umum digunakan di antara tim pengembangan perangkat lunak saat ini. Kami akan berbicara tentang metrik Agile lebih detail nanti di artikel.
Metrik analitik operasional.
Kumpulan metrik ini difokuskan untuk mengukur kinerja perangkat lunak dalam lingkungan produksinya saat ini. Waktu rata-rata antara kegagalan (MTBF), waktu rata-rata untuk pulih (MTTR), dan tingkat kerusakan aplikasi adalah metrik yang paling banyak digunakan di sini.
Metrik pengujian.
Pengujian perangkat lunak memiliki kumpulan metriknya sendiri untuk mengukur kualitas pengujian sistem, seperti persentase pengujian otomatis, cakupan kode, dll.
Metrik kepuasan pelanggan.
Terakhir, metrik pamungkas untuk perangkat lunak apa pun adalah pengalaman pelanggan akhir, dan ada serangkaian metrik untuk itu juga, seperti skor upaya pelanggan (CES), skor kepuasan pelanggan (CSAT), skor promotor bersih (NPS) dan lain-lain.
Metrik pengembangan perangkat lunak yang gesit
Seperti yang Anda lihat, sangat mudah tersesat dalam semua seluk-beluk metrik produktivitas perangkat lunak. Namun, satu-satunya yang harus diketahui oleh pengembang perangkat lunak biasa adalah metrik Agile, yang biasa digunakan oleh tim pengembangan perangkat lunak saat ini sebagai standar pengukuran produktivitas tim di berbagai bagian siklus hidup pengembangan perangkat lunak. Mari daftar metrik Agile utama dan paling umum digunakan.
1. Pembakaran Sprint.
Laporan Sprint Burndown adalah salah satu metrik utama untuk tim pengembangan scrum yang gesit. Seperti pada agile, proses pengembangan diatur melalui sprint terikat waktu, Sprint Burndown digunakan sebagai cara melacak penyelesaian tugas selama sprint. Jam atau titik cerita digunakan sebagai unit pengukuran. Tujuannya adalah untuk mencapai kemajuan yang konsisten dan menyelesaikan pekerjaan sesuai dengan proyeksi awal. Sprint Burndown membantu tim untuk mengukur kecepatan kerja dan menyesuaikannya bila diperlukan.
2. Kecepatan Tim.
Velocity adalah indikator kunci lainnya, yang juga didasarkan pada jam atau titik cerita sebagai unit pengukuran. Ini mengukur jumlah rata-rata pekerjaan yang diselesaikan tim selama sprint dan digunakan untuk estimasi dan perencanaan di seluruh proyek. Kecepatan pelacakan penting untuk memastikan tim memberikan kinerja yang konsisten.
3. Poin Cerita.
Pada level anggota tim pengembangan individu, poin cerita adalah metrik yang berharga, karena ukuran cerita yang diberikan programmer selama setiap rilis merupakan indikator produktivitas pembuat kode ini.
4. Bagan Kontrol Siklus.
Mengukur total waktu dari saat pengerjaan tugas atau item backlog lainnya telah dimulai hingga selesai. Memungkinkan untuk melacak dan mengontrol waktu siklus memberikan hasil yang lebih dapat diprediksi.
5. Throughput dan Nilai yang Disampaikan.
Manajer proyek menganalisis tugas yang diberikan kepada pengembang dan memberikan nilai kepada mereka. Metrik ini kemudian digunakan untuk mengukur kinerja tim atau, dengan kata lain, jumlah pekerjaan bernilai tambah yang dilakukan.
6. Penggilingan Kode.
Code churn adalah metrik lain yang patut disebutkan karena digunakan untuk mengukur produktivitas tim secara keseluruhan dan untuk melacak kinerja pemrogram individu. Perputaran kode mengukur seberapa sering pengembang menghapus atau membuat perubahan pada baris kode yang ditambahkan sebelumnya, dan berapa persentase kode yang ditulis sebelumnya yang akhirnya diubah atau dibuang.
Pendapat ahli
Akhirnya, untuk menambahkan beberapa perspektif, beberapa kutipan tentang masalah tersebut oleh para profesional industri pengembangan perangkat lunak yang berpengalaman. “Saya harap Anda tidak ingin "membandingkan" metrik Anda dengan semacam standar atau bahkan dengan kinerja tim lain di perusahaan lain. Di mana pun saya bekerja memiliki variasi unik dalam definisi poin cerita, kecepatan, perkiraan per jam, tugas, dll. yang benar-benar membuat hampir tidak mungkin untuk membandingkan kinerja satu tim dari satu perusahaan secara langsung dengan kinerja tim lain di perusahaan lain. perusahaan,” kata Cliff Gilley, mantan Manajer Produk Teknis dan Pelatih Agile. “Saya agak curiga dengan metrik dalam hal memandu kinerja tim. Setelah Anda memperhatikan hanya satu atau dua variabel, menjadi sangat mudah untuk jatuh ke dalam (sengaja atau tidak) mempermainkan metrik dan membodohi diri sendiri bahwa Anda meningkat - padahal yang Anda lakukan hanyalah meningkatkan metrik. Misalnya, metrik berdasarkan kecepatan dapat "ditingkatkan" oleh tim yang berpindah ke cerita yang lebih kecil (lebih sedikit pekerjaan per cerita - jadi lebih banyak cerita yang diselesaikan - sehingga kecepatan meningkat). Itu mungkin hal yang baik jika cerita tersebut adalah cerita pengguna yang bermanfaat yang menghasilkan peningkatan nilai bisnis yang lebih kecil. Itu mungkin hal yang buruk jika ceritanya menjadi lebih kecil dan lebih banyak tugas "teknis" yang tidak memberikan nilai nyata dengan sendirinya, ” kata Adrian Howard, profesional industri lainnya,. “Saat bekerja dalam sistem berbasis tarikan, saya menghargai hasil dan waktu siklus. Yang pertama memberi saya info umum tentang kapasitas tim kami, dan seiring waktu dapat menjadi ukuran prediksi yang sangat kuat. Yang kedua bermanfaat sebagai ukuran umum dari efisiensi saluran pipa kami. Jika waktu siklus tinggi, saatnya untuk mulai melihat pipeline, karena ada batasan yang mungkin dapat kita upayakan untuk melakukan easing/eksploitasi. Tapi metrik hanyalah alat. Jangan tersesat di dalamnya, dan tentu saja jangan mulai merencanakan metrik tertentu. Pikirkan tentang apa yang Anda buat sebagai sebuah tim dan bagaimana Anda bekerja secara alami, lalu bangun sistem di sekitar orang-orang. Metrik akan membantu Anda melihat bagaimana sistem Anda mendukung pekerjaan semua orang. Atau tidak, ”Dave Cerra, produser pengembangan video game, menyimpulkan .
