Essential Skills for an Excellent Career: 9.3. Kanban

Menciptakan Efisiensi di Tempat Kerja

Gunakan isyarat visual untuk bertindak.

Bukankah lebih bagus lagi jika apa pun yang Anda butuhkan ada di sana menunggu untuk Anda? Tidak berjalan sekitar mencoba untuk mencari pasokan pada menit terakhir.

Tidak melewatkan tenggat waktu karena sumber daya tidak berbaris.

Dan tidak ada energi emosional terbuang mencoba untuk mencari tahu siapa yang menggunakan sisa kertas salinan, dan tidak memesan lebih.

Anda bisa pergi ke ekstrem untuk menghindari masalah ini. Anda bisa memesan kertas salinan cukup untuk mengisi seluruh gudang, atau memiliki persediaan yang cukup persediaan di tangan untuk memenuhi pesanan untuk enam bulan ke depan. Tapi ini jenis "solusi atas" adalah miskin menggunakan sumber daya keuangan dan ruang.

Bagaimana jika ada cara untuk memastikan Anda selalu memiliki sumber daya yang diperlukan tersedia ketika Anda membutuhkan mereka? Jepang, pelopor dalam efisiensi, mengembangkan sistem Kanban untuk melakukan hal ini.

Kanban dalam Praktek

Kanban dikembangkan sebagai sarana pemenuhan just-in-time (JIT) sistem persediaan. Dengan menerapkan kanban, bahan dan persediaan tiba tepat ketika Anda membutuhkan mereka. Hal ini mengurangi biaya penyimpanan dan membawa.

Kanban sebagian besar berhubungan dengan manufaktur. Sebuah perhatian utama di bidang manufaktur adalah kebutuhan untuk memiliki persediaan siap bahan, tanpa menimbulkan biaya persediaan yang tidak perlu memegang. Tetapi juga dapat diterapkan dalam lingkungan non manufaktur, di mana efisiensi alur kerja Anda tergantung pada memiliki sumber daya yang tersedia.

Istilah 'kanban' menggabungkan kata-kata Jepang 'kan,' yang berarti 'visual' dan 'larangan', yang berarti 'kartu' atau 'papan. " Sebuah kanban kartu visual atau isyarat lain yang sinyal ada sesuatu yang diperlukan. Ini adalah "menarik" sistem, di mana pasokan ditentukan oleh produsen atau pengguna.

Sebuah Kanban adalah kartu fisik yang digunakan dalam Toyota Production System (TPS) untuk mendukung non-terpusat "tarik" kontrol produksi. Hal ini telah menyebar ke industri manufaktur di seluruh dunia sebagai alat Lean Manufacturing. Sekarang dalam pengembangan perangkat lunak Agile visualisasi proyek, seperti posting kartu tugas di dinding, adalah praktek umum terlihat, yang kadang-kadang disebut "Software Kanban", atau "Tugas Kanban". Sekarang kita bahkan melihat beberapa tim pemeliharaan produk memanfaatkan sistem Kanban dalam model proses air terjun seperti. Jadi apa Kanban? Mengapa ini dipakai dalam konteks pengembangan perangkat lunak?

Pada artikel ini, pertama di jelaskan bahwa sebuah sistem Kanban adalah dalam konteks Lean manufacturing, khususnya di TPS, dan mengumpulkan wawasan dari praktek dan prinsip-prinsip dalam industri dewasa, mengidentifikasi konsep-konsep yang dapat diterapkan untuk pengembangan perangkat lunak. Kedua kita lihat ke sekeliling proyek pengembangan perangkat lunak dan menunjukkan contoh-contoh aplikasi Kanban.

Kemudian, kita menganalisis kesamaan dan perbedaan antara sistem Kanban dalam produksi dan pengembangan perangkat lunak, dan mencoba untuk memberikan ide-ide tentang cara efektif menerapkan sistem Kanban untuk pengembangan perangkat lunak, termasuk pengantar untuk gerakan baru-baru ini "KSSE - Sistem Kanban untuk Sustaining Rekayasa" muncul pada kanbandev daftar diskusi. Akhirnya, kita memberikan gambaran besar TPS, konteks asli untuk yang menggunakan Kanban sebagai alat, dan dari pengembangan perangkat lunak yang masih dapat belajar lebih banyak.

