bakım için harcanan zamanın endüstri ortalamaları

Bir yönetici yakın zamanda hataları düzeltmek için çok fazla zaman harcadığını duyurdu. Sanırım o her zaman mükemmel bir kod yazmak gerektiğini düşünüyor (tabii ki bu imkansız son tarihlere isabet ederken!) Ve bana sanayi kod zaman v düzeltme yeni kod yazma harcanan zaman ortalama ne merak yaptı.

Peki herkes yeni kod geliştirme karşı hata gidermek için harcanan zaman metrikleri var mı? Yoksa bir bütün olarak endüstri için hata düzeltme zamanının ampirik bir analizi var mı? % 50 hata düzeltmek için fazla mı, yoksa doğru mu? Peki ya% 20 ya da% 33?

Kişisel deneyimlerden anekdot kanıtları kabul etmekten mutluluk duyuyorum, çünkü bu, performansımızı karşılaştırabileceğim bazı istatistiklerin bir parçasını oluşturacak.

Bir yönetici yakın zamanda hataları düzeltmek için çok fazla zaman harcadığını duyurdu.

Yukarıdaki sesler çok cahil. Bunun gibi durumlar için önerilen okuma: Robert L. Glass'ın Yazılım Mühendisliğinin Gerçekleri ve Yanlışları , özellikle "Gerçek 43. Bakım bir çözümdür, sorun değil."

Wikipedia makalesinde , yazılım bakımı için harcanan% 80 çabadan bahsedilmektedir.

yöneticim Dilbert'in PHB'sini dahi gibi gösteriyor :)

Yukarıda verilen tüm isteklerin gerçekten hata olup olmadığını analiz etmek için biraz çaba sarf ederim .

Deneyimlerime göre, geliştirme veya yeni özellik isteklerinin hata olarak gönderilmesi çok sık oldu. İyi yöneticiler programcılarını bunu öğrenmeye dahil eder - kötü yöneticiler, hataları düzeltmek için çok fazla zaman şikayet etmeye devam edin .

Sorulması gereken ilk soru, "hata düzeltmenizin" aslında kodlama hatalarını veya başka bir şeyi düzeltip düzeltmediğidir. Gerçek kod hatalarının düzeltilmesi, çoğu durumda iyi bir kod tabanına sahip olduğunuz sürece nispeten küçük olmalıdır. Kötü bir kod tabanı ile çalışıyorsanız, kapsamlı hata düzeltmeleri kaçınılmazdır.

Bununla birlikte, bir programı üretime sokarken, belgelenmemiş gereksinimleri, beklenmedik kullanıcı etkinliği, veri anormallikleri, donanım uyumsuzlukları, kurulum sorunları ve kesinlikle kod hataları olmayan diğer sorunları bulacaksınız. Genellikle yöneticiler ve kullanıcılar bu üretim destek / bakım sorunlarını genellikle kod değişikliği gerektirdiği için hata olarak düşünürler.

Ayrıca hata olarak küçük geliştirme istekleri olarak adlandırılması gerekenleri gruplandıracak yöneticilerle de karşılaştım. Bunlar genellikle bir hata izleme veya sorun raporlama sistemine girer ve bu, "hata" istatistiklerinizi gerçekte olduğundan daha yüksek yapabilir.

Orada ne kadar kodunuz olduğuna, ne kadar süredir orada olduğuna vb. Bağlıdır.

Yazılımdaki hataları düzeltmek için harcanan zaman, ilk 6-12 aylık sürüme önden yüklenmelidir, ancak zaman sonsuzluğa yaklaştıkça, bakım için harcanan zaman ile ilk geliştirme için harcanan zaman% 100'ü aşacaktır - işte bu şekilde iş.

