it-swarm-id.com

Metrik yang digunakan untuk meminta pertanggungjawaban pengembang

Saya mengajukan pertanyaan pada baris kode per jam dan mendapatkan yang baru. Jadi pertanyaan tindak lanjut saya yang matang adalah:

Jika bukan baris kode, lalu apa metrik yang baik untuk mengukur (berdasarkan jam/hari/satuan waktu) efektivitas programer jarak jauh?

72
Kyle

Dalam 16 tahun saya tidak pernah benar-benar menemukan metrik yang bisa diterapkan dari jenis yang Anda cari.

Pada dasarnya untuk menjadi berguna, apa pun harus dapat diukur, representatif, dan tidak dapat dinamai (yaitu sistem tidak dapat dimainkan oleh pengembang yang pandai). Ada terlalu banyak variabel dalam pengembangan perangkat lunak untuk membuatnya terukur sebagai karya per potong dengan cara ini.

Yang paling dekat Anda dapatkan adalah kemajuan terhadap perkiraan - yaitu berapa banyak tugas yang mereka selesaikan dalam perkiraan yang disepakati. Kuncinya di sini adalah (a) mendapatkan estimasi yang baik dan adil dan (b) memahami di mana estimasi telah terlampaui karena alasan yang baik yang tidak dapat/tidak dapat disalahkan pengembang (itu adalah sesuatu yang benar-benar lebih kompleks daripada yang diantisipasi). Pada akhirnya, jika Anda mendorong pengembang terlalu keras, Anda cenderung menemukan perkiraan secara bertahap merayap ke tingkat di mana mereka selalu bertemu bukan karena peningkatan produktivitas tetapi karena rentang waktu yang empuk.

Berlalu terlalu jauh dalam hal perkiraan (menguranginya untuk membuat tekanan untuk disampaikan) dan Anda membuat tenggat waktu yang palsu yang menurut penelitian tidak meningkatkan produktivitas dan cenderung berdampak pada semangat tim (lihat Peopleware untuk informasi lebih lanjut ).

Tetapi pada dasarnya saya bertanya-tanya apakah Anda melihat masalah yang sedikit salah. Mengapa pemrogram jarak jauh berbeda dari pemrogram lain dalam hal mengukur produktivitas? Bagaimana Anda mengukur produktivitas programmer non-jauh?

Jika ini tentang tidak memercayai mereka untuk bekerja dari jarak jauh maka itu pada dasarnya masalah kepercayaan yang lebih luas. Jika Anda tidak memercayai mereka untuk bekerja dari rumah, maka Anda perlu membangun kepercayaan itu, tidak membiarkan mereka bekerja dari rumah, atau menemukan cara untuk memuaskan diri sendiri bahwa mereka memang bekerja ketika seharusnya.

101
Jon Hopkins

Metrik berfungsi paling baik di pabrik, dan pemrogram tidak bekerja pada jalur Majelis.

Saya sepenuhnya memahami keinginan untuk mengukur produktivitas.

Tetapi apakah Anda akan menggunakan metrik yang sama untuk dokter keluarga dan ahli bedah jantung? Bagaimana dengan Michelangelo yang melukis Kapel Sistine, dan seorang lelaki di Meksiko mengaduk-aduk lukisan beludru hitam Elvis?

Louis de Broglie menulis tesis doktoral yang sangat singkat, para penguji akan menolaknya - kecuali de Broglie adalah seorang bangsawan yang berposisi tinggi, dan mereka membutuhkan alasan yang bagus. Jadi penguji mengirimnya ke Einstein, yang tidak hanya tidak menolaknya, dia juga merujuknya ke komite Nobel, dan de Broglie mendapatkan Hadiah Nobel dalam Fisika untuk lima tahun kemudian.

Langkah-langkah numerik paling sesuai untuk pekerjaan yang berulang, seperti menuang besi atau memasang baut pada pintu mobil. Tetapi jika Anda mengulangi kode yang sudah dilakukan sebelumnya, Anda tidak perlu seorang programmer, Anda hanya perlu copy-and-paste. Pemrograman pada dasarnya adalah disiplin kreatif, dan produktivitas sepenuhnya tergantung pada apa yang Anda lakukan.

Beberapa hari, saya membuat 1.000 baris kode. Hari ini, saya akan memperbaiki bug geometri koordinat, dan kode mungkin menyusut. Jika saya harus memperbaiki bug pada driver kernel Linux, saya mungkin menghabiskan waktu seharian untuk debugging, dan tidak menulis baris kode baru.

Mengukur produktivitas programmer sangat, sangat, sangat subyektif.

Jika Anda ingin tahu apakah Joe produktif, temukan Sally dan Ralph, yang tahu apa yang dilakukan Joe dan mahir dalam bidang yang sama, dan tanyakan pada mereka.

