Scrumban: Menggabungkan Scrum dan Kanban

Scrumban ialah hasilnya apabila anda berhenti memaksa satu pilihan antara Scrum dan Kanban. Pasukan yang memerlukan perancangan berstruktur tetapi tidak mampu menampung sprint yang tegar akan beralih kepada scrumban terlebih dahulu.

Apakah Scrumban?

Scrumban ialah rangka kerja agile hibrid yang melapisi mekanisme aliran berterusan Kanban di atas disiplin perancangan Scrum. Kerja bergerak melalui papan berasaskan tarikan dengan had Kerja Dalam Progres (WIP), tetapi acara perancangan dicetuskan atas permintaan dan bukan mengikut jam sprint yang tetap.

Corey Ladas mencipta istilah ini dalam sebuah esei pada 2008 dan kemudian mengembangkannya dalam bukunya Scrumban: Essays on Kanban Systems for Lean Software Development. Hujah terasnya: Scrum adalah perancah yang baik untuk pasukan yang baharu kepada agile, tetapi apabila pasukan semakin matang mereka sepatutnya membuang upacara yang tidak menambah nilai dan mengekalkan yang benar-benar berguna. Model aliran Kanban mengisi kekosongan itu. Hasilnya ialah rangka kerja yang cukup fleksibel untuk kerja penyelenggaraan, giliran sokongan, dan operasi pemasaran, yang mana kesemuanya tidak dapat dipetakan dengan kemas ke dalam sprint dua minggu.

Fakta utama

• Laporan State of Agile ke-17 (2023) mendapati 9% responden menggunakan hibrid Scrum/Kanban sebagai pendekatan penghantaran utama mereka, meningkat daripada 6% dua tahun sebelumnya.
• Pasukan yang melaksanakan had WIP bersama sistem tarikan biasanya melihat pengurangan 20-40% dalam masa kitaran, menurut data penambahbaikan aliran yang dipetik dalam Principles of Product Development Flow oleh Donald Reinertsen (2009).
• Scrumban mengekalkan acara perancangan tetapi mencetuskannya berdasarkan saiz giliran, bukan kalendar, supaya usaha perancangan kekal berkadar dengan jumlah kerja sebenar.

Scrum lawan Kanban lawan Scrumban

Ketiga-tiga rangka kerja ini berkongsi papan dan backlog, tetapi cepat berbeza dari segi kadensi, peranan, dan cara kerja memasuki sistem.

Jika pasukan anda sudah menjalankan Scrum tetapi sentiasa melenturkan peraturan sprint untuk menangani permintaan mendesak, anda sudah separuh jalan ke arah scrumban. Dan jika anda menjalankan Kanban tetapi mendapati anda tidak pernah berhenti untuk merenung atau merancang, model scrumban yang berstruktur apabila diperlukan memberi anda sebab untuk berhenti sebentar.

Bagaimana Scrumban Berfungsi

Mekanisme scrumban bertunjangkan empat idea yang saling berkait.

Sistem tarikan. Kerja tidak ditolak kepada jurutera. Ia ditarik. Apabila seseorang selesai dengan sesuatu tugasan, mereka menarik item seterusnya daripada giliran sedia ke dalam lajur mereka. Ini menghalang kerja daripada bertimbun dalam laluan seseorang dan menjadikan kesesakan kelihatan dengan segera.

Had WIP. Setiap lajur papan membawa bilangan maksimum. Lajur Doing mungkin hanya boleh memuatkan tidak lebih tiga kad pada satu masa. Apabila lajur itu penuh, pasukan menumpukan kepada menyiapkan kerja sebelum memulakan apa-apa yang baharu. Had WIP adalah tuas paling berkuasa untuk memotong masa kitaran dalam mana-mana sistem berasaskan kanban.

Giliran sedia. Antara backlog dan lajur kerja aktif terletak giliran sedia, iaitu penampan kecil item yang telah disikat, diberi keutamaan, dan benar-benar sedia untuk ditarik. Giliran sedia memisahkan perancangan daripada pelaksanaan. Perancangan boleh berlaku dalam satu sesi tumpuan, kemudian pasukan menarik daripada giliran itu bila-bila masa tanpa memerlukan seorang perancang berada dalam bilik.

