David Anderson - Kanban. Kanban

David J Anderson

Perubahan Evolusioner yang Berhasil untuk Bisnis Teknologi Anda

Diterbitkan dengan izin dari Lean Kanban Inc.

Kami berterima kasih kepada Komunitas Lean Kanban Rusia yang diwakili oleh Alexey Pimenov, Vyacheslav Tsyrulnik, Anton Manin, Sergey Baranov dan Igor Filipyev atas bantuan mereka dalam mempersiapkan publikasi.

Seluruh hak cipta.

Tidak ada bagian dari buku ini yang boleh direproduksi dalam bentuk apapun tanpa izin tertulis dari pemegang hak cipta.

* * *

Didedikasikan untuk Nikola dan Natalie

Kata pengantar

Saya selalu memperhatikan karya David Anderson. Saya bertemu dengannya pada bulan Oktober 2003 ketika dia mengirimi saya bukunya Manajemen Agile untuk Rekayasa Perangkat Lunak: Menerapkan Teori Kendala untuk Hasil Bisnis. Seperti judulnya, buku ini sangat dipengaruhi oleh Theory of Constraints (TOC) Eliyahu Goldratt. 1
Theory of Constraints adalah metodologi manajemen produksi populer yang dikembangkan pada 1980-an oleh Eliyahu Goldratt, yang didasarkan pada penemuan dan pengelolaan kendala sistem utama yang menentukan keberhasilan dan efisiensi seluruh sistem secara keseluruhan. Catatan. ed.

Kemudian, pada bulan Maret 2005, saya mengunjungi David di Microsoft, pada saat itu dia bekerja erat dengan diagram alur kumulatif. Bahkan kemudian, pada April 2007, saya berkesempatan mengamati bagaimana terobosan sistem kanban yang dia terapkan di Corbis bekerja.

Saya memberikan seluruh kronologi ini sehingga Anda dapat merasakan kecepatan tak terbendung di mana pemikiran manajerial David berkembang. Dia tidak berpegang pada satu ide pun, mencoba menyesuaikan seluruh dunia dengannya. Sebaliknya, ia mencoba mempertimbangkan masalah secara keseluruhan, terbuka terhadap berbagai solusi, mencobanya dalam praktik, dan mengevaluasi prinsip-prinsip kerja. Anda akan melihat hasil dari pendekatan ini dalam buku ini.

Tentu saja, kecepatan itu bagus selama berada di arah yang benar, dan saya yakin David bergerak ke arah yang benar. Saya sangat mengagumi karya terbaru dengan sistem kanban. Saya selalu percaya bahwa prinsip-prinsip lean dapat langsung diterapkan pada pengembangan produk, berlawanan dengan ide-ide TOC. Terlebih lagi, pada bulan Oktober 2003, saya menulis kepada David sebagai berikut: “Salah satu kelemahan utama CBT adalah meremehkan pentingnya ukuran partai.

Jika prioritas utama Anda adalah menemukan dan memperbaiki kendala, maka itu sering kali berarti Anda hanya memecahkan masalah yang salah." Saya masih percaya pernyataan ini benar.

Pada pertemuan kami di tahun 2005, saya kembali menyarankan kepada David untuk melihat lebih dari sekedar fokus pada kemacetan di TOC. Saya menjelaskan kepadanya bahwa hype Toyota Production System (TPS) tidak ada hubungannya dengan menemukan dan menghilangkan kemacetan. Toyota mencapai peningkatan produktivitas dengan mengurangi ukuran lot dan variabilitas, yang mengurangi jumlah persediaan yang dibutuhkan. Pengurangan persediaan itulah yang menyebabkan pencapaian manfaat ekonomi, dan ini dimungkinkan oleh sistem pengurangan barang dalam proses seperti kanban.

Pada tahun 2007 saya mengunjungi Corbis. Hasil pengenalan sistem kanban tampak mengesankan. Saya menunjukkan kepada David bahwa dia telah sangat meningkatkan pendekatan kanban yang digunakan di Toyota. Mengapa saya berpikir begitu? Sistem Produksi Toyota dioptimalkan untuk menangani tugas yang berulang dan dapat diprediksi dengan durasi yang seragam dan biaya penundaan yang seragam. Dalam kondisi ini, cukup tepat untuk menggunakan pendekatan seperti prioritas FIFO ("masuk pertama, keluar pertama"). Juga sangat tepat untuk memblokir kedatangan pekerjaan jika batas tugas yang belum selesai tercapai. Namun, jika kita berurusan dengan aktivitas yang tidak berulang dan tidak dapat diprediksi dengan durasi yang berbeda dan biaya penundaan yang berbeda, pendekatan ini tidak dapat dianggap optimal - dan inilah yang terjadi pada pengembangan perangkat lunak. Kita membutuhkan sistem yang lebih maju, dan ini adalah buku pertama yang menjelaskannya secara praktis.

Saya ingin memperingatkan pembaca tentang beberapa hal. Pertama, jika Anda merasa tahu cara kerja sistem kanban, mungkin yang Anda maksud adalah sistem yang digunakan dalam lean manufacturing. Ide-ide dalam buku ini jauh lebih maju daripada sistem sederhana yang menggunakan batas WIP statis. 2
WIP - pekerjaan yang sedang berlangsung, jumlah tugas yang sedang berlangsung. Catatan. ed.

Penjadwalan FIFO dan layanan kelas tunggal. Harap perhatikan perbedaan-perbedaan ini.

Kedua, jangan berpikir bahwa pendekatan ini adalah sistem kontrol visual. Visualisasi pekerjaan yang sedang berlangsung yang dicapai dengan papan kanban sangat berguna, tetapi itu hanya aspek kecil dari pendekatan ini. Jika Anda membaca buku ini dengan seksama, Anda akan menemukan banyak hal menarik di dalamnya. Informasi yang paling berharga disembunyikan, misalnya, dalam aspek-aspek seperti struktur proses untuk menerima dan mengirimkan tugas, mengelola sumber daya yang tak tergantikan, dan menggunakan kelas layanan. Jangan terganggu oleh bagian visual, jika tidak, Anda akan kehilangan momen paling menarik.

Ketiga, jangan mengabaikan metode ini hanya karena tampaknya terlalu mudah digunakan. Kemudahan penggunaan adalah hasil dari ide David tentang bagaimana mendapatkan manfaat yang maksimal dengan hasil yang minimal. Dia mengetahui kebutuhan praktisi dengan baik dan telah memberikan perhatian serius pada apa yang benar-benar berhasil. Metode sederhana menunjukkan stabilitas tinggi dan hampir selalu mengarah pada hasil jangka panjang terbaik.

