Geliştirme ekibim% 100 büyüdü (1 geliştiriciden 2'ye). Yeni kohortum böcek takip yazılımına yatırım yapmak istiyor. Bu kadar küçük bir takım için bu tür bir yazılımın faydaları var mı?

Bence tüm "evet" cevapları bu fikri onaylamak için uzun bir yol kat ediyor. Ancak kararın birkaç soruya dayandığı fikrini ortaya koyacağım:

• Takım olarak nasıl iletişim kurmak istersiniz? 2 geliştiriciyle, artık bir takımsınız. Nasıl iletişim kurmak istersiniz? Birçok çevik ekip, kişisel tartışmalarda ve beyaz tahta eskizlerinde yaşar. Ancak bir şeyleri yazacak kadar ileri gidebilirler, özellikle de bir süre öncelik listesinde yüksek olmayacak bir böcekse.
• Müşterilerinizle nasıl iletişim kurmak istersiniz? Bunun cevabını bilmiyorum, ancak hataları (veya sürüm sürüm belgesindeki sabit hataları) yayınlamak için herhangi bir nedeniniz varsa, sonunda bunları yazmayı bırakacaksınız. Düşük stresli bir hata yönetim sistemi seçip, onunla bitirin.
• Tarihi korumanın bir değeri var mı? Cevap "şu anda değil" olabilir, ancak gelecekte gelecekte hata eğilimini görmek isteyip istemediğinizi, böylece kullanıcıların en fazla sorun yaşadığı yerleri veya zaman kontrol etmek için harcayabileceğiniz yerleri görebilirsiniz. ve büyük bir sürümden önce gözden geçirme - ardından bir hata izleme sistemi edinin. Tarihle ilgili olan şey, kaydı istediğiniz günün, kayıt tutmaya başlamanız gereken gün olmadığıdır.

IMO, bu soruların cevapları, ürünün nereye gittiğini ve ekibinizi nasıl büyütmek istediğinizi ve “2 kişi = hata izleme sisteminin nedeni” olup olmadığına dair daha az şeyle ilgili. Büyük soru, muhtemelen "yapılandırma ve yönetme zamanına ve satın alma maliyetine değer bir hata izleme sistemidir?"

1, ancak sadece ağrısızsa. Örneğin GitHub, küçük bir ekip için fazlasıyla özellik içeren çok basit ve kullanışlı bir sorun izleyiciye sahiptir . Bugzilla, Trac veya diğerleri iyi, ancak hepsinin kullanmadan önce donanım, kurulum ve yapılandırma gerektiriyor ve bakım kesinlikle sıfır masraf gerektirmiyor.

Hata izleme yazılımını ilk kullandığımda çok küçük bir ekibimiz vardı ve bir şekilde düzeltilmemesi için düzeltmemiz gerektiğini düşündüğümüz şeye şaşırmıştım. Takımın ne kadar büyük olursa olsun buna değer.

Evet. Binlerce kez evet.

Hata takibi anlamında bile düşünmeyin, ancak bilet takibi olarak düşünün.

Biletlerde tüm görevlerinizi görebilmek büyük bir avantaja sahip. Bir görevin geçmişini tek bir yerde saklayabilirsiniz. Kimin üzerinde ve ne zaman çalıştığını biliyorsun. Bir görev için hangi günde ne yapıldığını söylemek kadar ayrıntılı olabilirsiniz.

Böcek takibi için tüm böceklerinizi tek bir yere koyabilir ve olanların neler olduğunu ve halen devam etmekte olanları takip edebilirsiniz.

Sadece işleri çok daha iyi yönetmenize yardımcı olur.

Bir veya daha fazla bir ekiple buna değer.

Resmi bir yazılım çözümü satın alsanız da almasanız da, bir hata / özellik takip sistemine sahip olacaksınız. Not defterinde olabilir, yapışkan notlar olabilir, kodunuzun üstündeki bir açıklama bloğunda olabilir. Ancak, rastgele gelişmekte olan sürece, yapılacaklar listelerini bir yere not düşüyor olacak. Neden ekibinizle birlikte büyüyebilecek daha organize bir sistem kullanmıyorsunuz?

Aynı zamanda göz önünde bulundurmaya değer: Bug-tracker'ların birçoğu çok küçük takımlar (1-2) tarafından ücretsiz olarak kullanılabildiğinden, fayda için herhangi bir büyük masrafa maruz kalmayacaksınız.

Her ekibin üyesi olduğu sürece herhangi bir hata izleme yazılımına ihtiyacınız yoktur.

• Mükemmel bir fotoğrafik hafızası var ve
• Düşüncelerini ekibin diğer üyeleriyle senkronize edebilir.

Kısa cevap evet.

Bazı nedenler neden:

1. Belirli sürümlere karşı bulunan hataları günlüğe kaydetme yeteneği.
2. Hangi (bilinen) hataların henüz çözülmediğini bilme yeteneği.
3. O zamandan beri tekrar bulunan bir hatayı düzeltti.
4. Geliştirici cirosu - meşhur otobüs olsanız bile bilgi transferine izin verir.

Muhtemelen kurulum / yönetmeniz için fazla zaman almayan bir şeye bakmak isteyeceksiniz. Ayrıca, onu kaynak kontrolünüzle entegre etme yeteneğini içeren bir şey aramanızı da öneririm.

Bu cevap, argümanın YES tarafına ağırlık eklemektir .

Ben çoğunlukla bir takımım. SVN entegrasyonu ile birlikte sorun takibini (redmin) yoğun bir şekilde kullanıyorum.

Gerçekten muhteşem ve onsuz çıldırırdım; kalitem düşecekti, çünkü işleri unuturdum ve üzerinde çalışmam gerekeni izlerdim.

Verimlilik araçları:

• İyi IDE
• Sorun takibi
• Kaynak kontrolü

Sorun takibi; onsuz evden ayrılma

3'ten az varsa, muhtemelen bir google docs elektronik tablo ile alabilirsiniz belki, sanırım. Ama gerçekten bir yerde bugzilla veya benzerlerini kurmanın maliyeti, bir programcının maliyetinin yanında, sadece bunu yaparken daha iyi olduğunuz için çok önemsizdir. (Artı 7'ye büyüdüğünüzde zaten orada olacak)

