Satu Cincin Untuk Menguasai Mereka Semua
Jrtolkien
“Anda hanya bisa mengontrol apa yang bisa diukur”
P. DruckerKetika sampai pada metrik, lusinan, jika bukan ratusan, pilihan berbeda muncul di benak Anda.
Pengukuran apa yang belum ditemukan!
Tetapi masalahnya adalah, ketika Anda melihat foto-foto indah ini, seringkali sama sekali tidak dapat dimengerti apa artinya.
Dan secara umum, sama sekali tidak jelas apakah metrik ini dipilih dengan benar atau apakah layak untuk melihat yang sama sekali berbeda?
Saya ingin semacam metrik, sehingga saya melihat, dan semuanya segera menjadi jelas.
Tetapi apakah itu ada? Atau tidak ada sihir?
Mari kita lihat dan lihat contoh spesifik ...
Seringkali, semua yang kita miliki hanyalah serangkaian input data yang tidak jelas apa yang harus dilakukan.
Jira dan tugasnya
Bayangkan bahwa perusahaan Anda menggunakan pelacak tugas Jira dan semua pengembang wajib menandai acara untuk mengambil tugas untuk bekerja dan solusinya.
Anda bisa mendapatkan pembongkaran untuk tugas-tugas Jira, tetapi apa yang harus dilakukan selanjutnya?
Ide bagus dalam situasi ini adalah untuk memikirkan dengan tepat apa yang ingin Anda kelola dan hasil apa yang ingin Anda capai.
Baca, misalnya, artikel "
Wawasan metrik: seperti yang saya pahami, apa itu metrik dan apa pesona utama mereka "
Dan jika kita menambahkan di sini juga buku-buku "Lean Analytics", "Running Lean" dan Tao Toyota, maka menjadi jelas bahwa dalam kasus Jira adalah yang paling tepat untuk mengelola dan mengukur waktu pengiriman fungsi yang dikembangkan ke prom.
Jadi, tujuannya dipilih - kami ingin mengukur waktu pengiriman perangkat lunak, tetapi Anda dapat melakukan ini dengan seratus cara berbeda. Misalnya, Anda dapat mengukur panjang setiap langkah pengembangan, dan juga menambahkan ke pengukuran ini hilangnya waktu untuk menunggu, memperbaiki cacat, menemukan kembali, dll. Bahkan vskidku dapat dipanggil sekitar 50-70 metrik berbeda yang terkait dengan pengembangan perangkat lunak.
Bagaimana menjadi? Apakah ada Metrik Satu-Satunya yang dengan satu pandangan dapat memahami segalanya?
Jika Anda melihat dengan mata kepala sendiri puluhan metrik yang dibahas di atas, maka saya tahu jawaban Anda sebelumnya - Anda akan berkata: Tidak! Jadi saya ingin ...
Saya ingin metrik seperti itu, sekilas di mana orang bisa memahami seberapa sukses pengembangan bergerak dan apakah perlu untuk melakukan sesuatu tambahan dengan itu.
Anehnya, tampaknya ada satu metrik yang layak yang dapat dengan aman mengklaim gelar
One and Only .
Mari kita lihat lebih dekat.
Ada laporan di Jira sebagai "Total Flow Diagram" ...
"Stop-stop-stop ... Semua orang mengenalnya, - Anda berkata, saya tidak akan menemukan sesuatu yang baru di sini"
Secara umum, ya, laporan ini diketahui semua orang, tetapi mari kita lihat lebih detail. Saya yakinkan Anda bahwa Anda akan menemukan beberapa kejutan "menyenangkan".
Begini tampilannya biasanya:
Beberapa garis. Mengapa mereka Mengapa Apa yang mereka maksud Dan inilah yang ...
Bilah merah gelap - jumlah tugas yang diselesaikan
berdasarkan basis akrual . Biru adalah jumlah tugas dalam pekerjaan, dan kuning adalah tugas baru yang terdaftar dalam jaminan.
Total kumulatif adalah ketika tugas yang dilakukan selalu ditambahkan ke jumlah tugas yang dilakukan sebelumnya.
Misalnya, bayangkan Anda melakukan 2 tugas sehari sebelum kemarin. Pada grafik pada hari sebelum kemarin akan dicatat: 2.
Kemarin Anda melakukan 3 tugas lagi. Poin berikutnya pada grafik adalah 2 (kemarin) +3 (kemarin) = 5.
Dan hari ini kamu telah melakukan satu tugas lagi. Poin hari ini pada grafik akan sama dengan 2 (kemarin) +3 (kemarin) +1 (hari ini) = 6
Yaitu jadwal akan meningkat setiap saat.
Dan sekarang, jika Anda menempatkan pada grafik jumlah tugas yang dilakukan, jumlah tugas dalam pekerjaan dan tugas baru, maka kita dapat mengekstrak Metrik One One dan Only.
Mari kita perhatikan contoh nyata (pembongkaran dari Kibana dan Elasticsearch):
Lihat?
Bahkan, kita bisa menghitung kecepatan (atau produktivitas) pengembangan. 200 tugas baru selesai dalam 17 hari. Dari sini kita dapatkan bahwa kecepatan pengembangan saat ini adalah 11,76 tugas / hari, mis.
0,085 hari per
tugas .
Mereka dinilai berdasarkan jadwal, jumlah tugas dalam pekerjaan, area biru, tidak berubah (lebar strip hampir sama di mana-mana), yaitu. kita dapat mengasumsikan bahwa kecepatan pengembangan konstan, berbeda dengan jumlah tugas baru.
Pada kecepatan pengembangan saat ini, 800 tugas baru yang dibuat pada 06/17/2018 akan selesai hanya setelah 68,03 hari.
Ok Menurut saya, tidak juga.
Berbicara? Pasti!
Ini adalah contoh dunia nyata lainnya (laporan Jira). Ini adalah jadwal pelaksanaan tiket oleh dukungan teknis:
Dengan cara yang sama, kami menghitung produktivitas layanan dukungan - 2,7 tugas / hari.
Ada sesuatu untuk diperjuangkan
Tidak cukup mengetahui kecepatan saat ini. Anda juga harus memahami nilai target, mis. lihat apa yang harus diperjuangkan.
Memahami kecepatan satu orang, Anda dapat menghitung berapa banyak orang yang membutuhkan layanan dukungan untuk merealisasikan jumlah target tugas atau meningkatkan produktivitas saat ini.
Layanan dukungan mempekerjakan 15 orang. Ternyata ada 0,18 tugas / hari per orang.
Misalkan Anda ingin meningkatkan kecepatan eksekusi dan membuat layanan dapat bekerja bukan 2,7 tugas per hari, tetapi 10 (nilai target).
Satu orang melakukan 0,18 tugas per hari, yang berarti 56 orang akan melakukan 10 tugas.
Baik, atau sebagai opsi, Anda dapat meningkatkan kecepatan satu orang.
Dengan kecepatan 1 tugas per hari, untuk 10 tugas Anda tidak perlu lagi 56 orang, tetapi hanya 10.
Kami mengatur waktu pengiriman
Ternyata metrik memungkinkan Anda, pada kenyataannya, memengaruhi waktu pengiriman.
Membandingkan kinerja saat ini dengan nilai target, Anda dapat memahami berapa kali Anda perlu mempercepat proses.
Dengan memvariasikan parameter yang membentuk produktivitas (jumlah orang dan kecepatan pekerjaan mereka), Anda dapat mengontrol total waktu pengiriman.
Di mana lagi ini berlaku?
Bahkan, analog dari metrik dapat dilihat di banyak daerah.
Ambil DevOps misalnya. DevOps digunakan untuk mempersingkat interval waktu antara membuat kit distribusi dan menyebarkannya ke prom, mis. di sini, seperti pada contoh di atas, Anda perlu mengontrol waktu pengiriman.
Jelas, metrik ini juga ideal untuk DevOps. Hitung saja berapa banyak distribusi (rakitan) yang telah mencapai prom dalam waktu tertentu dan dapatkan kinerja pipeline Anda saat ini.
Pada prinsipnya, metrik yang sama dapat digunakan di bidang yang terkait dengan uang.
Misalnya, untuk toko online, orang juga bisa menghitung jumlah pesanan untuk waktu tertentu. Seluruh pertanyaannya adalah, apakah toko benar-benar membutuhkannya?
Kesimpulan
Seperti yang Anda lihat, One Only Universal Metric masih memiliki hak untuk hidup, setidaknya di bidang pengembangan perangkat lunak dan di divisi layanan (layanan dukungan teknis).
Mudah untuk menghitung, mengandung makna, dan dapat digunakan untuk membandingkan dengan nilai target.
Tentu saja, itu tidak dapat digunakan tanpa berpikir. Sebelum Anda memulai implementasi, pikirkanlah, tetapi Anda benar-benar membutuhkannya.
Apa pendapat Anda tentang metrik universal?
Metrik apa yang Anda gunakan sebagai universal?