Alur kumulatif, waktu tunggu, dan panduan waktu siklus
Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019
Anda menggunakan diagram aliran kumulatif (CFD) untuk memantau alur kerja melalui sistem. Dua metrik utama untuk dilacak, waktu siklus, dan waktu tunggu, dapat diekstrak dari bagan. Untuk mengonfigurasi atau melihat bagan CFD, lihat Mengonfigurasi bagan alur kumulatif.
Atau, Anda dapat menambahkan bagan Kontrol waktu prospek dan waktu siklus ke dasbor Anda.
Sampel bagan dan metrik utama
CFD Alur berkelanjutan menyediakan bagan yang paling disukai oleh tim yang mengikuti proses yang ramping.
Namun, banyak tim telah mulai menggabungkan praktik ramping dengan Scrum atau metodologi lain yang berarti mereka berlatih miring dalam rentang perulangan atau sprint. Dalam situasi ini diagram mengambil tampilan yang sedikit berbeda dan menyediakan dua informasi tambahan, dan sangat berharga seperti yang ditunjukkan pada bagan berikutnya.
Alur berkelanjutan
CFD periode tetap yang ditunjukkan di sini adalah untuk sprint yang selesai.
Baris atas mewakili cakupan yang ditetapkan untuk sprint. Dan, karena pekerjaan harus diselesaikan pada hari terakhir sprint, kelereng status Tertutup menunjukkan apakah tim berada di jalur untuk menyelesaikan sprint atau tidak. Cara term mudah untuk menganggap tampilan ini adalah sebagai bagan burnup.
Data selalu digambarkan dengan langkah pertama dalam proses sebagai kiri atas dan langkah terakhir dalam proses sebagai kanan bawah.
CFD periode tetap untuk sprint yang telah selesai
Metrik bagan
Bagan CFD menampilkan jumlah item kerja yang dikelompokkan menurut status/kolom dari waktu ke waktu. Dua metrik utama untuk dilacak, waktu siklus, dan waktu tunggu, dapat diekstrak dari bagan.
Metrik
Definisi
Waktu Siklus 1
Mengukur waktu yang diperlukan untuk memindahkan pekerjaan melalui satu proses atau status alur kerja. Penghitungan adalah dari awal satu proses hingga awal proses berikutnya.
Waktu Tunggu 1
Untuk proses alur berkelanjutan: Mengukur jumlah waktu yang diperlukan saat permintaan dibuat (seperti menambahkan cerita pengguna yang diusulkan) hingga permintaan tersebut selesai (ditutup).
Untuk proses sprint atau periode tetap: Mengukur waktu dari saat pekerjaan pada permintaan dimulai hingga pekerjaan selesai (yaitu waktu dari Aktif ke Tertutup).
Pekerjaan sedang Berlangsung
Mengukur jumlah pekerjaan atau jumlah item kerja yang secara aktif sedang dikerjakan.
Cakupan
Mewakili jumlah pekerjaan yang dilakukan untuk jangka waktu tertentu. Hanya berlaku untuk proses periode tetap.
1 Widget CFD (Analitik) dan bagan CFD bawaan (penyimpanan data pelacakan kerja) tidak menyediakan nomor diskrit pada Waktu Prospek dan Waktu Siklus. Namun, widget Waktu Prospek dan Waktu Siklus menyediakan angka-angka ini.
Ada korelasi yang terdefinisi dengan baik antara Waktu Prospek/Waktu Siklus dan Work in Progress (WIP). Semakin banyak WIP, semakin lama waktu siklus, yang juga menyebabkan waktu tunggu yang lebih lama. Sebaliknya juga benar—semakin sedikit WIP, semakin pendek siklus dan waktu tunggu. Ketika tim pengembangan berfokus pada lebih sedikit item, mereka mengurangi siklus dan waktu tunggu. Korelasi ini adalah alasan utama mengapa Anda dapat dan harus menetapkan batas Work In Progress di papan tulis.
Jumlah item kerja menunjukkan jumlah total pekerjaan pada hari tertentu. Dalam CFD periode tetap, perubahan dalam hitungan ini menunjukkan perubahan cakupan untuk periode tertentu. Dalam CFD aliran berkelanjutan, ini menunjukkan jumlah total pekerjaan dalam antrean dan selesai untuk hari tertentu.
Menguraikan pekerjaan ke dalam kolom papan tertentu menyediakan tampilan tempat pekerjaan sedang dalam proses. Tampilan ini memberikan wawasan tentang di mana pekerjaan bergerak dengan lancar, di mana ada penyumbatan dan di mana tidak ada pekerjaan yang dilakukan sama sekali. Sulit untuk menguraikan tampilan tabular data, namun, bagan CFD visual memberikan bukti bahwa sesuatu terjadi dengan cara tertentu.
Mengidentifikasi masalah, mengambil tindakan yang sesuai
CFD menjawab beberapa pertanyaan tertentu dan berdasarkan jawabannya, tindakan dapat diambil untuk menyesuaikan proses untuk memindahkan pekerjaan melalui sistem. Mari kita lihat masing-masing pertanyaan tersebut di sini.
Apakah tim akan menyelesaikan pekerjaan tepat waktu?
Pertanyaan ini hanya berlaku untuk CFD periode tetap. Anda mendapatkan pemahaman dengan melihat kurva (atau perkembangan) pekerjaan di kolom terakhir papan.
Dalam skenario ini, mungkin tepat untuk mengurangi cakupan pekerjaan dalam iterasi jika jelas pekerjaan itu, pada kecepatan yang stabil, tidak diselesaikan dengan cukup cepat. Ini mungkin menunjukkan pekerjaan itu diremehkan dan harus diperhitungkan ke dalam perencanaan sprint berikutnya.
Namun mungkin ada alasan lain yang dapat ditentukan dengan melihat data lain pada bagan.
Bagaimana alur kerja berkembang?
Apakah tim menyelesaikan pekerjaan dengan kecepatan yang stabil? Salah satu cara untuk mengetahuinya adalah dengan melihat penspasian antara kolom yang berbeda pada bagan. Apakah mereka memiliki jarak yang mirip atau seragam satu sama lain dari awal hingga akhir? Apakah kolom tampak garis datar selama periode beberapa hari? Atau, apakah tampaknya "menjulur"?
Mura, istilah ramping untuk garis datar dan massa, berarti tidak merata dan menunjukkan bentuk limbah (Muda) dalam sistem. Ketidak merataan dalam sistem akan menyebabkan massal muncul di CFD.
Memantau CFD untuk garis datar dan massal mendukung bagian utama dari proses manajemen proyek Teori Batasan. Melindungi area terlambat dari sistem disebut sebagai proses drum-buffer-rope dan merupakan bagian dari bagaimana pekerjaan direncanakan.
Dua masalah muncul secara visual sebagai garis datar dan sebagai massal.
Garis datar muncul ketika tim tidak memperbarui pekerjaan mereka dengan irama biasa. Papan menyediakan cara tercepat untuk transisi bekerja dari satu kolom ke kolom lainnya.
Garis datar juga dapat muncul ketika pekerjaan di satu atau beberapa proses membutuhkan waktu lebih lama dari yang direncanakan. Garis datar muncul di banyak bagian sistem karena jika hanya satu bagian dari sistem atau dua bagian sistem yang bermasalah maka Anda akan melihat bulge.
Garis datar
Massal terjadi ketika pekerjaan dibangun di salah satu bagian sistem dan tidak bergerak melalui proses.
Misalnya, tonongan dapat terjadi ketika pengujian membutuhkan waktu yang lama sementara pengembangan membutuhkan waktu yang lebih singkat, menyebabkan pekerjaan terakumulasi dalam keadaan pengembangan (massal menunjukkan bahwa langkah yang berhasil mengalami masalah, belum tentu langkah di mana massa terjadi).
Tonjolan
Bagaimana Anda memperbaiki masalah alur?
Anda dapat menyelesaikan masalah kurangnya pembaruan tepat waktu melalui:
- Stand-up harian.
- Pertemuan reguler lainnya.
- Menjadwalkan email pengingat tim harian.
Masalah garis datar sistemik menunjukkan masalah yang lebih menantang, meskipun masalah seperti itu jarang terjadi. Garis datar menunjukkan bahwa pekerjaan di seluruh sistem telah berhenti. Penyebab yang mendasar dapat berupa:
- Penyumbatan di seluruh proses.
- Proses memakan waktu lama.
- Bekerja bergeser ke peluang lain yang tidak ditangkap di papan tulis.
Salah satu contoh garis datar sistemik dapat terjadi dengan fitur CFD. Pekerjaan fitur dapat memakan waktu lebih lama daripada mengerjakan cerita pengguna karena fitur terdiri dari beberapa cerita. Dalam situasi ini, kelereng diharapkan (seperti dalam contoh di atas) atau masalah ini sudah diketahui dan sudah diangkat oleh tim sebagai masalah. Jika ini adalah masalah yang diketahui, penyelesaian masalah berada di luar cakupan artikel ini.
Teams dapat secara proaktif memperbaiki masalah yang muncul sebagai massal CFD. Tergantung di mana bulge terjadi, perbaikannya mungkin berbeda. Sebagai contoh, mari kita misalkan bahwa bulge terjadi dalam proses pengembangan. Tonongan mungkin terjadi karena menjalankan pengujian membutuhkan waktu lebih lama daripada menulis kode. Penguji mungkin juga menemukan sejumlah besar bug. Ketika mereka terus mentransisikan pekerjaan kembali ke pengembang, pengembang mewarisi daftar pekerjaan aktif yang terus berkembang.
Dua cara yang berpotensi mudah untuk menyelesaikan masalah ini adalah: 1) Geser pengembang dari proses pengembangan ke proses pengujian sampai tonongan dihilangkan atau 2) mengubah urutan pekerjaan sederajat sehingga pekerjaan yang dapat dilakukan dengan cepat adalah terjalin dengan pekerjaan yang membutuhkan waktu lebih lama untuk dilakukan. Cari solusi sederhana untuk menghilangkan massal.
Catatan
Karena banyak skenario berbeda dapat terjadi yang menyebabkan pekerjaan dilanjutkan secara tidak merata, sangat penting bagi Anda untuk melakukan analisis aktual tentang masalah tersebut. CFD akan memberi tahu Anda bahwa ada masalah dan kira-kira di mana itu berada tetapi Anda harus menyelidiki untuk sampai ke akar penyebabnya. Panduan yang diberikan di sini menunjukkan tindakan yang direkomendasikan yang menyelesaikan masalah tertentu tetapi yang mungkin tidak berlaku untuk situasi Anda.
Apakah cakupan berubah?
Perubahan cakupan hanya berlaku untuk CFD periode tetap. Garis atas bagan menunjukkan cakupan pekerjaan. Sprint telah dimuat sebelumnya dengan pekerjaan yang harus dilakukan pada hari pertama. Perubahan pada baris atas menunjukkan pekerjaan ditambahkan atau dihapus.
Satu skenario di mana Anda tidak dapat melacak perubahan cakupan dengan CFD terjadi ketika jumlah item kerja yang sama ditambahkan seperti yang dihapus pada hari yang sama. Garis akan terus datar. Membandingkan beberapa bagan satu dengan bagan lainnya. Pantau masalah spesifik. Gunakan Lihat/konfigurasikan burndown sprint untuk memantau perubahan cakupan.
Terlalu banyak WIP?
Anda dapat dengan mudah memantau apakah batas WIP telah melebihi dari papan. Anda juga dapat memantaunya dari CFD.
Sejumlah besar WIP biasanya muncul sebagai bulge vertikal. Semakin lama ada wip dalam jumlah besar, semakin besar tonongan akan meluas menjadi oval. Ini adalah indikasi bahwa WIP berdampak negatif pada siklus dan waktu tunggu.
Berikut adalah aturan praktis yang baik untuk pekerjaan yang sedang berlangsung. Seharusnya tidak ada lebih dari dua item yang sedang berlangsung per anggota tim pada waktu tertentu. Alasan utama untuk dua item versus batas yang lebih ketat adalah karena realitas sering mengganggu proses pengembangan perangkat lunak apa pun.
Terkadang perlu waktu untuk mendapatkan informasi dari pemangku kepentingan, atau membutuhkan lebih banyak waktu untuk memperoleh perangkat lunak yang diperlukan. Ada sejumlah alasan mengapa pekerjaan mungkin dihentikan. Memiliki item kerja kedua untuk dipivot untuk memberikan kelonggaran. Jika kedua item diblokir, saatnya untuk menaikkan bendera merah untuk mendapatkan sesuatu yang tidak diblokir—bukan hanya beralih ke item lain. Segera setelah ada sejumlah besar item yang sedang berlangsung, orang yang mengerjakan item tersebut akan mengalami kesulitan pengalihan konteks. Kemungkinan besar mereka akan lupa apa yang mereka lakukan, dan kesalahan mungkin terjadi.
Waktu tunggu versus waktu siklus
Diagram di bawah ini menggambarkan bagaimana waktu tunggu berbeda dari waktu siklus. Waktu tunggu dihitung dari pembuatan item kerja hingga memasuki status Selesai. Waktu siklus dihitung dari pertama kali memasukkan kategori status Sedang Berlangsung atau Diselesaikan hingga memasukkan kategori Status selesai.
Ilustrasi waktu tunggu versus waktu siklus
Jika item kerja memasuki status Selesai lalu diaktifkan kembali, setiap waktu tambahan yang dihabiskannya dalam status Diusulkan, Sedang Berlangsung, atau Diselesaikan akan berkontribusi pada waktu prospek/siklusnya saat memasuki kategori Status selesai untuk kedua kalinya.
Jika tim Anda menggunakan papan, Anda mungkin ingin memahami bagaimana kolom Anda dipetakan ke status alur kerja. Untuk informasi selengkapnya tentang mengonfigurasi papan Anda, lihat Menambahkan kolom.
Untuk informasi selengkapnya tentang cara sistem menggunakan kategori status—Diusulkan, Sedang Berlangsung, Diselesaikan, dan Selesai—lihat Status alur kerja dan kategori status.
Merencanakan menggunakan perkiraan waktu pengiriman berdasarkan waktu prospek/siklus
Anda dapat menggunakan waktu prospek/siklus rata-rata dan penyimpangan standar untuk memperkirakan waktu pengiriman.
Saat membuat item kerja, Anda dapat menggunakan waktu tunggu rata-rata tim untuk memperkirakan kapan tim Anda akan menyelesaikan item kerja tersebut. Penyimpangan standar tim Anda memberi tahu Anda varianbilitas perkiraan. Demikian juga, Anda dapat menggunakan waktu siklus dan penyimpangan standarnya untuk memperkirakan penyelesaian item kerja setelah pekerjaan dimulai.
Dalam bagan berikut, waktu siklus rata-rata adalah delapan hari. Simpang siur standar adalah +/- enam hari. Dengan menggunakan data ini, kami dapat memperkirakan bahwa tim akan menyelesaikan cerita pengguna di masa mendatang sekitar 2-14 hari setelah mereka mulai bekerja. Semakin sempit penyimpangan standar, semakin dapat diprediksi perkiraan Anda.
Contoh widget Waktu Siklus
Mengidentifikasi masalah proses
Tinjau bagan kontrol tim Anda untuk outlier. Outlier sering mewakili masalah proses yang mendasar. Misalnya, menunggu terlalu lama untuk menyelesaikan tinjauan PR atau tidak menyelesaikan dependensi eksternal dengan cepat.
Seperti yang Anda lihat di bagan berikut, yang menunjukkan beberapa outlier, beberapa bug membutuhkan waktu lebih lama untuk diselesaikan daripada rata-rata tim. Menyelidiki mengapa bug ini membutuhkan waktu lebih lama dapat membantu mengungkap masalah proses. Mengatasi masalah proses dapat membantu mengurangi penyimpangan standar tim Anda dan meningkatkan prediksi tim Anda.
Contoh widget Waktu Siklus memperlihatkan beberapa outlier
Anda juga dapat melihat bagaimana perubahan proses memengaruhi waktu prospek dan siklus Anda. Misalnya, pada 15 Mei tim melakukan upaya konser untuk membatasi WIP dan mengatasi bug basi. Anda dapat melihat bahwa penyimpangan standar menyempit setelah tanggal tersebut, menunjukkan peningkatan prediktabilitas.
Langkah berikutnya
Mengonfigurasi bagan alur kumulatif Anda atau Mengonfigurasi bagan waktu tunggu atau waktu siklus