Ini adalah buku yang menarik dan penting dan layak untuk dipelajari dengan cermat. Tingkat manfaat yang Anda peroleh tergantung pada seberapa serius Anda membaca. Tidak ada buku lain yang akan memperkenalkan Anda pada ide-ide lanjutan ini dengan lebih baik. Saya harap Anda menikmatinya sama seperti saya.

dan Reinertsen,

Bagian I
Dasar-dasar

Bab 1
Memecahkan Dilema Manajer Agile

Pada tahun 2002, saya adalah seorang manajer pengembangan di kantor terpencil di divisi ponsel Motorola di Seattle (disebut PCS) dan menemukan diri saya dalam situasi yang sulit. Departemen saya adalah bagian dari perusahaan rintisan yang diakuisisi Motorola setahun sebelumnya. Kami telah mengembangkan perangkat lunak jaringan untuk transmisi data nirkabel, seperti unduhan nirkabel dan kontrol instrumen. Aplikasi back-end ini adalah bagian dari sistem terintegrasi yang digabungkan erat dengan kode klien ponsel, serta elemen lain dalam jaringan telekomunikasi dan infrastruktur operasional, seperti penagihan. Tenggat waktu ditetapkan oleh manajer yang tidak memperhatikan kompleksitas rekayasa proyek, risikonya, atau skalanya. Kode inti berevolusi dari startup, dengan banyak fitur yang awalnya direncanakan ditunda hingga nanti. Seorang pengembang senior bersikeras bahwa produk kami disebut "prototipe". Kami sangat membutuhkan peningkatan produktivitas dan kualitas produk untuk memenuhi tuntutan bisnis.

Dalam kegiatan sehari-hari saya pada tahun 2002 dan dalam proses mengerjakan buku sebelumnya 1
Anderson, David J Manajemen Agile untuk Rekayasa Perangkat Lunak: Menerapkan Teori Kendala untuk Hasil Bisnis. Upper Saddle River, NJ: Prentice Hall, 2003.

Saya prihatin terutama dengan dua masalah. Pertama, bagaimana melindungi tim dari tuntutan bisnis yang terus meningkat dan mencapai apa yang sekarang disebut “kecepatan optimal” di komunitas tangkas. Dan kedua, bagaimana saya bisa berhasil menerapkan pendekatan tangkas di seluruh organisasi, mengatasi penolakan yang tak terhindarkan terhadap perubahan?

Menemukan kecepatan yang tepat

Pada tahun 2002, komunitas tangkas berpikir bahwa kecepatan optimal hanyalah "40 jam kerja dalam seminggu". 2
Beck, Kent. Pemrograman Ekstrim Dijelaskan: Rangkullah Perubahan. Boston: Addison Wesley, 2000. Edisi Rusia: Beck K. Extreme Programming. Sankt Peterburg: Peter, 2002.

Prinsip-prinsip Manifesto Agile 3
Beck, Kent et al., "Prinsip Dibalik Manifesto Agile." http://www.agilemanifesto.org/principles.html. Terjemahan Rusia: http://agilemanifesto.org/iso/ru/principles.html .

Mereka mengatakan bahwa “proses tangkas berkontribusi pada pengembangan yang optimal. Sponsor, pengembang, dan pengguna harus siap untuk mempertahankan kecepatan konstan tanpa batas.” Dua tahun sebelumnya, tim saya di Sprint PCS terus mendengar dari saya bahwa "pengembangan perangkat lunak dalam skala besar adalah maraton, bukan sprint." Jika anggota tim harus mempertahankan kecepatan konstan dalam proses mengerjakan proyek satu setengah tahun, maka mereka tidak dapat dibiarkan kehabisan tenaga dalam satu atau dua bulan. Proyek harus direncanakan, dianggarkan, diatur waktunya, dan dievaluasi untuk memastikan bahwa anggota tim menghabiskan cukup banyak waktu untuk bekerja setiap hari dan tidak terlalu lelah. Sebagai seorang manajer, tugas saya adalah untuk mencapai tujuan ini dan memenuhi semua kebutuhan bisnis.

Ketika saya berada di posisi manajerial pertama saya (pada tahun 1991, di sebuah start-up yang membuat papan perekam video untuk komputer pribadi dan komputer yang lebih kecil), CEO 3
Chief Executive Officer - Chief Executive Officer (CEO). Catatan. ed.

Dia mengatakan bahwa manajemen memiliki "pendapat yang sangat negatif" tentang saya. Saya selalu menjawab "tidak" ketika peluang kami sebagai pengembang sudah habis, dan semakin banyak produk atau fitur yang dibutuhkan dari kami. Pada tahun 2002, saya telah menjadi kebiasaan: saya menghabiskan sepuluh tahun lagi untuk menolak menuruti keinginan pemilik bisnis.

Tim pengembangan dan departemen TI perusahaan sangat bergantung pada kelompok lain yang terus-menerus menawar, memohon, mengancam, dan mengerjakan ulang bahkan rencana yang paling jelas dan dirancang secara objektif. Rentan juga mencakup rencana berdasarkan analisis yang cermat dan pengalaman sejarah. Sebagian besar tim, yang tidak memiliki analisis menyeluruh dan pengalaman sejarah, tidak dapat mengatasi mereka yang mendorong mereka untuk mengambil komitmen yang tidak jelas dan seringkali tidak mungkin.

Sementara itu, karyawan telah menerima beban kerja yang gila, dan beban kerja yang terlalu tinggi telah menjadi norma. Tampaknya tidak ada yang berpikir tentang fakta bahwa insinyur perangkat lunak juga dapat memiliki kehidupan sosial atau keluarga. Kedengarannya kasar, tapi itu benar! Saya tahu terlalu banyak contoh di mana beban kerja yang berlebihan telah selamanya menghancurkan hubungan keluarga. Sulit untuk bersimpati dengan geek pengembang yang khas. Di negara bagian asal saya di Washington, pendapatan seorang insinyur perangkat lunak adalah yang kedua setelah dokter gigi. Seperti di masa Ford, yaitu pada 1920-an, ketika orang-orang di pabriknya memperoleh lima kali lebih banyak daripada rata-rata nasional, tidak pernah terpikir oleh siapa pun untuk memikirkan monoton pekerjaan atau kesejahteraan spesialis: mereka adalah dibayar begitu banyak! Sulit membayangkan serikat pekerja di industri berbasis pengetahuan seperti pengembangan perangkat lunak, karena tidak ada yang akan meneliti secara serius penyebab penyakit fisik dan psikologis yang dialami pengembang. Pengusaha yang lebih bertanggung jawab menawarkan, misalnya, tindakan seperti pijat atau psikoterapi. Atau mereka menghabiskan hari-hari kesehatan mental - dan ini bukannya memperhatikan mempelajari akar penyebab masalah. Seorang penulis teknis di sebuah perusahaan perangkat lunak terkenal pernah mengatakan kepada saya, "Tidak apa-apa jika saya menggunakan antidepresan, karena semua orang melakukannya!" Pemrogram biasanya mengikuti semua tuntutan, dibayar dengan baik, dan menanggung akibatnya. Saya ingin mengubah keadaan ini, untuk menemukan pendekatan win-win yang memungkinkan saya untuk mengatakan ya dan tetap melindungi tim saya, memastikan bahwa kecepatan optimal tercapai. Saya ingin membawa anggota tim saya kembali ke komunitas dan keluarga, dan memperbaiki kondisi yang menyebabkan stres dan masalah kesehatan bagi pengembang di bawah tiga puluh tahun. Jadi saya memutuskan untuk mulai menangani masalah ini.

