Scrum vs Kanban: Perbezaan Utama dan Bila Menggunakan Setiap Satunya

Kedua-duanya Agile. Kedua-duanya menggunakan papan. Namun pasukan yang mengelirukan Scrum dengan Kanban akhirnya mendapat ketegaran Sprint di mana mereka memerlukan aliran berterusan, atau kelonggaran Kanban di mana mereka memerlukan perancangan berstruktur. Perbezaan utama di sini ialah kadens: satu terikat masa, satu lagi mengalir seperti sungai.

Apakah perbezaan antara Scrum dan Kanban?

Scrum terikat masa: kerja berjalan dalam Sprint tetap (biasanya satu hingga empat minggu), dengan peranan yang ditakrifkan dan kadens perancangan yang wajib. Kanban adalah aliran berterusan: kerja bergerak melalui papan tanpa pengesetan semula yang keras, terhad bukan oleh masa tetapi oleh had Kerja Dalam Kemajuan (Work in Progress/WIP) pada setiap lajur.

Kedua-dua rangka kerja muncul daripada pemikiran Agile dan Lean. Tetapi matlamat mereka berbeza. Scrum direka untuk kerja produk yang tidak dapat diramal dan banyak penemuan di mana pasukan memerlukan gelung maklum balas berstruktur. Kanban, yang bermula dari Toyota Production System (TPS) pada tahun 1940-an, direka untuk pengoptimuman aliran di mana matlamatnya adalah daya pemprosesan yang stabil dan halangan yang minimum, bukan Velocity Sprint.

Fakta Utama

• Panduan Scrum pertama kali dikodkan oleh Jeff Sutherland dan Ken Schwaber pada tahun 1995 dan paling baru disemak pada tahun 2020. Semakan 2020 memudahkan rangka kerja dan menggantikan "Pasukan Pembangunan" dengan "Pembangun."
• Kanban untuk kerja pengetahuan secara rasmi dikodkan oleh David J. Anderson dalam bukunya 2010 "Kanban: Successful Evolutionary Change for Your Technology Business" (Blue Hole Press), walaupun asal-usul pembuatannya boleh dikesan kepada Toyota Production System Taiichi Ohno pada tahun 1940-an.
• Menurut Laporan Keadaan Agile Tahunan ke-17 (2023), 87% responden menggunakan Scrum atau hibrid Scrum sebagai kaedah utama mereka, manakala 56% menggunakan Kanban, dan 9% menggunakan Scrumban. Ramai pasukan melaporkan menggunakan lebih daripada satu pendekatan.

Sekilas pandang: 10 perbezaan terbesar

Berikut ialah cara terpantas untuk melihat bagaimana kedua-dua rangka kerja sebenarnya berbeza:

Kadens dan perancangan

Sprint Scrum adalah tidak boleh dirunding. Pasukan bersetuju dengan matlamat, menarik satu set item dari Backlog, dan tidak mengubah skop itu di pertengahan Sprint. Ini mewujudkan fungsi paksaan: setiap satu hingga empat minggu, pasukan menghantar sesuatu, mengkajinya dengan pihak berkepentingan, dan menyesuaikan arah. Ia adalah rentak yang boleh Anda rancang.

Kanban tidak mempunyai Sprint. Kerja tiba, diutamakan, dan mengalir melalui papan apabila kapasiti tersedia. Perancangan adalah ringan: mesyuarat pengisian semula untuk mengisi bahagian atas giliran. Tiada komitmen tentang "apa yang akan kita selesaikan minggu ini." Komitmen berlaku pada peringkat item individu, dijejak mengikut masa kitaran (berapa lama satu item mengambil masa dari mula hingga selesai?).

Dalam amalan, pasukan Scrum sering bergelut dengan "teater Sprint" di mana upacara berlaku tetapi matlamat Sprint adalah rekaan. Pasukan Kanban sering bergelut dengan kebalikannya: segalanya dalam proses, had WIP diabaikan, dan papan menjadi tempat letak. Kedua-dua masalah adalah masalah disiplin, bukan masalah rangka kerja.

