Bilinen bir hataya sahip bir ürün ne zaman gönderilir?

Bilinen bir hataya sahip bir ürün ne zaman gönderilir?

"Bilinen" bir hatadan bahsettiğinizi varsayıyorum (soru başka türlü anlamsızdır). Cevap şu faktörlere bağlıdır:

1) Kullanıcı kimdir ve bulunması durumunda hatayı nasıl kabul eder?

2) Hatanın potansiyel etkisi (hasarı) nedir?

3) Hatayı düzeltmek için yazılımın gönderilmesini geciktirmek mümkün müdür?

4) En önemlisi: yazılımınızdan ne bekliyorsunuz? Market zamanı? Kalite? Müşterilerinizin hatayı bulmak için yazılımı yeterince uzun süre kullanıp kullanmadığını görmek ister misiniz?

Her zaman iyi olmalı, çünkü hatasız yazılım diye bir şey yoktur.

Bu bir karar çağrısı. Unutmayın, bir böcek birçok şey olabilir. Bu düz değil çalışma önemli bir işlevsellik parçası ise, o zaman ilk düzeltmek. Programın yararları üzerinde minimum etkisi olan veya gerçek bir etkisi olmayan küçük bir şeyse, kaymasına izin verebilirsiniz.

Bu yüzden maliyet / fayda açısından bakın.

Hatayı düzeltmenin toplam maliyeti ve riski, dışarıdaki hatanın neden olduğu sorunlardan ve olumsuz etkiden daha ağır bastığında, bilinen hataları olan ürünleri gönderirsiniz.

Bu nedenle, yayınlamadan önce 2 haftalık bir test süreniz varsa ve küçük bir hata bulunursa, soru ... ekibin uygulamayı ve yüklemeyi yeniden test etmek için harcayabileceği 2 hafta daha bu hatayı düzeltiyor olması (yazılım oluşturmada sıkça unutulan bir adım)? Yazılım geç kalırsa itibar veya satış maliyeti nedir? İnsanlar öfkeli mi olacak? Büyük işlevsellik zamanında teslim edilebilirse, küçük bir hata ile yaşamak oldukça mutlu olabilirler.

Riskler, sadece hatayı düzeltmede değil, aynı zamanda yeni bir kurulum oluşturmaktan kaynaklanabilecek yeni bir sorun getirme riskini de içerir.

Olumsuz etki, hatayı bildiren müşterilerle uğraşmanın hem zaman hem de çabası ve itibar hasarı gibi şeylerdir.

Böcekler farklı şiddetlerde gelir. Çalıştığım herhangi bir yazılım şirketinde hataları P0'dan P4'e Öncelik sırasına göre sınıflandırdık.

P0 Yazılım çalışmıyor / çöküyor ve müşterinin işine zarar verebilir mi? P1 Tasarlandığı gibi çalışmıyor ve çekirdek işlevsellikte sürekli çöküyor P2 Zaman zaman kilitleniyor ve bir parça yan işlev çalışmayabilir. P3 Yazılımın bazı öğeleri tasarlanan / beklenen P4 Kozmetik sorunu olarak çalışmıyor.

P4'lerin sabitlenmediği yerlerde çalıştım çünkü yazılım üzerinde küçük bir etkisi var.

Yazılımınızın P3 / P4 sorunlarını bildiğini göndermenin iyi olduğunu söyleyebilirim, bunu sürüm notlarına koyarım ve üzerinde çalışıldığını not ederdim.

Farkında olduğum bir P0, P1 veya P2 sorunu olan yazılımı asla yayınlamam.

Buna " Bilinen Sorun " denir . Google, Microsoft, Apple vb. Tüm ürünler hem bilinen hem de bilinmeyen hata içeren ürünler gönderir. Onları en aza indirmeye çalışın, ama mükemmelliği beklemeyin. Hızlı gemi, sık gemi.

Hata olmadan yazılım gönderemezsiniz. Verebileceğim tavsiye, müşterinize söylemenin her zaman daha iyi olduğudur: "Bu sürüm bunu yapamaz ve bunu ancak bunu çözeceğiz", müşteri SİZİN bir hata olduğunu söylediğinde durumdan daha fazladır.

"özellik" olduğunda! ;)