Mencari Manajemen Perubahan yang Berhasil

Isu kedua yang ada di pikiran saya adalah manajemen perubahan dalam organisasi besar. Saya adalah seorang manajer pengembangan di Sprint PCS dan kemudian di Motorola. Di kedua perusahaan, ada kebutuhan yang kuat untuk beralih ke metode kerja yang lebih fleksibel. Namun dalam kedua kasus tersebut, saya mengalami kesulitan menerapkan metode tangkas pada lebih dari satu atau dua tim.

Kedua kali, saya tidak memiliki wewenang yang cukup untuk hanya memesan perubahan yang akan dilakukan ke beberapa tim. Saya mencoba menerapkan perubahan atas permintaan manajemen senior, tetapi tidak memiliki wewenang yang diperlukan. Saya diminta untuk mempengaruhi rekan kerja untuk menerapkan perubahan yang sama di tim mereka seperti yang saya lakukan di tim saya. Tetapi mereka tidak terburu-buru untuk mengadopsi metode yang tampaknya paling berhasil di tim saya. Resistensi ini mungkin memiliki beberapa alasan. Lebih sering daripada tidak, saya mendengar bahwa setiap tim memiliki situasinya sendiri dan metode saya perlu disesuaikan dengan kebutuhan spesifik orang lain. Pada pertengahan tahun 2002, saya menyadari bahwa tidak ada gunanya meresepkan proses pengembangan perangkat lunak secara kaku - itu tidak akan berhasil.

Prosesnya harus disesuaikan dengan setiap situasi tertentu, sehingga diperlukan kepemimpinan aktif dari setiap tim. Dan ini seringkali tidak cukup. Bahkan dengan kepemimpinan yang tepat, tidak ada kepastian bahwa perubahan signifikan dapat terjadi tanpa struktur yang mapan dan saran tentang bagaimana menyesuaikan proses dengan situasi yang berbeda. Jika manajer, pelatih, atau insinyur yang bertanggung jawab tidak memiliki gagasan yang jelas tentang apa yang harus dilakukan, maka adaptasi apa pun cenderung bersifat subjektif. Pada saat yang sama, ada kemungkinan kesalahan yang tinggi - misalnya, pengenalan templat proses yang tidak sesuai.

Saya mencoba membahas masalah ini dalam buku Agile Management for Software Engineering yang saya tulis saat itu. Saya bertanya-tanya, "Mengapa pembangunan tangkas menghasilkan hasil ekonomi yang lebih baik daripada pendekatan tradisional?" Saya ingin menerapkan struktur teori kendala untuk tujuan ini. 4
Goldratt, Eliyahu M. Apa ini yang disebut Theory of Constraints dan Bagaimana penerapannya? Great Barrington, MA: Pers Sungai Utara, 1999.

Dalam proses penelitian dan penulisan buku ini, saya menyadari bahwa setiap situasi adalah unik. Dan bagaimana kendala atau hambatan bisa sama untuk setiap tim dan proyek kapan saja? Setiap tim unik: keterampilan, peluang, pengalaman yang berbeda. Setiap proyek berbeda dari yang lain dalam hal anggaran, jadwal, ruang lingkup dan risiko. Organisasi juga berbeda: mereka memiliki rantai nilai yang berbeda dan beroperasi di pasar yang berbeda (Gambar 1.1). Bagi saya, ini bisa memberikan petunjuk untuk memahami penolakan terhadap perubahan. Jika perubahan yang diusulkan dalam metode dan perilaku kerja tidak memberikan, menurut pendapat karyawan, keuntungan yang jelas, maka dia tidak akan menerimanya. Jika perubahan ini tidak mempengaruhi apa yang tim anggap sebagai pembatas atau pencegah, maka tim akan melawan. Dengan kata lain, perubahan yang diusulkan tanpa memperhatikan konteks akan ditolak oleh karyawan yang mengetahui konteks pekerjaan dengan sempurna.

Beras. 1.1. Mengapa Metodologi Pengembangan Generik Salah?

Tampaknya akan lebih baik jika proses baru mulai berkembang, menghilangkan satu demi satu batasan. Ini adalah poin utama dari teori kendala Goldratt. Menyadari bahwa saya masih harus banyak belajar, saya menyadari nilai materi dan bergegas maju dalam mengerjakan naskah. Jelas bagi saya bahwa buku itu tidak memberikan nasihat tentang bagaimana menerapkan ide-ide dalam skala yang lebih besar, juga tidak memberikan banyak bantuan dalam menemukan cara untuk mengelola perubahan.

Pendekatan Goldratt, yang diuraikan dalam , bertujuan untuk menemukan keterbatasan, dan kemudian cara untuk menghilangkannya sehingga tidak lagi menghambat kinerja. Setelah itu, kendala baru muncul, dan siklus berulang. Ini adalah pendekatan berulang yang secara sistematis meningkatkan kinerja dengan mengidentifikasi dan menghilangkan hambatan.

Saya menyadari bahwa Anda dapat menggabungkan pendekatan ini dengan beberapa teknik dari bidang lean manufacturing. Dengan memodelkan alur kerja siklus hidup pengembangan perangkat lunak sebagai aliran nilai dan membuat sistem pelacakan dan visualisasi untuk menangkap perubahan status dari pekerjaan yang muncul "mengalir" melalui sistem, saya dapat mengidentifikasi kendala. Kemampuan untuk mengidentifikasi kendala adalah langkah pertama menuju model yang mendasari TOC. Goldratt telah mengembangkan aplikasi teori ini untuk masalah alur kerja yang menyandang nama kikuk "drum-buffer-rope". Namun, saya menyadari bahwa versi sederhana dari sistem ini dapat diimplementasikan di bidang pengembangan perangkat lunak.

