← Esai

Praktik penerapan Cumulative Flow dalam konteks Scrum dan SAFe

Dalam artikel ini saya berencana menceritakan bagaimana dalam praktik kami menerapkan Cumulative Flow Chart dalam Scrum dalam proses kerja dengan framework SAFeBlog pribadi.

2 menit baca
TelegramAsli
Praktik penerapan Cumulative Flow dalam konteks Scrum dan SAFe

Dalam artikel ini saya berencana menceritakan bagaimana dalam praktik kami menerapkan Cumulative Flow Chart dalam Scrum dalam proses kerja dengan framework SAFe

Saya mulai saja dengan tautan ke artikel berikut - di sini, menurut saya, tujuannya dalam bentuk standar dijelaskan dengan baik, saya sarankan untuk mempelajarinya sebelum membaca artikel saya. Di bawah ini saya akan menjelaskan bagaimana kami mengadaptasinya untuk proses Scrum (awalnya ia digunakan dalam Kanban) dan masalah apa yang dibantunya untuk kami selesaikan saat bekerja dengan sprint.

Sebelumnya, dalam artikel tentang Burn Down Charts saya sudah mengatakan bahwa di sana kita melihat munculnya pekerjaan baru dan habisnya pekerjaan lama. Masalah Burn Down Chart adalah, berbeda dengan Cumulative Flow Chart, di sana kita tidak melihat pergerakan User Story berdasarkan status. Ketika kita mulai mengamati pergerakan berdasarkan status dalam Cumulative Flow Chart, kita mulai melihat perubahan harian (Burn Down Chart bisa tidak berubah selama beberapa hari dan dalam beberapa konteks ini bisa jadi sepenuhnya normal) dan kita dapat menyadari masalah yang lebih halus.

Begini tampilannya dalam dinamika (pada gambar adalah diagram yang dibuat berdasarkan data nyata).

Image



Image

Dalam contoh ini kita melihat hal berikut

  • Tujuh hari pertama sprint, volume pekerjaan yang berada dalam pengujian sangat kecil dan tidak berubah
  • Dari DOR (di sini berupa draf) ke pekerjaan, User Story keluar cukup merata - ini bagus.
  • Sama seperti pada Burn Down, kita melihat bahwa sesuai tren User Story tidak akan selesai pada akhir sprint

Ketiga pengamatan ini secara keseluruhan mengarah pada kesimpulan berikut. Di sini jelas pada tahap awal (sekitar hari kedua-ketiga sprint) Scrum Master seharusnya memperhatikan lapisan "Pengujian", yang terlalu kecil dan tidak berubah cukup lama (memastikan apa penyebabnya). Dapat diasumsikan bahwa volume pekerjaan yang siap untuk diuji tidak dapat diuji karena keadaan tertentu, tetapi jika demikian berarti para penguji menganggur, yang berarti setidaknya mereka perlu didengarkan lebih cermat pada standup terdekat.

Jika berbicara tentang praktik penerapan, saya misalnya mempublikasikan setiap hari di chat tim semua metrik sebelum standup dengan menyebut seluruh tim.

Secara umum, jangan lupa bahwa metrik tetap harus diinterpretasikan dengan benar. Mampu melihat masalah sistemik yang sebenarnya jika ada dan tidak menganggap sebagai masalah hal yang dalam konteks Anda mungkin bahkan merupakan tanda positif