Hataları / sorunları izlemek için paylaşılan bir e-tablo kullanmamayı nasıl savunursunuz?

Şirketimizde, geliştiriciler uygulamamızdaki sorunları yönetmek için uygun bir hata izleme aracı kullanmak istiyorlar. Ancak yönetim, paylaşılan bir e-tablo kullanmakta ısrar ediyor (daha önce paylaşılan bir excel dosyası, şimdi web tabanlı bir çözüm üzerinde eşzamanlı erişime izin veren bir e-tablo).

Onların argümanı, elektronik tablonun hızlı bir bakışta kaç hatanın açık olduğunu görebildikleri için projenin durumu hakkında daha yüksek bir görünüme sahip olmalarına izin vermesidir. Bu aynı zamanda her bir hata üzerinde kimin çalıştığını görmelerine ve hepsini kapatmak için gereken süreyi tahmin etmelerine olanak tanır (geliştiricinin üzerinde çalıştıkları hatanın zaman tahminini doldurması gerektiğinden).

Anlayacağınız gibi, bu geliştiriciler için gerçekten pratik değildir (hata izleme yazılımı bir nedenden dolayı icat edildi). Peki geliştiricinin çalışmasını kolaylaştırmak için hata izleme yazılımını nasıl savunabilirim?

Bir bonus olarak, yönetimin geri bildirimlerini (hataların sayısı açılır, üzerinde çalışan, zaman tahmini) yüksek düzeyde bir görünümle alabilmesini sağlayan hangi yazılımı önerirsiniz?

Peki geliştiricinin çalışmasını kolaylaştırmak için hata izleme yazılımını nasıl savunabilirim?

Bu ifade verildiğinde:

elektronik tablo, hızlı bir bakışta kaç hatanın açık olduğunu görebildikleri için projenin durumu hakkında daha üst düzey bir görünüme sahip olmalarını sağlar.

elektronik tabloların "gerçek zamanlı" (veya mümkün olduğunca ona yakın) oluşturulmasına etkin bir şekilde izin veren raporlama araçlarına sahip sistemlere bakmanız gerekir. Bunlardan birini, geliştiricilerin "uygun" bir sistem kullanmasının, ilgilendikleri verilerin (umarım) daha doğru ve güncel (örneğin) olacağı anlamına geleceğini açıkladığınızda.

E-tablonun hangi sürümü güncel? Bu e-tabloya kim sahip?

İyi bir hata takipçisi, bir e-tablonun yapabildiklerini yapacaktır, sadece:

• bir şey değiştiğinde ilgili taraflara e-posta gönderecek
• güncel bilgi için tek bir standart kaynak sağlar
• özet raporlara izin verir, projenin durumu hakkında üst düzey görüş verir

Kişisel projelerim için Mantis kullanıyorum (sadece kurulumu gerçekten kolay olduğu için). Çalışma kullanan Trac Mercurial entegrasyonu ile.

Mantis kutunun dışında açık / kapalı / atanan hata sayısı gibi şeyler sağlar ve çoğu bugtrackers olacağını hayal ediyorum. Zaman tahminini bilmiyorum, çünkü bakmayı zahmet etmedim. Trac (veya işyerindeki kurulum) zaman tahminine sahiptir ve örneğin kilometre taşı başına tahminleri toplayacak özel bir rapor yazmak kolaydır.

Herkesin cevapları iyidir. Başka bir yönü bana geliyor.

E-tablo etrafındaki güvenlik hakkında. Yönetim, herhangi bir rastgele geliştiricinin yanlışlıkla CTRL + A, DELETE düğmelerine basabileceği ve işleri gerçekten bozabileceği konusunda endişelenmemeli mi? Uygun bir hata izleme sistemi, bu tür veri bozulmasına izin vermez. Ve bu kötülüğü bile hesaba katmıyor. Belirli bir geliştirici daha fazla kredi isterse ve tüm kusur düzeltmelerini yeniden atamaya başlarsa ne olur? Gerçek bir sistemin, bu tür şeylerin farkedilebileceği bir denetim izi vardır. Bir e-tablo olmaz.

Yönetim'e gereksinimlerinin karşılanacağını göstermelisiniz.