Apa Kanban di TPS?

Kanban adalah perangkat sinyal (biasanya kartu fisik dalam amplop plastik bening) yang menginstruksikan bergerak atau membuat bagian-bagian dalam suatu sistem "menarik" produksi, ditemukan dan dikembangkan sebagai bagian dari Toyota Production System (TPS). Sebelum masuk ke Kanban dalam pengembangan perangkat lunak, di sini saya mengambil melihat dari dekat aslinya yaitu penggunaan yang Kanban di TPS.

Tujuan kanban adalah untuk meminimalkan WIP (Work-In-Process), atau persediaan, antara proses dengan memastikan bahwa proses menghasilkan bagian hulu hanya jika proses hilir membutuhkannya. "Tarik" berarti bahwa para pekerja hilir menarik atau "tarik" bagian-bagian yang mereka butuhkan dari proses hulu mereka.

Gambar 1 Kanban dan Tarik Produksi

Gambar 1 adalah sebuah model abstrak dari sistem Kanban. Digambarkan di dalamnya adalah dua proses, sebuah hulu dan hilir proses, dimana proses persediaan bagian (item) hulu ke hilir. Dalam rangka untuk memasok produk ke konsumen akhir, proses kebutuhan untuk memproduksi komponen dan membuat mereka mengalir ke hilir, tetapi tidak terlalu banyak, karena overproduksi dianggap pemborosan terburuk. Jadi untuk mencegah kelebihan produksi, hulu tidak "mendorong" selesai bagian ke hilir, tetapi itu adalah hilir yang secara aktif menarik (mengambil) bagian-bagian dari hulu. Ruang di mana bagian ditempatkan disebut "toko" (atau "supermarket Taiichi Ohno mendapat ide pertama dari Kanban ketika ia mengunjungi sebuah supermarket Amerika, di mana tidak pegawai toko namun pelanggan sendiri yang pergi untuk mendapatkan apa yang ia membutuhkan di toko).

Toko adalah di lokasi hulu dan bekerja sebagai "penyangga" atau "antrian" WIP. Ketika seorang pekerja dari proses hilir, yang disebut "materi handler", datang ke toko dan mengambil bagian yang baru selesai, itu juga kembali sinyal produksi - yaitu hal-hal menarik hilir dari hulu dan pada saat yang sama mendorong informasi kepada hulu melalui kartu Kanban. Hal ini diperlukan, karena proses hulu tidak pernah menghasilkan bagian tanpa instruksi dari proses hilir.

Jadi di sini adalah dua jenis Kanban bekerja sama dalam Gambar 1:

Withdraw Kanban - adalah salah satu item pada daftar belanja yang handler bahan yang dibutuhkan untuk toko.
Kanban Produksi - menginstruksikan proses hulu untuk memproduksi komponen untuk proses hilir.

Seperti ditunjukkan dalam Gambar 1, menarik Kanbans beredar antara proses, sementara Kanbans beredar dalam proses produksi, dan mereka dipertukarkan di toko. Mari kita sedikit lebih ke dalam mekanisme ini. Gambar 2 mengilustrasikan bagaimana "Kanban pertukaran" bekerja di toko.

Gambar 2 Kanban Exchange di Store

Seorang penangan material di lokasi hilir ditandai untuk menarik bagian. Sinyal didefinisikan oleh proses hilir dan salah satu dari dua di bawah ini:

(A) ditandai dengan jumlah dikumpulkan menarik Kanbans
(B) ditandai dengan interval waktu periodik
Ia mengunjungi toko di lokasi hulu dengan palet kosong dan dikumpulkan-Nya menarik Kanbans sebagai daftar belanja, yang menunjukkan apa yang dibutuhkan dan dalam jumlah apa untuk proses hilir.

Bagian selesai dengan proses hulu dikemas dalam palet dan ditempatkan di toko dengan Kanbans produksi terpasang. (Hal ini terjadi terlepas dari (1), dalam thread terpisah.)
Handler bahan mengambil bagian yang ditentukan oleh menarik Kanban (daftar belanja), memeriksa apakah cocok dengan Kanban produksi melekat pada bagian-bagian, dan pertukaran dua Kanbans.
Dia menempatkan Kanban produksi ke "Dewan Produksi", yang nantinya akan memicu produksi visual hulu saat Kanbans tumpukan pada ambang.
Dia menyampaikan bagian yang diperlukan, dengan Kanban menarik terpasang, dari toko ke lokasi hilir.

Anda melihat bahwa toko adalah antrian antara dua proses, bekerja di sebuah thread terpisah dari kontrol, bertukar informasi melalui hal-hal dan Kanban. Pada permukaan kartu Kanban, informasi seperti nomor bagian / nama, jumlah, jenis palet, alamat toko, ditulis sehingga penangan bahan yang mengambil kartu ini bisa tahu apa yang harus dilakukan.

Ada disiplin yang ketat menjalankan Kanban, yang disebut "aturan enam dari Kanban":

Pelanggan (Hilir) proses menarik item dalam jumlah yang tepat ditentukan pada Kanban itu.
Pemasok (Hulu) menghasilkan item dalam jumlah yang tepat dan urutan yang ditentukan oleh Kanban
Tidak ada item yang dibuat atau dipindahkan tanpa Kanban sebuah.
Kanban A harus menemani setiap item, setiap saat.
Cacat dan jumlah yang salah tidak pernah dikirim ke proses hilir berikutnya.
Jumlah Kanbans berkurang hati-hati untuk persediaan yang lebih rendah dan untuk mengungkapkan masalah.

Sebagaimana telah kita bahas, toko bekerja sebagai antrian bagian, palet bekerja sebagai pembawa bagian, dan kartu Kanban bekerja sebagai pembawa pelanggan membutuhkan informasi. Mereka membuatnya menjadi "menarik" sistem, menciptakan keseimbangan antara mempertahankan "aliran kontinu" (menghilangkan pemborosan menunggu) dan "WIP minizing" (menghilangkan pemborosan overproduksi). Mekanisme pengelolaan "hak" jumlah WIP dalam aliran antara membeli-in dan menjual-out adalah persis apa yang terjadi di supermarket, dan melakukannya dengan baik adalah kunci untuk profitabilitas toko.

Sejauh ini, saya telah menggambarkan bagaimana Kanban bekerja di manufaktur. Perhatikan bahwa deskripsi ini adalah sebuah model sederhana dari sistem Kanban nyata. Satu hal lain yang tidak disebutkan secara eksplisit di sini adalah bahwa Kanban visual menunjukkan aliran informasi dan hal-hal untuk setiap pekerja dan merangsang Kaizen (proses perbaikan) di tempat kerja. Kaizen dimulai dengan menonton apa yang terjadi di Gemba. Via Kanban, setiap pekerja (bukan manajer) dapat melihat aliran dan memiliki kesempatan untuk melihat pemborosan dalam aliran dan menyarankan perbaikan terhadap proses di mana mereka bekerja.

Properti dari Kanban

Dari pengamatan rinci dalam bagian sebelumnya, di sini adalah daftar properti diekstraksi dan efek dari konsep Kanban asli di TPS.

Fisik: Ini adalah kartu fisik. Hal ini dapat diselenggarakan di tangan, bergerak, dan dimasukkan ke dalam atau ke sesuatu.
Batas WIP: Ini batas WIP (Work-In-Process), yaitu mencegah overproduksi.
Continuous Flow: Ini memberitahukan kebutuhan produksi sebelum toko kehabisan stok.
Tarik: Proses hilir menarik item dari proses hulu.
Mengarahkan diri: Ia memiliki semua informasi tentang apa yang harus dilakukan dan membuat produksi otonom dengan cara non-terpusat dan tanpa mikro-manajemen.
Visual: Ini adalah ditumpuk atau diposting untuk menunjukkan status dan kemajuan, visual.
Sinyal: Status visual yang Its sinyal penarikan berikutnya atau tindakan produksi.
Kaizen: alur proses Visual menginformasikan dan merangsang Kaizen.
Terlampir: Hal ini melekat dan bergerak dengan bagian-bagian fisik yang disediakan.

Gambar 3 adalah diagram efek dari sembilan sifat di atas, menunjukkan bagaimana bentuk ini jaringan sebab-akibat. Seperti yang akan Anda lihat di sini, ada sekitar dua arti yang berbeda dari Kanban, satu adalah "Batas WIP sementara mempertahankan Continuous Flow", dan yang lainnya adalah "Kaizen".

Gambar 3 Properties dan Efek dari Kanban

Sisi kanan dari grafik ini menjelaskan bagaimana meminimalkan WIP sementara mempertahankan aliran kontinu. Jika WIP di toko terlalu sedikit, proses hilir telah menunggu untuk item tidak siap ketika dibutuhkan, tetapi pada saat yang sama WIP harus diminimalkan untuk mencegah kelebihan produksi. Jadi dua gol yang bertentangan, dan Kanban dapat dilihat sebagai strategi untuk memecahkan dilema.

Kanban secara fisik melekat bagian dan ini dikumpulkan dan digunakan kembali, sehingga jumlah Kanbans adalah tetap. Dan itu juga visual sinyal proses hilir untuk menarik bagian-bagian hanya bila diperlukan. Kedua mekanisme batas WIP.

Mekanisme "Kanban Secara fisik melekat" pertama bekerja seperti "hukum kekekalan energi". Setelah jumlah Kanbans didefinisikan berdasarkan tingkat penjualan produk di pasar dan variabilitas intrinsik untuk proses saat ini, WIP terbatas dalam proporsi dengan jumlah Kanbans, terlepas dari aliran masuk dan keluar dari bagian. Jumlah maksimum Kanbans ("energi" dalam sistem) adalah tetap dan fisik melestarikan batas atas WIP pada waktu tertentu. Pada Gambar 4, Anda akan melihat bahwa "Sistem" adalah persediaan antara proses hulu dan proses hilir, yaitu WIP di "toko".

Gambar 4 Kanban Mekanisme Membatasi WIP

Mekanisme kedua, "Tarik," juga membatasi WIP dengan membuat kecepatan produksi dari proses hulu tergantung pada kecepatan konsumsi hilir. Mekanisme pertama hanya mengacu pada jumlah WIP, tetapi yang kedua ini mengacu pada aliran, arah dan kecepatan.

"Arah" - Motivasi produksi hanya diberikan oleh proses hilir.

"Kecepatan" - Kanban mengkomunikasikan waktu dan jumlah produksi berikutnya.
"Tarik" batas WIP dengan membuat proses produksi hulu tergantung pada konsumsi proses hilir dalam urutan derivasi 1. Ketergantungan ini dicapai dengan pertukaran Kanban yang terjadi di toko, mendorong informasi kontrol produksi dari proses hilir ke hulu.

Kembali ke Gambar 3: sisi kiri dari grafik menjelaskan bagaimana membuat pekerjaan mengarahkan diri dan mempromosikan Kaizen. Setiap orang dapat memahami apa yang terjadi dan seberapa baik proses yang mengalir dengan melihat kartu Kanban diposting ke papan. Melihat alur kerja di Gemba adalah awal dari Kaizen. Dan kartu Kanban fisik diletakkan pada papan visual membuat pekerjaan mengarahkan diri tanpa kontrol pusat dari manajemen. Proses otonom memberikan data tentang kinerja untuk mendukung Kaizen, dan mengalihkan perhatian manajemen dari menugaskan atau deliverable kerja secara terperinci kegiatan Kaizen.

Seperti yang ditunjukkan oleh panah grafik itu, mengakhiri dalam tiga efek, tujuan akhir dari Kanban dapat diwakili oleh "Batas WIP", "Continuous Flow" dan "Kaizen". Sebuah sistem Kanban "Batas WIP" sementara mempertahankan "Continuous Flow". Ini buffer variabilitas karena variasi penyebab umum, dan mengekspos variabilitas sebab khusus, menyediakan calon Kaizen.

Kanban dalam Software Development

Sekarang, mari kita lihat bidang kita sendiri kerja - pengembangan perangkat lunak. Dalam pengembangan perangkat lunak Agile, telah menjadi praktek umum untuk memvisualisasikan dan berbagi status proyek dengan posting kartu di dinding ruang proyek. Saya telah menggambarkan banyak contoh dalam artikel terakhir saya InfoQ Visualisasi Proyek Agile menggunakan Kanban Board [Hiranabe07]. Secara khusus, tugas kartu dipasang di dinding menunjukkan status saat ini kadang-kadang disebut "Tugas Kanban" atau "Perangkat Lunak Kanban" [Poppendieck03]. Gambar 5 adalah contoh dari Kanban Tugas dilaksanakan oleh JUDE tim pengembangan di Perubahan Visi, Inc

Gambar 5 Agile Kanban

Di papan tulis, tugas-tugas rekayasa diwakili oleh kartu (Post-It Notes), dan status yang ditunjukkan oleh posting mereka ke daerah-daerah yang terpisah pada papan berlabel "ToDo", "Melakukan", dan "Selesai" (nama Label seringkali berbeda dari situs ke situs, contoh "In Progress", "Diuji", "Diterima", "blokir" dll). Dewan ini membantu visual tugas Kanban sinyal dan batas WIP (tugas aktif sedang dikerjakan). Tapi tidak "proses" (hulu atau hilir) yang ditemukan di sini, dan konsep baru "iterasi" muncul. Untuk setiap iterasi, tugas-tugas yang baru diidentifikasi dengan memecah cerita pengguna menjadi tugas-tugas dan itu adalah tugas-tugas yang diposting ke area ToDo.

Apakah ini suatu sistem tarik? Dalam manufaktur, bagian yang diserahkan dari proses hulu hingga hilir proses. Dalam visualisasi pembangunan Agile ditunjukkan dalam Gambar 5, tidak ada "handoffs" dapat dilihat. Satu kartu Kanban adalah mitra dari satu tugas, dan tertulis di dalamnya informasi seperti: tugas id, nama tugas, perkiraan waktu, dan nama orang yang mendaftar untuk tugas itu. Tugas memiliki status, baik "ToDo", "Melakukan" atau "Selesai", dan dibagi oleh tim. Pendekatan pembangunan Agile nilai-nilai bekerja sama, dan cenderung mengurangi handoffs dalam tim. Saya menyebut ini sebuah "Agile Kanban".

Gambar 6 adalah contoh lain dari Dewan Kanban diterapkan di Yamaha Motor Co Solusi, Ltd.

Gambar 6 Mempertahankan Kanban

Di sini, sistem Kanban digunakan dalam model pembangunan air terjun tradisional tetapi dengan aliran. Proyek ini memiliki proses yang terpisah dan serial yang mereka sebut "desain", "pembangunan", "validasi" dll, dan kartu Kanban bergerak di antara proses. Setiap kartu merupakan persyaratan untuk perubahan atau penambahan ke sistem dan merupakan handoff untuk proses hilir. Catatan bahwa ini bukan proses air terjun klasik, di mana semua persyaratan yang "dirancang" pada satu waktu, "mengembangkan", dan "divalidasi" di lain waktu, yang akan menyebabkan semua kartu untuk bergerak dalam kelompok. Sebaliknya, kartu memindahkan satu per satu, seperti yang aliran sepotong-manufaktur. Apa yang terjadi di sini adalah stabil "mempertahankan" fase dalam siklus hidup suatu produk, dikelola dengan model air terjun keadaan transisi dengan aliran. Di sini, Anda dapat dengan jelas melihat "aliran kerja" konsep sebagai gantinya, berbeda dengan konsep "iterasi" dari Agile. Ini lebih mirip Kanban di pabrik-pabrik dari Agile Kanban dilakukan dan dapat menjadi sistem tarik dengan membuat sebuah aturan untuk mengizinkan hanya proses hilir untuk memindahkan kartu. Saya menyebutnya "Sustaining Kanban", dan merasa mirip dengan "Sistem Kanban untuk Mempertahankan Teknik" David Anderson, yang saya bahas di bagian selanjutnya.

Dan contoh lain, Gambar 7, adalah eksperimen pemikiran yang menunjukkan penggunaan Kanban dalam value stream dari proses pengembangan produk secara keseluruhan [Poppendieck 07].

Gambar 7 Bersandar + Kanban Agile

Misalkan ada sebuah tim pelanggan, pemilik produk, tim pengembangan dan tim QA dalam satu aliran pengembangan produk, dan mereka bekerja sama lewat handoffs menggunakan antrian sehingga tim dapat bekerja secara asynchronous, mempertahankan kecepatan kerja tergantung pada satu sama lain. Setiap "DONE" ruang, efektif, antrian bekerja seperti "toko" di pabrik manufaktur, dan terlihat cukup banyak seperti sistem Kanban TPS. Secara kebetulan, terlihat agak mirip menggunakan Agile Kanban serentak dalam setiap proses dan menggunakan Kanban MELESTARIKAN asynchronous seluruh value stream seluruh proses. Saya pikir sistem Kanban dapat skala untuk menutupi aliran nilai penuh, dalam hal ini bekerja sebagai visualisasi langsung dari value stream.

Dalam contoh ini, WIP dapat dibatasi dengan mendefinisikan ukuran masing-masing daerah. Untuk membuat sistem ini menarik, perlu mekanisme yang memungkinkan proses hilir entah bagaimana sinyal proses hulu untuk mulai bekerja. Membuat aturan bahwa hanya hilir dapat memindahkan kartu DIBUAT untuk sinyal hulu adalah salah satu pilihan. Setelah "Pertemuan Iterasi" berkala adalah pilihan lain yang mensinkronisasikan tim dan transportasi (komunikasi) dari informasi di antara tim. Kedua opsi komunikasi mungkin sesuai dengan dua sinyal penarikan bagian yang dibahas dalam bagian 1, sinyal yaitu visual dari jumlah penarikan Kanban (a) dan interval waktu periodik (b). Di sini, satu set cerita pengguna untuk satu iterasi sesuai dengan bagian ditarik pada palet untuk iterasi, dan jumlah bagian (Kanban) sesuai dengan proyek "Velocity" (kemarin cuaca [Beck00]) dari iterasi. Saya menyebutnya "Lean + Agile Kanban", dan dapat dikombinasikan dengan "Agile Kanban", seperti yang ditunjukkan contoh berikut.

Gambar 8 adalah lebih kecil "portabel" sistem Kanban saya temukan dalam sebuah proyek di TENGAH KOMPUTER LAYANAN Co Ltd Dalam proyek ini, tim bekerja di beberapa tim yang lebih kecil sub (biasanya sepasang). Seluruh tim memiliki alur kerja konseptual mirip dengan Gambar 7, serta papan Kanban kecil Agile ditunjukkan pada Gambar 8 (ToDo / Melakukan / jenis DIBUAT), terlalu. Ketika sebuah tim sub-mengambil satu cerita pengguna, mereka memecahnya menjadi tugas mereka dan posting mereka ke papan ini Kanban portabel. Dalam kasus ini, sistem Kanban adalah terdiri dari dua tingkat, tingkat proyek di mana kartu merupakan cerita pengguna dan tim (atau pasangan) tingkat di mana kartu mewakili tugas.

Mereka menyukai sistem Kanban portabel kecil sangat banyak dan menamakannya "Kanban-nano".

Gambar 8 Portabel Agile Kanban ("Kanban-nano")

Seperti yang Anda lihat, ada beberapa cara untuk menerapkan konsep Kanban untuk pengembangan perangkat lunak. "Agile Kanban" bekerja dalam tim untuk berbagi informasi dan untuk membuat pekerjaan mengarahkan diri, tetapi tidak mendukung aliran.

"Mempertahankan Kanban" adalah jenis lain, memungkinkan kecil-batch pekerjaan pemeliharaan mengalir di antara beberapa negara. Dan kombinasi adalah "Lean + Kanban tangkas" yang menggunakan "Kanban Mempertahankan" di seluruh value stream, dan menggunakan "Agile Kanban" dalam aliran sub-.

Adalah penting untuk menyadari bahwa yang pertama "Kanban Agile" pada Gambar 5, yang sering terlihat dalam proyek-proyek Agile hari ini, hanya melihat sebuah tim sub-dalam value stream. Ketika Anda berpikir tentang value stream penuh dari pelanggan untuk pelanggan, biasanya ada sebuah tim dalam aliran yang sama bahwa tangan Anda persyaratan atau tim lain yang memberikan hasil Anda ke customer.One tujuan dari makalah ini adalah untuk memberikan ide kepada memperpanjang penerapan Kanban luar "Agile Kanban," lebih dari value stream.

Produksi dan Pengembangan

Pengembangan perangkat lunak adalah bukan produksi atau aktivitas manufaktur [Reves92]. Software insinyur menciptakan hal yang berbeda setiap kali, sementara manufakturing menghasilkan hal yang sama berulang-ulang. Jadi pemetaan langsung antara produksi dan pengembangan berbahaya. Namun, mari kita periksa bagaimana sifat TPS Kanban ditemukan dalam berbagai jenis pengembangan perangkat lunak Kanban. Tabel 1 menunjukkan apakah sifat Kanban ditemukan di bagian 1 masih berlaku dalam dua jenis Kanban perangkat lunak yang kami telah dijelaskan.

"Batas WIP", "Continuous Flow" dan "Tarik" properti tidak dicapai dengan contoh Kanban Agile dengan sendirinya, ditunjukkan dalam Gambar 5. Agile Kanban lebih berfokus pada tugas-tugas memungkinkan, "Visual" dan "Self-directing," sehingga untuk membantu tim menjadi otonom dan meningkatkan proses mereka sendiri. Dalam rangka untuk membuat proses terus-menerus mengalir serta untuk membatasi WIP, "pertemuan iterasi" yang diperlukan untuk mengkomunikasikan informasi.

"Mempertahankan Kanban" pada Gambar 6 dapat membatasi WIP dan juga mengontrol aliran dalam "one-piece" dan "menarik" cara, tanpa pertemuan iterasi. Dalam pendekatan ini, fokusnya adalah pada "Batas WIP", "Continuous Flow" dan "Tarik", pada saat yang sama, yang memungkinkan tim (atau manajer) untuk menggunakannya untuk tujuan perbaikan proses.

Kembali ke Gambar 3, saya dikategorikan sifat dan efek dari Kanban menjadi dua area fokus pada Gambar 9, sehingga konsep perangkat lunak di atas dua Kanban dapat sesuai tujuan mereka. Dan Gambar 10 menggambarkan spektrum Produksi dan Pengembangan. Produksi adalah proses dengan kesempatan berhasil yang sangat tinggi (lebih dari 99%), sedangkan pembangunan satu dengan kesempatan sukses yang jauh lebih rendah. Agile adalah pendekatan pembangunan yang optimal saat kemungkinan keberhasilan adalah 50% dari waktu, sementara air terjun optimal ketika peluang keberhasilan lebih dari 90% (menerapkan teori Shannon, sebuah proyek dengan peluang 50% dari sukses adalah proyek yang paling berharga) . Biasanya sebagai perkembangan bergerak ke modus pemeliharaan mempertahankan, peluang keberhasilan untuk bug-fixing atau menambahkan fitur baru naik.

Kanban sistem "Proses Fokus Kontrol" cocok bekerja dengan tingkat "lebih dari 90%" keberhasilan dan "Peningkatan Proses Fokus" bekerja sesuai di daerah 50% serta 90%.

Perhatikan bahwa pendekatan Agile masih bekerja dengan baik dalam modus mempertahankan produk, dan "Peningkatan Proses Terfokus" fitur kerja dengan baik dalam mempertahankan Kanban modus, juga.

Gambar 9 Properties dan Efek dari Kanban (2)

Gambar 10 Spektrum Pendekatan menggunakan Kanban

KSSE - Mempertahankan Sistem Rekayasa Kanban

Di sini saya memperkenalkan munculnya baru-baru aplikasi Bersandar untuk pengembangan perangkat lunak. Sementara aku berada di konferensi Agile2007, saya menghadiri sebuah CWAC (Konferensi-Konferensi Dalam-A-) sesi tentang perangkat lunak Kanban, dipimpin oleh David Anderson. Dia berhasil "pemeliharaan mode" jenis sistem Kanban di Corbis.com dan menerbitkan sebuah makalah yang terkait, Kanban System untuk Mempertahankan Teknik [Anderson 07]. Pendekatan pertama berfokus pada "Batas WIP" milik Kanban, seperti dalam diagram abstraksi dari Gambar 4, serta "Self-Mengarahkan" properti yang membuat tim mengorganisir diri, membutuhkan kurang manajemen top-down. Kemudian, dengan memvisualisasikan aliran melalui Kanbans ia menemukan titik stagnasi dalam aliran seluruh proses, dan sumber daya manusia disesuaikan, yaitu bergeser anggota antara proses. Itu berarti bahwa pendekatan mencakup dari "Batas WIP" properti dan "Self-Mengarahkan" untuk properti "Kaizen" dari Kanban, seperti pada Gambar 3.

Setelah konferensi, Anderson memulai sebuah mailing list kanbandev , di mana telah ada, muncul pengetahuan-menciptakan diskusi pada penerapan Kanban untuk pengembangan perangkat lunak, yang disebut "KSSE" - Sistem Kanban untuk Teknik Mempertahankan, diucapkan Cium-ee ;-). Harun Sanders juga terlibat dalam membangun pengetahuan tentang Kanban, dan telah mulai membangun kosa kata KSSE .

