Hata düzeltme görevleri için hikaye noktaları: Scrum için uygun mu?

Sadece hata düzeltme görevlerine hikaye noktaları atamamız gerekip gerekmediğini merak ediyorum. Sorun izleme yazılımımız olan JIRA'da, Hata türü sorunlar için hikaye noktası alanı yoktur (yalnızca Story s ve Epic ).

Hata sayı türünü Öykü Noktaları alanının geçerli sayı türlerine eklemeli miyiz ? Artıları ve eksileri nelerdir? Scrum için uygun olur mu?

İdeal olarak, yazılımınız her yinelemeden sonra hatasız olmalı ve hataları düzeltmek her süratin bir parçası olmalı, böylece hataları düzeltmek için gereken iş, hikaye noktaları atanırken göz önünde bulundurulmalıdır (yani, böcek üretme olasılığı daha yüksek olan bir görev, atanmış daha fazla hikaye puanı var).

Ancak gerçekte, testleriniz ne kadar katı olursa olsun, her zaman dağıtımdan sonra yüzeyde hatalar meydana gelir; Bu olduğunda, hatayı kaldırmak sadece başka bir değişiklik, eğer yapacaksanız bir özellik. Bu raporda bir hata raporu ile bir özellik isteği arasında temel bir fark yoktur: Her iki durumda da uygulama belirli bir davranış gösterir ve kullanıcı (veya başka bir paydaş) değişmiş olduğunu görmek ister.

İş perspektifinden bakıldığında, düzeltmeler ve özellikler de aynıdır, gerçekten: ya sen (senaryo B) ya da değil (senaryo A); Her iki senaryoda da maliyetler ve faydalar eklenmiştir ve iyi bir iş adamı onları daha da ağırlaştıracak ve daha fazla kar kazandıran her şeye (iş stratejisine bağlı olarak uzun vadeli veya kısa vadeli) devam edecektir.

Yani evet, elbette, böceklere hikaye noktaları verin. Hatalara ve özelliklere ve böceklere karşı böceklere öncelik vermeyi nasıl başaracaksınız? Her ikisi için de bir miktar geliştirme çabasına ihtiyacınız var ve bunun karşılaştırılabilir olması daha iyi.

Bununla ilgili en büyük sorun, düzeltmelerin genellikle tahmin etmekte zorlanmasıdır: gerçek çabanın% 90'ı veya daha fazlası, nedeni bulmakta yatar; bir kere bulduktan sonra, doğru bir tahminde bulunabilirsiniz, ancak aramanın ne kadar süreceğini değerlendirmek neredeyse imkansızdır. Hatta çoğu zaman sadece böceği yeniden üretmeye çalışırken harcanan böceklerden adil bir pay aldım . Öte yandan, böceğin doğasına bağlı olarak, bir tahminde bulunmadan önce araştırmayı biraz minimal araştırma ile daraltmak genellikle mümkündür.

Noktaları olan böcekleri tahmin etmek, diğer cevaplarda da belirtildiği gibi doğal olarak zordur ve evet, ideal çözüm, sprint kabul edildikten SONRA bir özellikte bulunan böceklerin yeni özellikler olarak kabul edilmesi gerektiğidir .

Bununla birlikte, hatalar için nokta tahminindeki bu zorluk, Agile PM yazılım paketlerinin, görevlerin ve hataların saatler içinde tahmin edilmesine izin vermesinin birçok nedeninden biridir, çünkü nokta tahmininde yetenekli olmak için incelik ve deneyim gerektirir. Pek çok proje uygun hız belirleme konusunda önemli problemlerle karşı karşıya kalmaktadır, bu yüzden birçok Çevik proje sprint içine hangi hikayelerin onu koyduğunu belirlemek için puanlar kullanmaktadır, ancak yazma çizelgesini hesaplarken saatler kullanmaktadır .

Karşı sezgisel görünmektedir ancak saat tahmini, sprint taahhüdünün belirlenmesinde bir faktör olarak kullanılmadığı sürece yönetilebilir görünmektedir. Aşırı bağlılık doğal olarak kaçırılan veya eksik olan özelliklere veya fazla mesaiye yol açacaktır, bu nedenle zamanla ilgili tüm görevler ve hatalar üzerindeki saati tahmin etmenin yavaş yavaş anlamsız bir ölçü haline geldiği nokta tahmininde daha iyi olmaya zorlanır.

