Orijinal gelişmeye karşı böceklere ne kadar zaman harcanmalıdır? [kapalı]

Bu soru biraz soyut ama birinin beni doğru yöne götürebileceğini umuyorum.

Sorum şu ki, bir yazılım projesinin orijinal geliştirme zamanı ile ilgili hatalarına ne kadar zaman ayıracağı beklenebilir. İçine giren çok sayıda belirleyici faktör olduğunu biliyorum ama tipik veya ortalama bir bozulma umuyordum.

Örneğin, Proje A'nın tamamlanması 40 saat sürerse ve 10 ek hata daha yaparsa, bu proje 4: 1 oranına sahip olacaktır.

Başka bir Projenin (B) tamamlanması 10 saat sürerse, ancak böcekler üzerindeki 8 ise, 5: 4 oranına sahip olacaktır.

Bu belgelenmiş / araştırılmış bir kavram mı?

GÜNCELLEŞTİRME

Tüm bilgilendirici cevaplar için teşekkürler. İlgili tüm değişkenler ve çevresel faktörler nedeniyle bu tür bir metriğe standart koymanın imkansız olduğunu biliyorum. Bir cevap vermeden önce, bu metriğin üzerinde anlaşılmış bir isim olup olmadığını bilmek istiyorum, böylece daha fazla araştırma yapabilirim. Metrikleri kendim oluşturmak için gerekli ölçümleri anlayabildiğim ve sonunda projem için temel bir standart olan bir noktaya gelmek istiyorum.

Hata tespitine tahsis edilen toplam kapasitenin denge yüzdesi, hata enjeksiyon oranına eşittir .

Tabii ki, birçok faktör bu oranı etkileyebilir: elbette: ekibin ne tür bir ürün geliştirdiğini, hangi teknolojileri ve teknik uygulamaları kullandıklarını, ekibin yetenek seviyesini, şirket kültürünü vb.

B takımını göz önünde bulundurarak, tamamladıkları her 10 iş için ortalama 8 ünite yeniden işleme yarattıkları takdirde, bu 8 ünitenin çalışması yeni 6.4 ünite yeniden işleme yaratacaktır. Sonuçta harcayacakları toplam çabayı geometrik bir ilerlemenin toplamı olarak tahmin edebiliriz:

10 + 8 + 6,4 + 5,12 + ...

Hataların sayısı zamanla katlanarak azalacak, ancak B Takımı, üslerinde çok yavaş bir şekilde sıfıra gidecek kadar katsayıya sahip. Aslında, yukarıdaki serideki ilk üç terimin toplamı sadece 24,4'tür; ilk beşin 33.6; ilk 10, 45; Tüm seri, 50. Öyleyse, B Takımının özeti: Hatalı enjeksiyon oranı, 0.8; özellik geliştirme, 10/50 =% 20; Hata giderme,% 80. 20/80 sürdürülebilir kapasite tahsisatıdır.

Aksine, A Takımı çok daha iyi durumda. İlerlemeleri şöyle gözüküyor:

40 + 10 + 2,5 + 0,625 + ...

Bu serinin toplamı 53 1/3, bu nedenle A Takımının özellik geliştirme tahsisi 40 / (53 1/3) =% 75 ve kusur tespit tahsisi% 25'tir, bu da kusur enjeksiyon oranlarını 10/40 = 0.25 ile eşleştirir. .

Aslında, ilk üçten sonra Team A serisindeki tüm terimler önemsiz derecede küçüktür. Bunun pratik açıdan anlamı, A Takımının tüm hatalarını birkaç bakım sürümüyle ezebilmesidir, ikinci sürüm kapsamı oldukça küçüktür. Bu aynı zamanda herhangi bir ekibin bunu yapabileceği bir yanılsama yaratır . Ama B Takımı değil.

David Anderson'un yeni kitabı "Kanban" ı okurken bu eşdeğerliği düşündüm . (Kitap farklı bir konu üzerinde ancak kalite endişelerini de ele alıyor.) Yazılım kalitesini tartışırken, Anderson bu kitabı, "Yazılım Değerlendirmeleri, Karşılaştırmalar ve En İyi Uygulamalar" başlıklı Capers Jones'tan alıyor :

"... 2000 yılında ... Kuzey Amerika ekipleri için ölçülen yazılım kalitesi ... işlev noktası başına 6 hata ile 100 işlev noktası başına 3 ile 200 arasında 1 arasında değişmekteydi. Orta nokta başına yaklaşık 1 hata 0,6 ile 1,0 arası işlev puanları Bu, takımların çabalarının% 90'ından fazlasının kusurlarını gidermek için yaygın olduğu anlamına geliyor. ” .

Anderson'ın kusurlu enjeksiyon oranından kusurlu sabitleme kapasitesi tahsisine (akıcılık talebi bunun için bir terim olduğu) akıcılık , iki şeyin eşitliğinin, yazılım kalitesi araştırmacıları tarafından iyi bilindiğini ve muhtemelen bir süredir bilindiğini ortaya koymaktadır. .

