Ukur sistem pengiriman perangkat lunak

Mulai dari keputusan yang perlu dibuat

Sebuah tim ingin mengetahui apakah AI memperbaiki pengiriman perangkat lunak. Menghitung baris kode yang dihasilkan menjawab pertanyaan yang berbeda. Tetapkan hasil yang berguna dan syarat kualitas sebelum memilih metrik.

Untuk layanan ekspor fiktif, hasil yang diinginkan adalah pengiriman perubahan yang telah diterima secara andal dengan total upaya lebih sedikit. Catat persiapan, implementasi, peninjauan, perbaikan, dan waktu tunggu. Sertakan perubahan yang gagal atau dibatalkan.

Gunakan satu layanan dengan batas yang jelas. Menggabungkan situs eksperimental dan layanan pembayaran kritis dapat menghasilkan angka yang tidak menjelaskan keduanya. Jelaskan konteks sebelum membandingkan periode atau tim.

Gunakan definisi terkini

Model pengiriman DORA saat ini mencakup lima metrik. Cakupannya adalah kinerja pengiriman, bukan nilai setiap fitur atau kontribusi individu. Definisi metrik DORA.

Dashboard dapat menggunakan definisi lain. Baca definisinya sebelum menafsirkan hasil. Dokumentasi deployment Taiga saat ini menjelaskan empat metrik yang dilaporkan dari catatan deployment penyedia. Ukuran pemulihannya menggunakan deployment berikutnya yang berhasil. Ukuran itu bukan catatan lengkap setiap insiden produksi. Definisi Taiga.

Periksa urutan perubahan fiktif

Misalkan sebuah layanan melakukan dua belas deployment dalam sebulan. Delapan mengirimkan perubahan terencana. Empat memperbaiki masalah dari rilis sebelumnya. Jumlahnya dua belas, tetapi jenis deployment tersebut juga penting.

Bulan berikutnya, tim melakukan sepuluh deployment: sembilan perubahan terencana dan satu perbaikan. Jumlah deployment yang lebih sedikit dapat disertai lebih banyak pekerjaan yang berguna. Angka ini menggambarkan cara menafsirkan hasil; angka ini bukan tolok ukur kinerja.

Periksa juga distribusinya. Satu waktu tunggu peninjauan yang panjang dapat tersembunyi dalam rata-rata. Ukuran pemulihan dari satu kegagalan merupakan bukti yang lemah untuk keandalan mendatang. Laporkan jumlah pengamatan dan pengecualian yang berpengaruh.

Hubungkan alur kerja dengan dampaknya

Gunakan sinyal layanan untuk memeriksa apakah perubahan pengiriman memengaruhi pengguna. Pipeline yang lebih cepat tidak cukup jika ekspor lebih sering gagal. Gunakan SLO yang sesuai atau ukuran hasil lain dengan definisi yang jelas. Panduan SLO.

Upaya peninjauan dan pengerjaan ulang membantu menjelaskan hasil. Jika AI mempercepat implementasi tetapi menghasilkan diff besar, peninjauan dapat menjadi penghambat. Jika penyediaan lingkungan memerlukan beberapa hari, penulisan kode yang lebih cepat mungkin hanya sedikit memengaruhi total waktu pengiriman.

Pilih satu perbaikan yang mengatasi penghambat yang diamati. Misalnya, sediakan lingkungan pengujian yang didukung atau perkecil perubahan. Tetapkan metrik kualitas sebagai penyeimbang agar tim dapat mendeteksi peningkatan kecepatan semu akibat pemeriksaan yang lebih lemah.

Pastikan pengukuran tetap berguna

Hindari peringkat individu berdasarkan jumlah PR atau kode yang dihasilkan. Ukuran ini dapat mendorong pembagian pekerjaan secara dibuat-buat, penghindaran pemeliharaan yang sulit, atau pengalihan beban peninjauan ke rekan kerja.

Tinjau hasil bersama orang yang bertanggung jawab atas seluruh layanan. Catat perubahan pada alat, komposisi pekerjaan, tim, dan lingkungan. Perlakukan perbandingan sebelum dan sesudah sebagai bukti yang memiliki keterbatasan, bukan bukti otomatis tentang hubungan sebab-akibat.

Tujuannya adalah keputusan berikutnya yang lebih baik. Pengukuran kecil yang dapat dipercaya dan menghasilkan perbaikan terverifikasi lebih berguna daripada dashboard besar tanpa kesepakatan tentang maknanya.

Berlatih dengan sepuluh perubahan

Dataset fiktif terpisah ini mencatat sepuluh perubahan terencana. Semua waktu menggunakan UTC pada tanggal yang ditampilkan. Kolom perbaikan yang kosong berarti tidak ada perbaikan yang dicatat dalam dataset ini.

Bandingkan waktu dari kode siap hingga peninjauan dimulai, lalu dari penerimaan hingga rilis. Identifikasi waktu tunggu terlama yang terlihat. Selidiki penyebabnya sebelum menyatakan bahwa waktu tunggu itu dapat dihindari. Timestamp ini tidak mengukur upaya aktif atau menunjukkan kapan insiden dimulai. Rilis perbaikan saja tidak dapat menetapkan waktu pemulihan deployment yang gagal.

Unduh dataset fiktif (CSV)