Dalam hal asal, drum-buffer-rope adalah contoh dari kelas solusi yang dikenal sebagai sistem tarik. Seperti yang akan kita lihat di , kanban juga merupakan salah satu contoh dari sistem semacam ini. Efek samping dari sistem tarik adalah bahwa mereka membatasi WIP ke jumlah yang telah ditentukan, mencegah karyawan dari kewalahan. Selain itu, hanya pekerja yang secara langsung menghadapi pembatasan tetap terisi penuh; semua orang harus memiliki waktu luang. Saya menyadari bahwa sistem tarik dapat menyelesaikan kedua masalah yang membuat saya khawatir. Sistem tarik akan memungkinkan saya untuk memperkenalkan perubahan tambahan, yang (saya harap) akan secara signifikan mengurangi resistensi terhadapnya, serta membuatnya lebih mudah untuk mencapai kecepatan optimal. Saya membuat keputusan untuk beralih ke sistem drum-buffer-rope sesegera mungkin. Saya ingin bereksperimen dengan evolusi proses inkremental dan melihat apakah itu memberikan kecepatan yang optimal dan mengurangi resistensi terhadap perubahan.

Kesempatan seperti itu muncul pada musim gugur 2004 di Microsoft, yang dijelaskan secara rinci dalam buku ini dalam analisis contoh.

Dari drum-buffer-rope ke kanban

Solusi drum-buffer-rope di Microsoft telah membuahkan hasil. Perlawanan lemah, kinerja lebih dari tiga kali lipat, waktu tunggu berkurang 90%, dan prediktabilitas meningkat 98%. Pada musim gugur 2005, saya melaporkan hasil yang dicapai pada sebuah konferensi di Barcelona 5
Anderson, David J., dan Dragos Dumitriu, “From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department,” Prosiding TOCICO World Conference, Barcelona, November 2005.

Dan pada musim dingin tahun 2006 dia membuat laporan lagi. Pekerjaan saya menarik perhatian Donald Reinertsen, yang melakukan kunjungan khusus ke kantor saya di Redmond. Dia ingin meyakinkan saya bahwa semuanya sudah siap untuk transisi penuh ke kanban.

Kan-ban - kata Jepang yang secara harfiah diterjemahkan menjadi "papan sinyal". Dalam produksi, papan semacam itu digunakan untuk memvisualisasikan laju produksi yang meningkat, yang memungkinkan lebih banyak produk diproduksi. Karyawan pada setiap tahap proses tidak dapat melanjutkan ke tahap kerja berikutnya sampai sinyal yang sesuai diberikan melalui papan kanban. Meskipun saya tahu tentang keberadaan mekanisme ini, saya tidak yakin bahwa itu berguna atau bahkan layak dalam kaitannya dengan pekerjaan intelektual, terutama pengembangan perangkat lunak. Saya mengerti bahwa kanban memberikan kecepatan yang optimal, tetapi tidak tahu tentang reputasi baiknya sebagai metode untuk mendorong peningkatan proses inkremental. Saya tidak tahu bahwa Taiichi Ohno, salah satu pencipta Sistem Produksi Toyota, berkata, “Dua prinsip utama Sistem Produksi Toyota adalah otomatisasi atau otonomi yang tepat waktu dan dibantu manusia. Alat digunakan untuk mengelola sistem - ini adalah kanban. Dengan kata lain, Kanban sangat penting untuk proses tersebut. kaizen(“perbaikan berkelanjutan”) yang digunakan oleh Toyota. Ini adalah mekanisme yang membuat sistem bekerja. Sekarang, dengan lima tahun pengalaman di belakang saya, saya menerima ini sebagai kebenaran mutlak.

Untungnya, Don membuat alasan yang kuat untuk beralih dari drum-buffer-rope ke kanban. Kedengarannya agak esoteris: sistem kanban memberikan transisi yang lebih mulus dari waktu henti ke kemacetan daripada drum-buffer-rope. Namun, memahami perbedaan ini tidak penting untuk membaca dan memahami buku ini.

Meneliti kembali solusi yang diterapkan oleh Microsoft, saya menyadari bahwa jika kita langsung merasakannya sebagai hasil dari sistem kanban, maka hasilnya akan sama. Saya merasa menarik bahwa dua pendekatan berbeda menghasilkan hasil yang sama. Jadi, karena prosesnya sama, saya tidak merasa berkewajiban untuk melihatnya semata-mata sebagai produk dari sistem drum-buffer-rope.

Saya mulai lebih menyukai istilah "kanban" daripada frasa yang rumit ini. Ini digunakan dalam lean manufacturing (sama seperti Toyota Production System). Tubuh pengetahuan ini telah menerima lebih banyak distribusi dan pengakuan daripada teori kendala. Kanban, meskipun berasal dari Jepang, kurang metaforis daripada gabungan drum, penyangga, dan tali. Kata ini lebih mudah diucapkan, dijelaskan, dan ternyata kemudian, untuk diajarkan dan diterapkan. Di sinilah macet.

Munculnya metode kanban

Pada September 2006, saya meninggalkan Microsoft untuk memimpin pengembangan perangkat lunak di Corbis, sebuah perusahaan penyimpanan foto dan kekayaan intelektual milik pribadi di pusat kota Seattle. Terinspirasi oleh apa yang telah dicapai Microsoft, saya memutuskan untuk menerapkan sistem tarik kanban di Corbis. Di sini juga, hasilnya sangat berhasil, mengarah pada pengembangan sebagian besar konsep yang disajikan dalam buku ini. Ini adalah kumpulan konsep yang diperluas—visualisasi alur kerja, tipe item alur kerja, irama, kelas layanan, pelaporan manajemen khusus, dan analisis aktivitas—yang menentukan metode Kanban.

Dalam buku ini, saya menggambarkan Kanban (huruf besar) sebagai metode perubahan evolusioner menggunakan sistem tarik kanban (huruf kecil), visualisasi, dan alat lain untuk mengkatalisasi pengenalan ide lean ke dalam pengembangan teknologi dan operasi TI. Ini adalah proses evolusioner dan langkah demi langkah. Kanban memungkinkan Anda mencapai pengoptimalan proses berbasis konteks dengan resistensi minimal terhadap perubahan sambil mempertahankan kecepatan optimal untuk semua orang yang terlibat.

Buku David Anderson Kanban mengambil alih dari halaman pertama.