Pencetus perancangan atas permintaan. Berbanding merancang setiap dua minggu tanpa mengira keadaan, scrumban mencetuskan acara perancangan apabila giliran sedia jatuh di bawah ambang yang ditetapkan, katakan dua item bagi setiap pembangun. Ini bermakna usaha perancangan berskala mengikut keperluan sebenar. Minggu yang tenang mendapat pengisian semula pantas; minggu yang sibuk mungkin langsung tidak memerlukan perancangan.

Rajah aliran kumulatif adalah alat penjejakan semula jadi untuk scrumban kerana ia memvisualisasikan saiz giliran, WIP, dan throughput dalam satu paparan. Jika jalur mula melebar, kerja terkumpul lebih pantas daripada yang selesai.

Faedah Scrumban

Aliran tanpa kekacauan. Model aliran berterusan Kanban memastikan kerja terus bergerak. Scrumban menambah struktur secukupnya untuk menghalang backlog daripada bertukar menjadi tanah perkuburan tiket yang tidak disentuh.

Perancangan mengikut syarat anda. Pasukan yang bergelut dengan upacara perancangan sprint yang mengambil masa sehari penuh untuk keputusan sebenar yang hanya berlangsung dua jam akan menyedari perbezaannya dengan segera. Perancangan berlaku apabila giliran perlu diisi semula, bukan kerana kalendar mengatakan begitu.

Overhed lebih rendah untuk pasukan yang stabil. Sebaik sahaja pasukan tahu apa yang mereka lakukan, upacara Scrum yang berguna semasa fasa permulaan mula terasa berlebihan. Scrumban membenarkan pasukan membuang apa yang tidak berguna dan mengekalkan apa yang berguna.

Mengendalikan jenis kerja bercampur. Kebanyakan pasukan sebenar mengendalikan kedua-dua kerja terancang (ciri baharu, projek) dan kerja tidak terancang (pepijat, permintaan, insiden). Scrum bergelut dengan kerja tidak terancang kerana ia mengganggu sprint. Scrumban dapat menyerapnya kerana papan sentiasa mempunyai ruang untuk menarik item baharu ke dalam giliran sedia di luar kitaran penyikatan biasa.

Keterlihatan. Papan kekal aktif sepanjang masa. Sesiapa sahaja boleh melihat apa yang sedang berjalan, apa yang tersekat, dan sejauh mana giliran sedia hampir mencetuskan perancangan. Tiada keperluan menunggu semakan sprint untuk mengetahui keadaan sistem.

Kekurangan Scrumban

Scrumban bukan penyelesaian sejagat. Ia membawa mod kegagalannya sendiri.

Tiada peranan bermakna tiada akauntabiliti. Peranan yang ditentukan dalam Scrum wujud kerana seseorang perlu memiliki backlog, seseorang perlu memudahcarakan, dan seseorang perlu melindungi pasukan daripada perluasan skop. Scrumban membuang peranan-peranan ini secara lalai. Pasukan yang melangkau struktur itu sering berakhir dengan backlog yang tidak disikat, mesyuarat perancangan yang tiada siapa bersedia, dan papan yang tiada siapa mengemas kini.

Had WIP memerlukan disiplin. Kali pertama seorang pengurus meminta pasukan untuk "tambah satu perkara lagi sahaja," had WIP itu akan secara senyap-senyap dinaikkan. Sebaik sahaja had itu menjadi cadangan sahaja, mekanisme aliran akan runtuh. Scrumban hanya berfungsi jika pasukan melayan had WIP sebagai kekangan mutlak.

Tidak ideal untuk kerja penerokaan yang besar dan kompleks. Jika anda sedang membina sesuatu yang benar-benar tidak diketahui, irama sprint dalam Scrum memaksa perenungan dan perancangan yang diperlukan oleh kerja penerokaan. Perancangan atas permintaan dalam scrumban boleh membenarkan pasukan berlaku terlalu lama tanpa berhenti untuk bertanya sama ada mereka membina perkara yang betul.