Peranan dan upacara

Scrum mempunyai tiga peranan dan lima acara:

Peranan: Product Owner (memiliki Backlog, mentakrifkan keutamaan), Scrum Master (melatih proses, menghapuskan halangan), Pembangun (membina perkara itu). Ketiga-tiganya diperlukan agar Scrum berfungsi seperti yang direka bentuk.

Acara: Perancangan Sprint, Daily Scrum (standup 15 minit), Semakan Sprint, Retrospektif Sprint, dan Sprint itu sendiri. Ini tidak pilihan, walaupun pasukan kerap mencuba untuk melangkau Retrospektif.

Kanban tidak memerlukan sebarang peranan sama sekali. Tiada Scrum Master Kanban, tiada setara Product Owner dalam spesifikasi. Pasukan sering mempunyai pengurus aliran atau pengurus penghantaran perkhidmatan dalam amalan, tetapi itu adalah pilihan organisasi, bukan keperluan rangka kerja. Kadens pilihan termasuk mesyuarat pengisian semula (isi giliran), perancangan penghantaran, semakan penghantaran perkhidmatan, dan retrospektif. Tiada yang diwajibkan.

Itulah sebabnya Kanban lebih mudah diperkenalkan ke dalam pasukan yang sedia ada. Anda tidak meminta orang mengubah tajuk kerja mereka. Anda hanya menjadikan aliran kerja kelihatan dan menambah had WIP.

Metrik: Velocity berbanding masa kitaran

Scrum mengukur Velocity: berapa banyak mata cerita (atau unit yang serupa) yang diselesaikan oleh pasukan setiap Sprint? Velocity berguna untuk perancangan Sprint dan ramalan kapasiti kasar. Ia tidak berguna untuk meramalkan bila item tertentu akan dihantar.

Kanban mengukur masa kitaran (berapa lama satu item mengambil masa dari "dimulakan" hingga "selesai"?) dan daya pemprosesan (berapa banyak item yang diselesaikan oleh pasukan setiap unit masa?). Ini lebih ramalan untuk penghantaran individu: jika purata masa kitaran Anda ialah 3 hari dengan varians yang rendah, Anda boleh memberitahu pihak berkepentingan "item ini kemungkinan akan siap menjelang Khamis" dengan keyakinan sebenar.

Rajah aliran kumulatif adalah carta khas Kanban: ia menunjukkan jumlah kerja dalam setiap peringkat dari semasa ke semasa, menjadikan halangan kelihatan sebagai jalur yang melebar. Carta burndown Scrum menunjukkan kerja yang tinggal dalam Sprint. Kedua-duanya berguna; mereka mengukur perkara yang berbeza.

Bila menggunakan Scrum berbanding Kanban: pokok keputusan

Jawapan yang jujur ialah: pilih berdasarkan cara kerja Anda sebenarnya tiba, bukan berdasarkan rangka kerja mana yang terdengar lebih berprestij.

Gunakan Scrum apabila:

• Kerja Anda mempunyai matlamat produk yang boleh ditemui yang mendapat manfaat daripada kitaran penemuan berstruktur.
• Pasukan boleh berkomitmen kepada skop Sprint tanpa segalanya menjadi "kecemasan."
• Gelung pembelajaran penting: Anda menghantar sesuatu, belajar daripadanya, dan membetulkan arah sebelum membina lebih banyak.
• Pihak berkepentingan mendapat manfaat daripada titik semak semakan yang tetap dan boleh diramal.
• Anda membina produk dengan Roadmap, bukan memproses giliran tiket.

Gunakan Kanban apabila:

• Kerja tiba secara tidak dapat diramal: tiket sokongan, permintaan operasi, kerja penyelenggaraan.
• Pengoptimuman daya pemprosesan lebih penting daripada Velocity Sprint.
• Pasukan tidak boleh berkomitmen kepada skop tetap kerana gangguan adalah sebahagian daripada kerja.
• Anda mahukan titik masuk berceremoni rendah ke dalam pengurusan aliran kerja berstruktur.
• Anda memperbaiki proses sedia ada berbanding menemui produk baharu.

