Ketika memilih antara dua opsi, selalu ada risiko untuk dipengaruhi oleh opini dan fakta yang meragukan. Memilih metodologi atau pendekatan kerja apa pun, kami berusaha menghindari kesalahan dan mempelajari sebanyak mungkin fakta dan perincian tentang subjek untuk membuat pilihan yang tepat.
Dalam pengembangan perangkat lunak Agile, pilihan ini juga menantang, terutama jika ini tentang Scrum dan Kanban.
Scrum vs Kanban: dua metodologi, satu pilihan
Sebelum Anda sampai pada pemilihan yang sulit, Anda mungkin dihadapkan dengan dilema pendahuluan lain terkait dengan pilihan antara
Waterfall vs Agile . Namun, Anda telah membuat pilihan yang tepat dan sekarang Anda menghadapi dua jalur independen di dunia pengembangan Agile.
Scrum dan Kanban adalah dua cabang dari keluarga Agile (namun, banyak orang tidak menganggap Kanban sebagai metodologi independen dan memisahkannya dari metode lain). Keduanya fleksibel dan berulang.
Ada
survei , yang dilakukan pada 2018 di antara 101592 pengembang perangkat lunak dari seluruh dunia. Hampir 86% dari mereka menggunakan Agile dalam pekerjaan mereka. Terlihat mengesankan, bukan?
Scrum atau Kanban: apa pilihan terbaik?
Scrum memungkinkan orang untuk mengatasi masalah adaptif yang kompleks, sambil secara produktif memberikan produk dengan nilai tertinggi.
Kerangka kerja Scrum ringan dan mudah dimengerti tetapi bisa sulit dikuasai. Terdiri dari iterasi pendek atau Sprint, yang biasanya berlangsung 2-3 minggu.
Daftar fitur yang mungkin untuk iterasi dibuat oleh tim. Kemudian mereka mulai menjalankan Sprint. Biasanya, fitur yang sedang dikerjakan selama Sprint tidak berubah. Apa yang dimulai di awal harus dilakukan pada akhirnya.
Scrum berisi berbagai istilah, konsep, dan artefak. Untuk memahami semuanya, baca dan pelajari serta
daftar istilah Scrum atau panduan utama.
Kanban dapat
ditinjau dari perspektif tempat pembuatannya - perusahaan Toyota.
Jalur konveyor setiap hari menghasilkan komponen mobil. Mesin khusus merancang cermin untuk mobil Toyota: cermin kiri, kanan, belakang, dan cermin untuk pelindung matahari. Hanya satu klik pada tombol, modenya berubah dan mereka mendapatkan produk baru.
Saat kunci di sini adalah mereka dapat mengubah prioritas setiap saat. Mereka dapat mengganti mesin ke mode yang berbeda dan hanya itu.
Namun, jika Anda membutuhkan teori lebih lanjut tentang Kanban, Anda dapat menganggapnya sebagai sistem visual untuk mengelola pekerjaan saat bergerak melalui suatu proses. Ini memvisualisasikan alur kerja dan pekerjaan aktual yang melewati proses itu.
Kanban membantu mengidentifikasi potensi kemacetan dalam proses dan memperbaikinya untuk memberikan aliran yang hemat biaya.
Perbedaan utama antara Scrum dan Kanban adalah panjang iterasi:
- Anda bekerja selama 2 minggu di Scrum.
- Di Kanban, Anda dapat memberi pengembang tugas bahkan setiap hari.
Kanban lebih fleksibel. Bayangkan kemarin Anda merilis fitur baru ke server produksi dengan beberapa acara untuk melacak KPI fitur.
Dengan bantuan analitik, manajer produk Anda memahami bahwa ada yang tidak beres. Dia memutuskan untuk membuat beberapa perubahan pada logika fitur. Dia menempatkan tugas di papan Kanban dan mengangkatnya di kolom. Segera setelah programmer bebas, ia akan mengambil tugas ini dan akan melepaskannya setelah pengujian. Akan butuh beberapa hari untuk semuanya.
Dalam kasus Scrum, Anda harus menunggu seluruh Sprint, yaitu 2-3 minggu.
Scrum membutuhkan estimasi tugas dengan Story Points atau Hours. Anda tidak akan dapat membentuk Sprint tanpa estimasi ini. Dan Anda harus tahu persis, apakah Anda akan menyelesaikan semua tugas dalam 2 minggu.
Setelah 2 minggu, Anda mendapatkan statistik yang berharga tentang berapa banyak poin cerita atau jam yang berhasil diselesaikan tim Anda selama Sprint. Dengan bantuan info ini, master Scrum memprediksi di mana tim akan berada dalam 2 minggu.
Di Kanban, orang juga dapat memperkirakan, tetapi ini opsional. Tidak ada kecepatan tim. Anda hanya mempertimbangkan waktu rata-rata untuk penyelesaian tugas dan menghitungnya dalam Laporan Waktu Siklus.
Waktu Siklus Tugas = Waktu yang dihabiskan untuk mengerjakan suatu tugas - Waktu ketika tugas dimulaiBayangkan saja bahwa tujuan saat ini di Scrum adalah untuk menyelesaikan Sprint tetapi untuk Kanban, Anda harus menyelesaikan tugas.
Dari teori ke praktik: cara kita melakukannya
Membersihkan wip
WIP sedang dalam proses. Penting untuk membatasi jumlah tugas yang dapat dilakukan oleh spesialis pada saat yang bersamaan. Ya, tidak ada Caesar dan Napoleon di antara kita yang terkenal dengan keterampilan multitasking yang luar biasa.
Ini optimal ketika orang hanya bekerja pada satu tugas pada satu unit waktu. Biasanya dibutuhkan
15 menit bagi pengembang untuk beralih dari satu tugas ke tugas lainnya.
Anda perlu waktu untuk membuat teh, untuk melihat beberapa artikel di web, untuk membaca persyaratan untuk tugas baru, untuk mengingat di mana Anda telah berhenti dan menemukan tempat itu dalam kode.
Pastikan, beralih dari satu tugas ke tugas lain merupakan penyimpangan dari satu jalur pemikiran ke arah yang lain dan tidak selalu mudah untuk kembali.
Swimlanes
Tidak seorang pun aman dari kegagalan dan situs Anda mungkin tidak berfungsi selama jam kerja. Anda membuat dan menetapkan tugas untuk memperbaikinya segera ke insinyur DevOps Anda, misalnya.
Tapi dia sedang melakukan tugas lain dan berencana untuk menyelesaikannya besok dengan makan siang. Apa yang harus dilakukan Bukan ide yang baik untuk berputar di sekitarnya, ketuk bahu dan minta untuk beralih ke pemblokir. Anda bisa melakukannya sekali, tetapi apakah itu cara yang tepat untuk bertindak? Jelas tidak, itu sebabnya kami menggunakan Swimlanes.
Dalam contoh ini, “Blocker” Swimlane adalah solusinya, membuat pengembang berhenti melakukan tugasnya saat ini dengan segera, berhenti sebentar dan mulai bekerja untuk memblokir hal-hal.
Kami juga menggunakan Swimlane "Suatu Hari" yang mencakup semua tugas yang kemungkinan akan kami lakukan suatu hari di bawah blok itu.
Swimlane membantu mengesampingkan semua hal yang tidak perlu sehingga orang bisa fokus pada tugas-tugas penting.
Sub-kolom
Ada kolom "Coding" dan "Pengujian" yang tepat setelahnya. Ketika pengembang menyelesaikan tugasnya, ia memindahkannya ke "Pengujian". Anda mungkin berpikir bahwa penguji sudah mulai mengerjakan tugas ini, tetapi pada kenyataannya, dia melakukan yang lain. Setelah pengembang memindahkan tugas untuk pengujian, ia mengganggu batas WIP untuk QA. Ini adalah tantangan nyata!
Sebenarnya, pengembang bebas untuk tidak memindahkan tugas ini ke kolom "Pengujian" dan akan meninggalkannya di kolom "Pengkodean". Ini juga tidak baik karena tugasnya akan tetap di kolom "Sedang Berlangsung", meskipun dia sudah menyelesaikannya.
Namun demikian, bagaimana mengambil tugas berikutnya jika batas WIP tidak boleh dilanggar? Sub-kolom memang membantu. Pengembang hanya memindahkan tugas yang selesai dari sub-kolom "Agenda Pengodean" ke "Pengkodean Selesai". Dan tester, ketika saatnya tiba, akan mengambil tugas pengujian baru dari sub-kolom "Coding Done".
Pikiran terakhir
Merangkum semua bersama-sama, mari kita mendefinisikan Scrum sebagai metodologi pengembangan yang fleksibel tetapi akan menyebut Kanban sebagai lebih fleksibel.
Scrum terlihat lebih baik di awal pengembangan produk karena membantu mengelola tenggat waktu dengan lebih mudah. Selain itu, ada cukup komunikasi dalam tim. Mereka benar-benar mendiskusikan Sprint Backlog sebelum memulai.
Mereka mendiskusikan tugas dengan pencipta mereka. Tim memperkirakan tugas sesuai dengan sistem Perencanaan Poker. Faktanya, Scrum membantu untuk memahami inti dari produk.
Namun, setelah peluncuran produk, Anda menerima umpan balik dari pengguna dan Anda perlu bereaksi dengan cepat. Anda mulai mengukur dan mengoptimalkan metrik produk, semuanya memecah siklus pengembangan Anda menjadi unit yang lebih kecil dan Anda mulai melakukan banyak tugas kecil dalam kekacauan. Ini adalah waktu yang tepat untuk mengingat Kanban yang sempurna untuk kasus seperti itu.
Sudahkah Anda menerapkan kedua metodologi ini? Apa favorit Anda di oposisi Kanban vs Scrum?