Sen olmamalıdır hata çözünürlüğü puan verin. Böceğin, geliştiricilerin hikayeyi tamamlamak için zaten puan kazandığı bir hikayeden kaynaklandığını düşünün . Başlangıçta puan kazanmamış olması gerektiği yerde tekrar puan almamalı .

Hata tespitinin hız üzerinde olumsuz bir etkisi olmalıdır . Aksi takdirde düşürme kalitesi etkilenmemiş ve hatta arttırılmış bir hız ile ödüllendirilir!

Belki de faydalı bir link:

http://www.infoq.com/news/2011/01/story-points-to-bugs

Bu hatayı bir kullanıcı hikayesi olarak görmenizi ve birkaç puan vermenizi tavsiye ederim. "X olarak Y'yi istiyorum, böylece Z'yi" biçiminde yazmam gerekmeyebilir - kullanıcı hikayelerinde sıkça olduğu gibi - "X, IY, Z olduğunda ama Z 'beklenen davranıştır ".

Bunun avantajı, yeni özellik taleplerinin yanı sıra hata düzeltmelerini öncelikli hale getirmenize izin vermesidir. Gerçek şu ki, bazen, yeni bir özellik bir hatayı düzeltmekten daha önemlidir. Bununla birlikte, aynı zamanda, gereken işi uygun şekilde boyutlandırmanızı ve bunu yapabilme yeteneğine sahip olduğunuzda bir koşuya sığdırmanıza izin verir.

Bir hatayı düzeltmek için gereken çabayı tahmin etmenin zor olabileceğini akılda tutmak için bir şey. Birbiriyle etkileşime giren, birinin sistemin büyük parçalarının etkileşimlerine çok aşina olmalarını ya da düzeltme üzerinde çalışacak çok sayıda kişinin bulunmasını gerektiren birden fazla bileşen içerebilir.

Hikayeleri tahmin etmek, bir ekibin zaman içinde bunları çözmede deneyim kazandığı fikrine dayanır. Bununla beraber doğruluk geliştirilir ve takımların hızını ölçmek için bir hız oluşturulabilir. Gelecekteki sprintler için güvenilir tahminler oluşturmak için mükemmel bir metodoloji.

Hatalar bir yazılım geliştirme şirketi için yaşamın bir gerçeğidir. Bir hikayenin geliştirilmesi sırasında böceklerin hepsinin yakalanması gerektiği, buna her zaman ulaşılamayacağını kabul etmekle birlikte, her ekibin planlaması gereken bir şey olması gerektiği konusunda hemfikirim. İnatla, sürecin takıma hükmetmesi gerektiğini düşünmek yerine, tam tersi olmalıdır.

Tabii ki, böcek ya da hikaye, iş tarafından takımın neyle uğraştığı önemli değildir. Her ikisi de ürün sahibi için eşit miktarda değer üretebilir.

Ekibimizde hataları tahmin etmek için bazı teknikler denedik:

1. Tamamen bilinmeyen hataları tahmin etmek
2. Sadece zaten analiz edilmiş böcekleri tahmin etmek
3. Hata düzeltme ve hataları tahmin etmemek için zaman ayırın, ancak bunları yalnızca işletme değerine göre sıralayın

1. ile sefilce başarısız oldu. Çoğu hata için zamanın% 90'ının böcek analizine harcandığını tespit ettik. Bundan sonra hata düzeltme bir hikaye olarak aynı şekilde tahmin edilebilir. Bir sprint içine böcek planlayarak, bilinmeyen kapsamın, bu şekilde yaptığımız hemen hemen her sprintin başarısız olduğu noktaya kadar hikaye çözünürlüğünü etkilediğini yanlış yaptık.

