Eksik hikayenin tahmini ile ne yapmalı?

Ben nispeten yeni olan bir geliştirme ekibinin parçasıyım Scrum, sprint sonunda birkaç büyük hikayenin PO tarafından ya in progressda acceptedPO tarafından olmadığını varsayalım .

İlk olarak, bu kullanıcı hikayelerine ne olur? Onları bir sonraki sprint'e mi götürüyorsun?

Eğer öyleyse, yeniden tahmin edilmeli mi? Benim görüşüme göre bu kullanıcı hikayeleri üzerinde kalan çalışmalar çok az veya çok olabilir mi? Değilse, neden olmasın?

DÜZENLEME: Özel durumumda, hikayeler, kullanıcı hikayesinin hafife alınması nedeniyle değil, birkaç gün süren bir engel nedeniyle tamamlanmadı. Yardım edebilecekleriniz içinVersionOne

agile scrum

— ediblecode
kaynak

Bir XP süreci ile çalışıyorum ve bu tür bir durumla başa çıkmanın en iyi yolunun ne olduğunu merak ettim

— chrisbunney

Bir engelin olası bir risk olarak tanımlanmaması ve riske maruz kalmanın RE (etki * olasılığı) belirlenememesi, tahmin ile ilgili bir sorunu gösterir. Yüksek RE değerine sahip bir kullanıcı hikayesinin, sorunlara dönüşmesi durumunda bu riskleri ele almak için kendisiyle ilişkili daha büyük bir maliyet ve zaman tamponuna sahip olması gerekir.

— Thomas Owens

iki katına çıkarın ve 32 ekleyin, tıpkı C => F gibi

— Paul

Yanıtlar:

İlk olarak, bu kullanıcı hikayelerine ne olur? Onları bir sonraki sprint'e mi götürüyorsun?

Değişir. Başka bir hikayenin önceliği daha yüksek değilse, evet, bir sonraki sprint'e taşınırlar. Diğer hikayeler daha yüksek önceliğe sahipse, sprint'te bunları karşılamak için yeterli alan yoksa, ürün biriktirmesine geri dönebilirler. Tüm bunlar, Ürün Sahibiniz tarafından her bir hikayeye atanan önceliklere bağlı olarak sprint planlamasında gerçekleşir. Scrum gibi çevik yöntemlerin amaçlarından biri, zamanı azaltırken teslim edilen değeri en üst düzeye çıkarmak olduğu için, hepsi bu hikayeleri bitirerek ne kadar katma değer yaratıldığıyla ilgilidir.

Ne olursa olsun, yine de sprint sonunda potansiyel olarak sevk edilebilir bir ürün için çaba göstermelisiniz. Bu, sprint sonu ürününün tüm testleri geçmesini ve tamamlanan özelliklerin kullanıcı tarafından önemli bir sorun olmadan tamamen kullanılabilir olmasını sağlamak için geri dönme anlamına gelebilir.

Eğer öyleyse, yeniden tahmin edilmeli mi? Benim görüşüme göre bu kullanıcı hikayeleri üzerinde kalan çalışmalar çok az veya çok olabilir mi? Değilse, neden olmasın?

Tekrar tahmin etmem çünkü Scrum'da bir hikayeyi kabul ettiğinizde, çalışmaya başladığınızda ve kısmen tamamlanmış bir kavramınız olmadığında tahmin edersiniz . Bir hikaye ya% 100 tamamlanmış, test edilmiş ve kabul edilmiş (bitmiş) ya da bitmiş değil. Kısmen tamamlanmış bir kavram yoksa, hikayede ne kadar iş kaldığını belirlemenin bir yolu yoktur. Görünüşe göre bu düşüncede yalnız değilim . Yapabileceğinizi düşündüğünüz işi tahmin ettiniz, bu yüzden bu veri noktasını bırakın ve tahminin ölüm sonrası sprintinizdeki neden kapalı olduğunu tartışın ve gelecekteki sprintler için bu hatayı yapmaktan kaçınmaya çalışın.

— Thomas Owens
kaynak

Bunu sadece bir kez yaşadık ve tahminin yanlış olmasıyla ilgisi yoktu, yapılan işle sonuçlanan, ancak test edilmeyen bir tür engelimiz vardı.

— yenilebilir kod

@ user1016253 Bu, tahmininizin bir sorunu olduğu anlamına gelir. Tahminler riske maruziyeti içermelidir (etki * olasılık = maruz kalmanın maliyet, zaman ve kalite üzerinde etkisi olduğu maruziyet). Olan bir engel olduğu için, ancak tahmin bunu açıklamamış (veya yeterince açıklamamışsa), bir şey göz ardı edildi veya yanlış değerlendirildi (etki veya olasılık çok düşüktü, yani maruz kalma çok düşük, yani sorunu oluştuğunda tanımlamak ve düzeltmek için yeterli kaynak yoktu).

— Thomas Owens

@ user1016253 Eğer riskleri ve potansiyel engelleri tahmin etmekte ve görmekte sorun yaşıyorsanız, belki de iyi bir fikir, hikayeyi, her birinin biriktirme listesine girecek birden fazla hikayeye veya yalnızca geliştirme ekibi tarafından anlaşılmak üzere kullanmak için birden fazla hikayeye ayrıştırmak olabilir. yapılması gereken iş. Daha küçük bir iş biriminde risk analizi tahmin etmek ve gerçekleştirmek genellikle daha kolaydır.