Dengan gambar, grafik dan kesimpulan Biografi singkat David mengungkapkan metodologi Kanban untuk orang aneh manajemen proyek yang cerdas. Manajemen proyek menarik ketika diceritakan secara langsung oleh pengembang langsung metode tersebut.

tentang Penulis

Terdaftar di blog resmi David J Anderson sebagai p Ketua Lean Kanban Inc. Juga dia manajer manajemen dan konsultan sejak tahun 2000-an, pembicara dan pembawa acara konferensi sejak tahun 2005. Untuk pertama kalinya dalam posisi kepemimpinan, dia berada pada tahun 1991, jadi pengalamannya memungkinkan Anda untuk secara jujur membandingkan kanban dan waterfall, agile, scrum, dan metodologi manajemen proyek lainnya.

Dia menciptakan kanban untuk meningkatkan tingkat karya intelektual dan kreatif. Tujuan David adalah untuk memberikan tepat waktu, memenuhi target dan cukup mengelola perusahaan saat ini secara umum.

Dengan menggunakan contoh nyata dari kehidupan Microsoft, Motorola dan Corbis, dia menceritakan dan menunjukkan prinsip, metode dan instruksi untuk menerapkan kanban di sebuah perusahaan.

Muatan semantik dan esensi buku

Buku . Rute alternatif keAgile ditulis oleh orang yang pertama kali menemukan kanban. Bukunya sangat menarik dan informatif. Di sini, garis antara filosofi Kaizen sangat menarik terungkap ( perbaikan terus-menerus), metodologi ( Bersandar) dan Kanban (metode konservasi sumber daya manusia dan material).

Kaizen adalah filosofi dan etika hubungan antara pekerja pabrik dan manajemen.

Manufaktur ramping adalah sistem manajemen proyek yang dibuat di Toyota untuk menghilangkan semua pemborosan waktu dan sumber daya dari proses perusahaan.

Kanbanadalah metode manajemen proyek yang menyediakan cara membatasi secara bersamaan menjalankan tugas. Jika ada batasan pada orang, alat, atau waktu, kanban membantu mendistribusikan tugas dan proyek.

Anderson sangat dipengaruhi oleh teori kendala dalam menulis buku ini. Buku ini penuh dengan batasan WIP, kemacetan, dan kemampuan untuktentukan dengan jujur beban maksimum per satuan waktu, yang menjaga kualitas pada tingkat yang optimal.

Teori Kendala (TOC) Dr. Eliyahu Goldratt adalah metodologi manajemen bisnis manufaktur. Seorang fisikawan Israel mengembangkan teori dan metode praktis untuk mengelola organisasi, algoritma untuk operasi produksi, logistik, dan pemasaran barang. Pendekatan sistematis untuk mengidentifikasi kendala di perusahaan membantu mengatur segalanya. Menurut pengalaman Goldratt, Lebih sering daripada tidak, kebijakan perusahaan menjadi kendala.

Batas WIP (pekerjaan dalam proses) — jumlah tugas yang dapat dibuka pada saat yang sama.

Kemacetan - momen dalam alur kerja ketika ada masalah serius keterbatasan sumber daya atau peluang. Pada diagram, itu benar-benar terlihat seperti leher botol yang sempit: baik sebelum dan sesudah situasi seperti itu, garis melebar pada diagram.

Stereotip tentang kanban

Ketika kita mendengar tentang kanban, kita sering membayangkan papan dengan stiker - stereotip ini dipaksakan kepada kita oleh media. Secara kiasan, ada daftar tugas stiker yang terbuka, berjalan, dan selesai di dinding. . Anda dapat menggunakan dinding dan program virtual untuk mengelola proyek, di mana daftar tugas, prioritas, dan nuansa lainnya akan dimasukkan.

Metodologi kanban di sini tidak akan menjadi papan, dan bukan stiker, tapi proses memantau dan mentransfer tugas di dinding. Dengan aturan apa, siapa dan mengapa memindahkan stiker, berapa banyak stiker yang dapat disimpan di kolom "dilakukan", mengapa membatasi jumlah di kolom ini - ini David di halaman " Kanban. Jalan Alternatif untuk Agile.

Kanban bukan papan lengket, stiker hanyalah indikator beban kerja.

Anderson merancang kanban agar kita tidak memulai proyek baru sampai proyek sebelumnya selesai. Oleh karena itu, untuk satu pengembang, jumlah stiker dipilih - 3-5, misalnya, dan begitu banyak tugas per unit waktu yang dapat dibuka untuknya. Hanya setelah menyelesaikan salah satu tugas, dia dapat mengambil yang baru.

Kita berbicara banyak tentang jam kerja dan harganya, tetapi seringkali tidak menyadari bahwa ada satu jam kerja produktif dan satu jam diambil dari kehidupan. Dan ada seminggu kerja produktif, bidang di mana Anda harus mengambil cuti sakit. David berbicara tentang kecepatan kerja ini ketika setiap jam produktif dan ini adalah kondisi tim yang sehat.

Agile, Scrum dan Kanban

Anderson yakin bahwa metodologi Agile dan Scrum bersifat formula dan kaku. Menurutnya, manajemen proyek harus bersifat individual di setiap perusahaan. Oleh karena itu, Agile dan Scrum dengan algoritme tindakan standarnya sudah ketinggalan zaman, seperti metodologi langkah demi langkah Waterfall klasik. Sebuah kan ban - metodenya begitu khusus perusahaan, yang membuat takut para penganut metodologi fleksibel!

Agile adalah metodologi tangkas yang secara historis pemrograman dimulai dalam format meluncurkan pembaruan ke program setiap beberapa bulan. Pemrograman iterasi beberapa minggu untuk menambahkan setiap fitur mempercepat proses pengembangan dan mengurangi risiko.

Scrum adalah metodologi tangkas lainnya dengan iterasi singkat tetapi lebih banyak kontrol atas proses pemrograman. Ada sprint - periode waktu dengan tugas-tugas tertentu untuk diselesaikan. Mereka sangat terbatas. Ada backlog - daftar tugas secara umum, yang didistribusikan oleh pemilik produk. Itu bukan milik tim pengembangan, tetapi memprioritaskan tugas.

David Anderson

Kanban. Jalan Alternatif untuk Agile

David J Anderson

Perubahan Evolusioner yang Berhasil untuk Bisnis Teknologi Anda

Diterbitkan dengan izin dari Lean Kanban Inc.

Seluruh hak cipta.

Tidak ada bagian dari buku ini yang boleh direproduksi dalam bentuk apapun tanpa izin tertulis dari pemegang hak cipta.

* * *

Didedikasikan untuk Nikola dan Natalie

Kata pengantar

