(
c )
Hampir sejak munculnya industri teknologi, ia telah berburu untuk "Paus Putih" - metrik tenaga kerja pengembang. Mungkin keinginan untuk menghitung programmer KPI lahir dari ungkapan yang umum dalam bisnis tradisional: "Anda tidak dapat merencanakan, jika Anda tidak dapat mengukur."
Mengikuti ratusan KPI berbeda yang coba diprogram oleh programmer, banyak metode berbeda untuk menganalisis data operasional muncul - mulai dari melacak arah tampilan monitor hingga Scrum dan Kanban. Pengukuran kualitas kerja telah bekerja dengan sangat baik di banyak industri sehingga tampaknya logis untuk mentransfer pengalaman ini ke pengembangan perangkat lunak. Hasilnya mengecewakan.
Mengukur dan mengelola produktivitas pengembang belum menghasilkan standar kualitas internasional tunggal. Perusahaan IT berteknologi tinggi sedang mengembangkan metrik mereka sendiri ... beberapa di antaranya hampir tidak mungkin dibandingkan dengan KPI tradisional di bidang kegiatan lainnya.
Pada artikel ini, kita akan berbicara tentang metrik saat ini yang paling menarik dan tentang "metrik" di TI.
Sudah sulit untuk menemukan (setidaknya dalam sumber terbuka) informasi tentang menggunakan jumlah jam kerja, jumlah baris dalam kode sumber (SLOC), Poin Fungsi atau jumlah bug yang dibuat oleh masing-masing pengembang sebagai metrik.
Dalam wacana publik, adalah mungkin untuk mencapai konsensus bahwa bekerja lebih banyak
tidak berarti bekerja lebih baik, bahwa solusi dengan 200 baris kode dapat lebih cepat atau lebih produktif daripada solusi dengan 1.000 baris, dan metrik Function Points yang dibuat pada 1979 sudah usang.
Tetapi apa yang terjadi dengan keinginan untuk mengukur dan menghitung semuanya? Ternyata, itu belum hilang.
Netflix
(
c )
Netflix berfokus pada mengatasi hambatan yang memisahkan pengguna dari konten. Setiap kali sesuatu mencegah Anda menonton episode berikutnya dari seri favorit Anda, para pengembang memperbaiki masalah dan mengukur waktu yang dibutuhkan untuk menyelesaikannya.
Platform streaming menguji ide-ide baru secara nyata dan mengukur perbedaan yang signifikan secara statistik dalam interaksi pengguna dengan produk. Selain itu, kesalahan pada tahap pengujian hipotesis cukup dapat diterima - "satu-satunya kesalahan nyata yang tidak dapat diterima di Netflix adalah ketidakmampuan untuk berinovasi."
Pengembangan produk di Netflix dimulai dengan hipotesis yang terlihat seperti ini:
Algoritma / fungsi / desain (×) meningkatkan interaksi pelanggan dengan layanan dan, pada akhirnya, retensi mereka.
Hipotesisnya mungkin untuk meningkatkan relevansi hasil pencarian, menggunakan desain baru untuk antarmuka pengguna atau fitur baru - misalnya, menunjukkan kepada peserta apa yang dilihat teman-teman mereka dari jejaring sosial di Netflix. Intuisi dan gagasan tentang bagaimana memberikan layanan yang lebih baik kepada pelanggan menjadi dasar dari pendekatan pengembangan.
Langkah pengembangan kedua adalah menulis tes yang akan mengukur dampak hipotesis. Terkadang ini berarti Anda dapat segera membuat prototipe yang mencerminkan esensi konsep, yang akan memungkinkan Anda untuk dengan cepat menguji hipotesis dan berusaha untuk membangun solusi yang lebih baik.
Langkah ketiga adalah tes itu sendiri, di mana ratusan ribu penonton dapat berpartisipasi. Prototipe ini digunakan untuk peserta dalam percobaan untuk periode waktu tertentu. Dia mungkin memiliki dua kohort untuk pengujian atau 20, yang masing-masing menggunakan pendekatan yang berbeda atau menggabungkan elemen baru yang berbeda. Puluhan tes konsumen yang berbeda dapat diluncurkan kapan saja.
Bahkan kegagalan hipotesis dianggap sebagai hasil yang dicapai. Akibatnya, kemungkinan bahwa hipotesis berikut akan berubah menjadi lebih baik hanya meningkat. Tim pengembang memiliki kebebasan besar dalam menerapkan ide ke produk selama periode waktu yang lama.
Ibm
(
c )
Metrik tertua dan paling "jelas" untuk pengembangan perangkat lunak menghitung jumlah garis yang dihasilkan oleh pengembang atau tim individu, dan jumlah waktu yang dihabiskan untuk itu. Metrik ini pertama kali digunakan oleh IBM. Dalam
film dokumenter Triumphof the Nerds: The Rise of Accidental Empires, Steve Ballmer mencatat bahwa pada 1980-an, IBM tampaknya membuat agama keluar dari metrik itu.
Pada 2011, IBM
memperkenalkan alat untuk secara otomatis menganalisis kode sumber untuk kinerja, keamanan, dan kompleksitas teknis. Pengembang yang kodenya diberi nilai tertinggi menerima skor tertinggi dari sistem. Indikator kinerja rendah berfungsi sebagai sinyal untuk memperhatikan pelatihan karyawan (IBM mengklaim bahwa skor akhir yang rendah tidak digunakan sebagai hukuman).
Namun demikian,
publikasi kemudian memberi kesan pergeseran paradigma - metodologi untuk membangun hipotesis sudah disebutkan di jantung pengembangan. Pengembangan hipotesis tidak dapat dilakukan tanpa kehilangan waktu dan sumber daya.
Hal utama dalam metrik ini adalah umpan balik pelanggan pada produk. Kita perlu fokus pada apa yang paling penting bagi pelanggan, dan mengabaikan fungsi yang tidak bermanfaat, atau bahkan mengganggu pengguna. Strategi ini digambarkan dalam diagram di atas.
Spacex
(
c )
Ada sangat sedikit informasi tentang pekerjaan pengembang di SpaceX, yang terkait dengan kerahasiaan umum proyek-proyek perusahaan non-publik ini. Tetapi menurut
informasi tidak langsung, Anda dapat memahami garis besar perkiraan dari keseluruhan gambar. Dan gambar ini berbicara tentang pentingnya tes.
Dalam ilmu roket, tes adalah dasar dari desain. Dalam perangkat lunak pemrograman untuk roket,
prinsip yang sama digunakan . Misalnya, jika roket mendarat dengan selamat, maka semua tim yang bertanggung jawab atas pengembangan menyelesaikan KPI. Tanpa tes pendahuluan, tidak mungkin untuk berhasil menyelesaikan proyek semacam itu.
Mengingat masalah yang dihadapi oleh tim yang terlibat dalam menyiapkan peralatan untuk lingkungan ruang yang keras, tidak sulit untuk memahami apa yang menjadi tanggung jawab mereka.
SpaceX sedang
mencoba untuk memparalelkan kode antara proyek yang berbeda - dengan paradigma pengembangan ini, koreksi kesalahan untuk satu proyek (secara relatif, roket) secara otomatis meluas ke proyek lain.
Perusahaan memilih C ++ sebagai bahasa pemrograman utama. Pertama, ini memungkinkan Anda untuk mempekerjakan banyak pengembang profil tinggi, karena bahasanya masih relatif populer. Pada saat yang sama, pilihan sering dibuat untuk pengembang game yang terbiasa menulis kode dan bekerja di lingkungan dengan memori dan daya komputasi yang terbatas.
Kedua, mereka mendapat manfaat dari ekosistem C ++ yang besar. Tidak perlu membuat perangkat lunak khusus ketika Anda dapat menggunakan alat yang sudah lama dikenal, seperti gcc dan gdb.
Dan akhirnya, dalam pengembangan, perhatian besar diberikan pada pengujian metrik. Pengembang dan insinyur disarankan untuk memeriksa segala sesuatu yang dapat Anda pikirkan keselamatan dan toleransi kesalahan.
Data yang dikumpulkan selama pengujian disimpan bersama dengan kode sumber yang berfungsi selama pengujian. Jika ada kerusakan yang terjadi selama pengujian roket, SpaceX akan dapat membuat ulang lingkungan peluncuran yang tepat, mereproduksi masalah dan memperbaikinya.
Integrasi berkelanjutan digunakan untuk menguji semua kode secara otomatis. Mereka bahkan memiliki rig uji dengan semua komponen mesin untuk mensimulasikan sepenuhnya mulai dan mendeteksi potensi masalah.
Amazon
Amazon memiliki salah satu strategi paling menarik yang diuraikan dalam wawancara 40 menit ini dengan direktur AWS Developer Tools.
Gagasan kunci untuk membentuk tim pengembangan adalah penskalaan mitosis. Tim dibagi menjadi kelompok-kelompok kecil, sepenuhnya menjaga kontinuitas dan fungsi tim "ibu".
Jeff Bezos, CEO AWS Developer Tools,
percaya bahwa tim yang ideal tidak boleh melibatkan lebih banyak orang daripada yang bisa diisi oleh dua pizza.
Dalam tim kecil, komunikasi jauh lebih efektif, mereka tetap terdesentralisasi, mandiri, berkembang lebih cepat dan memperkenalkan inovasi.
Amazon awalnya memiliki arsitektur monolitik dan perangkat lunak (Perl / Mason / C ++). Kemudian arsitekturnya diuraikan menjadi layanan, dan struktur organisasi menjadi tim pizza. Jadi layanan cloud Amazon Elastic Compute Cloud (Amazon EC2) dibentuk oleh grup yang hanya terdiri dari dua "tim pizza".
Amazon berkomitmen untuk mengotomatisasi sepenuhnya semua proses (membangun, menyebarkan, melakukan transfer, dll.). Di dalam setiap penyebaran, beberapa jenis pengujian digunakan: integrasi, browser, web, dan memuat. Dengan demikian, semuanya dikendalikan dan diukur.
Keamanan dipantau sepanjang proses peluncuran produk, itulah sebabnya mengapa sangat normal bagi Amazon untuk "berpikir seperti insinyur keamanan" dalam budaya Amazon apa pun. Saat meluncurkan proyek baru, pengembang terutama bekerja pada model arsitektur dan ancaman.
Validasi dibangun di semua jalur pipa melalui kombinasi kebijakan kepercayaan lokal dan global. Pemimpin dapat secara independen menetapkan kebijakan audit untuk timnya (misalnya, sebelum penempatan, setiap komitmen baru harus ditanggung oleh pengujian unit hingga 70%).
Pada saat yang sama, ada aturan umum Amazon yang mencakup setiap penyebaran (misalnya, larangan penyebaran satu kali di setiap wilayah).
Adalah pengembang dalam tim, dan bukan arsitek, yang bertanggung jawab atas arsitektur proyek. Dan hanya kemudian dianggap oleh seorang arsitek atau chief engineer. Situasi yang sama dengan keamanan dan pengujian: tim mengelola seluruh proses. Meskipun pendekatan ini memiliki minus, yang terdiri dari periode pelatihan yang panjang.
Setiap tahun, tim menyiapkan rencana operasional pada enam halaman ("rencana bisnis" tersebut disajikan di semua tingkat Amazon). Rencana tersebut mengindikasikan apa yang akan dicapai tahun depan dengan sumber daya tetap dan apa yang dapat dicapai dengan sumber daya tambahan. Manajer mengumpulkan dokumen enam halaman dari semua tim yang mereka kelola, membuat dokumen enam halaman mereka sendiri dan menyerahkannya ke manajemen mereka - dan seterusnya hingga Jeff Bezos. Dalam arah yang berlawanan, sumber daya dialokasikan ke tim.
Apa yang dimiliki startup di sana
Berkat survei yang
dilakukan oleh Stackify (platform cloud untuk pemantauan dan pemecahan masalah aplikasi web), dimungkinkan untuk mengetahui sikap terhadap metrik di beberapa perusahaan baru dan perusahaan "tangan tengah" yang terkenal.
CircleCI adalah layanan yang populer, termasuk di Rusia, Continuous Integration-dengan pengaturan fleksibel untuk aplikasi web dan seluler. Rob Zuber, CTO CircleCI, percaya bahwa metrik terbaik untuk mengukur produktivitas dan keefektifan pengembangan perangkat lunak adalah ukuran waktu yang diperlukan kode untuk beralih dari komitmen menjadi penempatan - Waktu Berkomitmen untuk Menyebarkan (CDT).
Tujuan mengukur CDT adalah untuk "melacak" hambatan penyebaran. Idealnya, jika Anda menggunakan otomasi dan / atau tes dengan kualitas yang baik, Anda dapat pergi ke penyebaran dalam hitungan menit (atau bahkan detik) untuk layanan Microsoft. Jika Anda terutama menggunakan proses kontrol kualitas manual, maka ini mungkin akan berarti bahwa penyebaran akan memakan waktu lebih lama.
Analisis CDT CircleCI menunjukkan di mana menemukan peluang untuk perbaikan. Perbaikan dapat lebih teknis (misalnya, membuat tes lebih efektif), lebih berorientasi pada proses, atau kombinasi keduanya. Semakin kecil komit Anda, semakin cepat dapat diluncurkan, masing-masing, semakin cepat Anda dapat memperbaiki situasi jika terjadi kesalahan.
Adeva adalah perusahaan rekrutmen dan membentuk tim pengembangan siap pakai untuk startup. Untuk menawarkan layanan yang lebih baik kepada pelanggan, ia telah meneliti metrik kinerja programmer selama beberapa tahun. Kesimpulannya sederhana: tidak ada pengukuran formal dan obyektif dari efektivitas dan produktivitas pengembangan perangkat lunak.
Alih-alih menggunakan KPI, Adeva mengatur pertemuan singkat dengan pengembang, di mana manajemen dengan cermat mendengarkan cerita tentang pencapaian dan kegagalan. Untuk menentukan efektivitas departemen secara keseluruhan, pengembang ditanyai tentang kegunaan dan kesadaran anggota tim lainnya. Pada pertemuan-pertemuan ini, semua orang dapat menyuarakan gagasan yang dapat membantu diri mereka sendiri dan anggota tim lainnya.
Selain komunikasi antarpribadi, Adeva melihat bagaimana kode pengembang terintegrasi dengan basis kode, memeriksa kinerjanya, keamanan, dan menentukan apakah kode tersebut akan memiliki biaya layanan yang lebih rendah dalam jangka panjang.
Scorchsoft, pengembang aplikasi web dan seluler berbahasa Inggris, memperkirakan waktu proyek. Karena sebagian besar pelanggan Scorchsoft berharap untuk menerima suatu produk dengan harga tetap, perusahaan harus segera mengidentifikasi spesifikasi yang jelas dan tidak ambigu. Kinerja diukur berdasarkan waktu pengembangan berdasarkan alat Toggl (pelacak waktu) dan Jira.
Suatu proyek dianggap berhasil jika klien puas dan tim memenuhi tenggat waktu.
Kesimpulan
Terkadang, dengan evaluasi metrik, Anda masih bisa sampai pada penyebut yang sama - ini adalah fokus pada kenyamanan pengguna. Alih-alih mencoba mengukur langsung produktivitas programmer, fokusnya adalah mengukur segala sesuatu yang menghambat kemajuan dalam memberikan nilai kepada klien.
Ketika pelanggan akhir adalah indikator utama keberhasilan, jauh lebih mudah untuk menggunakan metrik yang berasal dari pemasaran: tingkat konversi, perilaku pengguna, atau penilaian peringkat. Di bidang ini, kesuksesan sangat tergantung pada manajemen, yang mungkin membuat keputusan yang salah. Misalnya, pengembangan fungsi yang tidak perlu bagi klien memiliki dampak negatif yang jauh lebih besar pada bisnis daripada pengembang yang menonjol dari "standar".