Sprint Planlama sırasında “çok fazla” tasarım yapmadan geçerli zaman tahminlerini nasıl sağlayabiliriz?

Ekibim Scrum ile hızlanıyor, ancak çoğumuz çevik olmayan veya "sahte" çevik metodolojilere daha aşinayız. Bizim için en büyük engel olan bölüm, birikmiş işlerimizi görevlere ayırdığımız ve saatleri tahmin ettiğimiz verimli bir Sprint Planlama toplantısı yapıyor. (VS2010 Scrum Şablonundaki terminolojiyi kullanıyorum; bir yerde yanlış kelime kullanırsam özür dilerim.)

Bir görevin ne kadar süreceğini anlamaya çalıştığımızda, bunun ne kadar süreceğini anlamak için, özelliği kod düzeyinde (tablo düzeni, arayüzler, vb.) Tasarlama tuzağına düşüyoruz. .

Bu tür bir tasarım yapmak için uygun bir yer olmadığından eminim. Sprint sırasında bu tasarım toplantıları için görevler planlamalıyız. Bununla birlikte, görevler için başka anlamlı tahminler bulmanın başka bir yolunu bulmakta zorlanıyoruz.

Herhangi bir pratik alışkanlık / teknik / vb. Var mı? bir özelliği nasıl uygulamayı planladığınızı bilmeden, ne kadar süre alacağına karar verdiğiniz için? Tasarım tamamlandıktan sonra zaman tahminlerimiz önemli ölçüde değişecekse, Sprint birikimimizi önceden nasıl uygun şekilde bütçeleyebiliriz?

DÜZENLE:

Sadece açıklığa kavuşturmak için, bazı yorumlar / cevaplar çok geçerli olduğu için, ancak yanlış soruyu ele aldığımı düşünüyorum.

Yaptığımız şeyin doğru olmadığını biliyoruz ve bu tasarım için sprint'e zaman ayırmalıyız. Kavramsal olarak tüm geliştiriciler bunu anlıyor. Ayrıca, yabani otlara girmeye başlarsak bizi yolda tutmak için Scrum deneyimi olan bir ekip üyesi de getiriyoruz.

Sorun şu ki, bu tasarım sürecinden geçmeden , herhangi bir şey için somut zaman tahminleri sunmakta zorlanıyoruz. Sürekli "Bu şekilde tasarlarsak 8 saat sürebilir ama bunun yerine başka bir şekilde yapmak zorunda kalırsak bu yaklaşık 32 zaman alacaktır ama yazmaya çalıştığımızda o kadar da kötü olmayabilir. ... ".

Ayrıca, çalışmak için bazı tarihsel hıza sahip olduğumuzda bu sürecin daha iyi olacağını varsayıyorum, ancak kullandığımız teknolojilerin ve mimari modellerin çoğu bizim için yeni. Ancak, potansiyel olarak çılgınca yanlış tahminler, bu süreci uyarlamanın sadece doğal bir parçasıysa, bunu kabul etmek için kendimizi yenilememiz gerekecek :)

1. Bu tasarım tartışmalarını yaptığınız yinelenen bir "tımar" toplantısı planlayın. Çalıştığım ekipte, planlamadan önceki gün sprint başına bir kez var. Amaç, tasarımın ekibin genel hikaye için zaman tahminleri üzerinde anlaşabileceği kadar yeterince çivilenmesi. Bu toplantıda görev dökümü yapmayı düşünebilirsiniz, böylece planlama tamamen ne kadar alacağınıza karar verme alıştırması haline gelir. Başka bir deyişle, gerçek işi yapmaya başlamadan ÖNCE tasarımı sprintlerde yapmalısınız.

2. Planlama pokeri kullanmayı düşünün , yani görevleri tahmin etmek için insan günü yerine "çaba" noktaları / birimleri. Ayrıca hikayeleri olabildiğince yıkmaya çalışın. Bir hikaye ne kadar uzun / karmaşıksa, tahmininizin doğru olma olasılığı o kadar az olur.

3. Planlamada, scrum ustası "çözme" ye çok fazla yaklaşan tartışmalara bir durma diyerek planlamayı takip etmelidir. Bu noktada ekip üyelerinin tahmin üzerinde hızlı bir şekilde anlaşmaya varmaları gerekir, bu da genellikle üst sınır / en kötü durum numarası verir. Görevler planladığınızdan daha kolay sonuçlanırsa daha fazla iş almak, planlanandan daha uzun süren görevler ve birden fazla sprint'e yayılan hikayeler nedeniyle kayma programları ile uğraşmaktan çok daha kolaydır.

