Sorun izleme sistemlerini kullanmanın dezavantajları hakkında çalışmalar var mı? [kapalı]

9

Sorun izleme sistemlerini sevmiyorum çünkü:

İçindeki sorunları tanımlamak çok zaman alıyor. Bu, kullanımını engelliyor.
Hatalarınızı tutmak için bir yer oluşturursunuz. Ve onlar için bir yer varsa, insanlar genellikle bir hatayı düzeltmek için çok fazla umursamazlar, çünkü bir gün birinin onu düzeltebileceği (veya edemeyeceği) için onu koyabilirler.
Zamanla, hata listeleri o kadar uzun olur ki artık kimse onunla başa çıkamaz, zamanımızın çoğunu alır.

Sorunları bir beyaz tahtada post-it kullanarak, yüz yüze görüşmelerle ve önemli hataları ortaya çıkar çıkmaz öldürmeyi tercih ederim. Ben hata geçmişini takip etmek için fazla umurumda değil çünkü ben yükü değer olduğunu sanmıyorum.

Burada yalnız mıyım? Sorun izleme sistemlerini kullanmanın dezavantajları (veya büyük avantajları) hakkında çalışmalar (kitap / makale / ne olursa olsun) var mı?

project-management agile issue-tracking

— user1062120
kaynak

5

Kapatmak için oylama, çok yerelleştirilmiş. Buradaki sorun, şirketteki hata işleme süreciyle değil, sorun izleme sistemleriyle ilgili görünmüyor.

— P.Brian.Mackey

1

Hangi sorun izleme sistemlerini denediniz (post-it notları ve yazı tahtaları hariç)? Kullanımları ile ilgili süreç nasıldı?

— FrustratedWithFormsDesigner

1

Bunlardan sadece Jira'yı kullandım (siz onun "ritmine" alışana kadar çok fazla yükü olduğu anlaşıyorum). Web kullanıcı arayüzünün bir hayranı değil, ama işi hallediyor. Burada ayrıca kaynak kontrolü yapan MKS kullanıyoruz. Jira'dan daha iyi. Hiçbiri mükemmel değil, ama hepsi hala kağıt notlardan ve insanların yanıltıcı organik anılarından daha iyi.

— FrustratedWithFormsDesigner

15

Sanırım soru kafam karıştı. Kullanılması post-it üzerinde beyaz tahta bir IS bir sorun izleme sistemi. Proje / ekip / kod tabanınız yeterince küçükse ve yüz yüze yüz yüze çalışsa, muhtemelen sürece daha fazla ek yük eklemeye ikna etmekte zorlanacaksınız. Aşağıda belirtildiği gibi böyle bir sistemi kullanmak için birçok aşağı taraf vardır. Proje ve ekip büyüdükçe, özellikle ekip üyeleri aynı binada, şehirde veya ülkede olmayabilirken, diğer sistemler aşağıdaki yanıtlarda belirtildiği gibi parlamaya başlar.

— s_hewitt

2

bir gönderiye yığın izlemeyi nasıl eklersiniz? veya ekran görüntüsü? ya da bir hata mesajı?

— jk.

41

İçindeki sorunları tanımlamak çok zaman alıyor. Bu, kullanımını engelliyor.

Eğer bir hatayı tarif bile edemiyorsanız nasıl düzeltebilirsiniz?

Hatalarınızı tutmak için bir yer oluşturursunuz. Ve onlar için bir yer varsa, insanlar genellikle bir hatayı düzeltmek için çok fazla umursamazlar, çünkü bir gün birinin onu düzeltebileceği (veya edemeyeceği) için onu koyabilirler.

Bu, yazılımla değil, ekibinizle ilgili bir sorundur.

Zamanla, hata listeleri o kadar uzun olur ki artık kimse onunla başa çıkamaz, zamanımızın çoğunu alır.

Yine ekibinizle ilgili bir sorunu tarif ettiğiniz.

Hata izleme yazılımının amacı, ekibinizi hataları düzeltmek için motive etmenize yardımcı olmak değil, hataların nedenini takip edebilmeniz ve tekrar olmasını durdurabilmeniz için bir kayıt tutmaktır. Hiçbir yazılım iyi yönetimin yerini tutmaz.

— Tom Squires
kaynak

İzleme yazılımı ayrıca düzeltilecek hataları izlemeye yardımcı olur. Yapışkan bir not düşebilir ve dört kişi size doğru çalışabileceğiniz hatalarla gelirse, üçünü düzeltebilir ve dördüncüyü unutabilirsiniz. Hataların nedenlerine dikkat etmeseniz bile yararlıdır.

— David Thornley

ve ekibinizle sorunu çözmek için oyunlaştırma kullanabilirsiniz -> en.wikipedia.org/wiki/Gamification

— marc.d

11