Onların argümanı, elektronik tablonun hızlı bir bakışta kaç hatanın açık olduğunu görebildikleri için projenin durumu hakkında daha yüksek bir görünüme sahip olmalarına izin vermesidir. Bu aynı zamanda her bir hata üzerinde kimin çalıştığını görmelerine ve hepsini kapatmak için gereken süreyi tahmin etmelerine olanak tanır (geliştiricinin üzerinde çalıştıkları hatanın zaman tahminini doldurması gerektiğinden).

Bu yüzden bir kukla sistem kurun ve onlara bu bilgileri bir Elektronik Tablo kullanmaktan daha iyi ve belki de daha iyi alabileceklerini gösterin.

Şimdiye kadar herkes benzer ve uygun cevaplar buldu. Henüz konuşulmayan önemli bir husus var. Hataları izlemek ve hiçbir şeyin çatlaklardan geçmediğinden emin olmak için iki şeye ihtiyacınız vardır:

• Hem özet hem de ayrıntılı olarak iyi raporlama - bu daha sonra aranabilir
• Herkes en güncel kopyanın nerede olduğunu bilmelidir.

Bir Excel elektronik tablosunu kullanarak savunulan hemen hemen her ortamda, bu elektronik tablonun herkesin makinesinde farklı kopyaları vardır ve bunların hiçbiri aynı değildir. Bu, ilerlemeyi gözden geçirme sürecini son derece zor ve verimsiz hale getirir.

Trac, RedMine, JIRA, Mantis veya istediğiniz her şey gibi merkezi bir sunucu bu sorunların her ikisini de halleder. Bu noktada, şirketinizin ihtiyaçlarına en uygun olan şeydir. Ortamınıza bağlı olarak, bu araçlar tıpkı sürüm kontrol sisteminiz gibi IDE'nizle entegre olabilir (Eclipse bu özelliğe sahiptir). Bu, atanan hatalarınızla çalışmayı çok daha kolaylaştırır.

Ortamınızı bilmiyorum, ancak Visual Studio kullanıcıları için TFS'yi öneriyorum. Hem kaynak kontrolü hem de sorun izlemeyi, tam raporlama yetenekleriyle bütünleştirir. Ayrıca yetki katmanları, tam geçmiş takibi (yani hatayı kimin ne zaman güncellediğini ve ayarladıysa, nedenini) sunar, bir "hata" ve "sorun" ile "geliştirme" ile başka ne isterseniz ayırt etmenizi sağlar gibi görünüyor ve Visual Studio IDE ile tamamen entegre oluyor. Belirli yapılara bağlanabilen, teslim edilen kodla bir hatayı birbirine bağlar. Ve çok daha fazlası.

Çok sayıda farklı kaynak kontrol sistemi (VSS, SVN, TFS ...) ve birçok hata izleme sistemi (Özel tescilli sistemler, Tracker, SharePoint ve evet, hatta Excel) kullandım, ancak param için (ve iyi bir değişim yığını), TFS para ve zaman yatırımına değer.

Ve evet, Excel'e dışa aktarabilir (ve buradan içe aktarabilirsiniz).

Düzgün bir sorun izleyiciye geçişi satmanıza yardımcı olmak için, yönetiminizin mevcut sisteminizle ilgili hangi sorunları olduğunu bulmaya çalışmalısınız ('iyi olursa ...' olması gerekir) ve kaşıntı çizip çizemeyeceğinize bakın onlar için.

Yönetimin argümanlarını okuma

Onların argümanı, elektronik tablonun hızlı bir bakışta kaç hatanın açık olduğunu görebildikleri için projenin durumu hakkında daha yüksek bir görünüme sahip olmalarına izin vermesidir. Bu aynı zamanda her bir hata üzerinde kimin çalıştığını görmelerine ve hepsini kapatmak için gereken süreyi tahmin etmelerine olanak tanır (geliştiricinin üzerinde çalıştıkları hatanın zaman tahminini doldurması gerektiğinden).

