Panduan aliran kumulatif untuk waktu tunggu dan waktu siklus

Layanan Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Diagram alur kumulatif (CFD) membantu Anda memantau proses kerja dengan memvisualisasikan alur kerja melalui sistem Anda. Artikel ini menjelaskan cara menggunakan CFD, waktu siklus, dan waktu tunggu untuk mengidentifikasi masalah dan meningkatkan efisiensi alur kerja.

CFD aliran berkelanjutan adalah bagan yang lebih disukai oleh sebagian besar tim yang mengikuti proses lean.

Tetapi banyak tim menggabungkan praktik ramping dengan Scrum atau metode lainnya. Mereka menggunakan praktik lean selama iterasi atau sprint. Dalam hal ini, diagram terlihat sedikit berbeda. Ini menunjukkan dua tambahan. CFD aliran kontinu adalah bagan yang lebih disukai oleh sebagian besar tim yang mengikuti proses lean.

Tetapi banyak tim menggabungkan praktik ramping dengan Scrum atau metode lainnya. Mereka menggunakan praktik lean selama iterasi atau sprint. Dalam hal ini, diagram terlihat sedikit berbeda. Ini menunjukkan dua informasi tambahan yang berharga, seperti yang ditunjukkan pada bagan berikutnya, CFD periode tetap. CFD aliran berkelanjutan
Bagan yang memperlihatkan CFD aliran berkelanjutan abstrak. Label menunjukkan waktu prospek, waktu siklus, pekerjaan sedang berlangsung, dan item di berbagai status.

CFD periode tetap ini menunjukkan sprint yang telah selesai.

Baris atas menunjukkan cakupan yang ditetapkan untuk sprint. Karena pekerjaan perlu diselesaikan pada hari terakhir, kemiringan status tertutup menunjukkan apakah tim berada di jalur yang benar. Anggaplah tampilan ini sebagai grafik burnup.

Dalam bagan, langkah pertama dalam proses berada di area kiri atas. Langkah terakhir ada di area kanan bawah.

CFD dengan periode tetap untuk sprint yang telah selesai
Bagan yang memperlihatkan CFD periode tetap yang abstrak. Label menunjukkan item aktif, terselesaikan, dan tertutup serta perubahan cakupan.

Bagan metrik

CFD memperlihatkan jumlah item kerja yang dikelompokkan menurut status atau kolom dari waktu ke waktu. Dua metrik utama untuk pelacakan adalah waktu siklus dan waktu tunggu. Anda mengekstrak metrik ini dari bagan.


Metrik

Definisi


Waktu siklus1

Waktu yang diperlukan untuk memindahkan pekerjaan melalui satu proses atau status alur kerja. Ukur panjang dari awal satu proses ke awal proses berikutnya.

Waktu tunggu1

Untuk proses alur berkelanjutan: Waktu sejak permintaan dibuat (seperti menambahkan cerita pengguna yang diusulkan) hingga permintaan tersebut selesai (ditutup).

*Untuk sprint atau fi Untuk proses alur berkelanjutan: Waktu sejak permintaan dibuat (seperti menambahkan cerita pengguna yang diusulkan) hingga permintaan tersebut selesai (ditutup).

Untuk proses sprint atau periode tetap: Waktu dari saat bekerja pada permintaan dimulai hingga pekerjaan selesai (misalnya, waktu dari status Aktif ke Tertutup).

Pekerjaan sedang berlangsung (WIP)

Jumlah pekerjaan atau jumlah item kerja yang sedang berlangsung secara aktif.

Cakupan

Jumlah pekerjaan yang dialokasikan untuk periode tertentu. Metrik ini hanya berlaku untuk proses periode tetap.


1 Widget CFD yang menggunakan data Analytics dan CFD bawaan yang dapat Anda lihat dari backlog tim atau papan tidak menyediakan waktu tunggu dan nilai waktu siklus yang diskrit. Namun, widget Waktu Prospek dan Waktu Siklus menyediakan nilai-nilai ini.

Ada korelasi yang jelas antara waktu tunggu atau waktu siklus dan WIP. Lebih banyak WIP menyebabkan waktu siklus yang lebih lama dan waktu tunggu yang lebih lama. Sebaliknya juga benar—WIP yang lebih sedikit mengakibatkan waktu siklus dan waktu proses yang lebih pendek. Ketika tim pengembangan berfokus pada lebih sedikit item, mereka mengurangi siklus dan waktu tunggu. Korelasi ini adalah alasan utama untuk menetapkan batas WIP pada papan yang Anda gunakan untuk melacak dan mengelola pekerjaan.