Bir ekip bile bir tür hata izleyiciden, notların bir metin dosyasından ya da tam gelişmiş bir yazılımdan faydalanabilir. 2 geliştirici için, paraya değil, sadece bazı hata takip sistemlerinin kurulmasına zaman ayırmayı tavsiye ederim. Projeye bağlı olarak, kağıda hata yazmak, paylaşılan bir çevrimiçi belge aracılığıyla bir listeyi sürdürmek veya Trac veya Bugzilla gibi ücretsiz hata izleme yazılımlarını kullanarak para cezası alabilirsiniz. Fogbugz , 45 gün boyunca ücretsiz deneme olarak da kullanılabilir.

Evet.

Onları biraz izlemelisin!

Mesele şu ki, kaç tane geliştiriciden çok hataya sahipsin. Birkaç hata ile uğraşırken bir excel sayfasıyla başa çıkabilirsiniz, ancak o zaman bile en iyisi değil.

Kesin bir benifet var - kişisel projelerde bile hata takip yazılımı kullanıyorum. Yalnızca hataları izlemek için değil, aynı zamanda 'TODO'ları ve özellik isteklerini izlemek için de faydalıdır.

Sadece kendi başıma çalışırken her yerde böcek kullandım . Hata bilgisini kaynağınızla bir arada tutarak DVCS'nizle birlikte çalışır. Merkezi bir sunucu gerektirmediği için genel gider çok düşük. Dezavantajı ise, hangi dalların zamanında yayıldığından emin olmak için yeni böceklere hangi dallara girdiğinize dikkat etmeniz gerekir; bununla birlikte, çoğunlukla kendi hatalarınızı izlemek ve en son çekimlerinizde nelerin sabitlendiğini bilmek önemli olmayabilir. Bir takımın durumunu bir bütün olarak takip etmek yerine.

Sadece birini kullanmaya başla

Sadece bir tanesini kullanmaya başlarsanız, sürüm kontrol yazılımı veya bunun için dağıtılmış sürüm kontrolü gibi pratikte kullanım kolaylıklarını fark etmeye başlayacaksınız.

Gelişme vadesi

100 ya da 1 kişilik bir ekibiniz varsa, sorun izleme ve dağıtılmış sürüm kontrolü kullanmaya başladım (yerel taahhütler nedeniyle çok mantıklı) sadece kendim ve kendim için ve başka bir seviyede hissetmiştim ama Ancak bu, çalışmamı başka bir düzeyde ... daha fazla çaba harcamadan ölçeklendirebilecek düzeyde yönetebiliyordum.

Bir izleyici kullanarak, sorunları önceden tahmin edebilir ve işe öncelik verebilirsiniz, hata / sorun izleyicileri yalnızca hatalar / sorunlar için değil, proje yönetimi için daha fazladır ve her projenin buna sahip olması gerekir .

