Takım hikaye noktalarını tahmin ediyor, iş gerçek zaman istiyor

Eminim bu nadir bir tema değildir. Hikaye puanlarını kullanarak kullanıcı hikayelerini tahmin etmede iyi bir iş yapan iki scrum ekibimiz var (ekip üyelerinin birkaç yıllık scrum deneyimi olmasına rağmen, mevcut takım takımyıldızları sadece 8 aylıktır). Ancak şirketin iş bölümünün kullanıcı hikayeleriyle ilgili olması zor; gerçek zaman birimlerini (veya "hikaye noktalarını saate dönüştürmek için bir formül") istiyorlar, böylece işlerin ne zaman hazır olacağına dair bir plan yapabilirler ( "müşterilere Özellik X'in üretimde olacağını ne zaman söyleyebileceğimizi bilmeliyiz " ).

Ben ve scrum ustası seleflerim elbette "hikaye noktaları ile gerçek zaman arasında kesin bir ilişki yok" ve "hikaye puanlarının takımın bir sprint'e ne kadar sığabileceğini belirlemek için kullanıldığını" açıkladım ve ben eminim bu cevaptan ne kadar memnun olduklarını tahmin edebilirsiniz. Hala takvim zamanında, iş yerindeki 27. kullanıcı hikayesine ne zaman ulaşacağımızı bilmek istiyorlar.

Her halükarda, bazı istatistikler derliyorum ve SP tahminlerimiz çılgınca farklı gerçek zamanlı harcanan sonuçlara (scrum board yazılımımız tarafından ölçüldüğü gibi) biletlerin "üzerinde çalışılıyor" sütununda ne kadar zaman harcadığını takip ediyor ). 1-SP kullanıcı hikayeleri için, elbette çok kısa süreli açıklıklara (ara sıra patlama ile) ağır bir önyargı vardır, ancak özellikle 2-SP hikayeleri için her yerdeler: 20 faktör var "en hızlı" ve "en yavaş" tamamlamalar arasında. 3, 5 ve 8-SP öyküleri için yayılma da 2 kattan fazladır.

