Kanban'da Devam Eden Çalışma limitleri nasıl belirlenir?


10

Tipik bir Kanban panosunu düşünün:

Girdi, Analiz, Geliştirme Hazır, Geliştirme, Yapı Hazır, Test, Yayın Hazır

Her sütun için Devam Eden Çalışma sınırları nasıl belirlenir? herhangi bir formül?

Yanıtlar:


7

Hayır, formül yok. Bir tane yok.

Çoğu, ekibinizin çalışma şekline, kullandığınız uygulamalara vb. Bağlıdır. Programı eşleştirirseniz, geliştirme sütununda birçok geliştiriciden daha düşük sınırlara sahip olursunuz.

Mevcut ekipte Kanban'ı tanıtırsanız, devam etmekte olan tüm çalışmaları MMF'lerle eşleştirmeyi deneyebilir ve ardından farklı sütunlarda kaç özelliğiniz olduğunu görebilirsiniz. Size şu anda gerçekten hangi limitlere sahip olduğunuz konusunda bir fikir verecektir ve bu Kanban limitlerini belirlemek için iyi bir başlangıç ​​noktasıdır.

Aldığınız bir diğer tavsiye, ekibinizin bağırsak hissi ile ilgilidir. Doğru olduğunu düşündüğünüzü yapın. Ardından limitlerinizin çok sıkı veya çok gevşek olup olmadığını izleyin ve ayarlayın. Bazı insanlar "tahta size söyleyecektir" der ve bu temelde doğrudur. Eğer darboğaz her hafta vurursanız muhtemelen çok düşük limitler koymuş olursunuz. Bir veya iki engelleyici sorun değilse, limitler çok yüksektir.

Kanban panomuzu hazırlarken sınırlarımızı nasıl belirlediğimize dair bir yazı yazdım: http://blog.brodzinski.com/2009/11/kanban-story-kanban-board.html


5

Her ikisi de farklı insanlar tarafından önerilen iki uç denedim. Birincisi yüksek limitler kullanmak ve acıyana kadar onları aşağılamak, diğeri ise tam tersi, n-1 ile başlamak için, burada n, bu sütuna bir görev çekebilecek insan sayısıdır. İkincisi kanban'a yeni takımlar için daha acı vericidir, ancak ilk seçenekten daha hızlı bir akış maksimizasyon noktasına ulaşmamıza yardımcı oldu, çünkü acı hissettiğimizde (darboğazlar) ilk içgüdümüz, Devam Eden Çalışma sınırını bir Son çare olarak ve sonuç olarak, aksi takdirde görünmeyen olabilecek birkaç süreç sorununu ortaya çıkardık ve çözdük.


3

Böyle bir formül olmadığını kabul etsem de - aynı zamanda Kanban sürecinizi modellemenin gerçek olasılığı da var. Bu, Döngü Süresi, Bekleme Süresi, Verimlilik vb. Şeyler için olası sonuçları simüle etmenize yardımcı olacaktır.

Kanban sürecimizi modelleyen böyle bir simülatör uyguladım. WIP limitleri ve takım kaynakları hakkındaki Kanban kısıtlamaları altında tahtadaki öykü akışını simüle eder. Harici müşteri incelemesini gerektiren bir durumumuz var. Hepimiz bu aşamanın hikayelerimizi destekleyerek Döngü Zamanımızı öldüren bir şey olduğundan şüphelendik.

Bağırsak hissi bu aşamayı zamanlamaktı, ancak bunun sorunu başka bir yere itip getirmeyeceğini bilmiyorduk. Ne zaman boksu ile ne kadar ileri gideceğini ne de ne kadar büyük bir gelişme sağlayacağını bilmiyorduk.

Her şey çok iyi söylüyorum sadece tweaking devam ama çok yıkıcı olabilir. İnsanlar bir sürece alışacaklar ve sürekli önseziler yapmaya çalışan biriyle sinirli olacaklar. Bu nedenle, değişikliği uygulamadan önce genellikle çok iyi bir dava açmanız gerekir.

Modellediğinizde, kesintisiz olarak ince ayar yapabilirsiniz ve ince ayarlarınızın istediğiniz sonucu vereceğinden çok daha fazla güvenebilirsiniz. Ayrıca sihirli formülünüzü almak için bir yere gidecek.


1
Harici müşteri inceleme gereksiniminin Çevrim Sürenizi öldürdüğünü kanıtladınız mı? Sorgulayan beyinler bilmek istiyor! :-)
Martijn Pieters

1

Her sütunda, ilişkili sütunda iş alacak kişi sayısına eşit bir dizi "yuva" ile başlardım. Bu, darboğazları veya ağrı noktalarını ortaya çıkaracaktır. Ağrı noktasına gidene kadar hitap edin.

Zaman içinde her sütundaki yuva sayısını azaltarak deney yapın.


Diyelim ki 10 geliştiricimiz var, bunun anlamı "Geliştirme" sütununda 10 alt sütun olacak mı? Her geliştirici için bir sütun var mı? Ve bina süreci bir geliştirici tarafından ele alınırsa, bu, "Yapıya Hazır" Devam Eden Çalışma sınırının 1 olacağı anlamına mı geliyor? "Darboğazlar veya ağrı noktaları" ile ne demek istiyorsun? ne gibi?
Chiron

10 geliştiriciniz varsa, bir sütun ve o sütunda 10 yuva ile başlama seçeneğiniz vardır. Bu, sıfırdan başladığınızda 10 tanesi için yeterli eşyaya sahip olduğunuz anlamına gelir. Bir öğe bittiğinde, yeni bir öğe için yer açarak bir sonraki sütuna geçer.

1

Yeni bir proje veya takım başlattığımızda Devam Eden Çalışma sınırını belirlemek için iki teknik kullanıyorum.

Bir geliştirme projesi durumunda: çiftler halinde çalışıyoruz (XP yapıyoruz), bu da iki üyenin aynı anda bir eleman üzerinde çalışabileceği anlamına geliyor. Ekip 6 kişiden oluşsaydı, WIP önceki cümle temelinde 3 olurdu. Ancak çift programlama yorucu bir iştir ve bazen meslektaşları biraz yalnız çalışmak ister, artı bir tane veririm, bu yüzden 6 üye için Devam Eden Çalışma sınırı 4 olur.

Bir bakım, doğrulama testi veya destek projesinden bahsederken, farklı meslektaşların ne kadar paralel iş yapabileceğini kontrol ediyorum, bu sayıyı topladım ve bir tane ile çıkarıyorum. Örneğin, daha önce bahsedilen takımdan herkes 2 paralel konu ile ilgilenebilir, Devam Eden Çalışma sınırını 12 yapar, ancak -1 ile 11 olur. -1, ekibin odaklanmış kalmasını ve birlikte çalışmasını sağlar. Bu durumda Devam Eden Çalışma sınırı 12 olsaydı, herkes maksimum iki kartı üzerinde çalışırdı ve hiçbir işbirliği olmazdı.

Bu teknikleri yalnızca proje / ekip başladığında başlangıçta kullandığımı vurgulamak istiyorum. Daha sonra Devam Eden Çalışma sınırının ayarlanması duygu, yük, amaç vb. Temelinde ekibin görevidir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.