2010-09-01 19 views
6

Scrum'dan daha fazla Kanban stiline geçmeyi düşünüyoruz, ancak bana açık olmayan bir şey Kanban'ın ilerlemesini nasıl izleyeceğimiz.Kanban'ı kullanırken ilerlemeyi nasıl izlerim?

Her bir hikayenin döngü süresini izleyerek ilerlemenin ölçülebildiğini ve bu süreyi büyük olasılıkla seçkin öykülerin sayısına uygulayarak okuyabildiğimi okudum. Ancak bu, hepimizin farklı olabileceği hikayelerin büyüklüğüne ve karmaşıklığına bağlı görünmüyor.

Kullanılmakta olan burndown tablolarını da gördüm, bu nedenle tüm sürüm için bir tablo var mıydı? Bekletme sabitlenmediği için (sprint sırasında olduğu gibi) beklemedeki bekletmenin PO tarafından değiştirilip çoğalmasına izin verir misiniz? Sanırım backloyu serbest bırakmak için yaklaştıkça, daha az uçucu olmalısın. Daha sonra düşündüm ki, benim sorunum, yöneticilerimizin bir kontrol grafiğinin getirdiği kontrolün 'yanılsamasını' beğenmesidir. Onlar bir program olarak (benim görüşüme göre yanlış) onu görmeye eğilimlidirler ve bu nedenle projenin 'programa göre' veya 'programın gerisinde' ya da her neyse olduğu gibi yargılamalar yapabilirler. Bunun Kanban'da nasıl çoğaltıldığını göremiyorum. Belki de bu iyi bir şeydir.

+0

Programlama soru? – Select0r

+0

Bir programlama projesinin yönetilmesiyle ilgili olarak, bu sitede sorulan sorulara cevap verdiğine inanıyorum. –

cevap

3

Tüm proje için ilerlemeyi izlemenin en iyi yolu Kümülatif Akış Diyagramıdır. CFD hakkında this presentation hakkında daha fazla bilgi edinin. CFD'den darboğazlar gibi şeyler hakkında da bilgi edinebilirsiniz.

Belirli bir görev için gerçekten sizin yaklaşımınıza bağlıdır. Kanban panosunda küçük özellikleriniz varsa (1-2 gün geliştirme gibi), özellikler iş akışında hızlı hareket ettiğinden, durumu doğrudan tahtada görebilirsiniz.

Daha büyük özellikler kullanırsanız, bunları daha küçük görevlere bölmek isteyebilirsiniz. Bu, temel olarak özelliklerimizle nasıl çalıştığımızdır: daha büyük özellikler için (5-10 gün gibi) onları geliştirme görevlerine ayırıyoruz (geliştirme görevini tahtaya koymuyoruz). Öyleyse, A görevinin tamamlanmış 4 geliştirme görevinden 3'ü olduğunu söyleyebilirim, bu yüzden iyi iş yapıyoruz. Ek olarak, geliştirme görevlerinin süresini tahmin ediyoruz, böylece 1 saatlik uzun ve 8 saatlik görevler arasında ayrım yapabilirim. Küçük özellikler için, özelliği geliştiren tek bir geliştirme görevimiz vardır.

+0

Sanırım sorunum, yöneticilerimizin bir burndown çizelgesinin getirdiği “illüzyon” u beğenmesi. Onlar bir program olarak (benim görüşüme göre yanlış) onu görmeye eğilimlidirler ve bu nedenle projenin 'programa göre' veya 'programın gerisinde' ya da her neyse olduğu gibi yargılamalar yapabilirler. Bunun Kanban'da nasıl çoğaltıldığını göremiyorum. Belki de bu iyi bir şeydir. –

+0

CFD, bir tür yanma çizelgesidir. Zaten ne kadar çalıştığını gösteriyor. Şimdi, bir tür programa karşı doğrulamanız gerekiyorsa, planladığınızdan daha iyi veya daha kötü olup olmadığınızı görmek için grafikte bir artış çizgisini (özelliklerin tamamlanma hızını temsil eden) bir referans çizin. – pawelbrodzinski

+1

@Si Keep: Bu, ekibin mevcut sprint sırasında görevlerini makul bir şekilde tamamlayıp tamamlayamadığını görmek için, yanmış grafikler içeren bir noktadır. Cross-sprint grafik için [yanma grafikleri] tavsiye ederim (http://blog.workingsoftware.se/2010/09/burn-up-or-burn-down.html) –

İlgili konular