Bu, (a) ekibin benzer karmaşıklığa ilişkin kullanıcı hikayelerini tahmin etmede çok daha tutarlı olması gerektiğini ve (b) ekibin zaman raporlamasındaki doğruluklarını iyileştirmesi (yani, biletleri toplantıdayken, öğle yemeğinde veya langırt oynarken "çalışıyor".

Hem (a) hem de (b) yi iyileştirme planlarım var ama bunun yeterli olmadığını hissediyorum, bu girişimlerin bu girişimlerin sağlayacağından daha fazla somutluk beklediğini düşünüyorum.

İş yönünün uygulanmasında bazı iyi stratejiler nelerdir , böylece çalışma şeklimize çok fazla müdahale etmeyeceklerdir (örneğin, IMHO'nun aptal olacağı ayrı zaman izleme kullanımını empoze ederek her durumda daha az doğru olacaktır. mevcut "otomatik" izleme), aynı zamanda hikayelerin ne zaman yapılacağı konusunda somut bir ölçüt elde etmelerine izin verir mi?

(Tarihsel olarak, planlama sırasında kullanıcı hikayelerini daha sonra gerçek çalışma zamanında ayrı ayrı tahmin edilen iş öğelerine ayırdık , ancak burada bahsettiğim şey, arka günlüğünde bu ayrıntı veya kırılma seviyesine sahip olmayacak kullanıcı hikayeleri. -aşağı.)

Güncelleme: Yöneticim, hikaye başına harcanan saat başına bir çeşit çan eğrisi dağılımı olduğuna dair bir önseziye sahipti, ancak harmanladığım veriler ve yaptığı grafikler onu bu kavramı tamamen devre dışı bıraktı. :-)

Haklısın, hikaye noktalarını saate dönüştürecek bir formül yok. Metreden ayağa oldukça kayıpsız bir dönüşüm elde edebilirsiniz ve bunun tersi de olabilir, ancak 3 puanlık bir hikayenin X saat alacağını söyleyemezsiniz, bu nedenle 5 puanlık bir hikaye Y saat sürecektir (Y için çözülür).

HorusKol bu sonraki bölüme değindi. Takım olarak sprint hızınız, daha uzun vadeli sonuçlar için yardımcı olabilir. Takımınızın sprint başına 50 puan olduğunu ve her sprint 2 hafta olduğunu varsayalım. Yani sprint başına 50 puan yılda 50 hafta ile çarpılır (insanların tatiller için 2 hafta izin aldıkları varsayılarak) o zaman mevcut ekibiniz 12 ayda en fazla 2.500 puan yapabilir.

Böylece iş 170 puanlık hikaye ve destanlarla karşınızda. Bunu takımın 50 puanlık tarihsel hızına bölün (şimdiye kadar her sprintin ortalaması) ve 3.4 sprint elde edersiniz. Bir tahmin yaptığımız için, 4 sprint'e yuvarlayın: 8 hafta. Temelde iki ay. Ayrıca son 3-4 sprint almayı ve başka bir tahmin almayı seviyorum. Diyelim ki son 3 sprintte takımınız sırasıyla 53, 67 ve 55 puan aldı. Bu 58-ish puanına kadar çalışır, bu oran 2.9 sprinttir - temel olarak 3 sprint. Görünüşe göre bu 170 puan için zaman çizelgeniz 6 ila 8 hafta gibi görünüyor.

İşletmeye 2 ay söyle. Onlara 6-8 hafta söyleme çünkü sadece "6 hafta" duyacaklar. Onlara 8 hafta bile söylemeyin, çünkü çoğu ayın içinde yaklaşık 4.5 hafta var ve insanlar "4 hafta" duyduğunda anında "1 ay" diye düşünüyorlar. Bir tahmin yaklaşık 4 haftaya ulaştığında 1 ay olur. O zaman sadece aylar içinde çalışın. Eğer bir yıl ya da daha fazla vurursanız dürüstçe bu işi tahmin etmeyin. Bu anlamsız. Bir yılda çok fazla şey değişebilir.

Bunu hikaye noktalarını saatlere dönüştürmenin oldukça doğru bir yolu olarak buldum ... iyi zaman, her neyse.

Bireysel hikayelerin tamamlanması için geçen sürede sapma elde edersiniz. Bazı geliştiriciler diğerlerinden daha hızlı çalışır. Tüm hikaye noktalarını bir kaseye koymak ve karıştırıcıyı ortalamalarla çalışmaya açmak bu tutarsızlıkları hafifletmeye yardımcı olur.

Oh, ve en önemli kısmını unutma:

Hesabı yuvarlamak. Her zaman.

Muhtemelen hikaye noktalarından zaman tahminlerine kadar bazı doğal dönüşümleriniz var - sprintiniz için yeterince iş seçmeye nasıl karar veriyorsunuz? Muhtemelen "ekip haftada 20 (ya da 40 ya da başka bir şekilde) puanı ele alabilir" dediniz. Birkaç sprintten sonra, bunu tamamlamaya dayalı olarak revize edebilmelisiniz - şimdi 15 veya 25 (veya 35 veya 50 veya ...) bir sprint gösteriyor - bu takımınızın hızıdır .

1-SP kullanıcı hikayeleri için, elbette çok kısa süreli açıklıklara (ara sıra patlama ile) ağır bir önyargı vardır, ancak özellikle 2-SP hikayeleri için her yerdedir: 20 faktör var "en hızlı" ve "en yavaş" tamamlamalar arasında. 3, 5 ve 8-SP öyküleri için yayılma da 2 kattan fazladır.

Belirli öyküleri tamamlamak için zamandaki bazı değişiklikler puan değerleri içinde iyidir - hız, bu belirsizliğin ardından yakın tarihte ortalama olarak bakar.

Ancak, puanları nasıl atadığınıza, özellikle de bu kadar büyük bir dalgalanma yaşıyorsanız, bu 2 puanlılara uzun bir göz atmanız gerekebilir. Daha yüksek puanlı görevlerin belirsiz olması gerekir (ve parçalanması gerekir) - ancak 2-işaretçi kadar küçük görevler oldukça tutarlı olmalıdır.

Aynı puan değerine atanan tüm görevlerin benzer çaba göstermesi gerektiğinden, tamamlanması için bu kadar çok zaman olması mantıklı değildir.

Bu yüzden, retrospektifinizde en uzun süren 2 imlecine bakın. Muhtemelen sabah alması gereken bir şey neden 10 günlük bir boşluğa dönüştü? O ilk sabah "bunun olması ve destansı olması ve daha küçük görevlere bölünmesi gerekiyor" diyen bir şey işaretlenmiş olabilir mi? Bu gerçekleşir gerçekleşmez, elbette, gerekli ekstra iş biriktirme listesine konulmalı ve süratin geri kalanına müdahale etmemelidir.

Ayrıca, ekibin bu öğeyi nasıl hafife aldığını görmeye çalışın - gelecekteki öğeleri inceleyerek daha iyi yapabilir misiniz?

Evet, teslimat tarihi buna göre itilecek veya teslimatın etkilenmeyeceği şekilde güncelleme için özellik listesi revize edilebilir. Ancak amaç gelecekteki nokta tahminlerini iyileştirmek ve daha doğru bir zaman çizelgesi elde etmektir.

Hava tahmini gibi: ne kadar uzakta, o kadar az güvenilir. Bu herkesin anlayacağı bir benzetmedir. Tahminlerdeki hatalar artıyor.

Satışlar müşterilere Scrum açısından konuşmayı öğrenmelidir. Scrum, izolasyonda bir anlam ifade etmiyor, şirket genelinde dikey olarak uygulanması gerekiyor ve tercihen müşteri alanına uzanıyor.

Bir geliştirme ekibi olarak bu konuda sağlam olmalısınız. Onlara beklentiler ve tahminler verebilirsiniz, ancak tek bir sprint'i uzatan taahhütler olmasına izin vermeyin.

Böyle sorular aldığımda birkaç şey yapıyorum.

İlk olarak, geçmişi tanımlayarak gelecekle ilgili soruları cevaplıyorum. Haftada bu hikayelerden yaklaşık ikisini geçiriyoruz gibi bir şey söyleyebilirim . Yani, hiçbir şey değişmezse, yaklaşık 14 hafta içinde 27. hikaye ile yapılmasını bekliyoruz.

İkincisi, insanlarla karşı karşıya olan müşterinin ticarete karşı riske karşı sorumluluk almasını istiyorum. Remember gibi bir şey söyleyebilirim , mühendislik ekibi 50/50 tahminler temelinde çalışır. Hiçbir şey değişmezse, özellik 27'nin 14 haftada hazır olma olasılığı 50/50'dir. Muhtemelen bu risk seviyesine sahip bir şeyi bir müşteriye rapor etmek istemezsiniz. % 90 güven duyduğumuz bir tahmin yapmamı ister misiniz? Daha sonra tarihsel kanıtlarınızı gözden geçirmeniz ve şöyle bir şey söylemeniz gerekir: Hikayenin 25 haftada yapılması için% 90 şans var .

Son olarak, iş arkadaşınıza harici bir taahhütte bulunduktan sonra şirketin sabitlendiğini hatırlatın. 27 numaralı hikaye hakkında dış vaatlerde bulunmak şirketin tüm çevikliğini ortadan kaldırıyor. Daha sonra belirli bir hareket tarzına bağlı kalacaksınız. Birisi size bir değişiklik isteği geldiğinde, şimdi yanıtlamanız gerekir . X tarihinden önce 27 numaralı hikayeyi bitirmeyi taahhüt ediyoruz. Bu değişikliği yalnızca müşteriyle iletişime geçip onlara taahhüdümüzün artık geçerli olmadığını söylerseniz yapabilirim. Temel olarak, geleceğe bir aydan fazla bir süre için özel taahhütlerde bulunmak birçok problemle birlikte gelir.

Zaten (çok kaba) bir dönüşümünüz var:
Scrum sprintleri (genellikle) iki haftadır.
Bilirsiniz, diyelim ki, bu iki haftada yaklaşık 20 hikaye puanı değerinde özellik (ya da tek bir sprint'te hangi özelliklerin ve kaç adet paketleneceğini başka nasıl belirlersiniz?) Ve önceki sprintleriniz bu tahmini onaylar (diyelim ki) son beş sprintte 18, 21, 23, 19 ve 20 hikaye puanını tamamladınız).

Diyelim ki X özelliği (ve tüm bağımlılıkları) 47 hikaye olarak tahmin edildi.
Yani, bunu en yüksek önceliğe uygularsanız, yaklaşık 3 sprint (yani 6 hafta) almanız gerektiğini tahmin edebilirsiniz (ancak tahminlerinizin kimin ne yapabileceğini dikkate aldığından emin olun - bu noktalardan 35'i DB işi ise ve sadece DB adamında, bunu dikkate almak için tahmini hızınızı gözden geçirmeniz gerekir).

Bununla birlikte - bunların kaba tahminler olduğunu kesin olarak söyleyin - sprintlerin altı değil iki hafta olmasının bir nedeni vardır. Tahmininiz ne kadar çok şey kapsıyorsa, belirsizlik ve hata o kadar fazla kayar. Ayrıca maliyeti de kesin bir şekilde iletin - yani bu, görevi en yüksek önceliğe koymak anlamına gelir, yani başka hiçbir görev üzerinde çalışma yapılmaz. Aksi takdirde şu senaryoya girebilirsiniz:

" Y özelliği ne zaman yapılacak?"
"Eğer daha sonra odaklanırsak ... 12 hafta"
" 12 hafta mı?!? 4 süreceğini söyledin."
"Evet, ama bize tüm kaynaklarımızı bağlayacağınızı ve 8 hafta alacağınızı söylediğimiz X özelliğine öncelik vermemizi söylediniz."
" X ve Y özellikleri üzerinde aynı anda çalışamaz mısınız?"
" inilti "

Sprint, 2 hafta gibi tanımlanmış bir süredir. Mevcut hikayeniz ve bir sonraki sprintiniz gibi, bazı hikayelerin 2 sprintten daha fazla olacağını tahmin edemezsiniz. Bir sonraki sprint için ekiple tartışılan ve iş tarafından önceliklendirilen hikayeler hazırladığınızı varsayıyorum. En iyisi diyebileceğiniz en iyi 4 haftalık çalışmadır.

4 haftadan uzun her şey değişebilir ve iş saatleri içinde ayarlanmayan yol haritasını yapabilir. Bu sprint başına planlanmalıdır, diyelim ki bazı epic1 (gruplandırılmış hikayelerin jira demetinde destansı) ve epic2 sprint 47 ve 48'de yapılmalıdır ve epic3 sprint 49'da yapılmalıdır. Destanları kabaca saatler içinde kendi başıma bir ya da ikisinin bir sprint'e uyup uymayacağına bakın, zaman çizelgesi yine de kayacak. Özellikler işe yaramazsa iş kapsamı azaltmak veya daha sonra gerektiği gibi geliştirilebilir mükemmel olmayan çözümler kabul etmek zorunda (çevik olması gerekir, aşağıdaki planı yerine gerçeği kucaklamak).

Gelecekteki sprintler ve bunlar için ana konular / destanlarla güzel Gantt şeması (iş gibi) yapabilirsiniz.

Her sprint yayınlamayı seviyorum ve daha sonra sprint'te bitenlerle (veya mükemmel olmasa da iş tarafından serbest bırakılmak üzere imzalanan şeyler) serbest bırakıyorum, bitmemiş şeyler bir sonraki sprint'e gider. Bu şekilde yaklaşık 2-3 haftalık zaman çizelgesinde öngörülebilir teslimatım var (serbest bırakma adayı üzerindeki nihai düzeltmeler için bir hafta).

Bu benim küçük ekibim, az miktarda dış bağımlılıklar ve makul işlere inandığım deneyim. Milajınız değişebilir.

Yeni özellikler için gereken süreyi tahmin etmek neredeyse imkansızdır.

Yazılım geliştirmeyle ilgili deneyim, çoğu durumda gerçekten geliştirmeye başlamadan önce göremediğiniz ayrıntıların olduğunu göstermektedir. En iyi durumda, bu deteils biraz ek zaman gerektirebilir, ancak en kötü durumda proje de başarısız olabilir. Bunun nedeni yazılım geliştirmenin kendisinin karmaşıklığıdır.

SCRUM'un sadece sorunun karmaşıklığını (hikaye noktaları) tahmin etmesinin nedeni budur, ancak zamanı değil. Sahip olduğunuz tek şans, yüksek karmaşıklığa sahip özellikleri daha küçük olanlara bölmektir. Bu şekilde riski en aza indirebilirsiniz.

Zaman tahmini neredeyse imkansız olduğu için, hikaye noktalarını zaman tahminlerine dönüştüren bir formül yoktur. Hız sadece çok kaba bir tahmin olabilir, daha fazla değil.

SCRUM'da, ürün sahibi her bir sprint'ten önce biriktirme listesi öğelerinin önceliklerini değiştirebilir. Bu nedenle SCRUM yöneticisi birden fazla sprint için herhangi bir tahmin veremez. Bir sonraki sprint'te hangi biriktirme öğesinin önemli olabileceğini bilmiyor.

SCRUM imkansız şeyler yapmak (planlanamaz olanı planlamak) veya gelişimi daha hızlı hale getirmek için bir yöntem değildir. Gelişimin süresi dolduğunda erken uyarı sistemidir. Yeni gereksinimlere hızlı tepki vermeyi sağlar.

İlk gönderiye:

Görevlerinizin çoğunu 1 SP'den 5 SP hikayelerine bölmeyi yönetiyorsanız zaten çok iyisiniz. Görevler benzer ve ekibiniz daha deneyimli olursa hız tahminleri daha iyi olabilir. Ancak, yeni eşyalarda her zaman yeni, kontaksız parçalar varsa, yanlışlıkla yaşamak zorundasınız.

Geliştiricileriniz normalde geliştirme dışı çalışmalarla (örneğin toplantılar) biraz zaman geçirdikleri için, her gün için 8 saatlik, ancak daha az, örneğin 6 saatlik bir gelişim planlamalısınız. Sonra diğer görevler veya daha fazla zaman alan iş öğeleri için bir yedek alırsınız.

İş arkadaşlarınız doğru tahminlere sahip olmak istiyorsa (ki bu da kendi içinde bir çelişkidir), onlara yazılım geliştirmenin doğasında var olan sorunları açıklayın. Sonra onlara çevik yöntemlerin avantajlarını gösterin.