Menciptakan Efisiensi di Tempat Kerja
Gunakan isyarat visual buat 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 ketika karena sumber daya tidak berbaris.
Dan nir terdapat tenaga emosional terbuang mencoba buat mencari memahami siapa yang memakai sisa kertas salinan, & tidak memesan lebih.
Anda mampu pergi ke ekstrem buat menghindari perkara ini. Anda mampu memesan kertas salinan cukup buat mengisi seluruh gudang, atau mempunyai persediaan yg cukup persediaan di tangan buat memenuhi pesanan buat enam bulan ke depan. Tapi ini jenis "solusi atas" merupakan miskin menggunakan asal daya keuangan dan ruang.
Bagaimana apabila terdapat cara buat memastikan Anda selalu mempunyai sumber daya yang diperlukan tersedia waktu Anda membutuhkan mereka? Jepang, pelopor pada efisiensi, menyebarkan sistem Kanban buat melakukan hal ini.
Kanban pada 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 primer pada bidang manufaktur adalah kebutuhan buat memiliki persediaan siap bahan, tanpa menyebabkan biaya persediaan yg tidak perlu memegang. Namun jua bisa diterapkan pada lingkungan non manufaktur, pada mana efisiensi alur kerja Anda tergantung pada memiliki sumber daya yang tersedia.
Istilah 'kanban' menggabungkan istilah-istilah Jepang 'kan,' yg berarti 'visual' dan 'embargo', yg berarti 'kartu' atau 'papan. " Sebuah kanban kartu visual atau isyarat lain yg sinyal ada sesuatu yang diperlukan. Ini adalah "menarikdanquot; sistem, di mana pasokan dipengaruhi 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 pada TPS?
Kanban merupakan perangkat frekuwensi (umumnya kartu fisik dalam amplop plastik bening) yang menginstruksikan beranjak atau membuat bagian-bagian dalam suatu sistem "menarik" produksi, ditemukan dan dikembangkan menjadi bagian menurut Toyota Production System (TPS). Sebelum masuk ke Kanban pada pengembangan aplikasi, di sini aku mengambil melihat berdasarkan dekat aslinya yaitu penggunaan yang Kanban pada TPS.
Tujuan kanban merupakan buat meminimalkan WIP (Work-In-Process), atau persediaan, antara proses dengan memastikan bahwa proses membentuk bagian hulu hanya apabila proses hilir membutuhkannya. "Tarik" berarti bahwa para pekerja hilir menarik atau "tarik" bagian-bagian yg 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 merupakan pada lokasi hulu & bekerja menjadi "penyanggadanquot; atau "antriandanquot; WIP. Ketika seseorang pekerja berdasarkan proses hilir, yg dianggap "materi handlerdanquot;, tiba ke toko & merogoh bagian yang baru selesai, itu pula kembali sinyal produksi - yaitu hal-hal menarik hilir dari hulu dan dalam waktu yang sama mendorong liputan kepada hulu melalui kartu Kanban. Hal ini dibutuhkan, lantaran proses hulu tidak pernah membuat bagian tanpa instruksi dari proses hilir.
Jadi pada 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.
Gambar dua Kanban Exchange pada Store
- Seorang penangan material di lokasi hilir ditandai untuk menarik bagian. Sinyal didefinisikan sang proses hilir dan keliru satu menurut 2 pada bawah ini:
(A) ditandai dengan jumlah dikumpulkan menarik Kanbans
(B) ditandai menggunakan interval ketika periodik
Ia mengunjungi toko di lokasi hulu menggunakan palet kosong dan dikumpulkan-Nya menarik Kanbans menjadi daftar belanja, yang menampakan apa yg diperlukan & dalam jumlah apa buat 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 2 proses, bekerja pada sebuah thread terpisah berdasarkan kontrol, bertukar warta melalui hal-hal dan Kanban. Pada permukaan kartu Kanban, informasi seperti nomor bagian / nama, jumlah, jenis palet, alamat toko, ditulis sehingga penangan bahan yg merogoh kartu ini bisa tahu apa yang harus dilakukan.
Ada disiplin yg ketat menjalankan Kanban, yg dianggap "anggaran enam dari Kanbandanquot;:
- 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 sudah kita bahas, toko bekerja sebagai antrian bagian, palet bekerja sebagai pembawa bagian, & kartu Kanban bekerja sebagai pembawa pelanggan membutuhkan liputan. Mereka membuatnya sebagai "menarikdanquot; sistem, membangun keseimbangan antara mempertahankan "aliran kontinudanquot; (menghilangkan pemborosan menunggu) & "WIP minizingdanquot; (menghilangkan pemborosan overproduksi). Mekanisme pengelolaan "hak" jumlah WIP pada genre antara membeli-in & menjual-out adalah persis apa yang terjadi pada supermarket, & 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 menurut Kanban
Dari pengamatan rinci dalam bagian sebelumnya, di sini adalah daftar properti diekstraksi & pengaruh dari konsep Kanban orisinil pada 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 Properties & Efek menurut Kanban
Sisi kanan dari grafik ini menyebutkan bagaimana meminimalkan WIP sementara mempertahankan aliran kontinu. Apabila WIP pada toko terlalu sedikit, proses hilir telah menunggu buat item nir siap ketika diharapkan, namun pada ketika yang sama WIP harus diminimalkan buat mencegah kelebihan produksi. Jadi dua gol yg bertentangan, & Kanban dapat dipandang sebagai taktik buat memecahkan problem.
Kanban secara fisik inheren bagian & ini dikumpulkan dan dipakai kembali, sebagai akibatnya jumlah Kanbans adalah tetap. Dan itu jua visual sinyal proses hilir buat menarik bagian-bagian hanya apabila dibutuhkan. Kedua mekanisme batas WIP.
Mekanisme "Kanban Secara fisik melekat" pertama bekerja misalnya "aturan kekekalan energi". Setelah jumlah Kanbans didefinisikan menurut taraf penjualan produk di pasar & variabilitas intrinsik buat proses waktu ini, WIP terbatas dalam proporsi menggunakan jumlah Kanbans, terlepas dari aliran masuk dan keluar menurut bagian. Jumlah maksimum Kanbans ("energidanquot; dalam sistem) merupakan permanen dan fisik melestarikan batas atas WIP pada saat eksklusif. 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 ke 2, "Tarik," pula membatasi WIP dengan membuat kecepatan produksi menurut proses hulu tergantung pada kecepatan konsumsi hilir. Mekanisme pertama hanya mengacu dalam jumlah WIP, tetapi yang kedua ini mengacu dalam genre, arah & kecepatan.
"Arahdanquot; - Motivasi produksi hanya diberikan sang proses hilir.
"Kecepatandanquot; - Kanban mengkomunikasikan waktu & jumlah produksi berikutnya.
"Tarik" batas WIP dengan menciptakan proses produksi hulu tergantung dalam konsumsi proses hilir pada urutan derivasi 1. Ketergantungan ini dicapai menggunakan pertukaran Kanban yang terjadi di toko, mendorong fakta kontrol produksi berdasarkan proses hilir ke hulu.
Kembali ke Gambar tiga: sisi kiri berdasarkan grafik menyebutkan bagaimana membuat pekerjaan mengarahkan diri & mempromosikan Kaizen. Setiap orang dapat tahu apa yg terjadi & seberapa baik proses yang mengalir dengan melihat kartu Kanban diposting ke papan. Melihat alur kerja di Gemba adalah awal menurut Kaizen. Dan kartu Kanban fisik diletakkan pada papan visual membuat pekerjaan mengarahkan diri tanpa kontrol sentra dari manajemen. Proses otonom memberikan data mengenai kinerja buat mendukung Kaizen, dan mengalihkan perhatian manajemen dari menugaskan atau deliverable kerja secara terang aktivitas Kaizen.
Seperti yg ditunjukkan oleh panah grafik itu, mengakhiri dalam 3 dampak, tujuan akhir berdasarkan Kanban dapat diwakili oleh "Batas WIP", "Continuous Flow" dan "Kaizendanquot;. Sebuah sistem Kanban "Batas WIPdanquot; ad interim mempertahankan "Continuous Flowdanquot;. Ini buffer variabilitas karena variasi penyebab umum, dan mengekspos variabilitas karena khusus, menyediakan calon Kaizen.
Kanban pada 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 lima Agile Kanban
Di papan tulis, tugas-tugas rekayasa diwakili oleh kartu (Post-It Notes), & status yg ditunjukkan sang posting mereka ke daerah-daerah yang terpisah dalam papan berlabel "ToDodanquot;, "Melakukandanquot;, & "Selesaidanquot; (nama Label acapkali tidak sinkron dari situs ke situs, contoh "In Progress", "Diuji", "Diterimadanquot;, "blokir" dll). Dewan ini membantu visual tugas Kanban sinyal dan batas WIP (tugas aktif sedang dikerjakan). Tapi nir "prosesdanquot; (hulu atau hilir) yg ditemukan di sini, & konsep baru "iterasi" timbul. Untuk setiap iterasi, tugas-tugas yg baru diidentifikasi dengan memecah cerita pengguna menjadi tugas-tugas dan itu adalah tugas-tugas yg 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, nir ada "handoffsdanquot; bisa dipandang. Satu kartu Kanban adalah kawan menurut satu tugas, & tertulis di dalamnya fakta seperti: tugas id, nama tugas, perkiraan ketika, dan nama orang yang mendaftar buat tugas itu. Tugas memiliki status, baik "ToDodanquot;, "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 merupakan contoh lain menurut Dewan Kanban diterapkan di Yamaha Motor Co Solusi, Ltd.
Gambar 6 Mempertahankan Kanban
Di sini, sistem Kanban dipakai dalam contoh pembangunan air terjun tradisional namun menggunakan genre. Proyek ini mempunyai proses yang terpisah & serial yg mereka sebut "desaindanquot;, "pembangunan", "validasidanquot; dll, & kartu Kanban beranjak pada antara proses. Setiap kartu adalah persyaratan buat perubahan atau penambahan ke sistem & merupakan handoff untuk proses hilir. Catatan bahwa ini bukan proses air terjun klasik, di mana semua persyaratan yg "dirancang" pada satu ketika, "mengembangkandanquot;, dan "divalidasi" pada lain saat, yang akan menyebabkan seluruh kartu untuk berkiprah pada grup. Sebaliknya, kartu memindahkan satu per satu, misalnya yg aliran sepotong-manufaktur. Apa yg terjadi pada sini merupakan stabil "mempertahankandanquot; fase pada siklus hidup suatu produk, dikelola dengan model air terjun keadaan transisi dengan genre. Di sini, Anda dapat menggunakan kentara melihat "genre kerjadanquot; konsep sebagai gantinya, tidak sama dengan konsep "iterasi" menurut Agile. Ini lebih mirip Kanban di pabrik-pabrik berdasarkan Agile Kanban dilakukan dan dapat menjadi sistem tarik dengan menciptakan sebuah aturan buat mengizinkan hanya proses hilir buat memindahkan kartu. Saya menyebutnya "Sustaining Kanban", dan merasa mirip dengan "Sistem Kanban untuk Mempertahankan Teknik" David Anderson, yg aku bahas di bagian selanjutnya.
Dan contoh lain, Gambar 7, merupakan eksperimen pemikiran yang menerangkan penggunaan Kanban dalam value stream berdasarkan proses pengembangan produk secara keseluruhan [Poppendieck 07].
Gambar 7 Bersandar Kanban Agile
Misalkan terdapat sebuah tim pelanggan, pemilik produk, tim pengembangan & tim QA pada satu genre pengembangan produk, dan mereka bekerja sama lewat handoffs menggunakan antrian sebagai akibatnya tim bisa bekerja secara asynchronous, mempertahankan kecepatan kerja tergantung dalam satu sama lain. Setiap "DONEdanquot; ruang, efektif, antrian bekerja seperti "toko" di pabrik manufaktur, & terlihat cukup banyak seperti sistem Kanban TPS. Secara kebetulan, terlihat relatif seperti menggunakan Agile Kanban serentak pada setiap proses & menggunakan Kanban MELESTARIKAN asynchronous semua value stream semua proses. Saya pikir sistem Kanban bisa skala untuk menutupi aliran nilai penuh, pada hal ini bekerja sebagai visualisasi pribadi menurut value stream.
Dalam model ini, WIP bisa dibatasi menggunakan mendefinisikan berukuran masing-masing daerah. Untuk menciptakan sistem ini menarik, perlu mekanisme yg memungkinkan proses hilir entah bagaimana frekuwensi proses hulu buat mulai bekerja. Membuat aturan bahwa hanya hilir dapat memindahkan kartu DIBUAT buat sinyal hulu merupakan keliru satu pilihan. Setelah "Pertemuan Iterasidanquot; terpola merupakan pilihan lain yang mensinkronisasikan tim & transportasi (komunikasi) dari berita di antara tim. Kedua opsi komunikasi mungkin sinkron dengan dua frekuwensi penarikan bagian yang dibahas dalam bagian 1, frekuwensi yaitu visual menurut jumlah penarikan Kanban (a) & interval saat periodik (b). Di sini, satu set cerita pengguna buat satu perulangan sinkron dengan bagian ditarik pada palet buat perulangan, dan jumlah bagian (Kanban) sinkron menggunakan proyek "Velocitydanquot; (kemarin cuaca [Beck00]) dari perulangan. Saya menyebutnya "Lean Agile Kanbandanquot;, & dapat dikombinasikan menggunakan "Agile Kanbandanquot;, seperti yang ditunjukkan contoh berikut.
Gambar 8 merupakan lebih mini "portabel" sistem Kanban aku temukan pada sebuah proyek pada TENGAH KOMPUTER LAYANAN Co Ltd Dalam proyek ini, tim bekerja pada beberapa tim yg lebih kecil sub (umumnya sepasang). Seluruh tim mempunyai alur kerja konseptual mirip menggunakan Gambar 7, dan papan Kanban kecil Agile ditunjukkan dalam Gambar 8 (ToDo / Melakukan / jenis DIBUAT), terlalu. Ketika sebuah tim sub-merogoh satu cerita pengguna, mereka memecahnya menjadi tugas mereka dan posting mereka ke papan ini Kanban portabel. Dalam masalah ini, sistem Kanban adalah terdiri dari dua taraf, taraf proyek di mana kartu adalah cerita pengguna dan tim (atau pasangan) tingkat di mana kartu mewakili tugas.
Mereka menyukai sistem Kanban portabel mini sangat banyak & menamakannya "Kanban-nano".
Gambar 8 Portabel Agile Kanban ("Kanban-nanodanquot;)
Seperti yang Anda lihat, ada beberapa cara buat menerapkan konsep Kanban buat pengembangan perangkat lunak. "Agile Kanbandanquot; bekerja pada tim buat membuatkan warta dan buat menciptakan pekerjaan mengarahkan diri, namun tidak mendukung aliran.
"Mempertahankan Kanbandanquot; adalah jenis lain, memungkinkan mini -batch pekerjaan pemeliharaan mengalir pada antara beberapa negara. Dan kombinasi merupakan "Lean Kanban tangkas" yg menggunakan "Kanban Mempertahankan" pada seluruh value stream, & memakai "Agile Kanban" dalam aliran sub-.
Adalah penting buat menyadari bahwa yg pertama "Kanban Agile" dalam Gambar lima, yg tak jarang terlihat pada proyek-proyek Agile hari ini, hanya melihat sebuah tim sub-pada value stream. Ketika Anda berpikir tentang value stream penuh menurut pelanggan buat pelanggan, biasanya ada sebuah tim pada genre yang sama bahwa tangan Anda persyaratan atau tim lain yg menaruh output Anda ke customer.One tujuan menurut makalah ini merupakan buat memberikan ide pada memperpanjang penerapan Kanban luar "Agile Kanban," lebih dari value stream.
Produksi & Pengembangan
Pengembangan software adalah bukan produksi atau kegiatan manufaktur [Reves92]. Software insinyur membentuk hal yg tidak sama setiap kali, sementara manufakturing membuat hal yg sama berulang-ulang. Jadi pemetaan eksklusif antara produksi dan pengembangan berbahaya. Tetapi, ayo kita periksa bagaimana sifat TPS Kanban ditemukan pada aneka macam jenis pengembangan aplikasi Kanban. Tabel 1 memperlihatkan apakah sifat Kanban ditemukan pada bagian 1 masih berlaku pada 2 jenis Kanban perangkat lunak yg kami telah dijelaskan.
"Batas WIPdanquot;, "Continuous Flow" & "Tarik" properti nir dicapai dengan model Kanban Agile dengan sendirinya, ditunjukkan dalam Gambar lima. Agile Kanban lebih berfokus dalam tugas-tugas memungkinkan, "Visual" & "Self-directing," sehingga buat membantu tim sebagai otonom & menaikkan proses mereka sendiri. Dalam rangka buat membuat proses monoton mengalir dan untuk membatasi WIP, "pertemuan iterasi" yang diharapkan buat mengkomunikasikan liputan.
"Mempertahankan Kanbandanquot; dalam Gambar 6 bisa membatasi WIP & juga mengontrol genre dalam "one-piece" & "menarikdanquot; cara, tanpa pertemuan iterasi. Dalam pendekatan ini, fokusnya adalah dalam "Batas WIPdanquot;, "Continuous Flow" & "Tarik", dalam waktu yang sama, yang memungkinkan tim (atau manajer) buat menggunakannya buat 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 & 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 Kontroldanquot; cocok bekerja dengan taraf "lebih berdasarkan 90%" keberhasilan & "Peningkatan Proses Fokus" bekerja sesuai pada wilayah 50% dan 90%. Perhatikan bahwa pendekatan Agile masih bekerja menggunakan baik pada modus mempertahankan produk, & "Peningkatan Proses Terfokus" fitur kerja dengan baik pada mempertahankan Kanban modus, jua.
Gambar 9 Properties dan Efek menurut Kanban (2)
Gambar 10 Spektrum Pendekatan memakai 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 menggunakan baik bila ada beberapa proses serial terhubung lewat handoffs dalam antrian antara proses. Perhatikan bahwa KSSE tidak selalu mempunyai "iterasidanquot; konsep. Saya melihat kemungkinan skala Agile pada cara yang berbeda dari "scrum menurut Scrums," menggunakan menggunakan pendekatan KSSE. [Ladas07]
Membuat genre nilai
Ketika scaling Agile buat Bersandar menggunakan Kanban, apa yg wajib satu kartu Kanban mewakili?
Dalam sistem Kanban Agile, satu kartu merupakan "tugasdanquot; dipecah dari "cerita pengguna". Dalam sebuah tim pengembangan, dia bekerja menjadi unit kerja karena semua orang di tim sanggup mengerti apa artinya. Tapi dalam sistem Kanban yang bekerja melalui beberapa proses (tim) pada seluruh value stream, apa yg mengalir harus memiliki pelanggan yg diakui nilai. Dalam hal ini, salah satu kartu Kanban sinkron buat nir "bekerjadanquot; tetapi buat "fitur", dan itu bukan merupakan fragmen berdasarkan WBS (pekerjaan struktur breakdown) tapi FBS (fitur struktur breakdown) sebagai akibatnya setiap orang pada sungai, bahkan pelanggan, bisa tahu makna dan nilai berdasarkan apa yg mengalir. Jim Highsmith pula diposisikan FBS lebih menurut WBS pada prinsip-prinsipnya yang digariskan dalam kitab Agile Manajemen Proyek. [Highsmith04]
"Pengguna Cerita", "Produk Backlog" atau "Gunakan Kasusdanquot; yang abstrak yang diklaim "MMF" (fitur berharga minimal) sebagai akibatnya untuk secara eksplisit menyatakan bahwa apa yang mengalir mempunyai nilai pelanggan. Dan pengembangan ramping dapat diterjemahkan sebagai "membuat cepat MMFs mengalir melalui aliran nilai penuh."
Contoh "Agile Kanban" dalam Gambar lima merupakan rincian pekerjaan, & bekerja menggunakan baik dalam tim. Contoh "Mempertahankan Kanban" pada Gambar 6 merupakan rincian fitur & satu kartu mewakili sebuah MMF. Dan model dari "Kanban Bersandar Agiledanquot; dalam Gambar 7 digunakan menggunakan Gambar 8 menerangkan kombinasi gangguan fitur di taraf atas dan gangguan bekerja di tingkat yg lebih rendah.
Setelah genre kerja dibentuk, konsep inti lima "Lean Thinkingdanquot; [Womack1996] dapat diterapkan secara pribadi ke semua proses. Pengelolaan proses Bersandar hanya mengikuti prinsip-prinsip pada bawah ini.
- Tentukan nilai dalam mata pelanggan - Tentukan dan mengurutkan MMFs
- Mengidentifikasi value stream dan menghilangkan pemborosan - Cari stagnasi (pemblokiran tugas)
- Membuat genre nilai pada tarikan pelanggan - Membuat aturan tarikan Kanban
- Melibatkan dan memberdayakan karyawan - Memberdayakan tim di Gemba
- Terus meningkatkan dalam mengejar kesempurnaan - Refleksi dan Kaizen
Home | Bab Sebelumnya | Menu | Bab Selanjutnya