Sistem numerik terbaik yang pernah saya lihat adalah poin poker perencanaan Agile. Itu hanya cara yang bagus untuk bertanya kepada Joe dan Sally dan Ralph seberapa keras mereka berpikir tentang pekerjaan Joe yang akan datang. Kemudian Anda dapat mengukur produktivitas poin per minggu untuk setiap anggota tim. Tetapi meskipun begitu, perlu beberapa saat untuk mengkalibrasi estimasi tim, dan angkanya tidak jelas dan mudah dibuang.

Banyak orang menginginkan perkiraan produktivitas sehingga mereka dapat melakukan perencanaan jadwal. Ini semacam "colokkan ke Proyek MS, lihat jalur kritis, dan ada teori tanggal pengiriman Anda". Saya belum pernah melihat pekerjaan itu - ada terlalu banyak hal yang tidak diketahui. Jika Anda menginginkannya, gunakan Waterfall, desain semuanya di depan, jangan izinkan perubahan pesanan, dan bersiaplah untuk kecewa.

48
Bob Murphy

Satu-satunya metrik yang saya gunakan adalah jumlah perangkat lunak yang berfungsi yang ia hasilkan untuk yang diberikan jumlah uang Saya berinvestasi.

Terlepas dari jadwalnya, jika dia bekerja jarak jauh atau tidak, jumlah jeda yang dia ambil, metodologi yang dia gunakan atau jumlah jam kerja.

By perangkat lunak yang berfungsi Maksud saya:

Daftar fitur yang ditentukan oleh pengguna/pelanggan yang memenuhi tingkat kualitas yang diperlukan

By jumlah uang:

Berapa banyak pengguna/pelanggan membayar untuk fitur yang ditetapkan + biaya perawatan

Jadi ia memiliki langsung tentang bagaimana itu dibangun dan kualitas pekerjaan yang dihasilkan tetapi tidak terikat pada metrik baris kode sumber.

42
user2567

Anda memerlukan pengembang atau pemimpin tim yang berpengalaman (yang tidak terkait dengan programer jarak jauh) untuk memperkirakan berapa lama beberapa tugas, dan efektivitas diukur dengan membandingkan waktu yang diperlukan dengan perkiraan. Untuk memastikan bahwa perkiraannya baik, Anda dapat secara acak memilih beberapa tugas dan menjalankannya oleh tim internal yang Anda miliki di bawah kendali.

23
user281377

Cara lain yang menarik untuk mengukur produktivitas adalah dengan menghitung tes yang dapat diautomatisasikan yang ditinjau oleh manajer per hari. Pengembang mendapat:

  • titik untuk menulis tes automatable (dan melewati ulasan) dan menambahkannya ke suite uji regresi,
  • titik untuk membuat mereka lulus, sementara tidak menyebabkan kegagalan tes regresi lainnya.

Pengembang dan manajer dapat bersama-sama meningkatkan sistem dengan:

  • bersama-sama menyetujui bidang-bidang penting pengembangan dan pengujian
  • meninjau dan menjalankan uji suite secara independen.
  • memutuskan untuk tidak membangun fitur yang memiliki manfaat bisnis terbatas tetapi membutuhkan banyak pengembangan dan pengujian yang diperlukan untuk menghadirkan fitur tersebut. (Baris kode yang paling produktif adalah yang Anda putuskan untuk tidak menulis karena tidak memberikan keuntungan bisnis).
  • mempartisi sistem menjadi arsitektur (seperti model-view-controller) yang memfasilitasi pengembangan fitur tambahan tanpa merusak keseluruhan sistem.

Pengembang tidak dapat memainkan metrik karena:

  • tes yang berlebihan akan diblokir oleh tinjauan manajer.
  • tes berbutir halus dapat diblokir oleh tinjauan manajer.
  • tes berbutir halus akan meningkatkan kualitas sistem.

Manajer tidak dapat memainkan metrik karena:

  • menolak terlalu banyak tes akan menyebabkan gesekan pengembang.
  • meminta terlalu banyak tes akan membuat sulit untuk menolak tenggat waktu nanti.

Pengembang tidak dapat mengacaukan manajer karena

  • Setiap unit fungsionalitas yang dikirim dengan tes juga harus lulus dari paket regresi. yaitu ini memaksa pengembang untuk mengembangkan dengan hati-hati tanpa melanggar kode lainnya.
  • Setiap klaim pekerjaan harus dapat dibuktikan dengan lulus tes baru dan tes regresi.

