Vakalar hatalar için yeniden mi açılmalı yoksa hatalar yeni bir vaka olarak mı açılmalıdır?

Şu anda iş yerimde , farklı web uygulamalarımız için tüm özelliklerimizi ve hatalarımızı yönetmek için FogBugz kullanıyoruz .

Web uygulamalarımızdan birine yeni bir özellik ekleneceği zaman yeni bir Vaka oluşturulur. Örneğin "CSV Yükleme Formu Oluştur".

Daha sonra dava için harcadığım zamanı kaydederek çalışıyorum. Bu dava tamamlandıktan sonra bunu çözdüm ve daha sonra davayı kapatan vaka açıcısına (genellikle proje yöneticisi) geri atanır.

Bu özelliğe sahip herhangi bir hata varsa, Proje Yöneticim vakayı yeniden açar ve bir bullet nokta hata listesi ile bana geri atar.

Bence bu mermi sivri böceklerin bireysel hata durumları olarak açılması gerektiğine inanıyorum, böylece daha kolay takip edilebilir ve orijinal özellik durum notlarıyla darmadağın olmazlar.

Yöneticilerim benimle aynı fikirde ise, özellik için harcanan toplam sürenin daha kolay olduğunu belirtiyor.

Ayrıca, müşterilerimiz için daha az kafa karıştırıcı olduğuna inanıyorlar, çünkü özellik için sadece 1 vaka numarası referansı var. Bununla birlikte, orijinal vakanın tamamlanmasından sonra hataların ayrı durumlar olarak ele alınması gerektiğini vurgulamak isterim.

Hataların yeni bir vaka olarak yeniden açılması gerektiğini belirtmekte haklı mıyım? Ve bunu yönetmenin her yolunun artıları / eksileri nelerdir?

Hem sizin hem de yöneticinizin, her birinizin tercih ettiği şekilde ilgilenmek için iyi bir nedeniniz var ve taviz vermek için gerçek bir ihtiyaç yok. Benim için çalışan ve her iki endişeye de cevap veren bir çözüm var.