Saya selalu memperhatikan karya David Anderson. Saya bertemu dengannya pada bulan Oktober 2003 ketika dia mengirimi saya bukunya Manajemen Agile untuk Rekayasa Perangkat Lunak: Menerapkan Teori Kendala untuk Hasil Bisnis. Seperti judulnya, buku ini sangat dipengaruhi oleh Theory of Constraints (TOC) Eliyahu Goldratt. Kemudian, pada bulan Maret 2005, saya mengunjungi David di Microsoft, pada saat itu dia bekerja erat dengan diagram alur kumulatif. Bahkan kemudian, pada April 2007, saya berkesempatan mengamati bagaimana terobosan sistem kanban yang dia terapkan di Corbis bekerja.

Saya ingin memperingatkan pembaca tentang beberapa hal. Pertama, jika Anda merasa tahu cara kerja sistem kanban, mungkin yang Anda maksud adalah sistem yang digunakan dalam lean manufacturing. Ide-ide dalam buku ini jauh lebih maju daripada sistem sederhana yang menggunakan batas WIP statis, penjadwalan FIFO, dan satu kelas layanan. Harap perhatikan perbedaan-perbedaan ini.

Memecahkan Dilema Manajer Agile

Dalam kegiatan sehari-hari saya pada tahun 2002 dan dalam buku saya sebelumnya (1), saya terutama memperhatikan dua hal. Pertama, bagaimana melindungi tim dari tuntutan bisnis yang terus meningkat dan mencapai apa yang sekarang disebut “kecepatan optimal” di komunitas tangkas. Dan kedua, bagaimana saya bisa berhasil menerapkan pendekatan tangkas di seluruh organisasi, mengatasi penolakan yang tak terhindarkan terhadap perubahan?

Menemukan kecepatan yang tepat

Pada tahun 2002, komunitas tangkas menganggap kecepatan optimal hanya sebagai "minggu kerja 40 jam" (2). Prinsip-prinsip Agile Manifesto (3) menyatakan bahwa “proses tangkas mendorong perkembangan yang optimal. Sponsor, pengembang, dan pengguna harus siap untuk mempertahankan kecepatan konstan tanpa batas.” Dua tahun sebelumnya, tim saya di Sprint PCS terus mendengar dari saya bahwa "pengembangan perangkat lunak dalam skala besar adalah maraton, bukan sprint." Jika anggota tim harus mempertahankan kecepatan konstan dalam proses mengerjakan proyek satu setengah tahun, maka mereka tidak dapat dibiarkan kehabisan tenaga dalam satu atau dua bulan. Proyek harus direncanakan, dianggarkan, diatur waktunya, dan dievaluasi untuk memastikan bahwa anggota tim menghabiskan cukup banyak waktu untuk bekerja setiap hari dan tidak terlalu lelah. Sebagai seorang manajer, tugas saya adalah untuk mencapai tujuan ini dan memenuhi semua kebutuhan bisnis.

Ketika saya berada di posisi manajerial pertama saya (pada tahun 1991, di sebuah startup yang membuat papan perekam video untuk komputer pribadi dan komputer yang lebih kecil), CEO mengatakan bahwa manajemen memiliki "pendapat yang sangat negatif" tentang saya. Saya selalu menjawab "tidak" ketika peluang kami sebagai pengembang sudah habis, dan semakin banyak produk atau fitur yang dibutuhkan dari kami. Pada tahun 2002, saya telah menjadi kebiasaan: saya menghabiskan sepuluh tahun lagi untuk menolak menuruti keinginan pemilik bisnis.

Tentang buku
Panduan mendalam tentang kanban dari perintis kanban pertama berusia 30 tahun dalam pengembangan perangkat lunak.

David Anderson, yang telah menerapkan metode kanban di beberapa perusahaan dan terus meningkatkannya, menunjukkan cara efektif memperkenalkan ide lean ke dalam pengembangan teknologi dan operasi TI - dengan resistensi minimal terhadap perubahan, sambil mempertahankan kecepatan optimal untuk semua karyawan yang terlibat dalam pekerjaan .

Kanban dengan cepat mengidentifikasi masalah yang memengaruhi kinerja dan memaksa tim untuk fokus menyelesaikannya agar pekerjaan tetap mengalir. Dengan membuat masalah kualitas dan proses terlihat, kanban memberikan kesempatan untuk menilai dampak cacat, kendala, variabilitas, dan biaya ekonomi pada alur kerja dan keluaran karyawan.

Cukup membatasi pekerjaan yang belum selesai melalui kanban menghasilkan peningkatan kualitas dan produktivitas kerja. Kombinasi alur kerja yang disederhanakan dan peningkatan kualitas membantu mengurangi waktu tunggu dan meningkatkan prediktabilitas dan kemungkinan pengiriman pekerjaan tepat waktu. Dengan menetapkan irama rilis reguler dan kepatuhan yang konsisten terhadap jadwal, kanban membantu membangun kepercayaan dengan pelanggan dan anggota lain dari aliran nilai—departemen lain, vendor, dan mitra dependen.

Kanban telah terbukti meningkatkan kepuasan pengguna melalui rilis perangkat lunak berharga yang teratur, andal, dan berkualitas tinggi. Ini juga telah terbukti meningkatkan produktivitas, kualitas dan mengurangi waktu produksi. Ada bukti bahwa kanban dapat menjadi katalis bagi munculnya organisasi yang lebih gesit melalui perubahan budaya evolusioner.

Buku ini menjawab pertanyaan:

- Apa itu kanban?
Mengapa perusahaan Anda membutuhkannya?
- Bagaimana menerapkannya?
- Bagaimana mengenali peluang untuk peningkatan dalam bisnis - dan apa yang harus dilakukan dengannya?

Untuk siapa buku ini?
Untuk manajer dan kepala perusahaan IT.

tentang Penulis
David Anderson adalah pendiri Universitas Lean Kanban dan Sekolah Manajemen David J Anderson, yang didedikasikan untuk membantu para pemimpin dan manajer mencapai hasil yang lebih baik melalui praktik terbaik.

Anderson memiliki 30 tahun pengalaman di perusahaan teknologi. Dia telah memperkenalkan praktik manajemen tangkas ke perusahaan seperti Motorola dan Microsoft.

David adalah orang pertama yang menggunakan kanban dalam pengembangan perangkat lunak pada tahun 2005.

Kanban berarti "papan sinyal" dalam bahasa Jepang. Di bidang manufaktur, papan semacam itu digunakan untuk memvisualisasikan kenaikan tarif, yang memungkinkan Anda menghasilkan lebih banyak produk dengan biaya lebih rendah. Contoh mencolok adalah pendekatan Toyota, berkat itu selama bertahun-tahun prinsip "tepat waktu" telah diterapkan secara efektif dengan biaya minimal.