Gunakan Scrumban apabila:

• Anda telah melebihi ketegaran Scrum tetapi masih mahukan beberapa rentak perancangan.
• Anda mempunyai campuran kerja produk yang dirancang dan kerja sokongan yang tidak dirancang dalam pasukan yang sama.
• Sprint Anda sebahagian besarnya hanya menamakan semula tiket yang sama, dan retro tidak menghasilkan sebarang perubahan.

Heuristik yang berguna: jika struktur pecahan kerja pasukan Anda boleh ditakrifkan dua minggu lebih awal dengan keyakinan yang munasabah, Scrum sesuai. Jika tidak, Kanban lebih sesuai. Dan jika carta Gantt Anda sebahagian besarnya rekaan kerana skop terus berubah, lihat apa yang carta Gantt sebenarnya untuk sebelum berkomitmen kepada mana-mana satunya.

Mitos dan salah faham biasa

Pasukan sering mengamalkan rangka kerja yang salah kerana mereka bertindak balas terhadap mitos berbanding kepada situasi sebenar mereka:

• "Kanban tidak mempunyai peraturan." Ia mempunyai lebih sedikit upacara, tetapi peraturannya nyata. Had WIP bukan cadangan. Melanggarnya menandakan masalah sistemik yang perlu diselesaikan, bukan had WIP yang perlu dipadam.
• "Scrum lebih matang atau profesional." Kematangan tidak relevan. Netflix beroperasi pada pengurusan aliran yang dipengaruhi Kanban. Pasukan produk perisian di Amazon menggunakan pendekatan berasaskan Sprint. Alat yang betul bergantung kepada kerja, bukan kepada prestij.
• "Anda tidak boleh mencampurkannya." Scrumban wujud tepat kerana pasukan menemui nilai dalam menggabungkan elemen kedua-duanya. Rangka kerja ini bukan agama.
• "Papan Kanban adalah papan Scrum." Papan hanyalah alat visualisasi. Papan Scrum diset semula setiap Sprint dan menunjukkan keadaan Sprint. Papan Kanban adalah berterusan, menunjukkan peringkat aliran kerja, dan menguatkuasakan had WIP. Perabot yang sama, bilik yang berbeza.
• "Standup harian adalah Kanban." Daily Scrum ialah upacara Scrum. Kanban tidak memerlukan standup harian, walaupun ramai pasukan Kanban mengamalkannya. Jangan mengelirukan upacara dengan rangka kerja.
• "Scrum berfungsi untuk perkakasan." Ia boleh, tetapi kaedah laluan kritikal dan carta PERT sering lebih sesuai untuk pembangunan perkakasan kerana perkakasan mempunyai kebergantungan berurutan sebenar yang pengesetan semula Sprint tidak mengubah.

Scrumban: menggabungkan kedua-duanya

Corey Ladas menggambarkan Scrumban dalam makalah 2008 sebagai cara untuk memindahkan pasukan dari Scrum ke Kanban. Dalam amalan, ia berkembang menjadi hibrid tersendiri: pasukan mengekalkan beberapa kadens perancangan seperti Sprint (sebuah "pencetus" yang aktif apabila Backlog jatuh di bawah ambang) sambil menggunakan had WIP Kanban dan metrik aliran pada papan itu sendiri.

Ia sangat berguna untuk pasukan yang separuh produk, separuh sokongan. Kerja produk mendapat manfaat daripada matlamat Sprint dan kitaran semakan. Kerja sokongan tidak boleh menunggu sempadan Sprint. Scrumban membolehkan Anda memproses item mendesak tanpa meruntuhkan komitmen Sprint.

Risikonya: Scrumban juga boleh menjadi alasan untuk mengelak disiplin mana-mana rangka kerja. Jika Anda menyebutnya Scrumban tetapi had WIP Anda sentiasa 10 dan matlamat Sprint Anda sentiasa "apa yang masuk minggu ini," Anda tidak mempunyai Scrum mahupun Kanban. Anda mempunyai papan putih berlabel.