Sizinki gibi durumlarda yüksek düzey görev / düşük düzey alt görevler yaklaşımı kullanıyorum ( JIRA'dan aldığım konsept , FogBugz desteğinin açıkça ^{göründüğü gibi} olup olmadığını söyleyemiyorum ). Bu şekilde, "müşteriye dönük" madde işaretli listeler üst düzey görevlere giderken benim için önemli olan "geliştirici yinelemeleri" alt görevlere yansır.

Yüksek düzey görev "yeniden" zaman, ben ilave çaba izlemek için yeni bir alt görev oluşturmak kendini .

Bu şekilde geliştirici, özellik belirtiminden geçen tüm permütasyonları, sapkınlıkları ve bükülmeleri net bir şekilde yansıtmaya izin verir ve yine de yöneticinin istemcilere mükemmel olarak sunmasını sağlar. Bu arada mükemmel sunumun bana geliştirici olarak değeri var - çünkü müşteriler için daha kolay okunabilmesi daha doğru ayarlamalar yapılmasına yardımcı oluyor.

Bu, doğal olarak, özellik uygulamasının başlangıçta beklenenden çok daha fazla zaman aldığı durumlarda açık bir gerekçeye sahip olmasına izin verir.

_{Görev veya alt görev başına zaman takibine gelince - JIRA alt görev takibini daha üst düzey bir özete dahil etmeye izin verdiğinden, alt görevlerde zamanı izlediğim yönetici için kabul edilebilir. Ancak, durum böyle olmasa bile, "ebeveyn" görevinde resmi olarak izleme süresiyle yaşayabilirim - bu durumda, belirli yinelemede ne kadar zaman harcandığını belirtmek için alt görev yorumlarını kullanırdım.}

Özellik müşteriye sunulmadan önce tüm bunlar oluyorsa, sadece bir vakanız var. Buradaki argüman, davanın KG'ye geçip serbest bırakılmaya hazır olana kadar tam olarak tamamlanmadığıdır. Diğer avantajlar - faturalandırmanın ve son kullanıcıların referans vermesi gereken tek bir vaka numarası geçerli ve önemlidir.

Özellik kullanıma sunulduktan ve hatalar bulunduğunda bunlar sorun izleme yazılımınızda yeni sorunlar olarak gündeme getirilmelidir.

Sana tamamen katılıyorum ve FogBugz da - Bu yüzden Hatalar ve Özellikler için farklı kategoriler tanımlar. FogBugz zaman kullanımını izlemek için bir araç olarak tasarlanmamıştır; bu, kanıta dayalı çizelgelemenin getirilmesinin tesadüfi bir yan ürünüdür.

Tamamlanan bir özelliğin hataları, özelliğin ana durumuna bağlanabilir (FogBugz'da, bir etiket adı veya çapraz referans kullanarak veya alt durumlar yaparak). Bunun, PM'niz için çeşitli durumlarda bilgileri birleştirmek için biraz daha fazla iş olduğunu görebiliyorum, ancak özellikle sabit fiyatlı sözleşmeler için orijinal geliştirme ve bakım için harcanan zamanı ayırmak da genellikle mantıklı. her şeyi bir davaya koyarsanız bunu yapma yeteneğinizi kaybedersiniz.

Bence bir bilet kapatıldıktan sonra kapalı kalmalı, hata izleyiciniz yine de diğer durumlarda bağlantı kurabilmelidir. Yeni hatalar oluşturmanın ve orijinal duruma bağlamanın, tarif ettiğiniz yöntemden daha iyi faydalar sağladığını belirtmeye çalışacağım.

• istemciler yine de her hataya bağlantı içeren bir referans numarasına sahip olabilir.
• her hatanın durumu ayrı ayrı izlenebilir, böylece daha iyi öncelik ve durum raporlaması sağlanır.
• ayrı hatalara sahip olmak, yöneticinizin hatalara harcanan zamanı ve yeni özellikler geliştirmek için harcanan zamanı parçalamasına izin verir ve bir değişiklik ve bu değişikliğin gelişimi ile ilgili tüm hatalar için toplam sayı elde etmek için yalnızca minimum bir çaba olmalıdır.
• hataları ayırmak, yöneticinizin toplam hata, hata düzeltmesi başına ortalama süre, kapalı / devam eden / sabit hata oranları gibi diğer metrikleri toplamasını kolaylaştırır.
• hata başına ayrı vakalar, görevlerin tüm geliştiriciler arasında daha iyi bölünmesine ve her birinin kendi çalışmaları için sorumlu tutulmasına izin verir veya daha sonraki bir tarihte daha fazla geliştiricinin işe alınması durumunda bu olasılığa izin verir.

Mevcut kurulumunuzun tek avantajı, sistemin ana kullanıcıları olmayan insanlar için son derece basit olmasıdır. Bir hata izleyicinin amacı, geliştiricinin bir hata hakkında her şeyi tek bir yerde bildirecek bir yere sahip olması ve aynı zamanda başkalarının ilerlemeyi görmesi için yeterince arkadaş canlısı olması, mevcut sisteminizin neredeyse her bölümünü zayıflattığı görülüyor.

Ürün müşterilere 'gönderildikten / bırakıldıktan' önce veya sonra bulunan hatalar mı?

Bir sürümden önce ise, hatalar orijinal bilete göre izlenmelidir.

Bir sürümden sonra ise, her hata kendi bileti olmalıdır.

Çalıştığım yerde sadece KG çalışanları bir davayı kapatabilir. Kod İncelendi, Mühendis Test Edildi ve Paydaşlara Gösteri (sizin durumunuzda Proje Yöneticisi) için onay kutularımız var. KG ekibi "Tamamlandı" olarak işaretlenmiş ve tüm bu alanları işaretlememiş bir davayı görürse, geri alındı ​​olarak işaretler ve bize geri gönderir.

Bir vaka tüm bu aşamaları geçip KG durumu kapattığında buldukları yeni sorunlar hata olarak kaydedilir.

Bu sistem bizim için iyi çalışıyor gibi görünüyor.

Bence her iki şekilde de argüman yapabilirsiniz. Başbakan ile oturup neden farklı sorunlara sahip olmanın size yardımcı olacağını düşündüğünüzü açıklamaya çalışacağım. Şahsen her yapılacak işin kendi bileti olmasını istiyorum ama neden bu şekilde istediğini görebiliyorum.