4. Sprint sonunda tahminlerin geriye dönük olarak nasıl gösterildiğinden bahsedin. Özellikle dikkate değer ölçüde uzakta olan herhangi biri olsaydı. Takım hikayenin nasıl gittiğinden ve nasıl gitmesini beklediklerinden bir şey öğrendi mi? Scrum master, tasarım / tahmin sürecinizde yapılabilecek eyleme geçirilebilir değişikliklere odaklanmalıdır.

Bence mesele zamanı tahmin etmeye çalışıyorsunuz. Yapma.

Karmaşıklığı tahmin edin. Bir gereksinime bakın (umarım bir kullanıcı hikayesi) ve ekibin, diğer gereksinimlerin veya kullanıcı hikayelerinin ne kadar karmaşık olduğuna göre, onu nasıl inşa edeceğini ve test edeceğini düşünmenin ne kadar karmaşık olduğunu değerlendirin. Bazen yanılırsınız, ancak çoğu zaman bir şeyin ne kadar zor olacağı hakkında iyi bir fikir edinirsiniz. Aynı karmaşıklığa sahip olan öğelerin tamamlanması için aynı miktarda çaba sarf etme eğiliminde olduğunu da göreceksiniz.

Böylece, karmaşıklık sıralamaları ürün birikiminizdeki kullanıcı hikayeleriyle ilişkili "hikaye noktaları" haline gelir. Birkaç sprint üzerinde çalıştıktan sonra, bir sprint'te kaç hikaye puanı alabileceğiniz hakkında bir fikir edinirsiniz ve bu sizin hızınızdır. Bu noktada, her öğenin ne kadar süreceği hakkında daha iyi bir fikriniz olacak.

Mike Cohn Kullanıcı Hikayeleri Uygulanan tavsiye ederim .

Sorunuzun özellikle planlamada tasarımdan kaçınmak olduğunu biliyorum. Ama bu bir çeşit XY Sorunu .

Ben senin olduğun yerdeydim. Size artımlı bir iyileştirme sağlayabilecek bir şey vermek yerine, bu ara devletlerden bazılarını atlamanıza yardımcı olmak isterim.

Ekibimizin özellikle iş planlama ve yürütme ile ilgili yaptığı üç şey: Bunlar tasarımın çökmesini önlememize ve yanlış zaman tahminlerinden kaçmamıza yardımcı oldu.

Otomatikleştirilebilir Kabul Kriterleri

Hikayelerimiz, Otomatikleştirilebilir Kabul Kriterleri sayısına işaret ediyor . Bu, hikayenin yapıldığını doğrulamak için otomatik testler yazsaydık, ne olurdu?

Örneğin, "Kullanıcı iOS 6+ çalıştıran bir iPad'de" oynat "ı tıkladığında video oynatılmaya başlar." Bu testi gerçekten otomatikleştirmek zor olabilir, ancak hikayenin kabul kriterleri (AC) ve bir noktaya katkıda bulunur.

Fibonacci ölçeğini kullanıyoruz ve her zaman yuvarlanıyoruz. Dolayısıyla, bir öykünün otomatik olarak kabul edilebilir dört kabul kriteri varsa, bu beş puanlık bir öyküdür.

Maksimum hikaye nokta boyutumuz sekiz puan, ancak nadiren bunlara sahibiz. Bir hikayede beşten fazla otomatikleştirilebilir kabul kriteri varsa, bunları ayırmanın bir yolunu buluruz.

Ön Bakım

Pazartesi günü bir başlangıç ​​toplantısı düzenliyoruz, ancak bakım toplantılarımız ekip planlamasının gerçekleştiği yerdir. Tımarlamadan önce ekip üyeleri , sonucu tanımlayarak ve otomatik olarak kabul edilebilir kriterleri saplayarak bir hikayeyi önceden hazırlar.

Bakım, takımın uzmanlığını önceden bakımlı hikayelere dayanması, belirtilmemiş gereksinimleri ortaya çıkarması, hikayeleri parçalanması vb.

Bazen kabul kriterlerine ek olarak görevleri de listeleyebiliriz, ancak bunlar tahmini değildir. Asla zamanı tahmin etmiyoruz. Görevler sadece kriterleri desteklemek için yapılması gereken çalışma ifadeleridir.

Devam Eden Çalışmayı Sınırlama

Geleneksel saldırı girişimleri sınırlamak için zaman sürat süresine işin. Bunun yapay olarak sprint son tarihlerini karşılamak için acele etmemize ve hafta sonlarımızı öldürmemize neden olduğunu gördük çünkü sprint Cuma günü sona eriyor.