KSSE bekerja dengan baik jika ada beberapa proses serial terhubung lewat handoffs dalam antrian antara proses. Perhatikan bahwa KSSE tidak selalu memiliki "iterasi" konsep. Saya melihat kemungkinan skala Agile dalam cara yang berbeda dari "scrum dari Scrums," dengan menggunakan pendekatan KSSE. [Ladas07]

Membuat aliran nilai

Ketika scaling Agile untuk Bersandar menggunakan Kanban, apa yang harus satu kartu Kanban mewakili?

Dalam sistem Kanban Agile, satu kartu adalah "tugas" dipecah dari "cerita pengguna". Dalam sebuah tim pengembangan, ia bekerja sebagai unit kerja karena semua orang di tim bisa mengerti apa artinya. Tapi dalam sistem Kanban yang bekerja melalui beberapa proses (tim) di seluruh value stream, apa yang mengalir harus memiliki pelanggan yang diakui nilai. Dalam hal ini, salah satu kartu Kanban sesuai untuk tidak "bekerja" tetapi untuk "fitur", dan itu bukan merupakan fragmen dari WBS (pekerjaan struktur breakdown) tapi FBS (fitur struktur breakdown) sehingga setiap orang di sungai, bahkan pelanggan, dapat memahami makna dan nilai dari apa yang mengalir. Jim Highsmith juga diposisikan FBS lebih dari WBS dalam prinsip-prinsipnya yang digariskan dalam buku Agile Manajemen Proyek. [Highsmith04]

"Pengguna Cerita", "Produk Backlog" atau "Gunakan Kasus" yang abstrak yang disebut "MMF" (fitur berharga minimal) sehingga untuk secara eksplisit menyatakan bahwa apa yang mengalir memiliki nilai pelanggan. Dan pengembangan ramping dapat diterjemahkan sebagai "membuat cepat MMFs mengalir melalui aliran nilai penuh."

Contoh "Agile Kanban" pada Gambar 5 adalah rincian pekerjaan, dan bekerja dengan baik dalam tim. Contoh "Mempertahankan Kanban" pada Gambar 6 adalah rincian fitur dan satu kartu mewakili sebuah MMF. Dan contoh dari "Kanban Bersandar + Agile" pada Gambar 7 digunakan dengan Gambar 8 menunjukkan kombinasi gangguan fitur di tingkat atas dan gangguan bekerja di tingkat yang lebih rendah.

Setelah aliran kerja dibentuk, konsep inti lima "Lean Thinking" [Womack1996] dapat diterapkan secara langsung ke seluruh proses. Pengelolaan proses Bersandar hanya mengikuti prinsip-prinsip di bawah ini.