Jumlah item kerja menunjukkan jumlah total pekerjaan pada hari tertentu. Dalam CFD periode tetap, perubahan dalam hitungan ini berarti perubahan cakupan untuk periode tersebut. Dalam CFD dengan aliran berkelanjutan, ini menunjukkan jumlah total pekerjaan yang ada dalam antrean dan yang telah diselesaikan untuk hari tertentu.

Mengategorikan pekerjaan ke dalam kolom papan tertentu menunjukkan jumlah pekerjaan di setiap area proses. Tampilan ini memberikan wawasan tentang di mana pekerjaan bergerak dengan lancar, di mana ada penyumbatan, dan di mana tidak ada pekerjaan yang dilakukan. Sulit untuk memahami tampilan data tabular, tetapi CFD visual membantu Anda melihat apa yang terjadi dalam proses kerja Anda dan mengapa.

Mengidentifikasi masalah dan mengambil tindakan yang sesuai

CFD memberikan jawaban atas pertanyaan berikut. Berdasarkan jawabannya, Anda dapat menyesuaikan proses untuk memindahkan pekerjaan melalui sistem.

Apakah tim akan menyelesaikan pekerjaan tepat waktu?

Pertanyaan ini hanya berlaku untuk CFD periode tetap. Anda dapat memperoleh pemahaman dengan melihat kurva (atau perkembangan) pekerjaan di kolom terakhir papan.

Bagan yang memperlihatkan CFD setengah selesai. Kurva yang diproyeksikan untuk item yang diselesaikan berada di bawah tingkat cakupan di akhir sprint.

Dalam skenario ini, Anda mungkin mempertimbangkan untuk mengurangi cakupan pekerjaan dalam iterasi. Tindakan ini sesuai jika jelas bahwa pekerjaan tidak diselesaikan dengan cukup cepat, dengan asumsi itu berlanjut pada kecepatan yang stabil. Skenario ini dapat menunjukkan bahwa pekerjaan itu diremehkan dan harus diperhitungkan dalam perencanaan sprint berikutnya.

Namun, mungkin ada alasan lain pekerjaan tidak diselesaikan dengan cukup cepat. Anda dapat menentukan alasan tersebut 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 di antara berbagai kolom pada bagan. Apakah mereka memiliki jarak yang mirip atau seragam satu sama lain dari awal hingga akhir? Apakah ada kolom yang tampak datar selama beberapa hari? Atau apakah ada yang tampaknya menonjol?

Mura, atau tidak merata, adalah istilah efisien untuk garis datar dan gundukan. Mura menunjukkan bentuk pemborosan (Muda) dalam sistem. Ketidakmerataan dalam sistem menyebabkan tonjolan muncul di CFD.

Memantau CFD untuk garis datar dan tonjolan mendukung bagian utama dari proses manajemen proyek Teori Kekangan. Melindungi area paling lambat dari sistem disebut sebagai proses drum-buffer-rope dan merupakan bagian dari cara perencanaan kerja.

Dua masalah tampak secara visual sebagai garis datar dan sebagai tonjolan.

Garis datar muncul ketika tim tidak memperbarui status item kerja mereka secara teratur. Papan yang Anda gunakan untuk melacak dan mengelola pekerjaan 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 atau dua bagian yang bermasalah, Anda akan melihat tonjolan.

Garis datar
Bagan CFD abstrak. Garis untuk jumlah item aktif, terselesaikan, dan tertutup tetap datar selama periode waktu yang signifikan.

Penumpukan terjadi saat pekerjaan menumpuk di salah satu bagian sistem dan tidak bergerak melalui proses.
Misalnya, tonongan dapat terjadi ketika pengujian membutuhkan waktu lama tetapi pengembangan membutuhkan lebih sedikit waktu. Hasilnya adalah pekerjaan terakumulasi pada tahap pengembangan. Tonjolan menunjukkan bahwa langkah berikutnya mengalami masalah, belum tentu langkah di mana tonjolan terjadi.

Benjolan
Bagan CFD abstrak. Area untuk item aktif menjulur ke sudut kanan bawah bagan.

Bagaimana Anda memperbaiki masalah alur?

Anda dapat menyelesaikan masalah kurangnya pembaruan tepat waktu dengan mengambil tindakan berikut:

  • Mengadakan stand-up harian
  • Mengadakan rapat 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 dihentikan. Penyebab yang mendasar dapat mencakup masalah berikut:

  • Penyumbatan di seluruh proses
  • Proses memakan waktu lama
  • Peralihan pekerjaan ke peluang lain yang tidak tercatat di papan

