Hataların giderilmesinde marjinal fayda var mı [kapalı]

Eski bir meslektaşımdan tüm hataların düzeltilmesi gerekmediğini duydum, çünkü öncelikli hatalar listesine girdiğinizde, bu hatanın daha da belirsiz kalmasına neden olan kullanım durumu azalır veya müşteri memnuniyeti azalır. Ancak bu hatayı düzeltmek için hala çok zaman harcamak zorundasınız.

Ürün sahibimizi bu kavram hakkında ikna etmek için iyi bir kaynak bulamadım. Tek bulabildiğim, yazılım geliştirmede marjinal bir maliyet olup olmadığı konusundaki tartışmalardı.

Hataların giderilmesinde gerçekten marjinal fayda var mı? Bu kavramı açıklayan farklı bir terim var mı?

İş açısından bakıldığında, bir hata düzeltme özelliği bir özellik isteğinden farklı değildir. Geliştirme süresinde belirli bir maliyeti vardır ve müşteriler için de belli bir değeri vardır. Bir hata kritik değilse, düzeltmenin üstündeki değerli bir özelliğe öncelik vermek tamamen işe yarar.

Ancak teknik açıdan bakıldığında, hatalar daha kritik olabilir , çünkü temelde başka bir kodun kullanabileceği / geliştirebileceği bir hata olduğunu gösterir, bu durumda hata "bulaşıcı" olur ve gelecekteki bakım için maliyet getirir. Yani değil veren bir hatayı düzeltmeye bir olan teknik borcu ise, tedavi gerektiren değil gerçekten devam eden bir maliyeti olmayan bir özellik uygulama. Ancak bir hatanın yol açtığı teknik borcun seviyesi, böceğin doğasına bağlıdır.

Önceliklendirme yapılırken tüm bu faktörler göz önünde bulundurulmalıdır.

Hataların giderilmesinde marjinal bir fayda olup olmadığına gelince: Bu verilen bir şey. Tüm hataların ciddiyeti bakımından eşit olmadığından, doğal olarak ilk önce en önemli hatalara öncelik verirsin. Böylece, ne kadar fazla hata giderirseniz, bir sonraki düzeltmenin marjinal değeri o kadar düşük olur. Ancak, seviyeye ulaşıp ulaşmadığı, hatayı düzeltmek için harcanan çabaya değmez, teknik bir karardan çok bir iş kararıdır.

İşte güzel bir referans

http://www.joelonsoftware.com/articles/fog0000000043.html

Yeni kod yazmadan önce hataları düzeltiyor musunuz? Windows için Microsoft Word'ün ilk sürümü bir “ölüm yürüyüşü” projesi olarak kabul edildi. [...] çünkü hata düzeltme aşaması resmi programın bir parçası değildi [...]

Microsoft evrensel olarak bir şeyi kabul etti [...] en yüksek öncelik, herhangi bir yeni kod yazmadan önce hataları ortadan kaldırmaktır [...] Genel olarak, bir hatayı düzeltmeden önce ne kadar beklerseniz, o zamana (para ve zamana) mal .

Bu böceklerin ne kadar uzun süre burada kalacağından, önceliğe girdikten sonra bunları düzeltmenin daha uzun süreceğinden emin olabilirsiniz. Dolayısıyla, şu anda ham bir fayda sağlamak yerine, gelecekte bir müşteri zararından kaçınıyorsunuz.

Bunu yönetmenin iyi bir yolu, biriktirme konularını ele almak için ayrılan süreyi tanımlamak olacaktır. Bu, Microsoft'un yaptığı kadar zorlayıcı olmazdı, ancak müşteri gerçekten umursamasanız bile, sizin sorununuz olmasa bile gelecekteki sorunların çözülmesini sağlayacaktır.

Ürün sahibimizi bu kavram hakkında ikna etmek için iyi bir kaynak bulamadım.

Ticari bir kuruluş için çalıştığınızı varsayalım, orada kesinlikle Fayda-Maliyet Analizinin farkında olan biri olacak .

Kuruluşunuzun sınırlı miktarda geliştirici kaynağı ve yapması gereken sınırsız faydalı listeye sahiptir. Bu yararlı şeyler arasında hem yeni özellikler eklemek hem de mevcut hataları kaldırmak sayılabilir - bir hatayı kaldırmak da yeni bir özellik eklemek gibi yazılımı iyileştirir.

Bu nedenle, bu sonlu kaynağın bu sonsuz listeye nasıl tahsis edileceği konusunda alınacak kararlar olduğu açıktır ve sonucun, bazı hataların şu anda veya gelecek hafta veya gelecek yıl ya da içinde çözülmemesi şaşırtıcı değildir. Şimdiye kadar gerçek.

Burada daha yapısal bir yaklaşım arıyorsanız , bir hatanın Kullanıcı ve Programcı görünümlerine sayıları atanan PEF / REV sistemini deneyebilir , neyin düzeltilip neyin düzeltmeyeceğine karar vermek için bir başlangıç ​​noktası olarak deneyebilirsiniz .

