Mengapa? Tidak bisakah beberapa tugas menunggu sampai minggu depan? Apakah sangat penting untuk menyelesaikan semuanya sebelum akhir pekan? Tidak, itu tidak penting. Dan semua ini disebabkan oleh fakta bahwa "Mengerjakan tugas itu buruk."
Scrum tidak lagi cukup metodologi pengembangan Agile
Saya sampai pada kesimpulan bahwa ada terlalu banyak penekanan pada proses kerja di Scrum. Atau, setidaknya, orang terlalu memperhatikannya, yang dinyatakan sebagai berikut:
- Tidak masalah untuk menyelesaikan kisah pengguna pada hari terakhir sprint. Tapi menyelesaikan pekerjaan Senin depan sudah merupakan "transfer tugas".
- - ( , ), , , , , .
- , , , . , , , ( , ).
Alhasil, ternyata Scrum tidak lagi membantu kami mencapai tujuan. Metode manajemen proyek ini sekarang membatasi kita.
Dengan semua hal di atas, saya dapat mencatat bahwa anggota tim saya mulai merasa tidak senang dengan apa yang terjadi. Ini memengaruhi kualitas apa yang kami buat. Programmer lebih peduli dengan memenuhi tenggat waktu daripada mencapai tingkat kualitas yang diinginkan.
Pada titik ini, kami mulai mencari cara lain untuk mengatur pekerjaan, mencari kerangka kerja gesit lain yang lebih sesuai dengan cara kami bekerja.
Kemudian kami menemukan Kanban (kanban).
Apa itu Kanban?
Kanban adalah metode manajemen produksi yang berasal dari Toyota pada 1950-an. Pada saat itu, Toyota menggunakan papan dengan tiga kolom: Direncanakan, Sedang Berlangsung, Selesai. Kerangka kerja ini memungkinkan Toyota untuk mengalokasikan sumber daya secara lebih efisien dalam situasi di mana kemacetan muncul di suatu tempat di sepanjang jalur produksi.
Kemudian, ketika menjadi jelas bahwa menggunakan Kanban dapat meningkatkan kecepatan pengembangan perangkat lunak, Kanban dipindahkan ke arena teknologi.
Perbandingan kerangka Scrum dan Kanban
Dalam beberapa tahun terakhir, Scrum dan Kanban telah berjuang untuk menjadi kerangka kerja tangkas terkemuka. Terlepas dari kenyataan bahwa Scrum menempati urutan pertama , kanban secara bertahap menyebar semakin banyak. Bagaimana jika Anda membandingkannya?
Jika kami menggunakan Scrum sebagai dasar dan membandingkannya dengan Kanban, kami mendapatkan yang berikut:
- , ().
- .
- «». , .
- , , .
- () -.
Perbandingan yang lebih rinci antara Scrum dan Kanban dapat ditemukan di sini .
Kanban memberi tim pengembangan tingkat fleksibilitas yang cukup tinggi. Kisah-kisah pengguna, dibandingkan dengan Scrum, dieksekusi secara lebih bebas. Tetapi kebebasan adalah tanggung jawab. Meskipun Kanban tidak mengharuskan pengembang untuk berkomitmen pada komitmen setiap dua minggu, metode pengelolaan pengembangan ini memiliki kendali sendiri. Misalnya, ini adalah metrik seperti waktu siklus dan throughput sistem.
Ini semua tentang metrik
Tidak mungkin untuk menilai efektivitas (atau inefisiensi) pekerjaan tanpa metrik khusus. Mari kita lihat metrik yang digunakan di Scrum dan Kanban.
▍Scrum Metrik
Saat menerapkan scrum, metrik dan grafik berikut digunakan:
- (velocity). , .
- , , (commitment vs. done). , , .
- (Burndown Chart). , .
Metrik ini tidak mungkin membantu Anda meningkatkan alur kerja Anda.
"Kecepatan" tidak mengukur tingkat di mana subsistem produk jadi dilepaskan. Metrik ini hanya mengukur jumlah langkah kerja yang diselesaikan yang relevan dengan cerita pengguna. Jika sebuah cerita membutuhkan waktu lebih lama dari yang direncanakan untuk diselesaikan, metrik ini tidak ada artinya.
“Rasio komitmen pengembang terhadap volume tugas yang diselesaikan” tidak boleh dianggap sebagai metrik sama sekali. "Metrik" ini membandingkan komitmen dengan hasil. Tak perlu dikatakan, ini dapat menyebabkan orang untuk menutup dan membuka kembali tugas hanya untuk menyelesaikannya.
Diagram burnout adalah sesuatu yang secara pribadi tidak pernah saya perhatikan. Hal ini terutama disebabkan oleh kenyataan bahwa grafik seperti itu sering terlihat seperti di bawah ini.
Diagram Burnout
Mengapa begitu? Katakanlah Anda mulai dengan papan kosong dan mulai bekerja secara paralel, misalnya dengan tiga cerita pengguna. Kisah-kisah ini kemungkinan akan dikerjakan dengan kecepatan yang sama, itulah sebabnya Anda dapat melihat gerakan ke bawah yang sangat kuat dalam diagram burnout. Apalagi, jika hanya ada satu penguji dalam tim yang harus menguji hasil kerja pada semua tugas, maka ia akan menjadi hambatan tim.
▍Kanban perkotaan
Saya percaya bahwa metrik adalah yang paling penting dari kekuatan Kanban. Kanban memiliki banyak metrik yang berbeda untuk membantu Anda lebih memahami apa yang terjadi dengan tim Anda. Sebagai contoh:
- Throughput tim Jumlah cerita pengguna yang diselesaikan dalam periode waktu tertentu.
- Waktu siklus Jumlah hari yang diperlukan untuk menyelesaikan pekerjaan sejarah sejak awal pekerjaan. Metrik seperti interval kepercayaan digunakan di sini. Yang paling umum adalah kepercayaan 85%.
- Diagram alir kumulatif Diagram seperti itu memungkinkan Anda untuk memvisualisasikan proses penyelesaian masalah berdasarkan cerita pengguna. Diagram ini akan terlihat seperti yang ditunjukkan di bawah ini.
Diagram Alir Kumulatif
Ada sebuah plugin untuk Jira yang memungkinkan Anda memanfaatkan semua metrik ini. Ini adalah ActionableAgile untuk Jira - Agile Metrics . Ini membantu mengeksplorasi metrik yang relevan dengan kinerja tim menggunakan platform yang sama yang digunakan untuk mengelola pekerjaan.
Adaptasi kanban
Penggunaan kanban "murni" tidak menyediakan untuk beberapa operasi yang diperlukan saat menggunakan scrum. Tetapi metode manajemen proyek ini cukup fleksibel untuk memungkinkan, jika tindakan seperti itu tampak bermanfaat, untuk ditambahkan ke alur kerja.
Retrospektif adalah salah satu jenis pertemuan paling penting. Pada pertemuan-pertemuan inilah para anggota tim dapat berbicara tentang apa yang telah mereka capai, apa yang tidak berjalan dengan sangat baik, dan apa yang dapat ditingkatkan. Retrospektif adalah peristiwa yang tenang di mana Anda dapat berbicara tentang masalah Anda dan memberi selamat kepada mereka yang telah melakukan pekerjaan yang sangat baik atas keberhasilan mereka.
Meskipun kilas balik tidak diperlukan di Kanban (diadakan di akhir setiap Sprint di Scrum), kami menganggapnya berharga dan tidak ingin melewatkannya. Bahkan, kami bahkan mulai melakukannya setiap minggu, bukan setiap dua minggu seperti dulu. Ini memungkinkan kami untuk bereaksi lebih cepat terhadap terjadinya masalah. Kami juga menggunakan pertemuan ini untuk menganalisis metrik tim dan memeriksa alur kerja untuk masalah dan kemacetan.
Kami telah menyimpan satu elemen lagi dari waktu Scrum kami, yang merupakan opsional ketika menggunakan kanban. Ini tentang memperkirakan waktu yang dibutuhkan untuk mengerjakan cerita pengguna. Ini dilakukan dalam rangka mengklarifikasi tugas-tugas yang turun dalam sejarah. Scrum menggunakan estimasi ini untuk lebih memahami apa yang cocok dengan sprint. Anda mungkin berpikir bahwa karena tidak ada sprint di Kanban, evaluasi cerita tidak perlu. Tapi sebenarnya tidak.
Memperkirakan waktu yang dibutuhkan untuk menyelesaikan cerita pengguna membantu untuk memastikan bahwa semua anggota tim memiliki pemahaman yang sama tentang ruang lingkup tugas yang harus diselesaikan saat mengerjakan cerita. Jika seseorang memberi cerita kelas 8, dan seseorang - 3, jelas bahwa kita perlu terus membahas masalah ini. Seseorang mungkin, ketika menilai waktunya, memperhitungkan beberapa masalah yang tidak diketahui orang lain. Dalam pemahaman seseorang, ruang lingkup pekerjaan cerita pengguna harus mencakup sesuatu yang orang lain tidak menganggapnya.
Faktanya, semua ini mendorong anggota tim untuk berdiskusi.
Ketika sesuatu seperti ini terjadi, menjadi jelas bahwa tidak semua orang memiliki pemahaman yang jelas tentang berapa banyak pekerjaan yang harus dilakukan pada cerita pengguna tertentu.
Skenario umum yang lain terlihat seperti ini: seluruh tim memberikan tingkat kesulitan cerita yang cukup tinggi (biasanya segala sesuatu yang lebih dari 8 poin). Ini berbicara tentang ketidakpastian. Ini berarti bahwa kita berbicara tentang banyak pekerjaan, atau tentang menyelesaikan masalah yang sangat sulit, yang membuat anggota tim tidak menyenangkan. Dalam kasus seperti itu, yang terbaik adalah membagi cerita pengguna menjadi beberapa cerita yang lebih kecil dan mendefinisikan tujuan pekerjaan dengan lebih jelas.
Hasil
Scrum akan selamanya tersimpan di hati kita sebagai metodologi tangkas pertama yang tersebar luas. Tetapi ketika perusahaan bergerak menuju skema penempatan yang berkelanjutan, penggunaan sprint terbatas waktu tidak lagi masuk akal.
Akan selalu ada proyek khusus di mana Scrum dapat bekerja dengan baik. Namun, mengingat fakta bahwa perusahaan semakin menggunakan metodologi lincah, Kanban secara bertahap akan keluar di atas, menggantikan Scrum.
Apa yang paling cocok untukmu? Scrum atau Kanban?
