Hata düzeltme yinelemesi nasıl hesaplanır?

9

Scrum'ı son 5 ayda oldukça başarılı bir şekilde uyguladık. Gerçi biz olmadan 3 hafta sonra PROD gelmektedir şimdiye herhangi uçtan uca entegrasyon testi yapıyor. Ah! Yardıma ihtiyacım var. Bunun nedenlerini ele almadan (BU noktada), şimdi küçük iyileştirmeler ve hala bilinmeyen birçok hata düzeltmesinden oluşan mevcut yinelemeyi planlamamız gerekiyor. Bu senaryoyu nasıl hesaplıyorsunuz? Henüz bulunamayan hataları düzeltmek için yinelemenizi nasıl planlıyorsunuz?

scrum bug planning

— Pomario
kaynak

16

"Scrum'ı oldukça başarılı bir şekilde uyguluyoruz ... uçtan uca entegrasyon testi yapmadan." Üzgünüm, yanlış yaptın. Her bir yinelemenin sonunda gönderim yapabilmeniz gerekiyordu.

— xsace

3

@xsAce 6 aylık bir yineleme

— Bart

3

Sorunun kendisi iyi ama süreç açıklaması bana işlerin ne kadar iyi çalıştığı hakkında inkar ettiğinizi hissettiriyor. Başka bir şey yapmazsanız, PO'ya ekibin şu anda bir çıkış tarihini taahhüt edemeyeceğini söyleyin. Yapabileceğiniz en iyi şey, bir sonraki yinelemede bir kalite değerlendirmesine odaklanacağınızı taahhüt etmektir. Bir sonraki geçmişinizde ciddi bir ekip tartışması yapın.

— GuyR

1

Bu sitede Scrum ile ilgili soruların geçmişini inceleyerek, şirketinizin Scrum gibi "hiçbir şey" yapmadığı ve bunun yerine Şelale gelişimine aşina ve daha rahat bir insan takımı gibi geldiği açıktır. Şelale kendiliğinden "kötü" değil, sadece yönetimin "Agile", "Scrum", "Sprint", "Backlog" ve "Planning Poker" gibi kelimeleri vızıltı kelimeler olarak kullanmayı sevdiğini ancak kültüre tam olarak bağlı olmadığını ve bunları yerine getirmek için gerekli yönetim değişikliği. Scrum'a bağlı kalmadan Scrum'ın faydalarını istiyorlar.

— maple_shaft

4

İnsanları ondan kapatan scrum süreç safları. Eğer bir problemi olduğunun farkında olmasaydı soruyu sormazdı. Nerede yanlış yaptığınızı bulmak ve gelecekteki yinelemelerde daha iyisini yapmak için adımlar atmak, çeviklikle ilgilidir. Bireyler ve süreçler ve araçlar üzerindeki etkileşimler.

— Karl Bielefeldt

7

Scrum ya da değil, hata düzeltme temel olarak tahmin etmek imkansızdır. Yapabileceğine inandığım en iyi şey:

Ne zaman yapılacağını ilk tahmin etmeden hemen test etmeye başlayın.
Her bir hatayı bulduğunuzda, tahmin edebileceğiniz noktaya kadar ilk analizi yapın.
Hatayı tahmin edin ve düzeltilip düzeltilmeyeceğine ve ilk relese için düzeltilip düzeltilmeyeceğine karar verin.
Düzeltilmesi gerekiyorsa, yinelemeye ekleyin.
Bir yazma grafiği çizin. Bir noktada azalmaya başlayacaktır, yani artık hataları düzeltmeyi yönettiğinizden daha hızlı bulmuyorsunuz. Bu noktada, serbest bırakılabileceği zaman kaba bir tahmin (ve giderek daha kesin) verebileceksiniz.

Bir dahaki sefere erken teste başladığınızdan emin olun ve giderken hataları düzeltin. Çevik olsun ya da olmasın tüm mantıklı metodolojiler, yeni özelliklerle ilerlemeden önce bilinen hataları düzeltmeyi gerektirir. Ayrıca, her bir özelliği ne kadar hata gidermek için ne kadar zaman harcandığını da hesaba katmalısınız;

Tahmin ve hata düzeltme, Kanıta Dayalı Programlama ve İnatçı Hata Düzeltme konularında Joel Spolsky tarafından iyi bir şekilde ele alınmıştır . Scrum ile ilgili değil, ama bence çoğunun geçerli olacağı kadar genel.

— Jan Hudec
kaynak

