Hata düzeltmeyi bir Scrum sürecine yerleştirmenin en iyi yolları? [kapalı]

Son birkaç gündür Scrum hakkında çalışıyorum ve okuyorum ve Sprint Planlama ve görevler hakkında okuyorum. Aklıma gelen sorunlardan biri, Scrum'da hatalarla nasıl başa çıkılacağıydı. Henrik Kniberg , Siperlerden yazdığı çok güzel kitabı Scrum ve XP'de bu sorunu ele almanın bazı yollarını listeliyor :

1. Ürün sahibi, en yüksek öncelikli Jira öğelerini yazdırır, bunları sprint planlama toplantısına getirir ve bunları diğer hikayelerle birlikte duvara asar (böylece bu öğelerin diğer hikayelere kıyasla önceliğini dolaylı olarak belirtir).
2. Ürün sahibi, Jira öğelerine atıfta bulunan hikayeler oluşturur. Örneğin "En kritik arka ofis raporlama hatalarını düzeltin, Jira-124, Jira-126 ve Jira-180".
3. Hata düzeltmenin sprint dışında olduğu kabul edilir, yani takım hataları düzeltmek için zamanları olmasını sağlamak için yeterince düşük bir odak faktörünü (örneğin% 50) tutar. Daha sonra, takımın Jira tarafından bildirilen hataları düzeltmek için her sprint için belirli bir süre harcayacağı varsayılır.
4. Ürün birikimini Jira'ya koyun (yani Excel'den kurtulun). Böceklere diğer hikayeler gibi davranın.

Bu gerçekten proje bazında karar verilmesi gereken bir şey mi yoksa daha iyi çözümler var mı? Bu yaklaşımların her biri ile ilgili sorunlar düşünebiliyorum. Bu yaklaşımlardan en çok işe yarayan bir melez var mı? Bunu projelerinizde nasıl ele alıyorsunuz?

Bu çok güzel bir soru ve konu bu soruna farklı yaklaşımlar geldiğinde bazı gözlemlerim var.

1. Tüm hataları biriktirme öğeleriyle eşit olarak ele almak teoride iyi bir fikir gibi görünebilir (iş tek bir yerde izlenir) ancak pratikte pek işe yaramaz. Hatalar genellikle düşük seviyelidir ve daha fazla sayıdadır, bu nedenle her hata için ayrı bir kullanıcı hikayesi oluşturursanız, "gerçek" hikayeler kısa süre içinde gizlenecektir.
2. Ürün sahibi tarafından görülebilecek bir şekilde yapılırsa, düzeltmeler için ayrılan her sprintte kesin süre iyidir. Günlük scrum sırasında hatalardan bahsedilmeli ve düzeltilen hatalarla ilgili tartışmalar sprint incelemesi sırasında yapılmalıdır. Aksi takdirde ürün sahibi projede neler olup bittiğinin farkında olmayacaktır.
3. Tüm iş yığınını hata izleme aracına koymak, 1'dekiyle aynı sorunlara yol açar. Üstelik, çoğu hata izleyici Scrum düşünülerek tasarlanmamıştır ve bunları bu amaçla kullanmak acı verici olabilir.

En tatmin edici bulduğumuz çözüm, her sprint'e "Biletler" veya "Hatalar" adlı tek bir kullanıcı hikayesi koymaktı. Daha sonra böyle bir hikaye, ya belirli bir hatayı açıklayan düşük seviyeli görevlere (planlama sırasında biliniyorsa) ya da genel hata düzeltmesi için belirli sayıda saati ayıran meta görevlere bölünebilir. Bu şekilde ürün sahibi süreçle ilgili görünürlüğe sahip olur ve kapanma tablosu ilerlemeyi yansıtır.

Aslında yeni özellikler olan tüm "hataları" acımasızca kapatmayı ve onlar için yeni biriktirme listesi öğeleri oluşturmayı unutmayın. Ayrıca, sprinti tamamlanmış olarak değerlendirmek için, sprint bitmeden önce mevcut sprint ile ilgili bildirilen tüm hataları düzelttiğinizden emin olun.

Aslında en iyisi tarafından cevap olduğunu düşünüyorum jpeacock Bu soru size Hüngür doğru hata düzeltmeleri için harcanan saatleri saymak Do?

Alıntı yapmama izin verin:

• Hata kolay / hızlısa (tek astar vb.), O zaman düzeltin.
• Hata önemsiz değilse ve engelleyici değilse, onu biriktirme listesine ekleyin.
• Hata bir engelleyiciyse, düzeltmek için gereken işi yakalamak için bir görev (mevcut sprint'e) ekleyin ve üzerinde çalışmaya başlayın. Bu, mevcut toplam saatiniz değişmediğinden, yeni saatleri hesaba katmak için başka bir şeyin (mevcut sprint'ten) iş yığınına taşınmasını gerektirir.

İlk adım, bir hatanın ne olduğunu tanımlamaktır. Bir hatanın, tasarlandığı / tasarlandığı gibi üretimde çalışmayan bir işlevsellik olması durumunda bir hata olduğunu öğretiyorum. Bunlar, yeni gelişime göre önceliklendirilecek hata tipi PBI'lar haline gelir. Üretimde eksik işlevsellik bir Özelliktir ve normal bir ürün biriktirme listesi öğesi haline gelir. Bir sprint sırasında bulunan herhangi bir hatalı kod eksik çalışma olarak kabul edilir ve mevcut hikaye bitene kadar bir sonraki hikayeye geçmediğiniz için; Takım her zaman sorun teşkil eden kod üzerinde çalıştığı için sprintte bu kusurları izlemek gereksizdir. Ekip arkadaşları arasında hızlı hatırlatıcılar için burada post-it'ler çok kullanışlı olabilir. Bozuk kodun düzeltilmesi her zaman yeni kod yazmaya göre önceliklidir.

