Istilah "kaizen" diperkenalkan oleh Toyota, dan banyak yang telah ditulis tentangnya dalam buku-buku tebal dari seri Toyota Tao.
Kaizen juga disebut "proses perbaikan berkelanjutan." Biasanya itu terkait dengan produksi industri mobil dan konveyor, baik, atau setidaknya dengan kontrol proses. Mereka mengatakan sedikit tentang pengembangan, tetapi kaizen sangat cocok untuk pengembangan perangkat lunak.
Selanjutnya, Anda akan belajar tentang beberapa kasus yang secara bertahap membuat penulis memahami kaizen dalam pengembangan.
Serangkaian masalah
Kasus pertama terjadi tepat pada Tahun Baru, pukul 20:00. Hard drive jatuh di server dan karena itu perlu melepaskan diri dari persiapan salad dan segera pergi ke Moskow ke situs pertukaran lalu lintas untuk mengubah perangkat yang rusak.
Setelah hard drive, motherboard terbakar. Mereka mengubah segalanya, tetapi kemudian memutuskan untuk mencari tahu mengapa ini terjadi.
Admin yang familier memperjelas bahwa Anda harus sangat berhati-hati dengan perangkat keras server, untuk tidak membeli di mana saja dan memesan semua dan di setiap level.
Diputuskan untuk mengubah server dan sangat berhati-hati dalam memilih penyedia. Kami melihat perangkat keras server, meminta rekomendasi, dan memilih server yang kemudian bekerja tanpa henti dan tanpa gangguan selama 7 tahun. Dia terus bekerja sekarang, meskipun 5 tahun telah berlalu sejak penulis meninggalkan pekerjaan itu.
Beberapa waktu berlalu dan kebakaran terjadi di lokasi. Server secara ajaib selamat. Kemudian semua orang bergetar dengan baik, karena ada risiko kehancuran total bisnis.
Setelah itu, cermin situs dan basis data dibuat pada situs terpisah yang sepenuhnya independen di ujung lain kota. Dan bahkan dia pernah digunakan.
Ada juga kasus ketika lalu lintas dimulai di situs yang baru saja diluncurkan, dan tiba-tiba itu benar-benar berhenti, tidak bisa menahan beban.
Setelah penelitian, menjadi jelas bahwa perusahaan outsourcing yang menciptakan situs membuatnya sehingga tidak dapat menampung lebih dari 200 orang per hari. Lucu dan sedih.
Setelah itu, diputuskan untuk meninggalkan outsourcing dan membentuk tim pengembangan Anda sendiri.
Setelah membuat tim, kami punya satu masalah lagi - koreksi setiap kesalahan menyebabkan longsoran kesalahan baru. Perubahan apa pun hampir membuat seluruh situs kewalahan.
Setiap perbaikan memerlukan masalah yang sangat, sangat banyak. Ketika kami menganalisis situasi, kami menyadari bahwa kami perlu mengubah segalanya secara umum secara umum - semua bagian dalamnya. Dan kemudian seluruh situs sepenuhnya di-refactored, seluruh arsitekturnya terbalik. Dan hanya setelah itu situasinya berubah secara radikal dan masalahnya hilang sama sekali.
Hilangkan Root Roots
Semua solusi ini disatukan oleh satu hal - semuanya ditujukan untuk memastikan bahwa masalah mendasar yang mendasari mereka tidak pernah muncul lagi, sehingga sepenuhnya dihilangkan. Dari kata sama sekali. Dan agar masalah yang sama tidak akan terulang lagi.
Apakah kamu mengerti
Dasar: komputer macet - kami menyadari bahwa kami harus memilih perangkat keras yang tepat, yang tidak akan pernah gagal.
Situs terbakar - mereka membuat salinan untuk mengecualikan terjadinya situasi serupa di masa depan.
Kemudian kata-kata itu tidak tahu hal seperti itu - kaizen.
5 mengapa
Tidak selalu akar penyebab masalahnya terletak di permukaan, terkadang Anda harus menggali ke dalamnya.
Contoh yang baik diberikan dalam salah satu buku Tao Toyota. Di pabrik, ditemukan bahwa salah satu mesin menganggur untuk sejumlah besar waktu sepanjang hari.
Kenapa dia harus istirahat dalam pekerjaan? Ternyata mesin berhenti untuk dibersihkan.
Di sekitar mesin ada keripik dan kotoran. Tentu, jika ada serutan di sekitar, maka itu harus dihilangkan, jika tidak tidak mungkin untuk bekerja. Apakah itu benar?
Tetapi kaizen mengatakan: Anda harus menggali akar masalahnya.
Mengapa chip jatuh? Jawabannya datang segera: chip ditumpuk karena mereka tidak ke mana-mana - mesin tidak memiliki perangkat yang akan memungkinkan untuk dihapus dan dikumpulkan. Jika ada perangkat seperti itu, maka mesin tidak harus dihentikan.
Kalau begitu, mari kita datang dengan solusi yang akan memungkinkan chip ini dikeluarkan dari mesin dan membuatnya agar tidak berhenti untuk membersihkan sama sekali. Solusi ini sudah murni teknis dan sangat sederhana.
Ada teknik yang sangat sederhana untuk menentukan akar penyebabnya: metode “5 mengapa” yang terkenal.
Kaizen menyarankan untuk menggunakannya untuk sampai ke bagian bawah penyebab root.
Pertimbangkan penyebab masalah secara konsisten, satu demi satu:
- Mengapa mesin berhenti? Karena pembersihan sudah dilakukan.
- Mengapa pembersihan dilakukan? Karena serpihan dan kotoran beterbangan dari mesin.
- Mengapa keripik dan kotoran terbang? Karena mereka tidak beranjak dari mesin.
Dengan bantuan "5 alasan" kami menemukan akar permasalahan, menghasilkan solusi untuk menghilangkannya, menetapkan orang yang bertanggung jawab dan tenggat waktu, dan memeriksa hasilnya setiap minggu.
Perlu diingat bahwa masalah apa pun dapat diselesaikan dengan cara mahal dan murah.
Kaizen mengatakan: pertama-tama pilih cara termurah. Ini biasanya yang paling sederhana dan terbaik.
Kaizen dalam pengembangan perangkat lunak
Dan sekarang beberapa contoh terbaru dari kehidupan tim pengembangan perangkat lunak.
Pekerjaan Feil
Tim ini menyebarkan praktik terbaik mereka di Prod dengan meluncurkan Jenkins. Faktanya, Jenkins adalah sheduler seperti crontab yang dapat menjalankan pekerjaan yang dijadwalkan. Dan tim memiliki pekerjaan seperti itu.
Begitu diketahui bahwa Prod-Jobs turun 5 kali berturut-turut dengan status Gagal. Dan tidak ada yang memperhatikan mereka, terlepas dari kenyataan bahwa, pada kenyataannya, setiap file pada Prod harus menjadi alarm universal.
Kemudian mereka mulai mencari tahu alasannya menggunakan metode "5 mengapa":
- Mengapa para pekerja membalik 5 kali dan tidak ada yang memperhatikan? Karena semua orang terus-menerus menerima pemberitahuan tentang pekerjaan kasar, ada banyak dari mereka, dan mereka menjadi akrab
- Mengapa mereka menjadi akrab? Karena hampir setiap hari kami menerima semacam pemberitahuan, gagal dan tidak gagal. Kami tidak melihat perbedaannya. Mereka hanya tidak memperhatikan mereka.
- Mengapa pemberitahuan datang setiap hari? Karena salah satu pengembang sedang menguji pekerjaan baru yang jatuh, dan pemberitahuan tentang hal itu pergi ke semua orang. Pekerjaan tidak penting saat ini, jadi semua orang berhenti memperhatikan pemberitahuan darinya dan, pada saat yang sama, dari semua pekerjaan lain.
Keputusan itu transparan: untuk pekerjaan uji, pemberitahuan tentang file tidak akan dikirim kepada siapa pun kecuali pemilik pekerjaan, dan bahkan jika ia membutuhkannya.
Plus, secara resmi dicatat bahwa setiap pemberitahuan dari pekerjaan adalah keadaan darurat yang luar biasa, yang harus ditanggapi semua orang.
Skrip jatuh
Contoh kedua adalah masalah dengan aplikasi QlikView.
Suatu ketika tim diberitahu bahwa laporan QlikView mereka agak berbeda. Semuanya tampak berfungsi, tetapi datanya tidak sama. Mereka mulai memahami masalahnya.
Ternyata skrip unduhan tidak berfungsi sampai akhir. Mengapa tidak berhasil sampai akhir? Karena ada banyak kode dalam skrip dan di suatu tempat di tengah ada operator debugging Exit Script - mereka hanya lupa untuk menghapusnya, tidak menyadarinya. Situasi berubah ketika skrip unduhan jatuh, dan data yang digunakan sudah tua.
Kenapa kamu tidak memperhatikan ini? Karena pengujian tidak menunjukkan ini karena arsitekturnya. Aplikasi ini dibagi menjadi dua bagian independen (skrip belakang / unduh dan depan), dan sebagainya. ada banyak data, mereka mencoba untuk tidak me-restart mereka lagi, agar tidak kehilangan banyak waktu dalam hal ini.
Itu dibuat khusus sehingga bagian depan tidak terhubung dengan skrip memuat. Dia hanya mengambil file data tertentu dan menunjukkannya. Tidak jelas apakah file data ini sudah tua, artinya, tidak mungkin untuk menentukan adanya kesalahan di dalamnya.
Apa yang diciptakan untuk menghindari situasi serupa di masa depan?
Tim bertanya pada diri sendiri pertanyaan: bagaimana memastikan untuk melihat situasi seperti itu di masa depan? Bagaimana memperjelas bahwa skrip unduhan tidak berfungsi sampai akhir?
Diputuskan untuk mendaftarkan label pada awal skrip, dan pada akhirnya menghapusnya. Yaitu jika label tidak dihapus, ini berarti bahwa skrip tidak menyelesaikan unduhan hingga akhir. Bagian depan memeriksa bahwa, jika ada tag, itu akan menampilkan spanduk merah di lantai halaman dengan pemberitahuan tentang masalah tersebut.
Jadi, meskipun kemungkinan munculnya masalah-masalah seperti itu tidak sepenuhnya dikesampingkan, setidaknya hal itu segera diketahui tentang mereka. Solusi sederhana murah.
Kehilangan Data saat Reboot
Layanan pemantauan web menerima data dari kios industri. Secara berkala, itu harus diselesaikan dan diperbaiki, dan setiap koreksi memerlukan reboot. Meskipun reboot berlangsung beberapa detik, pada saat itu data industri dan jurang bisa dijamin. Tidak mungkin kehilangan mereka, jadi tim memutuskan untuk menganalisis masalahnya lebih dalam.
Pertanyaan "5 mengapa" memperjelas bahwa akar penyebab masalahnya adalah arsitektur - itu yang tidak memungkinkan untuk melakukan sebaliknya. Tidak peduli seberapa memperketat layanan, tidak peduli apa yang mereka lakukan dengan itu, semua sama, semuanya turun ke reboot.
Arsitektur baru memecahkan masalah sekali dan untuk semua - layanan ini dibagi menjadi dua bagian independen, penerimaan data dan pemrosesan. Bagian-bagian ini dipisahkan secara fisik, mis. Anda bisa mematikan handler dengan aman, dan saat menerima data terus bekerja dan menyimpan semua yang datang kepadanya. Dan yang paling penting, penerima data dibuat agar tidak perlu reboot. Handler dapat dimatikan dengan aman, dimodifikasi dan kelebihan tanpa khawatir tentang fakta bahwa data bisa hilang.
DevOps tampaknya ada di sana, tetapi sepertinya tidak ada
DevOps adalah hal yang ajaib. Tampaknya ada di sana, tetapi pada saat yang sama juga terjadi bahwa itu tidak ada.
Salah satu pengembang memposting praktik terbaiknya di bangku tes. Terlepas dari kenyataan bahwa ia menggunakan DevOps, “tiba-tiba” ternyata bangku tes terhubung ke basis data tempur. Sebagian dari data itu hilang dan tidak dapat diperbaiki lagi.
Kami mulai mencari tahu. Ternyata pengembang tidak menyadari bahwa ia menggunakan string pertempuran koneksi.
Alasan dasarnya adalah bahwa pengembang harus mengubah string koneksi secara manual untuk dudukan dan server yang berbeda.
Apa kata kaizen? Benar! Kita harus datang dengan solusi seperti itu untuk sepenuhnya menghilangkan masalah, mis. hapus kebutuhan untuk mengubah saluran secara manual.
Dan solusinya diimplementasikan - string koneksi mulai dipilih secara otomatis tergantung pada server yang menjalankannya. Masalahnya diselesaikan sekali dan untuk semua.
Saya pikir Anda sendiri sudah memahami dari contoh-contoh di atas bahwa esensi perbaikan terus-menerus dapat diungkapkan dalam satu ungkapan sederhana - untuk sepenuhnya menghilangkan kemunculan kembali masalah.
Hasil utama - bagian integral dari kaizen
Hasil kaizen adalah realisasi, bukan ide.
Untuk menemukan solusi tidak begitu sulit, jauh lebih sulit untuk mengimplementasikannya.
Untuk setiap keputusan yang dibuat, penting untuk memberikan hasil utama, yaitu memahami siapa yang perlu melakukan apa dan pada tanggal berapa.
Bagaimana Anda memahami bahwa Anda telah mencapai hasil yang sukses?
Mari kita ambil contoh dengan string koneksi. Hasil
materi apa
yang akan dianggap sukses di sini? Sukses akan dicapai ketika:
- perpustakaan akan dibuat untuk secara otomatis memilih string koneksi,
- pengembang akan membangun perpustakaan untuk dirinya sendiri dan berhasil meluncurkan perangkat lunaknya.
Kedua langkah harus diambil pada tanggal tertentu oleh orang-orang tertentu. Hanya dengan kedua langkah kita dapat mengasumsikan bahwa kesuksesan telah dicapai.
Hasil utama adalah kriteria keberhasilan, kaizen tidak bekerja tanpa mereka. Keberhasilan adalah implementasi.
Hanya solusi yang diimplementasikan yang akan memungkinkan Anda untuk menghilangkan masalah di masa depan, oleh karena itu ketika berbicara tentang kaizen selalu berarti bahwa Anda harus mengimplementasikan semua yang ditemukan.
Di mana lagi ini bisa diterapkan
Seperti yang mungkin Anda lihat dari contoh, kaizen dapat dan harus digunakan dalam analisis kejadian. Sebenarnya, dia diciptakan untuk ini.
Insiden dalam kelompok dukungan teknis, infrastruktur, dan pengembangan produk sangat sempurna.
Adapun pengkodean, di sini Anda dapat menganalisis kode Anda dan melihat bagaimana itu dapat diubah untuk secara permanen menghapus masalah yang ditemukan.
Ya, dan Agile retro yang sangat terkenal juga kaizen, karena pada pertemuan ini masalah dianalisis untuk sprint, pertanyaan diajukan "5 mengapa", dan langkah-langkah diambil untuk mencegah masalah. Kaizen paling alami!
Teknik kaizen itu sendiri berfungsi dengan baik dalam pengembangan perangkat lunak, sangat mudah digunakan dan cocok untuk digunakan dalam masalah pribadi.
Rahasia kesuksesan itu sederhana: menghilangkan masalah satu per satu dan kemudian mereka tidak akan bertahan sama sekali. Ini adalah peningkatan berkelanjutan.
Toyota sendiri menggunakan kaizen dalam produksi dengan kesuksesan luar biasa. Hasilnya berbicara sendiri: cacat produksi hanya 3 cacat per 1.000.000 bagian.
Mengapa tidak menerapkannya sendiri?
Sekarang Anda secara resmi dipompa. Jika Anda mendengar istilah seperti itu, Anda akan tahu apa itu.
Dan sukses dalam pekerjaan Anda.