Benim için sadece yazılım ile ilgili değil, etrafındaki süreç. Gündelik işimde Test Yöneticisi olarak çalışıyorum temelde birinde yaşıyorum ve aşağıdaki avantajları sağlıyor:

Bunun 2+ test cihazı ve 3+ geliştiricisi ile gerçekten işe yaradığını düşünüyorum.

Geliştirici hata düzeltme çabalarının yönetimi

Geliştiricilere, onlara ne kadar çalışma yaptıklarını kontrol etmek için "hata kuyruğu" nu aktif olarak yönetiyoruz ve ekip genelinde hata düzeltme çalışması için seviye tahsisatımız olmasını sağlıyoruz.

Neyin düzeltip neyin kazanamayacağına karar vermek

Günlük işlemlerde yeni hatalar yapmak, yaptığınız şeyi düzeltip düzeltmeyeceğinize odaklanmak için harika bir yoldur. Bir projenin başlarında, her şeyi düzeltmek istersiniz. Sonunda sadece gösteri durdurucularını düzeltmek istiyorsun ve hata izleme aracı bunun için harika

Metriklere ihtiyacınız olduğunda

Benim için en önemli şey Metrics, yani hata bulma ve düzeltme trendlerini görüntüleyebilmeniz, kodlu alanların nerede olduğu veya test edicilerin hataları bulup yeniden test etmeleri için. Hata izleme sistemi zamanı geldi.

Bir takım üyesinin bir hata izleyiciye ihtiyaç duymaya başlamak için yeterli olduğu fikrine katılıyorum. Bir veya iki gerçek kullanıcınız olduktan sonra zorunlu olarak nitelendireceğim, ancak ilk sürümünüzden önce çok önemli.

Şahsen, hem kaynak kontrolü hem de hata takibi için fosili severim . Bir hata izci ve bir wiki ile iyi bir şekilde bütünleşmiş düşük bir TAM dağıtılmış SCM'dir. Ve genel olarak taşınabilir tek bir çalıştırılabilir kurulumdur ve GUI'si olarak dahili bir web uygulaması kullanır. Ana sayfası aslında neredeyse tamamen bir fosil kopyası ile sunuluyor.

İzleyici kontrolü ile sıkı sıkıya entegre edilmiş izleyici ile değişiklikleri kolayca biletlere bağlayabilir ve bilet güncellemelerini düzeltmeler (ve wiki sayfa düzenlemeleri) ile aynı zaman çizgisi görünümünde görebilirsiniz.

Evet evet evet evet! Sorunlarınızı izleyebilmek, önceliklendirmek ve yönetmek, başarılı bir yazılım geliştirmenin anahtarıdır. Bir kişiyle (neredeyse) bir elektronik tablodan kurtulabilir ve eski kaynak ağaçlarını sıkıştırabilirsiniz. Bir geliştiriciyi bile bir projeye eklemek işleri çarpıcı biçimde değiştirir - aniden, sorun izleme ve kaynak kod kontrolü gerekir, ya da sorunları bırakacaksınız, işlevlerin üzerine yazacaksınız ve genellikle sefil bir zaman geçireceksiniz.

Henüz kimsenin StackExchange'in ana şirketi FogCreek'ten bahsetmediğine şaşırdım, ancak FogBugz yazılımı şimdiye kadar kullandığım en iyi sorun izleme uygulaması. Yüksek hızlı, düşük sürükle ve uygun fiyatlı, özellikle onların barındırılan çözümünü kullanıyorsanız. Eskiden iki kullanıcı lisansının ücretsiz olduğunu düşündüğüm ücretsiz bir deneme sürümüne sahiplerdi - artık böyle olmayabilir, ancak kontrol etmenizi öneririm.

İşte benim 2 kuruş.

hata takibi için sadece bir google-doc elektronik tablosu kullanıyorum, düzenlemek veya görüntülemek istediğim herkesi davet edebilirim. ücretsiz değil, bir yatırım değil. Oradaki bütün işleri takip edip sadece böceklerim var.

Ayrıca web barındırma için SVN kullanıyorum, bu da web barındırma için herhangi bir ek maliyet getirmiyor.

Bazı müşteriler, taklit veya başka bir proje yönetimi / hata izleme yazılımı kullanmayı zorunlu kılmışlardır, ancak yukarıda bahsettiğim ücretsiz çözümleri tercih ederim.

