Menilai efisiensi proses dengan peta aliran nilai
Saat Anda membuat peta aliran nilai, atau VSM, ini membantu Anda menganalisis proses siklus rilis Anda saat ini. Tujuan VSM adalah untuk menunjukkan secara visual di mana tim membuat nilai dalam proses dan di mana ada limbah. Tujuannya adalah untuk sampai pada proses yang memberikan nilai maksimum kepada pelanggan dengan pemborosan minimum. VSM dapat membantu Anda menentukan area yang tidak berkontribusi nilai apa pun atau yang benar-benar mengurangi nilai produk.
Mari kita lihat bagaimana Tailspin mengukur.
Mara, yang baru dalam tim, akan membuat VSM untuk membantunya memahami proses yang ada. Dengan VSM, dia akan mengetahui saat tim cocok dengan model kematangan DevOps. Ternyata, tim yang lebih matang biasanya merilis lebih cepat, dengan keyakinan yang lebih besar, dan dengan bug yang lebih sedikit daripada tim yang kurang matang.
Mara tahu dia belum mengerti semuanya, jadi dia akan membuat VSM cepat di papan tulis di ruang rapat. Akan ada beberapa celah dan pertanyaan yang belum terjawab, tapi tidak apa-apa. Ini permulaan. Ketika dia melakukan sebanyak yang dia bisa, dia akan berbagi dengan tim. VSM memberi semua orang titik awal yang umum untuk mengidentifikasi langkah-langkah pertama menuju peningkatan bagaimana Tailspin mengembangkan dan merilis situs webnya.
Mari kita lihat petanya.
Memahami proses saat ini
Mara mengumpulkan tim di ruang pertemuan untuk menyajikan VSM-nya.
Mara: VSM membantu kami mengukur saat proses memiliki nilai bagi pelanggan dan saat proses tersebut memakan waktu tanpa menghasilkan nilai apa pun. Peta kami dimulai di kiri atas dengan spesifikasi fungsional untuk perangkat lunak. Mari kita ikuti hanya satu fitur untuk melihat bagaimana hal itu bergerak melalui siklus rilis kami saat ini.
Beberapa orang meremehkan, tetapi Mara terus melanjutkan.
Proses pengembangan
Membuat fitur baru saat ini dimulai dengan membuat label di kontrol sumber 
. Kami memiliki satu orang yang dapat membuat label, dan itu Andy. Kami meminta label melalui email. Kami menggunakan sistem kontrol versi terpusat, sehingga Andy menunggu sampai semua kode yang ada dicek masuk dan stabil sebelum ia membuat label. Setelah label dibuat, kami mendapatkan email yang mengatakan kami dapat mulai bekerja. Proses ini memakan waktu hingga tiga hari dan tidak memiliki nilai bagi pelanggan. Hal-hal tanpa nilai kepada pelanggan akan memakan waktu sesedikit mungkin.
Pengodean fitur membutuhkan waktu sekitar empat hari untuk satu orang setelah kami mendapatkan akses ke semua file yang kami butuhkan
. Kita harus berada di jaringan perusahaan untuk mengakses kontrol sumber. Kali ini memiliki nilai bagi pelanggan. Mereka menginginkan fitur ini.
Proses pengujian
Setelah memutuskan bahwa kami memiliki build yang stabil, kami memperbarui spreadsheet untuk memberi tahu Amita bahwa ada build yang siap untuk pengujian dan di mana menemukannya 
. Butuh dua hari untuk mendapatkan pemberitahuan.
Amita secara manual menguji build 
. Proses ini semakin lama seiring pertumbuhan basis kode. Untuk saat ini, katakanlah tiga hari. Dia kemudian mengirim email kepada Andy dengan laporan bug. Pengujian tidak menambah nilai, tetapi diperlukan.
Andy kemudian harus mengambil waktu untuk melakukan triase bug dan menetapkan pekerjaan . Dibutuhkan tiga hari lagi bagi Andy untuk memahami masalah dan membawanya ke pengembang yang tepat.
Proses operasi
Ketika Amita menyetujui sebuah bangunan, dia menyerahkannya ke Tim. Tim perlu menyebarkan build ini ke server praproduksi untuk pengujian lebih lanjut. Seringkali, server praproduksi tidak sinkron dengan patch terbaru dan pembaruan yang diperlukan untuk menjalankan situs web. Dibutuhkan Tim sekitar dua hari untuk menyebarkan ke praproduksi dan menjalankan beberapa pengujian. Sekali lagi, saat menyebarkan ke praproduksi tidak menambah nilai, perlu 
.
Setelah build siap untuk produksi, kepemimpinan perlu menyetujui rilis sebelum dapat disebarkan. Persetujuan dilakukan dalam rapat. Dibutuhkan empat hari agar kepemimpinan dapat bertemu dan meninjau rilis.
Terakhir, Tim menyebarkan fitur tersebut, dan fitur tersebut sampai ke pelanggan di sini di sudut kanan atas VSM. Jika konfigurasi server produksi telah melayang sehingga tidak sinkron dengan praproduksi, Tim pertama-tama perlu memperbaruinya, yang membutuhkan waktu satu hari 
.
Menghitung metrik nilai pelanggan
Sekarang kita dapat melihat metrik performa utama dan melihat cara mengukurnya.
Total waktu peluang penjualan adalah waktu yang dibutuhkan sebuah fitur untuk sampai ke pelanggan. Di sini, total waktunya adalah 22 hari. Waktu proses adalah waktu yang dihabiskan untuk fitur yang memiliki nilai bagi pelanggan. Di sini, waktu proses mencakup empat hari untuk pengkodean ditambah satu hari untuk menyebarkan fitur, yang memberikan total lima hari.
Rasio aktivitas adalah waktu proses dibagi dengan total waktu peluang penjualan:
$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$
Ini adalah efisiensi kita. Kalikan efisiensi dengan 100 untuk mendapatkan persentase. Hasilnya lebih besar dari 0% dan biasanya kurang dari 100%. Persentase yang lebih tinggi menunjukkan efisiensi yang lebih besar.
Ganti nomor kita dan kita akan mendapatkan:
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{22\ days}}{\ =\ .23}$$
Kalikan hasilnya dengan 100% dan Anda mendapatkan 23%.
Seperti yang Anda lihat, kita memiliki banyak ruang untuk perbaikan. Dan membutuhkan waktu 22 hari untuk mengembangkan fitur terlalu panjang.
Tim: Jadi bagaimana ini bisa membantu kita?
Dari mana kita harus pergi dari sini?
Mara: Ini membantu untuk melihat di mana kita sekarang sehingga kita dapat menentukan area tempat adanya limbah. Kami ingin meminimalkan waktu yang kami habiskan yang tidak bernilai bagi pelanggan. Saya percaya kita benar-benar dapat meningkatkan efisiensi kita dengan mengadopsi pendekatan DevOps. Untuk satu hal, kita dapat mengotomatiskan banyak langkah-langkah ini, yang pasti mengurangi waktu.
Sebaiknya kita tidak menghilangkan proses kita saat ini, tetapi saya pikir kita dapat bekerja menuju proses yang lebih efisien dengan tahapan kecil tanpa mengganggu apa yang saat ini kita miliki.
Mari kita lihat hanya beberapa area tempat kita dapat meningkatkan.
Andy: Kita mungkin juga mulai dari awal. Butuh waktu lama untuk mendapatkan label pada kode agar kita dapat memulai fitur baru. Saya harus berjalan-jalan ke pengembang dan meminta mereka untuk memeriksa apa yang mereka miliki sehingga kita dapat membangun dan menguji. Jika Anda bisa mencari tahu cara mempercepatnya, Anda akan mendapat perhatian saya.
Juga, saya perhatikan bahwa Anda tidak punya waktu di sana untuk build itu sendiri. Itu membutuhkan waktu setengah hari sekarang. Akan menyenangkan melihat waktu meningkat.
Amita: Dan dev tidak selalu memperbarui spreadsheet untuk memberi tahu saya ada build baru yang perlu diuji. Ini akan menghemat waktu jika ada beberapa cara untuk memastikan bagian itu selesai.
Mara: Bagus. Saya pikir DevOps dapat membantu kita mengatasi semua kekhawatiran ini.
Andy: Kita tidak punya waktu untuk mengubah prosesnya sekarang. Anda dengar Irwin. Kita berada dalam mode krisis di sini.
Mara: Saya mengerti. Untuk saat ini, mari kita lakukan apa yang selalu kita lakukan. Namun, kita semua dapat memikirkan tentang bagian kita dalam proses dan cara meningkatkan. Kita dapat mulai membuat perubahan kecil secara paralel dengan proses kita saat ini. Kita kemudian dapat melihat apakah DevOps membantu kita tanpa mengganggu apa yang kita miliki. Saya akan menyimpan peta ini dan metrik performa. Jika kita akhirnya mengadopsi praktik Azure DevOps, maka kita dapat mengunjungi kembali angka-angkanya. Mungkin kita bisa memperbarui VSM di beberapa titik.