90/10 oranına (hata tespitine göre analiz) göre tahmin tekniği seçeneği 2. seçeneği, sprint planlaması için kapsanmayan bir analiz yapmayı planladığımız anlamına geliyordu (seçenek 1'den öğrenmiştik, ancak gerçek bir çözümü yoktu) analiz edilmiş böceklerle nasıl devam edileceği). Sonuçta, bir sprint planlanan öğelere odaklandığından beri böcek analizi yapılmamıştır. Takımın, backlog'daki hatalara odaklanmak için zamanı yoktu. Sonunda onlar da yapılmadı.

Belirsizliği benimseyerek, şimdi seçenek 3'e karar verdik. Ürün biriktirmeyi, ekip tarafından hikaye puanları ve bir hata bildirimi kullanarak tahmin edilebilecek düzenli bir hikaye / görev bölümüne ayırdık. Böcek birikiminde, ürün sahibi işletme değerine ve çok kaba bir takım kararına dayanan hataları sıralar. Ekip, böceklere odaklanarak harcayabileceği bir sprint boyunca çok fazla zaman ayırmasına izin veriyor. Ürün sahibi kesin sonucu bilmiyor çünkü daha önce bunu planlamak mümkün değildi. Böcek biriktirme ve düzenli biriktirme oranı, her bir birikintinin mevcut durumuna ve içeriğin önemine ve ticari değerine bağlı olarak her sprint için ayarlanabilir.

Belirsizliği ortadan kaldırarak takımı tekrar serbest bıraktı. Sprint'ler bilinmeyen böceklerden ödün vermedi. Her iki takımın da düzenli sprint odağını yükselten ve hataları farklı bir iş grubuna ayırarak, bize önemli bir iş değeri de içeren böcekleri bitirmemizi sağladı.

Bu yüzden hikaye noktalarının sizin için uygun olup olmadığına bağlı. Önce hikaye noktalarını kullanarak hataları tahmin etmeye çalışırdım. Bu başarısız olursa benim seçenek 3'ü deneyin. (30'dan fazla sprint eski) ekibimiz daha büyük iş değeri içeren eski böceklere odaklandı. Ayrıca, ekibin basitçe tahmin edemediği bir şeyi sunmaya çalışmaktan da kurtuldu. Bu gerçeğe daha yakın bize var ve ayrıca başarılı yine bizim sprintler yapılan bilinmeyeni kucaklayan edildi ederken hata düzeltmeleri aracılığıyla iş değerinin (hikaye oranına hata dayanarak) büyük bir parçasını teslim. Son zamanlarda kullandığımız oran 50/50 idi.

Öykü noktalarının hatalara atanmasındaki en üst cevaba katılmıyorum. Öykü noktaları, teslim edilen yeni değer için olmalıdır. Ürün değerine ve değer içermeyen öğelere puanlar atayacaksanız, sadece saatleri tahmin edip izleyebilirsiniz.

Hatalar, dün yaptıklarınızın yüküdür ve ürün tamamlama hızının göstergesi değildir ve herhangi bir yeni ürün değeri de yaratmazlar (bunu düşünün). Böcekler bir tür kesintidir ve haftalık olarak uğraşmanız gereken diğer tüm inek turtalarıdır. Tüm hikaye noktaları fikri, ürünü (veya özellik kümesini) ne zaman teslim edeceğimizi izlemesi / tahmin etmesidir. Öykü noktaları rastgeledir ve işte bu değer dışı yükü tahminlerden çıkarır. Genelde, değer dışı çalışma haftadan haftaya sabittir, bu yüzden takım hızına dahil edilir. Takım, bu değer dışı işi kaldırdığında veya azalttığında hızlanacaktır.

Başka bir deyişle, neden hataları izleyelim ki? Böylece günün sonunda her üyenin ne kadar "iş" yaptığını biliyorsunuz? Kes şunu! Kötü menajer! :) Takımı ölçün, oyuncuyu değil. Bir kişi ağırlığını çekmiyorsa, takımı kendilerini yönetmeye teşvik edin. Çok daha etkili. Hikaye noktası öğeleri yapmak, bir bireyi daha iyi hissetmemelidir, ancak sprint sonunda kararlılıklarını sürdürürken bir bütün olarak takım daha iyi hissetmelidir. Sporda amaç takım veya birey için iyi mi? Birey kendisi için oynarsa takım uzun vadede kaybeder.

Biliyorsun, sonunda hiç puan kullanmamak istiyorsun. Tahmin, gerçek işten uzaklaşan zamandır. Bir takım maksimum chi'ye ulaştığında , hiç puan kullanmazlar ancak bir sprint içine kaç tane madde bulabileceklerini tam olarak bilirler. Tahminin süreç israfı olduğu iş birimlerini bölme sanatında ustalaştı.