Minimalist bir hata takipçiniz varsa, bir ekip için bile faydalı olduğunu söyleyebilirim. Arkadaşımın proje sitelerinden QuokForge'da , her proje için temel olarak bir Red Mine örneği sunuyorlar. Red Mine, bence iyi bir böcek takipçisi var (zaman zaman biraz garip olsa bile). Yani bir hatayı yalnızca ONE alanına metin girerek dosyalayabilirsiniz. Ayrıca FogBugz'ı daha önce de kullandım . 2 ya da daha az kişi için ücretsiz. Ve aynı basitliği sağlar, sadece bir metin alanını doldurarak bir hatayı doldurur. (Aynı zamanda delicesine faydalı grafikler ve diğer şeyler sağlar)

Temel olarak, bir hata raporunu doldurmak için 30 dakikanızı ayırmanızı gerektiren kesin ve resmi bir işlem yapma hatası yapmayın (BugZilla, sana bakıyorum). Bu sadece insanların kullanmayacağı anlamına gelir.

Son olarak, bir hata listesine sahip olmak (her bir hatanın yaklaşık olarak 50 karakter içermesine rağmen) son derece değerlidir. "Hmm, 1.0'ı serbest bırakmak üzereyim. Son hataların düzeldiğini düşünüyorum." Ayrıca yöneticiler için aslında bir şey yaptığınızı görmek de harika :). Bir takımda, daha değerlidir çünkü ikinizde de farklı bir zihinsel yapılacaklar listesi tutmaya çalışmazsınız. Ve "Bu gerçekten kötü bir güvenlik hatasını] düzelttin mi? Evet, öyle düşünüyorum. Tamam, öyleyse 1.0'ı bırakalım."

Ayrıca özellikleri takip etmeyi de seviyorum. Bu biraz daha isteğe bağlı, ancak yine de kafamda yapılacaklar listesi tutmak için verilen zihinsel görevi yerine getirememekten fayda görüyorum.

Ayrıca, Joel'in bu konuda ne söylediğini gör.

Bu sayıya henüz ulaştınız ... 2 ! Tek geliştirici siz olsanız bile, hata takip yazılımı kullanmanın faydalarını görebildiğim halde, toplam geliştirici sayısı 1 olduğunda, sadece onsuz alabilirsiniz.

Ancak, iki veya daha fazla geliştiriciniz olduğunda, bir hata izleme yazılımına sahip olmamak için tek bir neden yoktur.

Evet. Ve bir öneri bitbucket http://www.bitbucket.org Onlar ücretsiz hata takibi yanı sıra mercurial ücretsiz Özel depoları sağlarlar .

Bir. Bu durumda, Yapılacaklar listesine benzer.

Sana zaman ayırıp yatırım yaparak varsayıyorum. İki kişilik bir ekip için iyi olması gereken çok sayıda ücretsiz hata takip sistemi var. Daha büyük bir ekibim olana kadar ticari tekliflere bakmam.

Bence sorunuzun yanlış algılara dikkat çekiyor. Hata izleme gerektiren ekip değil, ürün (ler) dir.

Öyleyse, yazılımda hata takibi yapılması gerekiyor mu? Bunun yardımı olur, sence de öyle değil mi?

Aşağıdaki iki koşul mevcutsa buna değmeyebilir:

1. Sorunların ömrü kısa. Bu durumda, basit bir görev tahtasında yeterli olabilir (iş akışını başka birçok nedenden dolayı görselleştirmek akıllıdır). Ancak, sorunları hızla çözemezseniz, f.ex. hızlı bir şekilde hataları düzeltmek, sorunu izlemek için yararlı bulacaksınız.
2. Kod değişiklikleri, canlı testler olarak otomatik testlerle belgelenir. Yani, hatalar ve düzeltmeler, göründükleri zaman başarısız testlerle belgelenir, geçen testler düzeltmeden sonra regresyon testi olur. - İşlevsellik değişiklikleri otomatik kabul testleriyle belgelenir (ör. FitNesse veya Salatalık gibi bir BDD aracı kullanarak). Bu belgeler, Jenkins gibi bir CI sunucusundan kolayca temin edilebilir olmalıdır.

1 veya 2 mevcut değilse, sorun izlemeden yararlanacaksınız.

Hayır

Hataları takip etmeyin, düzeltin .

Önemli olan takımın büyüklüğü değil, düzeltmeden önce listedeki böceklere bakmak için ne kadar zamana ihtiyacınız var.

Çevik / TDD kullanıyorsanız, hata listeniz kısa olacaktır ve hatalar listede oyalanmayacaktır. Herhangi bir izleme sistemi bu durumda yeterli olacaktır.