Bir projeye atanan kişi sayısı ile kusur sayısı arasında gerçekten bir ilişki var mı?

İşte SLIM ve yazılım tahmini ile ilgili bir eğitim kılavuzundan alıntı:

Dikkat edin, Çaba ve Kusurlar arasında bir korelasyon vardır. Bu, belirli bir büyüklükteki bir projeye ne kadar çok insan atanırsa, o kadar fazla Hata olacaktır.

Çaba, proje için kişi zamanıdır (kişi-yıl, kişi-ay). Kusurlar, yaşam döngüsünün herhangi bir noktasında tespit edilen kusurların sayısıdır. Boyut, projeyi oluşturan kullanım senaryoları, işlev noktaları veya SLOC olarak tanımlanır.

Bu iyi bir süreç ve yetenekli mühendisler varsayarak mantıksız görünüyor. Örneğin, daha fazla insana sahip olmak, tüm eserlere (gereksinim özellikleri, tasarımlar, kod, testler) daha fazla göz demek. Daha fazla göze sahip olmanın yanı sıra, sezgim, uygun kalite tekniklerini kullanan bir projedeki çaba ve kusurlar arasında çok az ilişki olduğunu öne sürüyor.

Putnam Modeli (SLIM tarafından kullanılan) ile ilgili olanlar dışında, kusurlar ve çaba ya da kusurlar ve bir projedeki insan sayısı arasında bilinen herhangi bir ilişkiyi gösteren hiçbir belge bulamadım. Bu bilinen bir ilişki mi ve “daha ​​fazla insan = daha fazla kusur” olduğu iddiası geçerli mi?

Sezgim şöyle gider:

Verilen büyüklükteki bir projeye ne kadar çok insan atanırsa, iletişim yükü o kadar büyük
=> yanlış anlama olasılığı ve her türlü iletişim sorunu
=> ortaya çıkan hataların sayısı o kadar fazla olur.

Ve

İyi geliştiriciler vasat / kötü olanlardan daha nadirdir, bu nedenle bulmak ve kiralamak daha zordur
=> verilen büyüklükteki bir projeye ne kadar çok insan atanırsa, ortalama yeterlilik seviyeleri ne kadar düşükse
=> ortaya çıkan kusurların sayısı o kadar fazla olur.

Ama bunlar sadece benim akıl yürütmem olabilir, destekleyici kanıtım yok.

Bir yan not olarak, aşağıda vurgulanan varsayımlarınız, mesleğimizin durumunu dikkate alarak IMHO (ne yazık ki) oldukça güçlüdür:

Bu iyi bir süreç ve yetenekli mühendisler varsayarak mantıksız görünüyor . [...] sezgim, uygun kalite tekniklerini kullanan bir projedeki çaba ve kusurlar arasında çok az ilişki olduğunu gösteriyor .

Sadece bir korelasyon olabilir. Yönetim, daha karmaşık olacağını düşündükleri projelere veya çok sayıda uzlaşmaz hata nedeniyle geride kalan projelere veya çeşitli bileşenler arasında çok fazla bağlantı gerektiren projelere yardımcı olmak için daha fazla kişi atama eğilimindedir. Yönetim kararlarını karışımdan çıkarırsanız, tersine olmasa da korelasyonun en azından azalacağından şüpheleniyorum.

Son zamanlarda güncellenen boyut ve çaba tanımları göz önüne alındığında, belki de sonuçların Çaba'nın (toplam çalışma saati) aslında gerçek proje büyüklüğünün kaynağın kullandığı önlemlerden daha iyi bir tahmincisi olmasından kaynaklandığını öneririm. tüm ekiplerin ve takımın kaynaklarının eşdeğer olması halinde mükemmel bir önlemdir).

Bu nedenle, gerçekte olan, daha büyük projelerin daha fazla kusura sahip olmasıdır, ki bu hiç de şaşırtıcı değildir.

Bu iyi bir süreç ve yetenekli mühendisler varsayarak mantıksız görünüyor.

Bunların hiçbirini gerçek dünyada kabul edebileceğinizi sanmıyorum. Bir projede ne kadar çok insan varsa, ayak uyduramayan ve en iyi geliştiricileri yavaşlatacak kötü elmalara sahip olma olasılığınız o kadar yüksektir. Varsayımlara devam etseniz bile, projeleri yavaşlatan ve insan sayısını artırdıkça daha fazla kusurlara neden olan birkaç şey daha var:

• iletişim yükü
• kod okuma yükü (bununla en iyi geliştiricilerin bile diğer insanların kodlarını okumaktan ve kendi kodlarından daha fazla tüketmek için daha fazla zaman aldıkları anlamına gelir)
• test daha kapsamlı olmalıdır (Hepimiz% 100 test kapsamı için çekim yaparız, ancak bu gerçek dünyada nadiren gerçekleşir. Tüm testler makul bir şekilde otomatik hale getirilemez, bu da daha fazla zaman alır.)