David Anderson memberikan serangkaian gagasan yang diperluas (visualisasi proses dan aturan kerja, pengetikan item pekerjaan, kelas layanan, irama, metrik, dan bagan untuk akuntansi dan analisis manajemen) yang mendefinisikan metode kanban.

Buku ini menjelaskan alat yang memungkinkan Anda untuk secara efektif memperkenalkan ide lean ke dalam pengembangan teknologi dan operasi TI dengan resistensi minimal terhadap perubahan, sambil mempertahankan kecepatan optimal untuk semua karyawan yang terlibat dalam pekerjaan.

Diterbitkan dalam bahasa Rusia untuk pertama kalinya.

Pemegang hak cipta! Fragmen buku yang disajikan ditempatkan dalam perjanjian dengan distributor konten legal LLC "LitRes" (tidak lebih dari 20% dari teks asli). Jika Anda yakin bahwa pengeposan materi melanggar hak Anda atau orang lain, beri tahu kami.

Yang Paling Segar! Pesan resi hari ini

Wasiat Yvette Blanche
Demange Patricia
terbitan berkala

Suzanne bangkit dari batu dan hendak berjalan kembali ke mobil ketika dia mendengar suara:

- Datang! Datanglah padaku! Datanglah padaku! Datang!

Dan, seperti pertama kali, kata-kata yang berbeda ini diikuti oleh isak tangis yang tidak dapat dipahami. Gadis itu membeku. Suara itu begitu sedih sehingga dia tidak bisa bergerak.

Dan kemudian dia mendengar kata-kata ini lagi:

"Ayo, ayo ... datang padaku!" Datang!

Tiba-tiba Susanna merasa otaknya akan meledak dari kalimat yang satu ini. Selama beberapa menit dia berdiri tak bergerak, tetapi kemudian mengumpulkan kekuatannya dan bergegas ke mobil yang diparkir di bawah pepohonan. Dia dengan cepat memasukkan kunci kontak dan menyalakan mesin. Dia ingin pergi dari sini secepat mungkin. Selama Anda tidak tahu atau mendengar apa pun. Tidak mungkin! Dia hanya Susanna Lambert, Susanna Lambert, Susanna Lambert...
manusia serigala
Penggiling Alexandra
terbitan berkala

Dia mengikuti Julia ke rawa yang paling ... Gadis itu merasakan tatapannya padanya dan mati rasa karena ngeri. Kaki segera mulai tenggelam lebih dalam dan lebih dalam ke rawa dingin. Kita harus keluar dari sini sebelum terlambat! Dia mencoba berbelok ke arah jalan setapak: ini dia, tanah padat, secara harfiah satu meter jauhnya ... Tapi ada sesuatu yang jauh lebih berbahaya daripada rawa busuk yang menunggunya: manusia serigala yang ditutupi wol abu-abu! Sosoknya yang bungkuk tiba-tiba muncul dari kegelapan. Kepala besar itu perlahan bergoyang seiring waktu dengan angin, dan di kedalaman rongga mata, bara mata berkilau merah. Julia melakukan satu upaya terakhir untuk mengatasi ketakutannya sendiri, tetapi kengerian itu melumpuhkannya: dia tidak bisa mengambil langkah. Sementara itu, makhluk menakutkan yang tampak seperti serigala mendekat. Hanya ada beberapa langkah di antara mereka. Sekarang Anda sudah dapat melihat wol abu-abu di cakar monster itu, di sini cakar tajam muncul di bawah sinar bulan ...
Mage-memutuskan. Pembentukan
Nazimov Konstantin
Kejatuhan

Seorang siswa, dia adalah seorang siswa di mana-mana. Hiburan dan upaya untuk menghasilkan. Salah satu hal yang biasa menyebabkan tragedi, dan saya berakhir ... di dunia sihir. Semoga berhasil, saya menyukainya. Mereka bahkan membantu dan ternyata ... seorang siswa, tetapi sudah di akademi sihir dan mulai bekerja.

Tapi hidup mengubah orang dan penyihir seperti yang diinginkannya. Dunia ini tidak mengenal perencana hebat, dengan kemampuannya menghasilkan uang dari udara tipis. Tidak ada yang membangun piramida keuangan. Karena itu, saya bisa berbalik sepenuhnya. Tapi, masalah serius dan penipuan telah hilang. Salah satu idenya ternyata sedemikian rupa sehingga saya dan teman-teman tidak bisa mencerna hasilnya. Saya harus keluar dari jalan saya dan membawa hal-hal ke tingkat yang sama sekali berbeda. Dan sulit untuk menariknya: inilah emas kantong uang dan serikat pencuri, orang biasa dan birokrat. Dan juga masalah dengan artefak dan anak perempuan, hutang kartu dan mobil yang indah. Anda harus memutuskan dengan cepat, bereaksi secara instan. Eh, tapi saya ingin hidup indah dan saya berharap itu akan berhasil, meskipun bukan fakta ...
wanita berbaju putih
Lara abu-abu
Detektif dan Thriller, Thriller

Setiap hari setelah tengah malam sesuatu terjadi di kastil...

Katerina mengerti bahwa hidupnya tergantung pada seutas benang. Dia meraih roknya dengan satu tangan sehingga ujungnya tidak mengganggu larinya, tangan yang lain dijulurkan ke depan agar tidak membenturkan kepalanya ke dinding. Akhirnya sebuah pintu! Gadis itu tiba-tiba membukanya dan berlari keluar dari koridor. Pengejarnya tidak ketinggalan: langkahnya semakin terdengar jelas. Dia bisa menyusul Katerina kapan saja!

- Untuk bantuan! Untuk bantuan! teriak gadis itu. - Seseorang! Membantu!

Dia tersandung batu dan menabrak keras, jatuh ke lantai. Katerina merangkak ke samping dan bersembunyi. Untungnya, hari sudah gelap, dan pengejarnya berlari melewatinya tanpa memperhatikannya. Katerina melihat sekeliling: dia berbaring di ruangan gelap tanpa jendela, tanpa cahaya, tidak ada yang bisa dilihat...
joker balap. Permainan bertahan hidup
Nazimov Konstantin
Fiksi, fiksi heroik

Permainannya tidak seperti yang saya bayangkan. Kebohongan dan pengkhianatan, penyuapan dan bahkan perbudakan berjalan beriringan di sini. Ada pemain normal, yang ada banyak, yang mencoba untuk hidup dengan aturan dan kehormatan. Dan juga terjadi bahwa hitam disajikan sebagai putih, kebohongan untuk kebenaran.