Salah satu contoh lapisan datar sistemik dapat terjadi dalam fitur CFD. Pekerjaan fitur dapat memakan waktu lebih lama daripada mengerjakan cerita pengguna, karena fitur terdiri dari beberapa cerita. Dalam situasi ini, kemiringan diperkirakan (seperti dalam contoh sebelumnya), atau masalahnya sudah diketahui dengan baik dan tim sudah mengangkatnya. Jika ini adalah masalah yang diketahui, penyelesaian masalah berada di luar cakupan artikel ini.

Teams dapat secara proaktif memperbaiki masalah yang tampak sebagai tonjolan CFD. Perbaikan yang tepat dapat bergantung pada lokasi terjadinya tonjolan. Sebagai contoh, misalkan benjolan terjadi dalam proses pengembangan. Pembengkakan mungkin terjadi karena pengujian memakan 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.

Ada dua cara yang berpotensi mudah untuk menyelesaikan masalah ini:

  • Pindahkan pengembang dari proses pengembangan ke proses pengujian sampai tonjolan itu hilang.
  • Ubah urutan pekerjaan. Secara khusus, mengombinasikan pekerjaan yang dapat dilakukan dengan cepat dengan pekerjaan yang membutuhkan waktu lebih lama.

Cari solusi dasar untuk menghilangkan tonjolan.

Catatan

Karena berbagai skenario dapat terjadi yang menyebabkan pekerjaan berlanjut secara tidak merata, sangat penting bagi Anda untuk melakukan analisis aktual tentang masalah tersebut. CFD dapat memberi tahu Anda bahwa ada masalah. Ini juga dapat memberi tahu Anda kira-kira di mana masalahnya, tetapi Anda harus menyelidiki untuk sampai ke akar penyebabnya. Panduan ini menyediakan tindakan yang direkomendasikan yang menyelesaikan masalah tertentu, tetapi solusinya mungkin tidak berlaku untuk situasi Anda.

Apakah cakupan berubah?

Perubahan cakupan hanya berlaku untuk CFD periode tetap. Garis atas bagan menunjukkan cakupan pekerjaan. Sprint disiapkan sebelumnya dengan pekerjaan yang harus dilakukan pada hari pertama. Perubahan pada baris atas menunjukkan penambahan atau penghapusan pekerjaan.

Dalam satu skenario tertentu, Anda tidak dapat melacak perubahan cakupan dengan CFD. Skenario tersebut terjadi ketika jumlah item kerja yang sama ditambahkan dan dihapus pada hari yang sama. Garis tetap datar dalam kasus ini.

Untuk melacak perubahan cakupan dalam kasus ini, lakukan tindakan berikut:

  • Membandingkan beberapa bagan satu dengan bagan lainnya.
  • Pantau masalah tertentu.
  • Gunakan sprint burndown untuk memantau perubahan cakupan.

Apakah ada terlalu banyak Pekerjaan Dalam Proses?

Anda dapat dengan mudah memantau papan untuk menentukan apakah batas WIP terlampaui. Anda juga dapat memantau tingkat WIP dengan menggunakan CFD.

Sejumlah besar WIP biasanya terlihat sebagai tonjolan vertikal. Semakin lama ada sejumlah besar WIP, semakin tonjolan meluas menjadi bentuk oval. Perilaku ini adalah indikasi bahwa WIP berdampak negatif pada siklus dan waktu tunggu.

Berikut adalah aturan praktis yang baik untuk WIP: Tidak boleh ada lebih dari dua item yang sedang dikerjakan per anggota tim pada waktu tertentu. Alasan utama untuk menggunakan batas dua item, bukan batas yang lebih ketat, adalah bahwa realitas sering mengganggu proses pengembangan perangkat lunak.

Terkadang perlu waktu untuk mendapatkan informasi dari pemangku kepentingan atau untuk memperoleh perangkat lunak yang diperlukan. Ada sejumlah alasan mengapa pekerjaan dapat dihentikan. Mempertahankan item kerja kedua memberikan fleksibilitas operasional selama penundaan yang tidak terduga. 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 barang yang sedang dalam proses, orang yang mengerjakan barang tersebut dapat mengalami kesulitan beralih konteks. Kemungkinan mereka lupa apa yang mereka lakukan, yang dapat menyebabkan kesalahan.

Waktu tunggu versus waktu siklus

Diagram berikut menunjukkan perbedaan waktu prospek dan waktu siklus. Waktu tunggu dimulai saat item kerja dibuat dan berakhir saat item kerja memasuki kategori Status selesai. Waktu siklus dimulai saat item kerja memasukkan kategori status Sedang Berlangsung atau Teratasi dan berakhir saat memasuki kategori Status selesai.