Burada sunmaya çalıştığım muhakeme doğrultusunda anahtar kelimeler "denge" ve "sürdürülebilir" dir. Sürdürülebilirliği ortadan kaldırırsak, bu sayıları aldatmanın açık bir yolu vardır: ilk kodlamayı yaparsınız, daha sonra başka bir yere kod koyarsınız ve bakımı başkalarına bırakırsınız. Ya da teknik borcu atar ve yeni bir mal sahibine atarsınız.

Açıkçası, belirli bir tahsisat tüm takımlara uygun olmayacaktır. % 20'nin böceklere harcanması gerektiğine karar verirsek, o zaman, eğer bir takım ultra düşük kusur enjeksiyon oranına sahipse, zamanı doldurmaya yetecek kadar böcekleri olmaz ve eğer bir takımın oranı çok yüksekse, birikmeye devam edecektir.

Burada kullandığım matematik basitleştirildi. Yüzdeleri biraz etkileyecek olan işlem maliyetleri (planlama ve tahmin toplantıları, ölüm sonrası vb.) Gibi şeyleri ihmal ettim. Aynı zamanda bir ürünü sürdürmeyi simule eden ve aynı anda diğerini geliştiren denklemleri atladım. Ancak sonuç hala geçerli. Hata enjeksiyon oranınızı ve dolayısıyla başarısızlık talebinizi azaltmak için birim testi, sürekli entegrasyon, kod incelemeleri vb. Teknik uygulamalar açısından elinizden geleni yapın. Her 10 özellik için yalnızca bir hata oluşturabilirseniz, yeni özellikler geliştirmek ve müşterilerinizi memnun etmek için çok fazla boş zamanınız olacak.

Ne yazık ki, bu oranın belirli bir projede oldukça değişken olduğuna inanıyorum. Çevrenizden, dilinizden, araçlarınızdan, takım boyutunuzdan ve deneyimlerinizden ciddi şekilde etkilenecektir.

Bir hataya zaman harcamalısınız, ancak düzeltmeden elde ettiğiniz kazanç yatırım yaptığınızdan daha büyükse.

Aşağıdakine benzer bir matris kullanın (hatayı düzeltmek için yatay zaman gerekir, kullanıcılar üzerinde düşey hata türü)

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

Problemlere örnek:

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add nice    | Fix: change architecture + DB
              | message                              |

Matris, farklı şiddet, efor, risk vb. Düzeylerle daha karmaşık olabilir.

Her bir hata için bir sıralama bile oluşturabilir ve sıralamaya göre düzeltebilirsiniz. Gibi bir şey:

Bug priority = Risk x Severity x Effort

* Seçtiğiniz ölçeğe bağlı olarak, bazı işlenenler için (1-x) olabilir :)

Dolayısıyla sorunuzu cevaplamak için: böcek türüne, uygun zamana / bütçeye vb. Bağlıdır.

Sadece (elbette) ekibin deneyimi ve kalitesi ile projenin zorluğu (yeni bir işletim sistemi çekirdeğinden başka bir standart web uygulaması yapmakla aynı şey değil), aynı zamanda sizin yönetim yaklaşımınız için de oldukça değişkendir. kullanacağım.

Örneğin, bir şelale modelinde ilk test aşamasında ilk hatayı tam olarak belirleyebilirsiniz, ancak çevik bir ortamda, özellikleri değiştirebildiği için "buradan itibaren hataları düzeltir" diyerek bir satır oluşturmak zor olabilir ( ve bana göre, bir özellik değişikliğini böcek olarak saymak adil değil)

Tecrübelerime göre, HER ZAMAN hafife alınan bir şey olduğunu ve "orijinal proje" den aynı miktarda saati kolayca geçirebileceğini söylüyorum.

Gerçekten doğru cevap, hata düzeltmelerinde sıfır saat olacaktır, çünkü kodunuz mükemmeldir. :-)

Gerçekçi olarak, birisinin bu tür bir oran istediğini veya teklif ettiğini duyduğumu söyleyemem. Bu, bazı şirketlerin hem geliştirme hem de bakım için zamanı takip etmediklerini söylemek değildir. Ancak bir uygulamanın gelişimi, çoğu şirketin geri dönmediği ve bu oranı hesapladığı bakım ile karşılaştırıldığında çok kısa bir zaman dilimidir. Muhtemelen bir uygulamanın neden bakım gerektirdiğini öğrenmek ve bu bulguları yeni uygulamalara uygulamak konusunda daha fazla endişe duyuyorlar.