5

Hata düzeltme yinelemesi nasıl hesaplanır? Henüz bulunamayan hataları düzeltmek için yinelemenizi nasıl planlıyorsunuz?

"Hata düzeltme yinelemesi" ile ilgili. Bulunan hatalara hikayelerden farklı davranılmamalıdır. Her bir hatayı düzeltmek için çaba (öykü noktaları) tahmin etmek için ekiple birlikte çalışın ve hatanın bir sonraki tekrarlamaya geçip geçmeyeceğine karar vermek için ürün sahibi / müşteri ile birlikte çalışın.

"Henüz bulunamayan hatalar" ile ilgili. Tercihen, ekip her bir yinelemede sorunları bulup düzeltir. Değilse, bunu bir sonraki retrospektifinizde tartışın. Ürün kalitesi o kadar düşükse, sürüm mümkün değildir, hemen en iyi " hata bulucularınızı " hataları bulmaya (sabitlemez) taşıyın . Kalite, belirli kullanıcılara beta sürümü sağlayacak kadar yüksekse, bunu yapın. Yapamıyorsanız, en azından zayıf alanları tartışan canlı kullanıcı demoları sağlamanız gerekir.

— GuyR
kaynak

+1. Beta kalitesi aşamasındayken, akran testi oturumları yapmayı da düşünebilirsiniz.

— louisgab

2

'Hata düzeltme yinelemelerini' planlamıyoruz, ancak her sürümden önce sistem testi yinelemelerini planlıyoruz. Sistem testi, ürünün tüm parçaları üzerinde entegrasyon, regresyon ve realee testleridir. Testçiler ürünü test eder (oldukça büyük bir eski sistem) ve geliştiriciler bulunan hataları düzeltir. Hiçbir hata bulunmazsa ya bir sonraki proje için özellikler çizelgelerini araştırmaya başlarız ya da dahili iyileştirmeler üzerinde çalışırız.

Şu anda, kod dondurulduktan sonra (beş aylık bir proje için, sistem testi dahil), her şeyin çalıştığından emin olmak için altı haftalık sistem testleri planlıyoruz. Bu, uygulama yinelemeleri sırasında yapılan tüm testlerin başında gelir.

— Paula
kaynak

1

Bir dizi "serbest bırakma" kriteri tanımlamanız gerekir. Bunlar şunları içerebilir:

Arıza arasındaki ortalama süre
Günde bulunan hata sayısı
Günde bulunan kusurların şiddeti
Bekleyen kusur sayısı

vb.

Daha sonra, bazı kişilerin (manuel olarak veya otomatik testler yazarak) test ettiği ve diğer sabitlemelerin yapıldığı her bir yinelemenin sonunda ölçütlerinizi karşılayıp karşılamadığınızı kontrol edin. Daha sonra serbest bıraktıysanız, değilse başka bir yineleme için gidin.

Bu konuda bir geçersiz kılma olasılığı olmalı ve çoğu zaman ham sayılar uygulamanın gerçekçi bir resmini sunmuyor. Birkaç ciddi kusurunuz olabilir, ancak sadece kısa vadede yaşayabileceğiniz nadir koşullar altında ortaya çıkarlar.

— ChrisF
kaynak

1

Bunu yapmanın bir yolu, entegrasyon testiniz için hikayeler yazmak, bu sırada bulduğunuz hatalar için yeni hikayeler yazmak ve daha sonra bir sonraki yinelemedeki hata hikayelerini düzeltmektir.

Bunu yapmanın başka bir yolu da "Entegrasyon testinde bulunan hataları düzelt" yazan bir hikaye oluşturmaktır. Önceki sürümlerden, genellikle kaç sorun bulunduğunu ve düzeltmenin ne kadar zor olduğu hakkında bir fikriniz olmalı, böylece bu bilgiye dayanarak hikaye noktaları atayabilirsiniz. Belki daha yönetilebilir hale getirirse bileşenlere ayırabilirsiniz. Bunda daima kaçınılmaz bir belirsizlik vardır. Bunu hesaba katmak için bazı ekstra hikaye noktaları ekleyin.

Muhtemelen gecikmiş bir şekilde, en iyi yolun mümkünse her yinelemeye küçük bir entegrasyon testi dahil etmek olduğunu fark ettiniz. Bunu tanıdığınızdan ve bir sonraki sürümünüz için sürecinizi biraz geliştirdiğinizden dolayı tebrikler.

— Karl Bielefeldt
kaynak