Başka bir yaklaşım, herhangi bir zamanda devam eden çalışmayı sınırlamaktır . İkincisine göç ettik ve bunun için önemli ölçüde daha mutlu olduk.

Bir hikaye biriktirme listesinden devam eden çalışmaya geçtiğinde, bunu birkaç durumdan birinde olduğu şeklinde nitelendiririz:

• Beklemede - ekip çalışması yapılamaz çünkü bazı ek takım etkinliklerini bekliyoruz
• Gelişimde - kabul kriterlerine ulaşmaya çalışmak
• Test Gerekiyor - AC ile tanıştığımıza inanıyoruz, bir başkasının doğrulama yapmasını bekliyoruz
• Testte - hikaye AC'ye karşı değerlendiriliyor, hatalar ele alınıyor
• Kullanıma Hazır - bir sonraki uygun fırsatta, yayınlanacak

Daha sonra ekibin odak noktasını yönlendirmek için her eyaletteki hikaye sayısını kullanıyoruz. Örneğin, bir geliştirici yeni bir hikayeyi ele geçirebilir, ancak Testte çok fazla hikayemiz varsa, mevcut hikayelere yardımcı olmaları daha iyidir.

İlk olarak, bu koşullar altında doğru tahminlerin imkansız olduğunu kabul edin. Yanlış yaparsanız strese girmeyin. Bununla birlikte, planlamak için hala kaba bir fikre ihtiyacınız var ve tam belirsizliği hesaba katmanın tek yolu tahmininize daha fazla hikaye noktası eklemektir. 5 veya 13 olup olmadığını bilmiyorsanız, 13'ü kullanın.

Ayrıca, hikayeleri olabildiğince küçük hale getirmek de yararlıdır. Genellikle, özelliğin nasıl yapılacağı hakkında daha iyi bir fikre sahip olmak için yeterli işi yapmak amacıyla bir araştırma / tasarım hikayemiz var, o zaman özellik hikayesinin kendisi sonraki bir sprint'e giriyor. Bunun neden işe yaradığını düşünün. Bir şeyin ne kadar zor olacağına dair hiçbir fikriniz olmasa bile, genellikle geçmiş deneyimlerden öğrenmenin ne kadar süreceğini oldukça doğru bilirsiniz.

Burada yapabileceğiniz iki şey var.

Öncelikle rolü tartışmayı izlemek ve "Hey, tekrar tasarlıyorsun" demek olan bir tür scrum ustası var. Göründüğünden daha zor, insanları günden güne döndürün ve başlangıçta herkes scrum ustası olsun, böylece herkes boru kurabilir.

İkincisi, sprint planlama sırasında tasarlıyorsanız, bir görevin süresi hakkında bir çağrı yapmak için yeterli bilmeme veya daha eğlenceli olduğu için tasarlayıp tasarlamadığınız arasında ayrım yapabilmeniz gerekir.

Yine, scrum ustası buraya girmeli ve planlamak için yeterince bilginiz olana kadar öğeyi beklemeye almanızı veya orijinal soruyu tasarlamayı bırakıp size cevap vermenizi söylemelidir (ne kadar sürecek).

Eğer sprint planlaması yapıyorsanız, sizinle biriken işlerin üstesinden gelmek ve ilk önce görmek istedikleri şeylere öncelik vermek için bir iş sponsoruna sahip olmak mantıklıdır. Bunu yaparsanız, seans sırasında tasarım yapmanın daha zor olduğunu göreceksiniz, çünkü huzursuz olacaklar ve sonunda gelmek istemeyeceklerdir.

Sprint planlama sırasında sınırlı bir tartışma ile 'soğuk' hikayesini tahmin etmeye dayanarak çalışıyoruz. Tahminler, oldukça dar bir odağa sahip takımların kurulmasına rağmen gerçekten oldukça yanlıştır ... esas olarak, gerçekte ne olması gerektiği hakkında hiçbir fikre gerçek olmayan bir çok belgelenmemiş, yorumlanmamış eski kodun varlığı nedeniyle Orijinalin yazılmasından bu yana büyük ölçüde değişen personel.

Şu anda denediğimiz şey, her bir hikayeyi araştırmayı planlamak için biraz zaman harcamaktır - ve burada sadece bir geliştirici bir hikayeyi araştıracaktır ... Bunun, araştırmacı geliştiricinin, tahmine yardımcı olur. Şimdiye kadar bu, denendiği durumlarda yardımcı oldu.

Ek soruşturmanın, maliyetleri haklı çıkarmak için tahminleri gerçekten daha doğru hale getirdiğine henüz ikna olmadım, ancak birkaç sprint için bunu deneyeceğiz.