Hepsine katıldım ve her biri JIRA tarafından karşılandı (JIRA'dan sadece kullandığım için bahsediyorum, değerli diğer adaylar olduğundan eminim)

JIRA gibi bir araçla, sadece mevcut kurulumunuzun tüm avantajlarını korumakla kalmayacaklarını, aynı zamanda birçok yeni avantaj elde edeceklerini vurgulamanız gerekir.

Hikaye zamanı.

Birkaç ay önce tüm şirketimin kafasını çevirdiğini bulmak için bir haftalık tatilden döndüm. Geliştirme departmanının başka bir bölümünün aylardır öğüttüğü bir proje aniden beyaz-sıcak-acil bir önceliğe sahipti ve tüm ekip, şeyi çözmek için üzerinde çalıştıkları şeyden çekildi. O günki toplantıda, şirketin sahibi ertesi gün o gün ve geri kalanını birkaç parça çalmamızı istedi ve biz iyi durumda olacağız.

Altı hafta sonra, hemen hemen kesintisiz çalışma / uyku döngülerinden sonra bu şeyi teslim ettik.

"Bitti" metriğimiz, müşterinin daha fazla geri bildirimi olmamasıydı. Yeni ve heyecan verici şeyler, daha önce hiç bulunmamış geri bildirimlerinin her bir sürümünde (bize e-posta ile teslim edildi) ortaya çıkacaktı ve söyledikleri her kelime anında spesifikasyonun bir parçasıydı ("hadi yapalım" ").

Bir gece geç saatlerde tamamen e-posta ve onay işaretli çıktıları ile hata raporları yönetmek HAD BT korkuttu. Mantis'i test sunucumuza yükledim ve bölümüm için yeni aldığım geri bildirim belgesini yükledim. Yöneticimi kullanıcı olarak ayarladım ve sorunları kapattığımda e-posta almaya başlamasına izin verdim.

Yaklaşık 6 saat içinde ekibin tamamını kullandım. PM, müşteri e-postalarını Mantis'e filtreliyordu, geliştiriciler sorun listeleri talep ediyor ve çalışıyorlardı. Daha da iyisi, sistem içinde açıklama ve iletişim talep edebildiler, bu da her bir öğe hakkında kağıtsız bir kağıt izi bıraktı.

Ertesi gün benden projenin geri kalanında Teknoloji Lideri istedi. Canlı bir el bombası vermek gibi bir şeydi, ama aldım ve onunla koştum. İki hafta sonra nihayet müşterimizin burun halkasını yakma yeteneğini tükettik ve siteyi üretime soktuk. Mantis artık hataları yönetme şeklimizdir ve bir projenin başından itibaren özellik isteklerini işleme biçimimiz olabilir.

TL; DR: Kendi benliğini kur ve kendi eşyaların için kullanmaya başla. Değerini kendi başına kanıtlasın.

BTW, bu sürüm kontrolü hakkında izlediğim politika ile aynı. Subversion'u kilitli bir ilke altında kullanıyoruz, çünkü yöneticim dosya birleştirmeye güvenmiyor. Bu iyi, ama bir SVN projesine baktıktan sonra, derhal geliştirmede kendi kullanımım için yerel bir git deposu hazırlıyorum.

Atlassian Jira kullanıyoruz .

Bunun gibi birçok rapor var:

Yönetici açtığında, gerekli tüm raporlama verilerinin seçtiğiniz uygulamadan güncellendiği bir e-tablo oluşturmanız gerekir. Eğer işe yaratırsanız, hiçbir argüman yoktur.

ağ paylaşımındaki hata izleme e-tablosuyla yanlış gidebilecek şeyler:

• kimse onu açık bırakıp iş istasyonunu kilitlediğinde ve öğle yemeğine gittiğinde onu düzenleyemez.
  • "bariz" geçici çözüm, yazmak için yeni bir sürüm kaydetmektir. Bu bir dal oluşturur ve Excel birleştirmede kötüdür. Birinin işi kaybolacak.
• belge gizli satırlarla kaydedilebilir, sorun haftalarca göz ardı edilir.
• her şey silinebilir ve geçmiş izleme marjinaldir. "Geçen hafta girmiş olduğum ayrıntılı problem analizine ne oldu?"
• 'kısıtlı' alanlara değer eklemek kolaydır. "Bu hatanın şiddeti 'Epik Başarısız' olarak nasıl işaretlendi?"
• kes ve yapıştır formülleri üzerine yazar. Bir hesaplama kolayca sabit olabilir.

Bunların hepsini yaşadım. Ve hala teslim etmeyi başardık ... Sadece üç ay geçti ve binlerce plansız mesai saatine mal oldu.

"Bedava!" genellikle oldukça iyi bir argüman. Pivotal Tracker ücretsizdir, kurulum gerektirmez ve yöneticilerinize düşük bir elektronik tabloyla mümkün olandan daha iyi bir üst düzey görünüm verebilir.

Düzenle:

Rahatsızlığım için, Pivotal Tracker'un daha uzun süre ücretsiz olmayacağı açıklandı. :(