看板 — Signboard
Kanban (看板) Japonca. Karakterler şu şekilde ayrılabilir: 看 (kan), izlemek, görmek ve 板 (ban): tabla, kütük, işaret. Birlikte: bir görsel sinyal panosu.
Söz, yönetim sistemi tarafından yüzyıllar önce kullanılmıştır. Edo dönemi Japonya'sında her dükkân kanban'a sahipti: Dışı satılan şeyleri açıklayan bir ahşap işaret taşı. Görsel sinyal, reklam, stok göstergesi ve yeniden sipariş etme tetikleyiciydi.
Taiichi Ohno'nun Süpermarket Fikri
1950'lerde Toyota mühendisi Taiichi Ohno, Amerikan süpermarketlerini ziyaret etti. Gördüğü şey, üretim tarihi değiştirdi.
Geleneksel bir fabrikada, push modeli, üretim bir takvim üzerinde çalışır. Bir öngörü, "bir ay içinde 500 birimi ihtiyacımız olacak" dedi, o zaman fabrika 500 birimi üretti ve bunları bir rafla paylaştı. Talebin yanlış olması durumunda, raf dolacak. Talebin öngörüden daha fazla olması durumunda, raf boş olacak. Her iki durumda da, yanlış biri var.
Süpermarketler farklı bir şekilde çalışıyordu. Her ürün için rafın sabit bir miktarı vardı. Sonuncu badem ezmesi kavanozunu alan müşteri için boş kutu, yeniden sipariş etme sinyaliydi. Çalışanlara bir yönetici söylemesi gerekmiyordu: raf onlara söyledi. Bu, çek modelidir: downstream talepler upstream yenileme sinyali sağlar.
Ohno, bu fikri Toyota'ya geri getirdi. Parça kutusunun (Kanban) bağlantılı olduğu fiziksel kart (kanban), "bu kutu boş: daha fazla üret" sinyali oldu. Hiçbir öngörüye ihtiyaç yoktu. Çalışma kendiliğinden ilerledi.
Push vs. Çek
Push/çek ayrımı, takip eden her şeyin temeli olarak kabul edilir.
Sütunlar olarak Durumlar
Bir kanban paneli işleri görünür kılar. Her iş parçası da bir karttır. Kartlar, durumları temsil eden sola doğru hareket eden sütunlar boyunca ilerler.
Klasik sütunlar: Arka Plan → Seçilmiş → İn Tasar → İnceleme → Tamamlandı
Ancak tam olarak ne kadar sütun önemli değil. Önemli olan her kartın şu anda tam olarak bir durumu olması ve bu sisteme çalışan herkesin bu durumu görebilmesi.
Bir kart ne temsil eder
Bir kart, bağımsız olarak tamamlanabilen bir iş parçicası temsil eder. Bir proje değil. Bir hedef değil. Net bir tamamlanma definisi olan belirli, kapsamlı bir şey.
İyi kart: Üretim sunucularında SSH anahtarlarını döndürmek: yeni anahtarın tüm sunucularda authorized_keys'te görüldüğü ve eski anahtarın kaldırıldığı zaman tamamlanmış.
Kötü kart: Güvenliği iyileştir. (Bu, bir görev değil, bir proje. Bölünmelidir.)
Çalışma limiti
İn Tasar sütununda bir WIP limiti gösterilmektedir: 3. Bu, aynı anda aynı anda 3 kartın İn Tasar'da olmasını sağlar. Eğer dördüncü bir kart çekmek isterseniz, birini tamamlamalısınız.
Bu, bir kısıtlama gibi hissedebilirsiniz. O gerçekten: tasarlanmıştır. WIP limitleri, başladığınız şeyi bitirmeden yeni bir şey başlamanızı zorla. Daha fazla ayrıntı daha sonra bir bölümde.
Çalışma Kartlarını Sınırlama
Kanban'da en zor beceri paneli çizmek değil. Çalışma kartlarını sınırlama. Çok büyükse, haftalar süren İn Tasar'da bekler ve diğer işleri engeller. Çok küçükse, panel doldurulur.
Silolar İşler İcin İyi İşler
Çok disiplinli bir operasyona sahip olan her şey fonksiyonel çalışma merkezine sahiptir: bir pastanede pastırmalı, ekmekli, tuzlu ve ön sayfa bulunmaktadır. Bir ürün studiyosunda tasarım, içerik, inşaa ve operasyon bulunmaktadır. Bir inşaat projesinde çatı, su, elektrik ve tamamlama bulunmaktadır. Bu merkezler, derinlemesine uzmanlaşmanın odaklanmış sahiplik gerektiği için iyi nedenlerle mevcuttur.
Kanban, bu bölümleri görünür ve açık hale getirir.
The handoff card
Bir iş birimi çalışmanın bir bölümü diğer çalışma merkezine geçtiği zaman, örneğin, bir tasarım varlığı yazım yapmadan önce sayfa oluşturucuların inşa edilebilmesi için, bir elde etme kartı ile birlikte hareket eder. Aşama merkezine göre, Backlog'larında bu kartı görünürler. Kapasiteye sahip olduklarında çekmeleri gerekir. Gerekli e-posta yok. Koordinasyonu sağlamak için bir toplantı gerekmiyor. Kart, sinyaldir.
Diagramda gösterilenler
★ bilet, Tasarım merkezinde (İnşaat: görsel varlıklar) başlayarak, Tasarım'ın kısmını tamamladığında, bir elde etme kartı oluşturulur ve ★ bilet Build merkezinin Backlog'ında görünür. Build çekti. Ardından, Ops çekti. Her merkez kendi paneline sahiptir. Her panel, sadece o merkezin şu anda çalıştığındaki alanı gösterir. Ama ★, tümünde geçiş yapar ve herkes nerede olduğunu görebilir.
Bu, organizasyonlara uygulanan süpermarket ilkesidir: her çalışma merkezi, bir raflardır. Kartlar, sadece tüketildi ve çekildiğinde, daha düşük seviyede rafları yeniden doldurur.
Elde etme tasarımı
Elde etme kartı, çalışma merkezleri arasındaki sözleşmedir. Alıcı ekibe yeterli bağlamı içermelidir, bir toplantıya ihtiyaç duymadan harekete geçirmeli.
Durdurmak Başlamadan Önce Başlatmak.
YAP, Çalışma Halinde İşler'in kısaltmasıdır. Bir sütun aynı anda birden fazla kartta bulunabilecek maksimum sayıya WIP limiti denir.
Kısıtlama gibi görünüyor. O da tam olarak amaçdır.
Neden sınırlar yardımcı olur
Herhangi bir yeni görevi başlatırken önceki işi bitirmeden, bağlam değiştirme vergisi ödemiş olursunuz. Zihniniz yeni görevin bağlamını yükler ve eski bağlamı kısmen boşaltır. Eski görevine geri döndüğünde, bağlamı yeniden yüklemeniz gerekir. Bilgi çalışması için, yazma, hata ayıklama, tasarım, gözden geçirme vb. için bu yükleme maliyeti saatlerle ölçülür, değil mi?
Yapım aşamasında yarı bitmiş işlerin birikmesini önleyen WIP limitleri, daha değerli bir şeyi da gerçekleştirir: engelleri ortaya çıkarır.
Engeller görünür hale gelir
Eğer Review sütunu 2'lilik WIP limitine sahip ve her zaman 2'de kalıyor, bu bir sinyaldir: inceleme, üretimden daha yavaştır. Daha fazla iş Tamamlandı column'da tamamlanırken, Review tarafından tüketilemeyebilir. WIP limiti olmadan, board 'un 'tamam ama incelemeyi bekleyen' kartlarla dolup taşır ve engelin görünmez olduğu yerdir. WIP limiti ile Active column yeni kartlar alamaz ve tüm takım kısıtlamayı görür.
Bu, bir başarısızlıktir. Bu, bir bilgi demektir. Sistem size Review'ü düzeltmeye, işe almayı yapmaya, eşleştirme yapmaya, lot boyutunu azaltmaya, daha fazla iş akışını artırarak göz ardı etmeye zorlamanız gerektiğini söylüyor.
Little's Law (görsel)
Süre (bir kartın baştan tamamlanması için geçen süre) = İşbirliği İçinde Beğeni (tamamlanan kartlar başına birim zaman) ÷ Throughput (tamamlanan kartlar). Eğer kısa süreli süreler işe almadan hiring yapmak isterseniz, WIP'yi azaltın. Az sayıda şeyin uçup gitmesi, her şeyin daha hızlı tamamlanması anlamına gelir.
R = (W × C) + T
WIP limitleri, üç değişkeni korur. 1986'da efficiency danışmanı Brian Tracy, onları adlandırdı.
R = (W × C) + T
- R: Sonuç: istediğiniz sonuç
- W: Hedefin netliği: istediğiniz neyin ne kadar net bilginiz (0-10)
- C: Konsantrasyon: odaklanmış çaba (0-10)
- T: Aralıklı saatler
Neden W ve C çarpılır
Hedefin netliği ve konsantrasyon bağımsız değildir. Belirsiz bir hedefe yüksek konsantrasyonla hızlı bir şekilde yanlış yönde hareket eder. Tam hedef netliği ve hiç konsantrasyon üretmez. Onlar etkileşir: bu yüzden Tracy'yi bir ürün olarak değil, bir toplam olarak yazdı. Her birinde 9/10 verirse R = 81 + T. Her birinde 3/10 verirse R = 9 + T. Fark artımsal değildir.
Neden T eklenir
Her aralıklı saat, sonucun üzerine doğrusal olarak eklenir. T, W ve C'nin karmaşıklaşmasına katkıda bulunamaz: sadece ürün üzerine sıralı olarak eklenir. Bu, daha uzun saat çalışmanın, düşük (W × C) ürünü üzerinde W ve C'yi iyileştirmeye öncelikle neden olduğu açıklar.
Kanban board'unun her değişken üzerinde yaptığı şey
- W: İyi bir kart (net başlık, ölçülebilir kabul kriterleri, tek sahibi) işe başlamadan önce W'yi yükseltir. Belirsiz kartlar otomatik olarak W'yi düşürür.
- C: WIP limitleri konsantrasyonu zorlar. Active'de tek bir kartla tam odaklanma. Active'de üç kartla C üç eşit parçaya bölünür.
- T: Pomodoro blokları & takvim koruma, T'nin arınmış saatlerini oluşturur. Zamanlayıcı sadece süslemeye değil, T'yi gerçek zamanlı olarak takip eder.
Tracy'nin, W, C ve T'nin tamamının optimize edildiği zaman herhangi bir sorunun 30 dakikada çözülebileceğini iddia etti. Kanban paneli, aynı anda üçünü de optimize etmek için kullanılan bir araçtır.
Panel Okuma
Panel durumundan akışkanlık okuma alışkanlığı edin.
Agile değil. Su Düşen Akıntı değil.
Agile bir metodoloji. Su Düşen Akıntı bir metodoloji. Kanban bir sistemdir.
Metodolojiler size nasıl çalışmanız gerektiğini söyler. Sistemler, çalışma hakkında neyin doğru olduğunu anlatır. Kanban, iki haftalık sınırlar, günlük toplantılar veya geri bildirim oturumları yapmanızı söylemez. Çalışmanın görünür olmasını, WIP'yi sınırlayın ve çekin sağlar.
Metodolojilerin problemleri
Agile, ürünlerin iteratif olarak geliştirildiği takımalar için iyi çalışır, genellikle yazılım. Su damlası modeli, belirsiz gereksinimlere sahip ve bilinen bilinmeyenleri içeren projeler için iyi çalışır, inşaat, donanım üretimi. Bu iki model de, tasarım görevi ve gerçekleştirme görevinin tamamen farklı döngü sürelerine ve 'tamam' kavramına sahip olan çok disiplinli çalışmalar için doğrudan bir eşleşme sağlamamaktadır.
Bir tasarım merkezini ve bir operasyon merkezini aynı sprint ritmine zorlaştırmak, bir kategorik hatadır. İçerik yaratma için çalışan iki haftalık bir sprint, lojistik çalışmalar için yapay acelecilik yaratır. Bir araya gelen takımlar için inşa edilmiş bir stand-up ritüeli, bağımsız sololar için koordinasyon overheadı yaratır.
Çalışmanın ortak zemini bulma
Un yaklaşımı: Yapılacak işi belirleyin. İşin yapılabilirliğini en iyi şekilde sağlayan kişileri veya ortakları bulun. O iş üzerinde bir süreç dayatmayın: İşin kendi süreçlerini paylaşabilen bir ortak görünüm sistemiyle işin kendi süreçlerini ortaya çıkarmaya izin verin.
Bu, süreç eksikliğidir. Koordinasyon sağlamak için yeterli süreç: İşin değerinden daha fazla koordinasyon overheadı yaratacak kadar süreç yaratmayın.
Yapmazsanız satın alabileceğiniz şeyi yapmayın. Satın alabileceğiniz şeyi büyütemeyebilirsiniz.
Herhangi bir çalışma kartı oluşturmadan önce: Bu gerçekten var olması gerektiği konusunda karar verin. Herhangi bir şey inşa ettiğinizde, sürekli olarak sahip olacaksınız. Herhangi bir SaaS abone olduğunuzda, sürekli olarak üzerinde bulunacaksınız. Herhangi bir açık kaynak bağımlılığı kullandığınızda, sürekli olarak koruyacaksınız.
Karar ağacı: Bu işi büyütebiliriz mi? Sürdürülebilir bir yetenekte olan süreç, yetenekler, ilişkiler, bu seçeneği tercih edin. Büyümeyi mümkün kılmayan durumlarda: Bu işi satın alabiliriz mi? Problemi %80 çözen off-the-shelf bir araç, bu seçeneği tercih edin. Satın almayı mümkün kılmayan durumlarda: Yapın. Ve şimdi sürekli olarak sahip olduğunuz bir şey inşa ettiğinizden bilgili olun.
Çoğu organizasyon bu sırayı tersine getirir. Sorunları iyi çözen ticari araçlar için özel altyapı inşa ederler ve sonra da sürdürmeyi başarmaya çalışırlar. Kanban, geri listelerinizdeki her kartın, inşa ettiğiniz şeyleri seçtiğiniz anlamına gelmesi açısından bu görünür kılar. Onu gerçekten geri listede olması gerektiği konusunda dürüst bir soru sormanız gerekiyor.
Yap / Al / Büyü
Karar çerçevesini uygulayın.
Bir Panel Tasarla
Bir araya getirin. Belirli bir çapraz işlevsel senaryo için bir kanban sistemi tasarıyorsunuz.
Senaryo
Küçük bir stüdyo, ürünlerini yeni bir marka ile yeniden başlatma sürecindedir. Çalışma dört merkezle ilgilidir:
- Design: Yeni logo, görsel kimlik, ürün fotoğrafları, sayfa düzenleri
- Content: Yenilenmiş ürün açıklamaları, ana sayfa metni, bildirim e-postaları
- Build: Güncellenmiş website, yeni ödeme akışı, eski URL'lerden yönlendirmeler
- Ops: Güncellenmiş ödeme işlemcisi ayarları, teslimat ortakına bilgilendirme, analizlerin yeniden yapılandırılması
Yeniden başlatma için kesin bir süre var: 45 gün içinde gerçekleştireceği bir fuar, yeni markanın kamuoyu önünde olduğu yer.
Bireysel Çalışanlar Kalıplar Kalır
Çoğu organizasyonda, kanban, yönetim hiyerarşisi üzerinden çalışma görünür kılar. Yöneticiler, kalıplar arasında koordinasyon sağlar. Kanban, koordinasyon maliyetini azaltır.
Un modelinde, yöneticiler yok. Tamamen bağımsız çalışan bireyler var: bir tasarımcı solo, bir yapısal solo, bir yazar solo, bir operasyon solo. Her solo, doğası gereği, tamamen bağımsız bir kalıp haline gelir. Onlar arasında bir org chart yok. Onlara rapor verme ilişkisi yok. Koordinasyonu sağlamak için bir yönetici yok.
Kanban, koordinasyon katmanına dönüşür. Kalıpları düzleştirmek değil, tam tersine, sololar tamamen bağımsız kalırlar, ancak birbirlerinden alıcılarından gelen işi görünür ve açık hale getirir. Bir solo, işi teslim etmek için bir e-posta göndermez veya bir toplantı düzenler. Çalışmayı bir paylaşılan pano üzerinde bir kart yerleştirerek teslim ederler. Alıcı solo, kapasiteye sahip oluncaya kadar onu çeker.
Bu, kanban'ın agile veya waterfall modelinden daha iyi uyduğu un modelini açıklar: ortak ritim gerektirmez, ortak geribildirim toplantısı gerekmeye, ortak planlama gerekmeye. Her solo, kendi WIP limitlerini, kendi döngü süresini, kendi işi bitti anlamını belirler. Koordinasyon, kart seviyesinde gerçekleşir, değilse süreç seviyesinde.