Değişen takım kapasitesi ile sprint hızını nasıl tahmin edebilirim?

Scrum'da oldukça yeşil olan 4 geliştiriciden oluşan küçük bir ekibiz. Ülkenin her yerinden gelirsek, genellikle eve gitmek için garip günler veya haftalar sürüyoruz. Bu nedenle, takım kapasitemiz yıllık izinler nedeniyle bir iterasyondan diğerine dramatik olarak değişir ve bu da bir iterasyondan diğerine çok farklı hızlara yol açar. Planlama Toplantısında hızı tahmin ederken ekip kapasitesini nasıl hesaplarız? Geçmiş veriler çok farklı kapasiteleri yansıtacaktır ve tahmin hızımız için bir ortalama elde etmek için bir yıl bekleyemeyiz.

Basit bir yaklaşım olabilir, ancak kapasiteyi nasıl ölçtüğünüze bağlı olarak neden hızınızı completed story points * capacityveya olarak hesaplamıyorsunuz completed story points / capacity? Kapasiteyi adam-saat olarak ölçüyorsanız, ikincisini kullanın. Kapasiteyi 40 saatlik haftanın yüzdesi olarak ölçüyorsanız, ilkini kullanın. Hikaye puanlarını çıkarmaya gittiğinizde, belirli bir sürat için kapasiteniz hakkında iyi bir fikriniz olmalı ve belirli bir yük için tamamlanan hikaye noktalarını belirlemek için projenizin geçmiş verilerini kullanmalısınız.

Bununla birlikte, bu, tüm çalışanlara eşit muamele etmek gibi potansiyel olarak tehlikeli varsayımlar yapar - en küçük geliştiriciniz bir hafta izin alırsa veya alan ve / veya teknolojilerdeki en fazla deneyime sahip geliştirici bir hafta sürerse, kapasiteniz aynı sayısal değer, ancak hız üzerindeki etki muhtemelen farklı olacaktır.

Sonuç olarak, bir sprint planlarken tarihsel verilere dayanan profesyonel muhakeme kullanın. Bu durumda, ekibi içeren diğer bir tahmin şemasına girdi olarak önceki hızı kullanın. Dikkatli olunca da hata yapardım - bir sprint'e daha fazla iş çekmek, bir görev yapma taahhüdünü ortadan kaldırmaktan daha kolaydır.

Kapasite aynı kalsa bile hız değişebilir.

Bu yüzden sadece hızınıza güvenin, değişen kapasitenin kendisi ile ilgilenecektir, yani 3. süratte olduğunuzu varsayarak, bir sonraki sprint'e katılmak için tamamlanan son iki süratin ortalamasını alın. kapasitedeki varyans konusunda endişelenmeyin.

Hız bir ölçüt değil, bir rehberdir. Tüm sprintlerinizin ortalamasını (standart sapmayı hesaba katarak) ve en kötü üçünüzün ortalamasını, en iyi üçünüzün ortalamasını alın ve "Kesinlikle bunları yapacağız, bunları yapabiliriz, elde edemeyiz bunlar bitti. " Bu üç hızı ve kaba teslim tarihinizi kullanarak (tam olarak tahmin edilen) birikiminizle üç satır çizerek (12 sprint ve 12x gibi davranın en kötü hızınız 75, 12x en iyiniz 120 ve 12x ortalamanız 90'dır. 100 puanlık bir birikimde , en kötüsünde bile, dörtte üçünü yapabilirsin, en iyi şekilde her şeyi çivirdin ve ortalama olarak çoğunu teslim edersin).

Bu verilerle PO'nuz, sahip olması gereken, vermesini istediğimiz ve dışarıda bırakmayı umursamayacağı kararları alabilir.

Nihai, işler değişiyor, gereksinimler ortaya çıkıyor ve işler yeniden değişecek. Belli bir figür elde etmek için matematikte pirzolalarınızı yakmayın, bu tür şeyler için doğru aralıklar yeterlidir. Doğrultmalarınızı biriktirme matematiğinde değil yazılım problemleri üzerinde yıkın.