Manajer tidak dapat mengacaukan pengembang karena.

  • Setiap unit fungsionalitas yang diminta harus menyertakan kasus uji utama, dan perkiraan jumlah kasus uji yang diperlukan untuk menyelesaikan pekerjaan.
  • Sulit untuk meminta jadwal yang agresif dan/atau lembur gratis ketika Anda jelas meminta banyak pekerjaan.

Manfaat besar lainnya bagi manajer adalah ia dapat membawa pengembang baru dan tahu bahwa mereka tidak akan dapat memberikan kode yang secara diam-diam merusak sistem (karena suite uji regresi menangkapnya).

Kelemahan besar bagi manajer adalah ia memaksanya untuk mengakui bahwa sistemnya lebih kompleks daripada yang terlihat pada deskripsi 1 halaman fitur tersebut. Kelemahan lainnya adalah transparansi metode ini akan mempersulit pengembang untuk menyalahkan kegagalan bisnis.

7
Jay Godse

Tentunya dimungkinkan untuk merancang semua jenis metrik rumit untuk mengevaluasi kinerja, tetapi pada akhirnya sebagian besar penilaian Anda harus bergantung pada subjektivitas dan masukan dari orang-orang yang dekat dengan basis kode.

Sebagai contoh, sangat mungkin bagi beberapa tim untuk melakukan crank slop yang tidak dapat dipertahankan secara internal dengan tingkat yang sangat cepat, dan ini bahkan mungkin memenuhi tenggat waktu dan spesifikasi yang diperlukan. Tetapi apakah utang teknis yang diperoleh dari gaya kerja semacam itu lebih buruk daripada jika tim telah menghasilkan sesuatu yang kuat dan dapat dipelihara tetapi melewati batas waktu beberapa minggu? Tergantung.

Jika tujuan dari pertanyaan ini adalah untuk menyelesaikan beberapa jenis masalah produktivitas, saya akan mengatakan bahwa apa yang sebenarnya dilakukan manajer untuk memfasilitasi pekerjaan tim sama atau lebih penting daripada teknik pengukuran apa pun yang digunakan untuk mengevaluasi tim. Ini adalah jalan dua arah. Dengan kata lain, saya mengatakan bahwa metrik baik-baik saja tetapi jika Anda ingin lebih banyak dari tim mana pun pertanyaan utamanya adalah apakah manajer melakukan segala yang mungkin untuk memastikan tim bisa produktif.

Ini jauh melampaui menulis spec, menemukan tim, melemparkan spec "di atas tembok" dan mengklik stopwatch.

6
Angelo

Beberapa ide:

  1. fitur diimplementasikan
  2. bug diperbaiki (juga akun bug yang kemudian dibuka kembali oleh QA)
  3. keluhan pengguna diselesaikan (perhatikan bahwa itu tidak sama dengan 2 - satu bug serius mungkin terasa sakit di leher sementara 100 kesalahan pengetikan mungkin tidak begitu penting)

Mungkin juga ingin dilacak:

  1. Cakupan kode dengan tes
  2. Cakupan kode oleh dokumentasi internal
  3. Cakupan fitur oleh dokumentasi eksternal (pengguna)
2
StasM

Ukur dengan cara yang sama seperti Anda diukur oleh pelanggan. Dari segi kode fungsional, tetapi pada skala yang lebih kecil.

Buat tujuan singkat - satu atau dua minggu - dan lihat apakah programmer memenuhi tujuan, dan lakukan dengan cara yang memuaskan.

Saya sangat menyarankan peer review kode, karena ini memungkinkan Anda untuk menangkap kode yang buruk di muka.

2
user1249

Bagaimana dengan Tingkat penjualan produk/layanan.

Terkadang saya pernah mendengar itu disebut komisi/persentase dari bruto

Orang-orang membeli produk yang bagus, bukan?

Bisnis ingin menjual produk (atau mungkin layanan, perbedaan yang sama untuk ini)

Jadi jika itu yang Anda inginkan, ukurlah.

Sedikit seperti mengatakan orang yang mendesain mobil yang mendapat ulasan bagus & menjual dengan baik telah melakukan pekerjaan dengan baik.

Sekarang mengadopsi metrik ini dan tim pemrograman akan ingin berinteraksi dengan petugas penjualan karena dua alasan.

  • Promising underliverable

  • Tidak menjual produk ke pelanggan secara efektif

1
Tim Williscroft

Menulis kode/Pemrograman tidak seperti meletakkan palu ke paku. Sama seperti "menulis" secara umum, itu bukan sesuatu yang dapat Anda terapkan, biasanya metrik juga - menurut saya.

Tidak bisakah Anda melihat check-in mereka, atau apa yang telah mereka lakukan melalui peer-review, review kode?

Atau Anda tahu, apakah mereka benar-benar menghasilkan kode kerja dan solusi yang memperbaiki masalah?

0
Jack Marchetti