Deneyimlerime göre, proje çok modüler olduğunda ve katman başına sadece 1 veya 2 kişiniz olduğunda geliştiricilere yüklenen projelerin olumsuz etkileri azalır. Hangi sürüm kontrol sistemini kullandığınız umurumda değil, 4 geliştiricinin aynı anda aynı dosyaya otomatik olarak birleştirilmesi muhtemelen kötü bir fikir olacaktır.

Korelasyon ve nedensellik arasında bir fark vardır; alıntı, daha fazla sayıda mühendisin tahsis edildiği projeler için toplam kusur sayısının daha yüksek olduğu söyleniyor gibi görünüyor. Bu benim için çok mantıklı, eminim MS Windows benim oluşturduğum uygulamalardan daha fazla kusura sahip, ama bu benim uygulamalarımın üstün kalitede olduğu anlamına gelmiyor.

Daha soyut bir örnek vermek gerekirse - eğer ülke başına toplam ölüm sayısını aldı ve ülkedeki toplam doktor sayısıyla ilişkilendirdiysek, eminim ki "daha fazla doktoru olan ülkeler daha fazla ölüme sahipti" diyebiliriz. Bunun nedeni doktorların ölümlere neden olması değil, daha çok sayıda doktorun büyük bir nüfusun göstergesi olması.

Bir an için insan sayısı hakkındaki iddiayı bir kenara bırakalım.

Çabaların bir fonksiyonu olarak enjekte edilen kusurların sayısına bakmak, artan çabanın mutlaka daha fazla boyut gerektirdiğini varsaydığınız sürece mantıklı olabilir, çünkü hata sayısı ve yazılım boyutu arasında güçlü bir korelasyon vardır.

Dolayısıyla, bir projeye ne kadar fazla çaba harcanırsa, daha fazla kod satırı yazıldığını varsayarsanız, büyük olasılıkla kusur sayısını tahmin etmek için ebat olarak bir proxy olarak çaba kullanabilirsiniz. Boyut (örneğin LOC) ve hata sayısı arasındaki ilişki, Watts Humphrey, Capers Jones ve diğerleri tarafından işte defalarca gösterilmiştir.

İnsan sayısının ne kadar uyduğunu görmüyorum, daha fazla insan daha fazla çaba gerektiriyor.

Bir yan not olarak, korelasyonu nedensellik ile karıştırmayın. Boyut ve enjekte edilen kusurların sayısı arasında bir korelasyon olsa da, boyut neden değildir. Sebep genellikle belirttiğiniz gibi insanlar ve süreç sorunlarından kaynaklanır. Bununla birlikte, boyutun bir fonksiyonu olarak kusurlar, bir sorun olup olmadığını anlamak ve değişimin etkinliğini ölçmek için harika bir metriktir.

Bunun çekirdek programlama ekibinin üyeleriyle sınırlı olduğunu ve UI, UX, DBA gibi uzmanların bulunduğu bir durumla sınırlı olmadığını düşünüyorum.

İyi yönetilmesi gerektiğini düşünüyorum, ama bu kolay değil. Kaliteli geliştiricilerden oluşan küçük ekipler kendilerini yönetebilir. Kodun büyük bölümlerinin daha az yetenekli biri yaratmasını önlemek daha olasıdır.

Daha fazla ekip üyesine sahip olmak görevleri bölmeyi kolaylaştırabilir. Daha iyi veya daha deneyimli geliştiricileri zor bölgelere koyun. Sıradan veya programlama dışı görevlerden bazılarını daha iyi geliştiricilerden uzaklaştırın ve genç geliştiricilerin kesintileri halletmesine izin verin. Bu daha fazla planlama ve düşünce gerektirecek, ancak yeteneğinizi geliştirmek için bir fırsat sunuyor.

Yeni bir beceri edinmesi gereken harika bir geliştiriciye sahip olmanın, zaten tanıyan ortalamanın altında bir geliştiriciden daha iyi olduğu fikri var. Vaktiniz varsa bu harika. Muhtemelen daha fazla geliştiricinin bir projeye atanmasının nedeni, gereken iş miktarı ve zaman kısıtlamalarıdır. Belirli bir alana odaklanabilecek ve daha yetenekli olabilecek birine sahip olabilirsiniz. Bu çok yönlü bir bilgiye sahip olmak harika, ancak bazen küçük bir yönle, küçük bir geliştirici biraz talimat alabilir ve onunla çalışabilir.

Gerçek şu ki, başarılı bir projede şimdiye kadar büyük bir takımı yöneten birçok insan yok. Hepsi yetenekli olsa bile, büyük takımların kendi kendini yönetmesi zor. Egolar engel olur mu?