Diagram yang memperlihatkan bagaimana kategori status digunakan untuk mengukur waktu siklus dan waktu tunggu.

Jika tim Anda menggunakan papan untuk melacak dan mengelola pekerjaan, memahami bagaimana kolom Anda memetakan ke status alur kerja membantu Anda mengelola pekerjaan secara lebih efektif. Untuk mempelajari cara menyiapkan papan Anda, lihat Mengelola kolom di papan Anda.

Untuk mempelajari bagaimana sistem menggunakan kategori status—Diusulkan, Sedang Berlangsung, Diselesaikan, dan Selesai—lihat Tentang status arus kerja pada daftar dan papan tugas.

Cara waktu siklus menangani item kerja yang diaktifkan kembali

Untuk item kerja yang diaktifkan kembali (dipindahkan dari status Selesai kembali ke status Sedang Berlangsung ), waktu siklus dimulai dari pertama kali item kerja memasukkan kategori status Sedang Berlangsung atau Teratasi dan mengakhiri waktu terakhir saat memasuki kategori Status selesai . Waktu siklus mencakup seluruh periode kerja aktif, termasuk kapan saja setelah aktivasi ulang.

Contoh skenario:

  • Baru → Aktif → Diselesaikan → Ditutup → Baru → Aktif → Ditutup
  • Perhitungan waktu siklus: Dari transisi pertama ke Aktif ke transisi akhir ke Ditutup
  • Total waktu siklus: Mencakup periode kerja aktif dan waktu dalam status Tertutup sebelum pengaktifan ulang

Metode penghitungan ini memberikan gambaran lengkap tentang total waktu yang diperlukan untuk menyelesaikan item kerja, termasuk pekerjaan ulang atau upaya tambahan setelah aktivasi ulang. Penghitungan waktu tunggu mengikuti prinsip yang sama—meliputi seluruh periode dari pembuatan item kerja hingga item tersebut benar-benar selesai, terlepas dari status yang selesai di tengah-tengah proses.

Memperkirakan waktu pengiriman berdasarkan waktu tunggu dan waktu siklus produksi

Gunakan waktu prospek dan siklus rata-rata Anda serta penyimpangan standar untuk memperkirakan waktu pengiriman.

Saat Anda membuat item kerja, gunakan waktu tunggu rata-rata tim Anda untuk memperkirakan tanggal penyelesaian. Penyimpangan standar tim menunjukkan varianbilitas perkiraan. Demikian juga, gunakan waktu siklus Anda dan simpang siur standarnya untuk memperkirakan kapan item kerja selesai setelah pekerjaan dimulai.

Contoh widget Waktu Siklus

Dalam bagan berikut, waktu siklus rata-rata adalah delapan hari dan simpang siur standar adalah enam hari. Dengan data ini, perkirakan bahwa tim menyelesaikan cerita pengguna di masa mendatang sekitar 2 hingga 14 hari setelah pekerjaan dimulai. Penyimpangan standar yang lebih sempit membuat perkiraan Anda lebih dapat diprediksi.

Cuplikan layar widget Waktu Siklus. Bagan plot sebar memperlihatkan titik-titik untuk item kerja, garis rata-rata bergerak, dan pita penyimpangan standar.

Mengidentifikasi masalah proses

Outlier sering berarti ada masalah proses yang mendasar. Misalnya, menunggu terlalu lama untuk meninjau permintaan pull atau tidak memperbaiki dependensi eksternal dengan cepat. Periksa bagan kontrol tim Anda untuk outlier.

Contoh widget waktu siklus yang memperlihatkan beberapa nilai pencilan

Bagan berikut menunjukkan beberapa outlier karena beberapa bug membutuhkan waktu lebih lama dari rata-rata untuk diselesaikan. Memeriksa mengapa bug ini membutuhkan waktu lebih lama dapat membantu Anda menemukan masalah proses. Memperbaiki masalah proses membantu mengurangi penyimpangan standar tim Anda dan meningkatkan prediksi tim Anda.

Cuplikan layar dari widget waktu siklus. Beberapa titik item kerja jauh di atas garis rata-rata bergerak dan pita deviasi standar.

Anda juga melihat bagaimana perubahan proses memengaruhi waktu tunggu dan waktu siklus Anda. Misalnya, pada 15 Mei, tim bekerja untuk membatasi WIP dan memperbaiki bug basi. Penyimpangan standar menyempit setelah tanggal tersebut, menunjukkan peningkatan prediktabilitas.

Langkah selanjutnya