@JoaoBosco: Elle yazılmış biletler kaybolur, karalanır, kazara atılır ... yüz yüze konuşmalar, fotoğrafik belleği olmayan insanlara karmaşık hataları tanımlamanız dışında harika. İnsanlar olacak onlar istemiyor çünkü konuşmaları şeyleri unutmak ama bu sadece çünkü ne olur.

— Sinirli

3

@JoaoBosco: GUI hatalarının ekran görüntüleri ne olacak? Onları elle yeniden çizecek misin? Yanlış veri çıktısı örnekleri (eğer bir veritabanı hatasıysa, m sütunu yanlış veri içeren n satırları elle yazmaya hazır mısınız?) Sadece yapışkan notlara iyi tercüme edilmeyen kusurla ilişkili diğer dijital eser türleri? Tüm bunlar bir sorun izleme sistemindeki bir bilete kolayca eklenebilir. Daha sonra yapışkan notunuzu metin dosyalarına dönüştürecekseniz, biletlerinizi sıralamanıza, sıralamanıza, kategorilere ayırmanıza izin veren bir veritabanı neden sorun izleme için biraz daha fazla.

— FrustratedWithFormsDesigner

10

@ user1062120: "Eğer hataları tutacak bir yer yoksa, insanlar onu daha sık düzeltmeye başlar" - ya da hataları görmezden gelmeye ve unutmaya başlarlar. Bu bir "insanları motive etme hilesi" değil, bir zayıflığı bir güce yeniden etiketlemek için saçma bir girişimdir.

— Michael Borgwardt

12

IMO başlangıç noktanız taraflı. Geliştiriciler hataları düzeltemezlerse, uygun bir hata izleme aracı, post-it, taş oymalar kullanarak hataları izleyip izlemeseler de, proje başarısız olmaya mahkumdur. Kullanılmadığı veya yanlış kullanıldığı takdirde aracın hatası değildir. (Elbette, orada kötü hata / sorun izleyicileri var ... Bu iş için tamamen yetersiz bir araç kullanarak bir proje üzerinde çalıştım, bu yüzden ne kadar kötü olabileceğini biliyorum. Ama iyi olanlar da var, asgari tören ve ek yük gerektiren, ilgili bilgilere odaklanmanızı sağlar.)

Bununla birlikte, geliştiriciler umursarsa ve proje önemsiz boyuttan daha büyükse ve üzerinde tek bir geliştiriciden daha fazlası varsa ve dahil olan bir tür yönetim var (hepsi gerçek dünya projelerinde oldukça yaygındır) ), yakında aşağıdaki gibi sorular ortaya çıkacaktır:

İlk önce açık hatalardan hangisi düzeltilmelidir? (not: aklı başında bir projede bu, bir geliştirici tarafından DEĞİL ürün sahibi ve / veya yönetimi tarafından kararlaştırılmalıdır - öncelikle açık hataların farkında olmaları gerekir !)
Kaç tane açık hata var ve hangi ciddiyette?
Serbest bırakılmaya hazır olmadan önce bunlardan hangileri düzeltilmelidir?
Bu düzeltmeler için ne kadar zaman planlanır - genellikle aşağıdakilere yol açar: bir hatayı ortalama olarak düzeltmek için ne kadar zaman gerekir?
son sürümde müşteriler tarafından kaç hata bildirilmiştir?
bu ve bu hatayı kim, ne zaman ve ne (kod / yapılandırma / veri) değişikliklerini düzeltti?
yayınlamak üzere olduğumuz sürümde hangi hata düzeltmeleri var?
...

Bu soruları tekrarlı, güvenilir ve verimli bir şekilde cevaplayabilir misiniz [/ update] post-it notlarınıza dayanarak ?

Evet, bir sorun izleyiciye hata verilerinin girilmesi bazı ek yükler gerektirir. Bununla birlikte, saklanan hata verilerinden yukarıya bakarken ve yukarıdaki gibi raporlar oluştururken harcanan zaman ve çabadan daha fazla telafi edilir.

— Péter Török
kaynak

Post-it her şeye cevap vermez. Bu sadece bir araç. Hala onları önceliklendirebilir, açık hatalar, sabit olanlar vb.

— user1062120

7

@ user1062120: Ve herkesin söylediği tek şey çok, çok yanlış olduğun. Post-onun olduğu bir sorun izleme sistemi, temel özellikleri bir çok yoksun sadece çok zayıf bir.

— Michael Borgwardt