Ne hata için çok geniş ölçütlere sahip olmak zamanınızı neredeyse ikiye katlayabilir. Bir müşterinin bir düğmeyi büyütme isteğini (fare sorunları var) istediğini düşünen aşırı derecede bir yönetici, düzeltdiğimiz hataların sayısını artırmak için harika bir yoldur. Düzeltme işleminin yapılması sadece birkaç saniye sürecektir çünkü bir düzeltme ekini düşünmeye, test etmeye, yeniden derlemeye ve dağıtmaya gerek yoktur. Oh, ve yeni bir özellik olarak çift sayılır.

Bunun için en büyük belirleyici faktör, yeni bir teknolojiyle mi yoksa mevcut bir teknolojiyle mi çalışacağınızdır. Yeni bir şeyle çalışıyorsanız ve farklı koşullarda birkaç kez yapılmamış veya yapılmamış bir şey geliştiriyorsanız, düzeltmelere ve projenizi istediğiniz şekilde çalışmasına yardımcı olacak çok zaman harcayacaksınız. . Sık sık hatalar, kendinizi bir köşeye sokmanın bir sonucudur ve yaptığınız şeyi yeniden yapılandırmak için önemli miktarda çalışma yapmanız gerekecektir. Ek olarak, birçok hata, kullanıcı beklentilerinin eksik bir şekilde anlaşılması ve geliştiricinin son vakaların farkında olmamasından kaynaklanacaktır.

Yerleşik bir teknoloji üzerinde çalışıyorsanız, sorunların çoğu, kütüphaneler veya topluluktaki uygulamalar tarafından ele alınacak ve karşılaştığınız tüm hataları gidermek için Google’a başvurabilir, satın alabilir veya sorununuzu çözebilmelisiniz.

Kritik yazılımlarda, A 1: 1 oranı sıra dışı değildir. Sadece ünite testi için, her 10 satır kod için 1 günlük ünite testinden bahsettim.

Bu sorunun önyargılı olduğunu düşünüyorum: Bu, hataları düzeltmenin yeni işlevsellikler geliştirmeye benzer bir aşama olduğu varsayımından başlar . Durum bu değil.

İyi bir geliştirici, kodu en baştan hatasız olacağından kod ayıklamak için çok fazla zaman harcamaz. Kötü bir geliştirici kodunu hata ayıklamak için çok zaman harcayacaktır çünkü gerçek problemleri çözmek için uygun soyutlamalar oluşturamaz.

Geliştiricilerin kendi kodlarını kendileri test etmesi gerektiğini unutmayın. Hatasız kod sunmak onların görevidir. Bu yüzden kodlamayı hata ayıklamadan ayırmak zor.

Aynı zamanda bir öncelik meselesidir. Geliştirme sırasında, bir hatayı düzeltmek için gereken süre, hatayı koda koyduğunuz andan beri geçmiş olan süre ile katlanarak ilgilidir. Bu yüzden hataları düzeltmek, yeni işlevler geliştirmekten daha öncelikli olmalıdır.

Bu yüzden "hatalara harcanan zaman" hakkında konuşmak yerine, "testlere harcanan zaman" hakkında konuşmalısınız (entegrasyon testleri, kullanıcı kabul testleri ...)

Bence haklısın - etkileyici faktörlerin sayısından dolayı anlamlı bir ölçü alamayacaksın.

Üzerinde çalıştığım projeleri (işletme alanı, büyük karmaşık sistemler, diğer sistemlere çok sayıda entegrasyon) anlatabilmeme yardımcı oluyorsa, oranı yaklaşık 3: 2'dir. Bunların çoğu koddaki hatalar değil - daha genel olarak arayüzlerdeki hatalar. Örneğin, sistem A ve B birbirleriyle X arayüzü üzerinden konuşurlar. Sistem A'nın geliştiricileri, arabirim X'i, sistem B'nin geliştiricilerinden biraz farklı olarak yorumlar.

Yapılması gereken bir gözlem, kodun geliştirilmesi ve kodun test edilmesi / hata düzeltilmesinin iki ayrı aşama olmaması gerektiğidir. Geliştirdiğiniz gibi test ederseniz, hata onarımının "maliyeti" daha az olur.

Tamamen pratik bir bakış açısı benimsem: Projenin pratikte faydasını daha fazla etkileyen nedir? Mevcut işlevsellikteki hatalar varsa, hataları gidermelisiniz. Eksik özellikleri varsa, orijinal geliştirme yapmalı, sonra en ciddi eksik özellikler uygulandığında geri dönüp hataları düzeltmelisiniz. Bu kullanım durumlarına aşina olmanızı gerektirir. Bazı garip köşe durumlarda programın çökmesine neden olan bir hata, herkesi etkileyen küçük kullanılabilirlik geliştirmelerinden daha düşük bir öncelik olabilir. En sık kullanılan işlevsellikteki küçük rahatsız edici bir hata, yalnızca yazılımınızı aşırı uçlara iten insanlara yarar sağlayan bir özellikten daha önemli olabilir.