Sukar mengukur velocity. Kerana tiada sprint tetap, metrik velocity dalam agile tradisional tidak terpakai secara langsung. Pasukan beralih kepada throughput (item disiapkan setiap minggu) dan masa kitaran sebaliknya. Itu adalah ukuran yang lebih baik dalam kebanyakan kes, tetapi ia memerlukan perubahan cara berfikir.

Cara Melaksanakan Scrumban

Langkah 1: Mulakan daripada papan semasa anda

Jangan reka bentuk semula segalanya sekali gus. Sama ada anda datang daripada Scrum atau Kanban, kekalkan lajur dan format kad sedia ada anda. Perubahan pertama adalah tidak kelihatan: anda beralih daripada mentaliti tolak (menugaskan kerja kepada orang) kepada mentaliti tarikan (biarkan orang menarik daripada giliran apabila sedia).

Langkah 2: Tambah had WIP kepada lajur aktif

Pilih nombor yang berhati-hati untuk setiap lajur sedang berjalan, biasanya satu hingga dua bagi setiap ahli pasukan. Anda akan menyesuaikannya selepas seminggu atau dua. Matlamatnya bukan memilih nombor yang sempurna, tetapi menjadikan masalah aliran kelihatan.

Langkah 3: Cipta giliran sedia

Tambahkan lajur "Sedia" antara backlog anda dan lajur aktif pertama anda. Item hanya bergerak ke Sedia apabila ia telah disikat: ditakrifkan, dianggarkan, dan benar-benar boleh diambil tindakan. Ini adalah output perancangan anda. Pasukan menarik daripada Sedia secara bebas tanpa memerlukan seorang perancang hadir.

Langkah 4: Tetapkan ambang pencetus perancangan

Tentukan sejauh mana rendahnya giliran sedia boleh jatuh sebelum anda menjalankan sesi perancangan. Titik permulaan biasa: rancang apabila Sedia jatuh di bawah bekalan dua hari. Tuliskan ini. Pencetus itu sepatutnya nombor sebenar, bukan "apabila terasa rendah."

Langkah 5: Jalankan retrospektif yang ringan

Walaupun tanpa sprint tetap, pasukan perlu berhenti sebentar dan bertanya apa yang berfungsi. Jadualkan retrospektif ringkas setiap dua hingga empat minggu, atau selepas bilangan item yang dihantar mencapai tahap tertentu. Kekalkan ia ringkas, 30 hingga 45 minit, dan tumpukan kepada aliran: apa yang melambatkan kita, apa yang membantu, dan satu perkara yang akan kita ubah seterusnya.

Selepas beberapa kitaran anda akan mempunyai data throughput sebenar. Gunakannya untuk memperhalusi had WIP, menyesuaikan pencetus perancangan, dan mengenal pasti jenis kerja mana yang bergerak paling pantas melalui papan. Itulah gelung penambahbaikan berterusan yang menjadi teras metodologi agile.

Contoh Scrumban Mengikut Jenis Pasukan

Amalan Terbaik

Kekalkan papan itu jujur. Kemas kini status kad sebaik sahaja ia berubah, bukan semasa stand-up, bukan pada penghujung hari. Papan yang lapuk lebih buruk daripada tiada papan langsung kerana ia mewujudkan keyakinan palsu.

Layan had WIP sebagai kontrak pasukan. Bersetuju mengenainya bersama, tuliskannya di papan, dan pastikan satu sama lain mematuhinya. Apabila seseorang ingin melebihi had tersebut, itu adalah satu perbualan, bukan keputusan sepihak.

Pisahkan kerja mendesak daripada kerja terancang. Tambahkan baris "Fast Lane" yang kecil di papan untuk kecemasan sebenar. Hadkan kepada satu item pada satu masa. Ini memberi insiden satu laluan tanpa mengganggu aliran utama.

Visualisasikan kerja yang tersekat. Gunakan bendera atau tag warna untuk kad yang tersekat berbanding hanya membiarkannya dalam status berjalan. Kerja tersekat yang duduk senyap dalam had WIP adalah pembaziran yang tidak kelihatan.