— Thomas Owens

@Thomas Owens: Bu benim için riski yönetmenin yararlı bir yolu gibi görünmüyor. Özellikle, felaket olmayan düşük olasılıklı bir olay düşük maruziyettir ve bu nedenle iyi yönetilen bir proje bile zaman zaman program dışı bir şekilde atılabilir. Asla bir risk almazsanız, çok az şey başaracaksınız. Tabii ki, tahmin takibinin bu tür mazeretleri kabul etmekten kaçınması gerekiyor, ya da sadece son ipotek kazasına yol açan yatırımlar kadar geçerli tahminler yapmaktan

— vazgeçiyorsunuz

@DavidThornley Riski yönetmenin bir yolu değil, aynı zamanda tespit ve azaltma stratejilerini de içerecek bir risk yönetim planı için bir başlangıç noktası. Risklerin sorunlara dönüşmesi durumunda planınızda yeterli para ve zamanınızın olmasını sağlamak için kullanılan bir tekniktir. Yazılım Tahmininde Steve McConnell ve bu makalede Karl Wiegers tarafından savunulmaktadır . Görev başına bir arabellek olmadığını, ancak bir proje (veya yineleme) ara belleğinin çeşitli risklerin gerçekleşmesi gerektiğini fark etmek önemlidir.

— Thomas Owens

Tipik olarak, ekibin geri kalanına ve proje sponsoruna / ürün sahibine danıştıktan sonra, bir sprint aşan görevlerden ne olacağına karar vermek seçilen Scrum ustasına bağlıdır. Bir sprint sonunda, önceliklerin ne olduğunu gözden geçirmenin zamanı geldi. Söz konusu öykünün yeni / mevcut bir öyküden daha az önceliğe sahip olması mümkündür ve izleyiciye 'devam eden' olarak veya izleyicinizin kullandığı etiket ne olursa olsun, bu hikayenin başka bir noktada takip edileceğini belirtir. zamanında. Alternatif olarak hikaye tamamen çürümüş olabilir. Hangi izleyiciyi kullandığınızdan bahsetmediniz, ancak gördüğümlerin çoğu, projenin bir parçası değilse, 'descoped' için bir hikaye belirlemenize izin veriyor.

İkincisi, ekibiniz Scrum'da yeni olduğu için, hepsi öğrenme sürecinin bir parçası. Artık bazı hikayelerin çok büyük olduğunu fark ettiniz, bu nedenle ekibiniz hikayeleri yıkmak için daha fazla zaman alacak. Bunun olduğundan emin olmak genellikle scrum ustasının onusudur. Scrum ustasının, onları daha da yıkmak veya tamamen çaresizlikle ilgili son sözünü almak için eksik hikayelerle proje sponsoruna / ürün sahibine danışması gerekecektir.

Ekibimde, her 2 haftada bir (sprint) yeni bir Scrum ustası seçilir, bu nedenle herkes görevleri yönetmeye, Scrum toplantılarını organize etmeye ve herkesin ilerleme raporları göndermesini sağlamaya çalışır. Kendi ekibinizde durumun bu olduğunu umuyorum, kesinlikle iyi bir deneyim.

— Issız Gezegen
kaynak

Nitpick: Eksik hikayeyle ne yapılacağına karar verilmesi, bir önsezi sorunudur. Bu yüzden, ürün sahibinin Scrum master değil, buna karar vermesi gerektiğine inanıyorum.

— sleske

@sleske - Kabul etti. Cevabımda bunu daha açık hale getirmeliydim. Başlangıçta scrum ustasının takıma danışacağını söyledim, ancak düzelttiğim proje sponsorunu / sahibini eklemeliydim. Kafanın kalktığı için teşekkürler.

— Issız Gezegen

Bir sprint sonunda eksik hikayeler hala eksikse, onları o noktada gerçekten yıkamazsınız çünkü bu, Tamamlanmış Tanımı tamamen bozacaktır - "Yani hikayenin bir kısmının Bittiğini mi söylüyorsunuz? Ancak kod henüz gözden geçirilmedi! " Bu yüzden tek hikayeli destanlar korkunçtur ve asla sprintlere girmesine izin verilmemelidir.

— Robin Green

@RobinGreen Destanlara katılmanıza katılıyorum ve ben onların hayranı değilim. Anahtar şeylerden biri (göz ardı ile çalıştığım birçok insan) retrospektiflerin değeridir. Kısa süre önce JIRA'nın Agile panosunu kullanmaya başladık ve sık sık takıma takım performansının yanma tablosunu gösteriyorum. Eksik hikayeler, ne zaman ve ne zaman meydana gelirse tartışılır ve derhal biriktirmeye geri döner. Geriye dönük olarak, hikayenin neden eksik olduğuna bakıyoruz. Kaynak yetersizliği? Bilgi eksikliği? ya da belki ikisinin gevşek bir kombinasyonu.

— Issız Gezegen