Envanter israftır. Hata takibi envanterdir. Hata izleme israftır.

Tüm hataları biriktirme öğeleriyle eşit olarak ele almak teoride iyi bir fikir gibi görünebilir (iş tek bir yerde izlenir) ancak pratikte pek işe yaramaz. Hatalar genellikle düşük seviyelidir ve daha fazla sayıdadır, bu nedenle her hata için ayrı bir kullanıcı hikayesi oluşturursanız, "gerçek" hikayeler kısa süre içinde gizlenecektir.

Özelliklerden çok daha fazla hatanız varsa, mühendislik uygulamalarınız üzerinde çalışmanız gerekir. Bu, başka bir şeyin yanlış olduğu ve izlemenin yanıt olmadığı kokusudur. Daha derin kaz. Aslında böcekler her zaman kokar. Havalı değiller ve bunlardan çoğuna sahipseniz, temel nedenleri bulmanız, bunları ortadan kaldırmanız ve hataları izlemeye odaklanmayı bırakmanız gerekir.

Bir listedeki kusurları takip etmeyin, bulun ve düzeltin - Mary Poppendieck

Nitekim, envanter israfsa, kusurların envanterine ne dersiniz ...

Bu nedenle , test odaklı geliştirme ve sürekli entegrasyon ile her zaman bir Stop-the-Line zihniyetini uygulamaya çalışıyorum , böylece kusurların çoğunu bir yeniden çalışma listesine koymak yerine bulup düzeltiyoruz.

Ve kusurlar geçtiğinde, yeni kod yazmadan önce onları düzeltiriz (zaten hatalar içeren hikayeler yapılmaz). Ardından, daha hatasız hale getirmek ve hataları oluştuğu anda tespit etmek için sürecimizi düzeltmeye çalışırız.

Tüm çözüme uyan tek bir çözüm yoktur ve her proje farklıdır. Hatalar aynı zamanda kritik görevlerden düzeltmeye değmeyecek şekilde sınıflandırılabilir.

Sistemin çalışması için kritik olmadıkça, böceklerin hikaye kartları olmasını tercih ederim. Bu, özellik geliştirmenin önceliğini hata düzeltmeye karşı gerçekten açık hale getirir. Hata düzeltmelerinin "sprint dışında" kabul edildiği bir senaryoda, gerçekten önemli iş özellikleri geliştirilmediği halde, hata düzeltmeleri gerçekten önemsiz hataları gidermeye doğru hareket edebilir.

Hatayı hikaye yaklaşımı olarak belirlemeden önce bir dizi permütasyondan geçtik. Bazı farklı şeyler deneyin ve onları retro ekip toplantılarında tekrarlayın.

Bizim durumumuzda (yeşil alan geliştirme, 2-3 geliştirici) bulunan hatalar yazılır, açıkça bir hata olarak işaretlenir ve önem derecelerine göre bir sonraki yinelemeye atanır veya biriktirme listesinde bırakılır. Kritik ve acil hatalar olması durumunda, devam eden yinelemeye eklenirler.

Neden hataları düzeltmek kadar basit bir şeyin kurallarla karmaşık olduğunu bilmiyorum .. Scrum'ın çok az kuralı vardır, hatırladın mı? Her özellik, Destek, Öneri veya Kusur Scrum'da bir İş Listesi sorunudur, herhangi bir ayrım yoktur. Dolayısıyla, Scrum kılavuzunun dediği gibi: Bir Sprint'teki görevler asla planlama toplantısı sırasında karar verdiklerinizle sınırlı değildir Günlük Scrum, insanların yollarındaki "engelleri" tartışmalarına yardımcı olur.

Neden?

Dolayısıyla, kusurun, yani birikim sorununun PBI'ye girmesini veya bu Sprint'te kalmasını ve teslim etmesini istiyorsanız, bir ekip olarak rasyonel bir şekilde tartışır ve düşünürsünüz ...

Daha iyi soru, geliştirme aşamasında hata oluşturmayı nasıl durdurabilirim? bkz -> http://bit.ly/UoTa4n

Hataları tespit ediyor ve belgeliyorsanız, ileride bir süre sonra önceliklendirmeniz ve düzeltmeniz gerekecektir. Bu, "stabilizasyon sprintlerine", yani sadece hataları düzeltmek için bir tam sprint'e yol açar. Ya da onları iş yığınına geri ekleyebilir ve gelecekteki bir sprintin parçası olarak önceliklendirebilirsiniz. Aynı zamanda, içinde bilinen hatalar bulunan (P3 & P4 aka kozmetik ve küçük) imzalı ve piyasaya sürülmüş bir yazılım sağladığınız ve beklediğiniz anlamına gelir.

Bu gerçekten çevik değil mi?

Her üç sprintte bir kısa hata düzeltme sprinti başlatma fikrini projemizde sıraladım. Mevcut sprintlerimiz üç haftadır.

Buradaki fikir, tüm geliştiricilerin birlikte hata düzeltmeye odaklanmasına izin verecek, düzenli sprintlerde yalnızca yeni hikayelere odaklanmaya izin verecek ve teknoloji borcunu azaltmaya düzenli olarak odaklanmaya devam edecek.

Hata düzeltmeleri, ilgili hikayeler halinde gruplandırılacak ve öncelik sırasına konulacaktır. Geliştiriciler, hatanın doğasını anlamak için takılıp kalmadan hata düzeltmelerini boyutlandırmaya çalışırken, sprint öncesi boyutlandırma üzerinde durulmuyor.

Bunu deneyen veya bunun nasıl işe yarayacağını düşündükleri konusunda geri bildirimi olan var mı?

Şerefe Kevin.