Adakah cara elegan untuk menganalisis proses seorang insinyur?

Ada banyak sentimen bahwa mengukur komit tidak tepat.

Apakah ada penelitian yang dilakukan yang mencoba untuk menarik lebih banyak sumber daripada yang dilakukan - seperti:

• pola penelusuran
• Pekerjaan IDE (pra-komit)
• waktu menganggur
• multitasking

Saya tidak bisa memikirkan cara mudah untuk melakukan langkah-langkah ini, tetapi saya ingin tahu apakah ada penelitian yang telah dilakukan.

Pada catatan pribadi, saya percaya bahwa refleksi pada 'metrik' sendiri dapat berharga terlepas dari (atau tanpa adanya) menggunakan ini untuk evaluasi kinerja. Yaitu cara yang tidak bias untuk merefleksikan kebiasaan Anda. Tapi ini adalah masalah diskusi di luar T&J.

Tidak yakin apakah Anda akan menganggapnya elegan, tetapi Watts Humphrey menulis seluruh buku yang disebut Proses Perangkat Lunak Pribadi yang semuanya tentang mengukur produktivitas Anda sendiri. Dia menguraikan metrik untuk input seperti waktu di meja Anda vs interupsi, waktu yang dihabiskan bekerja pada berbagai jenis kegiatan siklus hidup perangkat lunak, cacat per jumlah kode. Ada laporan teknis yang memberikan versi singkatnya di:

http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm

Jika Anda ingin melihat sesuatu seperti kualitas kode pengembang, Chidamber & Kemerer mengusulkan beberapa metrik untuk kode berorientasi objek.

Metrik untuk kode berorientasi objek

• kedalaman pohon warisan,
• sejumlah metode tertimbang,
• jumlah fungsi anggota,
• jumlah anak, dan
• kopling antar objek.

Menggunakan basis kode, mereka mencoba menghubungkan metrik-metrik ini dengan kepadatan cacat dan upaya pemeliharaan menggunakan analisis kovarian. Studi selanjutnya melakukan analisis serupa pada ratusan proyek Source Forge Java untuk menentukan karakteristik mereka relatif terhadap Metrik CK dan beberapa metrik tambahan yang diusulkan kemudian.

Metrik yang muncul dalam konteks Tinjauan Kode

Cacat dapat dikategorikan berdasarkan banyak kriteria:

• keparahan: (utama, minor, kosmetik, selidiki / tidak diketahui),
• ketik (logika, kesalahan ketik, pengejaan, penyandian pelanggaran standar, dll.),
• asal / fase kontainmen (persyaratan, desain, kode, dll).

Ada juga tingkat persiapan dan inspeksi (waktu per pengulas, waktu per baris kode) dan kepadatan cacat (per KLOC (ribuan baris kode), per menit waktu inspektur / pengulas).

Merencanakan nilai-nilai ini terhadap diagram kontrol dapat menunjukkan kepada kita apakah kita berada dalam batas untuk proses (misalnya, tim yang memeriksa 200 baris kode yang tidak menemukan cacat dalam grup yang rata-rata dua puluh lima cacat per KLOC mungkin tidak berfungsi).

Metrik lainnya

Metrik lain yang dapat membantu termasuk untuk

• nilai yang diperoleh untuk membantu mengkalibrasi estimasi
• kecepatan bagi mereka yang menggunakan Scrum atau Kanban .
• Karya Pareto , Juran , Demming , Ishikawa , dan lainnya dari kualitas dan teknik industri agak portabel untuk pengembangan perangkat lunak dengan sedikit imajinasi.

Keterbatasan Analisis

Ada batas luar biasa pada nilai metrik. Bug yang diperbaiki per pengembang dapat berarti hampir apa saja, dan ketika Anda mulai menghukum atau memberi penghargaan pada pengukuran itu, saya yakin bug akan semakin banyak dan terperinci, dan campuran bug yang sulit dan mudah yang diperbaiki juga akan berubah ketika tim cherry memilih di untuk berlomba untuk mendapatkan yang terbaik.

Ada juga gangguan tertentu dan berpotensi kehilangan fokus dan kenikmatan yang bisa datang dengan pengukuran yang mengganggu. Anda tidak bisa menjadi lebih elegan (dan terbebani secara emosional) daripada penyair danau seperti Wordsworth yang berkata,

      Sweet is the lore which Nature brings;
      Our meddling intellect
      Mis-shapes the beauteous forms of things:--
      We murder to dissect.

Meskipun perangkat lunak tidak persis Nature, beri saya beberapa kebebasan karena saya pikir saya tidak akan pernah bisa menggunakan apa pun dari kelas Sastra Inggris SMA.

Agile mungkin dianggap sebagai reaksi terhadap proses besar yang terpusat. Kadang-kadang cara kerja itu membutuhkan begitu banyak upaya analitis sehingga kemampuan untuk mencapai aliran sementara membuat perangkat lunak semuanya menghilang.

Saya ingin menambahkan jawaban alternatif yang mengarah dari praktik rekayasa perangkat lunak standar ke bidang lain dengan tujuan mencuri dari alat dasar yang dapat kita adaptasi sesuai kebutuhan. Orang-orang jaminan kualitas prihatin dengan produksi, hasil, dan deteksi cacat dan pencegahan, sama seperti pengembang perangkat lunak.

http://en.wikipedia.org/wiki/Seven_Basic_Tools_of_Quality

Saya suka peta kendali.

http://en.wikipedia.org/wiki/Control_chart

Lakukan aktivitas, plot metrik, lakukan yang lain, plot metriknya, dan sebagainya. Misalnya, plot komit per hari. Bagan akan menyebarkan data yang berkisar dari beberapa minimum hingga beberapa maksimum. Mungkin nanti Anda bisa mengkarakterisasi hasil untuk menentukan bahwa ketika nilainya rendah, sesuatu menghambat kemajuan dan ketika terlalu tinggi, pekerjaan mulai dilakukan dengan cara cepat tetapi ceroboh. Bagaimana Anda mendorong pekerja untuk mempercepat atau memperlambat diserahkan kepada Anda.

Metrik pribadi mungkin sesuatu yang dapat Anda korelasikan untuk diri Anda sendiri dimulai dengan pertanyaan seperti, "Saya merasa paling produktif ketika saya ..."

• Tulis kasus penggunaan lengkap sebelum mulai kode.
• Tulis tes unit saya sebelum kode saya.
• Periksa dengan pemangku kepentingan sering untuk memastikan persyaratan tidak berubah dan membuat pengerjaan ulang besar-besaran pada pekerjaan yang dilakukan terhadap rencana usang.
• Ubah kode sebanyak mungkin.
• Mendelegasikan perubahan yang terdefinisi dengan baik kepada anggota tim yang paling ahli dengan bagian-bagian yang saya minta mereka ubah.
  • Berikan gambaran lengkap kepada tim saya, tetapi dengan prioritas kami dapat menyelesaikannya di sprint saat ini.
  • Mulai pass refactoring saya dengan daftar direktori hirarki, file, kelas, metode, persamaan, variabel, dokumentasi, dll yang akan saya ubah.
  • Meneliti masalah tingkat tinggi untuk menemukan solusi seni sebelumnya, memperkirakan ruang lingkup dan perbaikan utama yang diperlukan untuk membuat solusi yang lebih baik.

Pandangan lama yang kami ukur adalah apa yang dilakukan mungkin mengarahkan Anda untuk menyerang masalah berdasarkan apa yang Anda tentukan sebagai faktor pembatas

atau beberapa faktor dalam urutan prioritas berdasarkan diagram Pareto.

http://en.wikipedia.org/wiki/Pareto_chart