@ user1062120, bunların hepsi teoride tabii olabilir yapışkan notlar yanıt bulunamayan - Eğer her birine benzersiz kimlikler eklerseniz, bir süre :-) sonra oldukça büyük yapışkan notlar ihtiyaç başlar böylece (onlara detaylı geçmişi yorumlar ekleyerek tutmak ve mevcut soruya göre bunları sıralamak, yeniden sıralamak ve yeniden düzenlemek için çok fazla zaman harcayın (daha büyük bir projede yeni bir adam kiralamanız gerekebilir ;-).

— Péter Török

@ user1062120, örneğin planlama yukarıdaki Soru 1'i verir - yapışkan notları önceliğe göre yeniden düzenleyelim. Yakında PM Q2'yi soruyor: ayy, şiddete göre yeniden düzenleyin. Ama Q1 hala açık, şimdi hepsini öncelik sırasına göre sıralayalım. Ayy, 3 post-its dışarıda kaldı çünkü Joe'nun masasındaydılar - baştan başla! Sonra Q6 - tarihsel post-it depolayan kutuları kazalım, uygun olanı bulmak için hepsine elle göz atalım, sonra arkasındaki karalamayı okumaya çalışın, değişiklikleri tanımlamak için ... hadi, biri açıldı Yakındaki pencerede, post-it'inizi rüzgardan kaçmaktan kurtarmak için acele edin ... vb.

— Péter Török

9

Metodolojiniz sınırlı sayıda programcıya sahip çok küçük projeler için işe yarayabilir. Bir proje büyüdükten sonra, özellikle farklı kod sürümlerinde düzeltmeler yapılacaksa, bir sorun izleme sistemine sahip olmak farklı takımlar arasındaki koordinasyon için çok daha önemli hale gelir. Karmaşık projeler birçok hareketli parçaya / bileşene sahip olacak ve sorunların planlanmasını ve düzeltilmesini sağlamak, iyi bir sorun izleme uygulamasının büyük bir parçası

İlginizi çekebilecek bazı makaleler / çalışmalar , Zend'in Jira kullanımını tartıştığı bu makaleyi ve hata izleme sistemlerinin kullanımını tartışan bu Fransız çalışmasını içerir.

— JW8
kaynak

1

Referanslarınız için çok teşekkür ederim. Onlara bir göz atacağım. Ve evet, burada 3 küçük ekip içinde çalışıyor.

— user1062120

2

Soruda açıklık istenen referanslar için +1.

— mattnz

4

Çalışmalar olabilir, ancak alandaki insanların zor kazanılmış deneyimleri daha da iyidir. Çoğu sorun izleme sistemi, tasarımlarını yönlendiren süreçlerden muzdariptir. Sorun izleyicilerin genellikle 2 farklı kullanıcı sınıfını desteklemesi gerekir:

Geliştirme ekibi
Sistem kullanıcıları

Cal Henderson (eski adıyla Flickr), birçok sorun izleyicinin tasarımı ve GitHub sorun izleyicisini neden tercih ettiği konusunda harika bir yazıya sahip (benim gibi). Ayrıca, Garrett Dimon tasarımını kapsadığı Sifter ve daha fazlası için sürecini kolaylaştırmak için bir yol tasvir etkili sorun izleme . Ekibimin sorun izleme iş akışını basitleştirmeye yardımcı olmak için bu gönderilerden de bazı fikirleri kabul ettim.

Bütün bunlar, hala süreç ve araçlar üzerinden insanlara geliyor. Benim genel düşüncem, sorun izleyicilerin yönetmeniz gereken bu birikmiş işi oluşturma eğiliminde olduğudur. Triyaj sırasında, insanların hata olan veya olmayan şeyleri rasyonelleştirme olasılığı daha yüksektir. Sürecimizde, hata bir sorun olup olmadığı hakkında hemen dosya açılır almaz kararlar alırız. Bu karar verildikten sonra, hata Pivotal Tracker'a gider. Buradaki fark, önceliklendirme için İzleyici'yi kullanmamızdır yapmak istemediğimiz şeyler için bir tutma kalemi olarak değil, . Aslında Icebox çok büyük olmaya başladığında, hatalar dahil olmak üzere öğeleri aktif olarak silerim. Bir sorun, ele alınması gereken kadar büyükse, tekrar ortaya çıkacaktır.

Hata geçmişine nadiren ihtiyacımız var. Bazen, birisi bir hata belirtisinden bahsedebilir ve zaten ele aldığımız bir sorunla ilgili olup olmadığını görmek için bir arama yapabiliriz. Ancak, bu nadirdir.

TL; DR İşleminize odaklanın, basit araçları seçin ve sorunları ortaya çıktıkça ele alın.

— kstewart
kaynak

Demek istediğim bu. Öğeleri göründükleri anda önceliklendiririz ve önemli olmayan öğeleri de sileriz. Önemli şeyler zamanla geri gelecek. Ben her şeyi takip etmek için ek yükü layık olmadığını buldum. Küçük bir post-it beyaz tahtaya sahip olma fikri, her şeyi fiziksel olarak kaydedemezsiniz, sadece önemli şeyleri. Bu hile sizi mümkün olan en kısa sürede halletmeye zorlar. Ama bu benim durumum, bu yüzden her yerde işe yarayıp yaramayacağından emin değilim.

— user1062120

2

önemli hataları ortaya çıktığı anda öldürmek

Buradaki açık kapıya girdiğiniz anlaşılıyor. Sorun izleyici kullansanız da kullanmasanız da önemli hatalar en kısa sürede "öldürülür".

Oh ve bölümü "göründüğü gibi" oldukça kaygan BTW olduğunu. Bir projede, tüm ürünü işten çıkarmakla tehdit eden önemli bir hata vardı (daha önemli ne olabilir?). Çok karmaşıktı (mimari hata) ve bunu düzeltmenin uzun süreceğini biliyorduk. Müşteriler bize düzeltmek için bir yıl vermeyi kabul ettiler (ürünümüzü bırakmadan önce) ve yaklaşık bir yıl içinde yaptık.

Sorun izleyicilere gelince, bunları neredeyse on yıldır kullanıyorum ve kural olarak, etrafımdaki tüm programcılar izleyiciyle çok az zaman harcadı (not programcılar hakkında konuşuyorum; yöneticiler farklı bir hikaye). Olmadığı zamanlarda nadiren vakalar gördüm - tüm bu durumlarda bir şey ciddi bir şekilde kırıldı.

Yüz yüze konuşmalar ve sorun takibi ile ilgili çalışmalarla ilgili olarak, yine burada açık kapıya giriyormuşsunuz gibi geliyor. Sorun izleme, tipik bir yazılı iletişimdir; şeyleri tartışmak için o bol araştırma gösteren vardır face2face iletişimi çok daha verimli daha telefon üzerinden sırayla çok daha verimli daha yazılı .

Aslında f2f hakkında sorduğunuzda, şeyleri tartışmak için izleyiciyi kullanıyormuş gibi hissedersiniz - bu onun amacı değildir. Amaçlanan kullanımını anlamak için, adını yavaş ve net bir şekilde heceleyin: sorun izleme sistemi .

hata listeleri çok uzuyor

Deneyimlerime göre, yukarıdaki bir sorun değil bir avantajdır.

İle uzun hata listesi geliştiricileri çok ilerisinde bir kuyruk ve plan düzeltmeleri ayarlayabilirsiniz. Bu mümkün olduğu kadar üretken; Bana göre bu, çalışmak için böyle bir kuyruğum olduğunda temelde bir nirvanadır. İlk hata - düzeltme - bitmiş, ikinci hata - düzeltme - bitmiş, sonraki hata - düzeltme - bitmiş vs vs yok aptal kesintileri, oh-so-verimli f2f konuşmaları, hiçbir acı dikkat dağıtıcı saf akışı .

Uzun hata listeleri bir sorun olduğunda sadece bir vakayı hatırlıyorum . Yüksek yönetimdeki bazı aptallar, geliştiricileri neredeyse 50-100'lük bir yığından bir sonraki hatayı almaya zorlayan bir politikaya karar verdiğinde oldu. Ne kadar da boş. Bunu başının üzerine nasıl tırmandıracağımızı ve düzeltebileceğimizi anlayana kadar bize birkaç ay sürdü.
Uygun iş akışı oluşturmayı başardıktan bir süre sonra, "sonsuz birikimimiz" in sihirli bir şekilde boşaldığını keşfettik.

— tatarcık
kaynak

2

Son zamanlarda, bir yıl içinde tahakkuk eden 300'den fazla açık hata (çoğunlukla kullanıcı arayüzü) boyunca dolaşarak 2.5 gün geçirdim, hepsi serbest olanlara / stajyerlere ya da onlarla başa çıkmak için zamana sahip olmayan proje yöneticisine atandım. Bunların yaklaşık yarısını sabit veya artık alakalı olmayan olarak kapatabildiğimi fark ettim. Onları doğru insanlara atadıktan sonra geri kalanı iyi bir oranda sabitleniyor. Hata izleme sistemi kötü kullanıldı, ancak onsuz, tüm bu hatalar (şov tıpaları yok, ama bazı oldukça çirkin) kesinlikle unutulurdu.

— Michael Borgwardt

1

@MichaelBorgwardt evet o kadar uzun listeler ki, deneyimlerimde hiç kimse onunla başa çıkamaz , biri 200, 400, 1000 gibi korkunç görünümlü sayılarla donmadığı sürece her zaman yönetilebilir hale geldi. Geçen yıl için 300 + sorunları giderdim - yalnız (!). Tuhaflıktan dolayı, takım düşüncesindeki diğer adamları da kontrol ettim, belki de benzersizim - hayır, 200-400 düzeltme / yıl sadece ortalama bir oran gibi görünüyor. 500 hata, ancak bu görünüm korkutucu, 4-5 geliştiriciler, çocuk oyuncağı için sadece yarım yıl olabilir :)

— gnat