Bazı görevler tahmin edilebilir, bazıları değildir. Tahmin edilemeyen şeyler için bir bütçe kullanın.

Bir hatayı düzeltmek, kolay tahmin edilebilir bir iş değildir, çünkü üzerinde birkaç bilinmeyen bileşen vardır. Kusura neden olan nedir? Sebep anlaşıldığında, nasıl düzeltilebilir? Bu değişikliğin sistemin geri kalanı üzerinde nasıl bir etkisi var? Bu hatayı düzeltmek için kaç yeni kusur enjekte ettiniz?

Bir hatanın nedeninin yazılım yaşam döngüsünün herhangi bir noktasından gelebileceğini unutmayın - yanlış anlaşılan veya yanlış anlaşılan gereksinimler, zayıf tasarım veya yanlış varsayımlar, zayıf kodlama, hatalı test, mevcut sürümden alınan bilgiye dayalı yeni bilgiler ...

Bütçe oluşturma, hata düzeltme görevleri için birkaç farklı yolla yapılabilir. İşte etkili kullandığım bazı fikirler:

• Hata düzeltme için ne kadar zaman ayıracağınızı anlamanıza yardımcı olmak için geçmiş verileri kullanın (önceki bir yinelemeden söyleyin).
• Hata düzeltme işleminin "bloklarını" (5 puan veya 20 saat) söyleyin ve müşterinin hikayeler yerine bunu seçmesine izin verin.
• Ekibinizin her bir üyesinin, her yineleme sabitleme kusurunda belirli bir süre tahsis etmesini isteyin.

Amacınız, tahsis edilen bütçe dahilinde mümkün olduğu kadar fazla hatayı düzeltmektir. Bildirilen hataları önceliklendirmek için müşteri stratejilerinizle görüşün. Örneğin, kusurları öncelik sırasına göre önceliğe göre sıralıyor musunuz? Sıkı öncelik? Önce "alçak meyveli meyvelere" mi saldırmalısınız? UI önce hata mı veriyor?

Ayrıca, hataların giderilmesi de değer kazanmaz. Sabitleme hataları bir atık şeklidir. Bu özellik için zaten değer kazandınız, bu nedenle hataları düzeltmek için "bonus puan" almamalısınız.

Bütçeye sahip olmak planlama konusunda size yardımcı olur ve yine de size Velocity'in doğru bir resmini sunar. Hata tespiti için belirli bir puan verin, bütçeye tarihi verilerinize göre yaklaşık bir süre verin ve bütçelendiğiniz süre boyunca olabildiğince fazla böcek ezin!

Hikayelere, hatalara ve işleri ve her birinin sahip olduğu noktalara odaklanmak yerine, müşteriye özellikler sunmaya odaklanmayı daha iyi buluyorum.

Müşteriler, yazılımın çalışmasını bekler ve yalnızca işi ilerlettiği için geliştirmeye, geliştirmelere ve yeni özelliklere gerçek değer verir.

Hata düzeltmeleri, olabilecekleri kadar önemli olduğu için, işi yeni alanlara ve yeni müşterilere doğru yönlendirmez (teğetsel ve nihayetinde belki de evet, ancak hangi yönetimin ölçmekte olduğu hemen değil).

Bu yüzden puanlar daha yüksek hız bakış açısıyla ve benzer puanlama öyküler için tarihsel olarak haftada kaç puan yapıldığı ile izlenir.

Bu, bu hafta hikayelerinin tamamlanmasına ve sık sık olmadıklarını bulmak için acil ihtiyaç duymaya çalışmak yerine, kayıt geçmişini takip ederek yönetime yol açabilir. Ancak, ön kontrolün kaybı ve bunun gerektirdiği konusunda artan güven, kapıdaki bazı yöneticilerin dehşet içinde çalışmasını sağlayacaktır.

Pivotal Tracker (Ben sadece JIRA, Trak, Trello ve diğerleri de kullanıyorum) kullanıyorum ve Pivotal Tracker da ev işleri veya hatalar için puan vermiyor. Kendinizi gördüğünüz gibi JIRA’da da doğru kılan yukarıdaki aynı iyi nedenlerle yapıldı.