Dengan kehendak pikiran jaringan, tugas dan misi kompleks ditetapkan di hadapan saya, yang bahkan tidak saya duga. Perlombaan untuk eliminasi atau bertahan hidup digantikan oleh pelarian dari pemburu hadiah. Kita harus terlibat dalam pertarungan dengan ketidakadilan dan kekejaman. Untuk meningkatkan kehidupan pemain biasa yang, dalam keluguan dan kenaifannya, mengejar janji dan menemukan diri mereka dalam situasi tanpa harapan. Menjuntai ke dalam permainan dunia tetangga, di mana monster bertemu di setiap belokan, dan tidak menganggap Anda apa-apa selain mangsa mereka. Tanpa semua ini, Anda tidak dapat mencapai garis finis.

Sepanjang permainan, teman dan musuh berdampingan dengan saya, beberapa membantu di masa-masa sulit, yang lain siap untuk menusukkan pisau ke punggung saya, tetapi saya harus mengandalkan diri sendiri dan semoga berhasil. Sebuah tujuan ditetapkan, bensin dituangkan ke dalam tangki, jimat ada di leher, dan kaki menekan pedal gas ke lantai. Kemenangan akan datang dan saya akan mencapai tujuan saya! Semoga saja…
Hantu dari kabut
Penggiling Alexandra
terbitan berkala

Sampai sekarang, Elena tidak mementingkan fakta bahwa pemilik wisma tempat dia tinggal selalu sendirian. Dia berasumsi bahwa istrinya sedang sibuk di dapur, atau sibuk dengan urusan lain dan karena itu tidak muncul di depan para tamu ...

Tetapkan "Minggu" - produk baru teratas - pemimpin untuk minggu ini!

2. Terkutuklah Rektor
musim panas lena
Novel roman, novel fiksi cinta, Fiksi, Fiksi Detektif,

Saya punya waktu satu tahun untuk menyelesaikannya. Satu tahun - dan saya bisa mendapatkan kebebasan dan kemandirian yang saya impikan sejak kecil. Namun, kematian ibu saya yang tiba-tiba dan sangat mencurigakan membuat dunia saya terbalik. Dia meninggalkan banyak pertanyaan, dan satu-satunya kesempatan untuk menemukan jawaban adalah pergi ke universitas paling elit di Republik. Saya berpikir bahwa keangkuhan teman sekelas baru akan menjadi masalah utama saya, tetapi saya salah. Jawaban-jawaban yang saya cari mungkin akan merenggut nyawa saya, dan untuk beberapa alasan saya sekarang lebih peduli dengan kehidupan rektor setempat, yang berada di bawah kutukan.
Akademi Arcturus. pengantin serigala
jeruk nipis sylvia
Fiksi, Fiksi Humoris

Terkadang pengkhianatan bukanlah akhir, tapi awal.

Kadang-kadang - ini adalah pintu ke dunia lain, di mana perang berada di ambang pintu. Di mana manusia serigala bertarung sampai mati untuk wanita dan pria mereka memuat senjata dengan peluru perak. Di mana seorang pembunuh misterius berkeliaran, menggerogoti tenggorokan semua orang yang sangat mirip denganmu. Di mana senyum yang baik hati adalah kesempatan pasti untuk jatuh ke dalam perangkap, dan serigala yang menggeram di belakang punggung Anda adalah kesempatan untuk melarikan diri.

Bersiaplah, akademi manusia serigala sedang menunggumu di sini, seorang maniak di luar pintu dan seorang pria misterius yang, untuk beberapa alasan, memutuskan bahwa dia bisa datang kepadamu di malam hari.

Dan semua karena pengkhianatan bukanlah akhir, tetapi hanya permulaan.
Akademi Arcturus 2. Istri serigala
jeruk nipis sylvia
Fantasi, Cyberpunk

Mereka mengatakan bahwa hidup dan kepercayaan hilang hanya sekali. Dulu saya beruntung, tetapi tidak mungkin keberuntungan ditakdirkan untuk terulang kembali. Maniak yang membunuh gadis-gadis itu ditemukan, tetapi dalang masih menarik tali bonekanya. Kematian mengikuti tanpa henti, dan aku harus selangkah lebih maju. Kali ini, untuk menyelamatkan tidak hanya dirinya sendiri, tetapi juga manusia serigala, yang dengannya dia terhubung oleh ikatan yang tidak bisa dipecahkan. Dia lebih kuat dari yang lain, dan ini adalah kelemahannya. Untuk membuatnya tetap hidup, aku harus mengkhianatinya. Atau ada jalan keluar lain?

Portal untuk siswa. Latihan mandiri

* * *

Kata pengantar

Bagian I Dasar-dasar

Bab 1 Memecahkan Dilema Manajer Agile

Menemukan kecepatan yang tepat

Mencari Manajemen Perubahan yang Berhasil

Dari drum-buffer-rope ke kanban

Munculnya metode kanban

tentang Penulis

Dengan menggunakan contoh nyata dari kehidupan Microsoft, Motorola dan Corbis, dia menceritakan dan menunjukkan prinsip, metode dan instruksi untuk menerapkan kanban di sebuah perusahaan.

Muatan semantik dan esensi buku

Kaizen adalah filosofi dan etika hubungan antara pekerja pabrik dan manajemen.

Manufaktur ramping adalah sistem manajemen proyek yang dibuat di Toyota untuk menghilangkan semua pemborosan waktu dan sumber daya dari proses perusahaan.

Batas WIP (pekerjaan dalam proses) — jumlah tugas yang dapat dibuka pada saat yang sama.

Kemacetan - momen dalam alur kerja ketika ada masalah serius keterbatasan sumber daya atau peluang. Pada diagram, itu benar-benar terlihat seperti leher botol yang sempit: baik sebelum dan sesudah situasi seperti itu, garis melebar pada diagram.

Stereotip tentang kanban

Kanban bukan papan lengket, stiker hanyalah indikator beban kerja.

Agile, Scrum dan Kanban

Agile adalah metodologi tangkas yang secara historis pemrograman dimulai dalam format meluncurkan pembaruan ke program setiap beberapa bulan. Pemrograman iterasi beberapa minggu untuk menambahkan setiap fitur mempercepat proses pengembangan dan mengurangi risiko.

Buku ini menjawab pertanyaan:

Yang Paling Segar! Pesan resi hari ini

Tetapkan "Minggu" - produk baru teratas - pemimpin untuk minggu ini!

ARTIKEL TERKAIT

Bagian I
Dasar-dasar

Bab 1
Memecahkan Dilema Manajer Agile