Ayrıca, Yazılım Mühendisliği'ndeki bu iki yazıya bakınız:

Hangi böceklerin en büyük maliyet avantajını sağlayacağını çözmek

Hemen hemen her rapor edilen hata yüksek öncelikli bir hatadır

Yazılım davranışının istenmeyen veya istenmeyen yönlerinin tümü hata değildir. Önemli olan, yazılımın yararlı bir şekilde çalışması için güvenebileceği kullanışlı ve belgelenmiş koşullara sahip olmasını sağlamaktır. Örneğin, iki sayı kabul etmesi, çarpması ve sonuçları çıkarması beklenen bir sonuç düşünün, eğer sonuç 9.95'ten daha yüksek ancak 10.00'dan az, 99.95'ten daha az ancak 100.00'den daha azsa, vb. Program, ürünü 3 ile 7 arasında olan ve hiç bir zaman başkalarına işlem yapmaya davet edilmeyecek olan işlem numaralarını yazmak için yazılmışsa, davranışlarını 9.95 ile sabitlemek, amaçlanan amacı için daha kullanışlı hale getirmez. Bununla birlikte, programı başka amaçlar için daha uygun hale getirebilir.

Yukarıdaki gibi bir durumda, iki makul hareket tarzı olacaktır:

1. Sorunu düzeltin, eğer pratikse.

2. Program çıktısının güvenilir olacağı aralıkları belirtin ve programın yalnızca geçerli aralıklar içinde değerler ürettiği bilinen verilerde kullanım için uygun olduğunu belirtin.

Yaklaşım # 1, hatayı ortadan kaldıracaktır. Yaklaşım # 2, ilerlemeyi bazı amaçlara göre daha az uygun hale getirebilir, ancak programların sorun olmayabilecek sorunlu değerleri ele almasına gerek kalmazsa.

99.95 ile 100.0 arasındaki değerlerin doğru bir şekilde işlenememesi bir programlama hatasının sonucudur [ör. Ondalık basamağın soluna iki basamaklı çıkmaya karar verdikten sonra bir yere yuvarlamadan önce, bu nedenle 00.00 vermesi] Program aksi takdirde bu gibi durumlarda anlamlı çıktı üretmek olarak belirtilirse hata. [Bu arada, yukarıda bahsedilen sorun Turbo C 2.00 printf kodunda meydana geldi; Bu bağlamda, açıkça bir hata, ancak hatalı baskı alanını çağıran kod yalnızca sorunlu aralıklarda çıktılar üretebiliyorsa, buggy olabilir.

Gevşek anlamda, evet, tüm hataların düzeltilmesi gerekmez. Her şey risk / fayda oranını analiz etmekle ilgili.

Genel olarak gerçekleşen şey, işletmenin, 'düzeltilmesi gereken' kazıkta bulunmayan hataları tartışmak için teknik adaylarla ve paydaşlarla bir toplantı yapmasıdır. Hatayı düzeltmek için harcadıkları zamanın (= para) iş için buna değer olup olmayacağına karar verecekler.

Örneğin, 'küçük bir hata' bir web sitesinin Şartlar ve Koşullar bölümünde küçük bir yazım / dilbilgisi hatası olabilir. Bunu yükselten birey değişmenin çok küçük olduğunu düşünebilir, ancak iş, markaya yol açabileceği olası zararı ve birkaç karakteri düzeltmenin göreceli kolaylığının farkına varır.

Öte yandan, önemli gibi görünen bir hataya sahip olabilirsiniz, ancak düzeltilmesi zor ve yalnızca önemsiz miktarda kullanıcıyı etkiler. Örneğin, Google Chrome'un eski bir sürümünü kullanan kullanıcılar için küçük bir düğme bağlantısı koptu ve ayrıca Javascript devre dışı bırakılmış oldu.

İşletmenin bir hatayı düzeltmemesinin diğer nedenleri, harcanan sürenin projeyi beklenmeyen bir süreye çarpması veya geliştiricinin zamanının diğer düzeltmeler / kodlamalar üzerinde çalışmak için daha iyi harcanması olabilir. Aynı zamanda, böceğin yaşayabileceği kadar küçük olması ve daha sonraki bir tarihte düzeltilmesi de olabilir.

Bu kavramı biraz daha iyi açıklar! Bu konuyu genel anlamda düşünmekten kesinlikle uzak dururum - her böcek eşsizdir ve böyle muamele görmelidir.

Çünkü öncelikli hatalar listesine girdiğinizde, bu hataya neden olan kullanım durumu daha belirsizleşir veya kazanılan müşteri memnuniyeti azalır.

Yani onların "argümanı" aslında

Hatayı yeterince uzun süre görmezden gelirseniz, Kullanıcı sorunun ne olduğunu unutacak veya bunun üzerinde çalışmanın bir yolunu bulacaktır.

Hatalara öncelik verilmeli ve yeni Özellik İsteklerinde olduğu gibi "sırayla" ele alınmalıdır (ancak tartışmalı olarak, hepsinin üzerinde ve üstünde).