Zor istatistiklere sahip olmasam da (Kod Tamamlandı, ancak tam olarak hangi sayfayı / bölümü söyleyemiyorum), deneyimlerime göre, kabaca gelişimin yaklaşık% 40'ı (bazen% 60 kadar yüksek) bakım için harcanıyor. Ne kadar çok kod bırakırsanız, bakım süreniz o kadar artar. Hatalar her zaman işlevsel değildir ve programlı kusurlar kadar belirsizliğin bir sonucudur.

iyi bir bilet izleyici (Atlasian'dan Jira gibi) kullanıyorsanız ve tüm farklı kategorileri, kullanıcı hikayelerini, aciliyet düzeylerini doğru bir şekilde ve takım arkadaşlarınızın anlaşmasıyla girmek için zaman harcadınız ve bu ölçümleri (ve daha fazlasını) hesaplarsanız inanılmaz derecede kolay.

Önceki bir projede, hata / görev / yapılacaklar listemizi yönetmek için Jira'yı kullandık ve sonunda bize gecikmelerin ve sorunların en büyük nedeninin verimsiz yönetim uygulamaları olduğu ortaya çıktı.

Garip bir şekilde, bu bilgi ortaya çıktığında, aniden Jira'yı kullanmayacağımızı ve bunun yerine yeni bir ürünün getirileceğini söyledik.

Bu arada, Jira'dan iletilecek tüm veri talepleri yönetim ekibine gönderilmek zorunda kaldı ve doğrudan erişimimiz kaldırıldı.

Fark edilmeyen şey, istatistik hesaplamasının bir parçası olarak, dev ekibinin Jira'yı bir web kancasına veri atmasıydı ve bu web kancasının, verileri oluşturduğumuz kodun olduğu bazı dahili sunuculardaki bir bitiş noktasına iletmek için kullanıldığıydı. otomatik olarak raporlar.

Web kancasını izlemeye başladık ve Jira'nın artık kullanılmadığını söylediğimiz halde, önemli ölçüde daha uzun bir süre (tam olarak 6+ ay) çok canlı kaldığını ve üst yönetim tarafından toptan kötüye kullanımın sadece yanlış kullanım ile düz yaygın.

Tabii ki, Jira kadar karmaşık bir şey olmak zorunda değil.

Düşük verimli bir çözüm istiyorsanız, görevleri / biletleri / hataları / özellik isteklerini vb. İzlemek için bir google-docs forma sayfası ve GDocs bildirim API'sı kullanabilirsiniz.

GDocların kendisi artık web kancaları ve her türlü şeyi yayınlayabilir.

Git ve / veya Github ve kod deponuza bağlı olduğunda tetikleyen bazı kancalarla birleştirin ve şaşırtıcı miktarda veri kaydedebilen makul derecede verimli bir ev demleme sisteminiz var.

Bununla birlikte, genel olarak, bir ürünün doğal kullanım ömrünün% 100'ünden, yeşil alan geliştirici ve bakım arasındaki bölünme genellikle 20/80'dir, ALM (Uygulama Yaşam Boyu Yönetimi) döngüsünde maliyetin çoğu bakım ve destek maliyetlerinden alınır.

Hataları düzeltmek için çok fazla zaman harcamak diye bir şey yoktur, çünkü hatasız kod yazmak mümkün değildir.

İyi testler ve sürekli entegrasyon politikaları eksikliği azaltır, ancak asla tamamen ortadan kaldırmazsınız.

Başka türlü inanan herkes (IMHO) doğru bir yargıya varmak için yeterli bilgiye sahip değildir veya yazılım yazmanın ne kadar zor olduğuna kördür (daha olağan durum).

Yöneticiniz buna hazırsa ve bazıları ise, o zaman bir gün boyunca sizi gölgelediğini önermek isteyebilirsiniz, böylece ne yaptığınızı ve nasıl yaptığınızı tam olarak görebilir.

Iv'e, bu tür çalışmaların aktif olarak teşvik edildiği birkaç şirkette çalıştı, üst düzey personel alt düzey personeli gölgeledi ve bunun tersi, her iki taraf için de gerçekten iyi bir öğrenme deneyimi olabilir.