Ukur masa kitaran, bukan velocity. Jejaki berapa lama item mengambil masa dari Sedia hingga Selesai. Masa kitaran memberitahu anda sejauh mana boleh diramal penghantaran anda. Menambah baiknya adalah matlamat utama sistem tarikan.

Rujuk semula kepada apakah Scrum dan apakah Kanban secara berkala. Scrumban meminjam daripada kedua-duanya, dan apabila sesuatu tidak berfungsi ia membantu untuk kembali kepada prinsip asal. Selalunya jawapan sudah pun ada di situ.

Jika pasukan anda sedang meneroka rangka kerja yang lebih luas untuk meningkatkan skala, Scaled Agile Framework (SAFe) menangani ketegangan yang serupa pada peringkat portfolio. Dan bagi pasukan yang mahukan lebih sedikit upacara berbanding scrumban, Extreme Programming (XP) mengambil arah yang berbeza: lebih banyak amalan kejuruteraan, lebih sedikit perancah proses.

Soalan Lazim

Adakah Scrumban mempunyai sprint?

Secara lalai, tidak. Scrumban menggantikan sprint tetap dengan perancangan atas permintaan yang dicetuskan oleh saiz giliran. Namun begitu, sesetengah pasukan mengekalkan kadensi perancangan dua minggu yang longgar sebagai fungsi pendorong sambil menggunakan mekanisme aliran untuk kerja harian. Rangka kerja ini cukup fleksibel untuk merangkumi sprint jika ia berguna kepada pasukan.

Adakah terdapat peranan yang ditentukan dalam Scrumban?

Tidak. Scrumban membuang peranan Product Owner, Scrum Master, dan Pasukan Pembangunan yang diperlukan oleh Scrum. Pasukan menentukan sendiri siapa yang memiliki backlog, siapa yang memudahcarakan perancangan, dan siapa yang mengekalkan papan. Ramai yang mengekalkan peranan product owner yang ringan kerana seseorang masih perlu mengutamakan. Tetapi rangka kerja ini tidak mewajibkannya.

Adakah Scrumban baik untuk pasukan penyelenggaraan?

Ia adalah salah satu padanan terbaik. Kerja penyelenggaraan tidak dapat diramal, datang dalam pelbagai saiz, dan tidak dapat dipetakan dengan baik ke atas kitaran perancangan sprint. Sistem tarikan dan perancangan atas permintaan membenarkan pasukan penyelenggaraan mengendalikan apa sahaja yang muncul tanpa perlu berterusan merunding skop terhadap sempadan sprint.

Bagaimanakah Scrumban berbeza daripada sekadar "menjalankan Kanban"?

Perbezaan utama ialah struktur. Kanban tulen tiada upacara wajib, tiada pencetus perancangan, dan tiada gelung renungan terbina dalam. Scrumban menambah giliran sedia, ambang pencetus perancangan, dan retrospektif pilihan. Ia adalah Kanban dengan pagar keselamatan untuk pasukan yang mendapati aliran tulen meninggalkan terlalu banyak kepada nasib.

Metrik apa yang perlu dijejaki oleh pasukan Scrumban?

Masa kitaran (masa dari Sedia hingga Selesai), throughput (item disiapkan setiap minggu), dan saiz giliran adalah tiga metrik teras. Rajah aliran kumulatif memplot ketiga-tiganya dalam satu paparan dan menjadikan kesesakan jelas kelihatan. Elakkan menjejaki velocity melainkan anda telah memperkenalkan sprint, kerana velocity adalah ukuran berasaskan sprint.

Scrumban terus berkembang seiring pasukan menemui gabungan baharu antara upacara Scrum dan alat aliran Kanban. Daya tahan rangka kerja ini datang daripada satu idea mudah: optimumkan proses untuk kerja sebenar, bukan sebaliknya. Mulakan dengan papan semasa anda, tambah had WIP, dan lihat apa yang didedahkan oleh kekangan tersebut.

Bacaan Berkaitan

• Apakah Scrum
• Apakah Kanban
• Scrum lawan Kanban
• Had WIP
• Rajah Aliran Kumulatif
• Perancangan Sprint
• Velocity dalam Agile
• Apakah Metodologi Agile
• Extreme Programming
• Scaled Agile Framework (SAFe)