Ciddi bir notta, mükemmel bir test kurulumuna sahip mükemmel bir programcı değilseniz, her bir kod yolunu mükemmel bir şekilde test etmek ve sonuçta potansiyel olarak var olabilecek, hatasız bir ürün göndermeniz mümkün değildir.

Bu nedenle, pragmatik olun, eğer testinizde karşılaştığınız her şey düzeltildiyse, ekstra her şey gerektiği gibi düzeltilmelidir.

Müşterilerinize dürüst olduğunuz sürece hatalarla gönderebilirsiniz. Onlara mevcut tüm hataları anlatmak, yazılımınız hakkında iyi bilgiye sahip olduğunuzu gösterir ve bu gerçekten iyi test edilmiştir (eğer öyleyse ..). :)

Açıkçası en iyi şey böcek ile nakliye kaçınmaktır.

Bilinen sorunların bir listesi ile zamanında bir ürün gemisine sahip olmak, hiç gemi olmamasından daha iyidir.

Bir projede insanlar güven verir programlama dünyasında şeylerden biri de serbest bırakılmasına sahip olup olmadığıdır planlanan ve zamanlama olmadığını tutar .

Bu yüzden Ubuntu gemileri hala açık konular olsa bile her altı yılda bir serbest bırakılıyor.

İyi bir kural olduğunu söyleyebilirim, "bu böcek bir showtopper mı?"

Hata "mutlu yol senaryosu" nun başarısız olmasına neden olursa, kesinlikle bu hatayla birlikte göndermeyin.

Hata bir "mutlu yol teğet senaryo" başarısız olursa ve geçici bir çözüm yoksa, bu hata ile birlikte göndermeyin.

Bir hata belgelenirse ve bilinen bir geçici çözüm varsa, bu hatayla birlikte gönderilmesi uygun olur.

Tüketiciler açısından ... Asla. Demek istediğim, yazılımda büyük bir hata olduğunu bildiğiniz sürece, o zaman asla göndermemelisiniz. Ancak, yazılımın üretim döngüsü şimdi iş modeline zarar verebilecek aşamadaysa ve (i) yazılımın güvenliğini tehlikeye atarsa ​​(ii) kullanılabilirliği etkiler

İnsanların söylediği gibi, bu çok geniş bir soru. Aslında beni ilginç bir bakış açısına götürüyor: iddia ettiğiniz "böcekler" sadece test kullanıcılarınız tarafından keşfedilen hatalardır. Sonsuz bir boşluk daha olabilir. Bir Lisansüstü Seminerde saygın bir Profesörden duyduğum ilginç bir hikayeyi hatırlattım: İskandinav ülkelerinden biri "el yazısı ile tanınabilir" tipte bir oylama makinesi kullandığında, bazı insanlar kötü niyetli SQL kodu ( sistem normal girdi olarak alındı).

FMEA (Hata modu ve etki analizi) adı verilen bir şey var, bilinen bir hatanın ne zaman önemli olduğuna veya dayanmadığına karar vermek çok yararlı:

1. olay
2. şiddet
3. Tespit etme

Başka bir karar faktörü, hatanın son sürümünüzle nasıl ilişkili olduğu olabilir. Hata yeni, ancak bozuk bir özelliğin parçasıysa, işlevsizlik işlevselliğin gerilemesini temsil etmez. Devam et ve gemi.

Öte yandan, kusur mevcut müşteriler için yararlı olduğu bilinen bir işlevsellik kaybına neden olursa, sürümü engellemelidir. Böyle bir sürüm , müşterileriniz için bir düşüş olacaktır ve ne çıkarlarınıza ne de onların çıkarlarına hizmet etmeyecektir.

Bunda gri tonlar olabilir. Çekirdek işlevsellikteki gerileme asla kapı dışına çıkmamalıdır. Sürüm, ilgi duyduklarını ifade ettikleri yeni işlevler de içeriyorsa, çevresel özelliklerde bazı gerilemeler ortaya çıkabilir. Birçok müşteriyi etkilemesi muhtemel olmayan belirsiz bir kusur, bu müşterileri etkiler. Yine de varsayılan olarak kapatılan yüksek deneysel özelliklerde oluşan hatalar, sürümün gecikmesine neden olmamalıdır.