Soalan lazim

Adakah Kanban satu metodologi atau alat?

Ia adalah metodologi. "Papan Kanban" adalah satu artifak kaedah Kanban, tetapi Kanban sendiri adalah satu set amalan untuk mengurus dan memperbaiki aliran: visualisasikan kerja, hadkan WIP, urus aliran, buat dasar proses eksplisit, laksanakan gelung maklum balas, dan perbaiki secara kolaboratif. Papan adalah bahagian yang paling kelihatan, tetapi had WIP dan metrik aliran adalah apa yang menjadikannya satu kaedah berbanding tabiat nota lekat.

Bolehkah pasukan beralih dari Scrum ke Kanban di pertengahan projek?

Ya, tetapi lakukan dengan sengaja. Peralihan paling biasa berlaku semasa retrospektif pasukan apabila pasukan bersetuju bahawa kitaran Sprint tidak menambah nilai. Langkah praktikal: hentikan perancangan Sprint, buat had WIP eksplisit pada papan sedia ada Anda, mula menjejak masa kitaran berbanding Velocity, dan jalankan semakan aliran berbanding semakan Sprint. Jangan Sprint dan Kanban secara serentak semasa peralihan. Pilih tarikh dan beralih.

Adakah Anda memerlukan Scrum Master dalam Kanban?

Tidak. Kanban tidak mempunyai peranan yang diperlukan. Sesetengah organisasi menggunakan "pengurus aliran" atau "pengurus penghantaran perkhidmatan" untuk menjalankan mesyuarat pengisian semula dan melindungi had WIP, tetapi ini tidak diwajibkan oleh kaedah Kanban. Pasukan yang mengamalkan Kanban dari Scrum sering mengekalkan Scrum Master mereka dalam peranan bimbingan, dan itu baik. Pastikan sahaja bahawa peranan itu kini pilihan berbanding wajib.

Mana yang lebih mudah untuk bermula: Scrum atau Kanban?

Kanban lebih mudah untuk bermula bagi kebanyakan pasukan kerana ia tidak memerlukan penyusunan semula peranan atau komitmen kepada kalendar upacara baharu. Anda boleh memperkenalkan Kanban hanya dengan menjadikan aliran kerja sedia ada kelihatan pada papan dan bersetuju tentang had WIP. Scrum memerlukan kejelasan peranan (siapa Product Owner?) dan komitmen upacara (kita akan melakukan perancangan Sprint setiap dua minggu) sebelum ia berfungsi seperti yang direka bentuk. Walau bagaimanapun, kadens berstruktur Scrum sering menjadi kelebihan bagi pasukan yang memerlukan fungsi paksaan untuk menghantar secara berkala. Jika pasukan Anda mempunyai sejarah "kita akan keluarkan apabila ia sudah sedia" tanpa batas masa, tekanan Sprint Scrum boleh menjadi tepat apa yang Anda perlukan.

---

Kebanyakan pasukan akhirnya menghabiskan masa berdebat tentang rangka kerja mana yang "lebih baik" apabila mereka sepatutnya bertanya yang mana satu sepadan dengan cara kerja mereka sebenarnya tiba. Scrum memberikan Anda gelung maklum balas berstruktur setiap satu hingga empat minggu. Kanban memberikan Anda kejelasan aliran dan kebolehramalan pada peringkat item individu. Kedua-duanya lebih baik berbanding bekerja dengan hamparan yang dikongsi. Mulakan dengan yang sesuai dengan corak kerja Anda, ukurnya dengan jujur, dan lakukan lelaran dari situ.

Bagi pasukan yang membina pelan projek berstruktur bersama kerja Agile mereka, matriks RACI boleh menjelaskan pemilikan keputusan merentasi pasukan Sprint. Dan jika latar belakang metodologi Waterfall Anda menarik Anda ke arah perancangan berurutan, struktur Sprint Scrum biasanya jambatan yang lebih baik berbanding terus melompat ke aliran berterusan Kanban.