Neden hem Önceliğe hem de Ciddiyete ihtiyacımız var?

Ne belirlediklerini anlıyorum, ancak bunları bulunan sorunlara atamak gerçekten yararlı mı? Yani, hızlı bir şekilde düzeltilmesi ya da düzeltilmesi gerekiyor.

Onları nasıl ayarlayacağımı, kategorilere ayıracağını vb. Biliyorum. IEEE / ISO'nun bunu yapmasını gerektirdiğini biliyorum. Sadece nedenini göremiyorum.

Bu değerlerin farklı olması kesinlikle mümkündür. Yüksek performans gerektiren ancak X modülünü kullanmayacak önemli bir devlet kurumuna satış yapmak istiyorsanız, X modülündeki ciddi bir hatadan daha küçük bir veritabanı kullanılabilirliği hatasını düzeltmek çok iş mantıklıdır. Temel olarak, bir yazılım işini yürütürken tek neden teknik nedenler değildir .

Tarih ve saat hataları

Hata: Yıl sonu işleme, veritabanınızı tamamen bozacaktır. Bu açıkça ciddi bir hata.

Tarih: 15 Aralık. Hata çok yüksek önceliğe sahip.

Tarih: 1 Şubat. Hata düşük önceliklidir.

Yanlışlıkla füze böceğinin fırlatılması

Hata: ICBM kontrol yazılımı 28 ile 1 Mart arasında 4 ile bölünebilir.

Bu, olabildiğince ciddi bir hata. Öncelik çok düşük olsa da - durum tetiklendiğinde yazılımın kullanımda olması için gerçekçi bir şans var mı?

Ekranda yanlışlıkla 'kötü' kelimeler

Hata: Ekranda yerlerinden taşan mesajlar, Bob'un istemeden küfür edilmesine neden olur. (Gerçek dünya: "Final Ass" bölümünde çalışan insanlar vardı. "Ass" = "Assembly".)

Maalesef yarın, satışın şirket için yap veya ara olduğu bir sunum yapacaksınız. "Bob" adlı birine sunum yapıyorsunuz. Önem derecesi: Çok düşük. Öncelik: Çok yüksek.

Sen yazdın:

Yani, hızlı bir şekilde düzeltilmesi ya da düzeltilmesi gerekiyor.

Bu doğru. Bununla birlikte, çoğu şirket gibiyseniz, kaynaklarınız sınırlıdır. Ya sorunları çözmek için yeterli insanınız yok ya da yeterli zamanınız yok.

Bir hatanın hızlı bir şekilde düzeltilmesi gerekip gerekmediği ve düzeltilmesi gereken birçok hatanız olduğu göz önüne alındığında, "öncelik" sorusunu "hangisini önce düzeltirim" sorusuna cevap verir?

Önem derecesi, önceliği ayarlayan kişi tarafından kullanılan bir göstergedir. Geliştiricinin bakış açısından, ciddiyet tartışmalı bir noktadır. İş atayan kişinin bakış açısından, ciddiyet, karar verme sürecine yardımcı olan önemli bir bilgi parçasıdır.

Tabii ki, tüm bunlar çok genel bir bilgidir. Eğer imkansız derecede uzun bir hata birikimine sahip bir takımsanız, öncelik ve önem, boş bir hata veritabanına sahip bir ekipte olduğunuzdan tamamen farklı bir şey anlamına gelir.

Eğer "yüksek önem derecesi == yüksek öncelik" olan hiçbir ekip önemli değilse ve her iki metriğe de ihtiyacınız yoksa. Günün sonunda, bunlar sadece araçlar. Ekibinizin bunları nasıl kullanacağına karar vermesi gerekiyor. Ekibiniz için her ikisini de kullanmak mantıklı olmayabilir.

IMHO, hem Önceliği hem de Şiddeti koymak sadece bürokrasidir.

Uygulamada, sadece bir "önem" ölçüsüne ihtiyacınız vardır. Genellikle öncelik bunun için kullanılır ve şiddeti daha sonra "yüksek = çökme sistemi veya kullanılamaz hale getirir", "orta = buggy davranışı, potansiyel olarak zararlı", "düşük = rahatsızlık, sinir bozucu ama zararsız" gibi teknik terim olarak kullanılır.

Genellikle öncelik, ciddiyetle el ele gider. Birkaç karşı örnek "herkesin her zaman şikayet ettiği bir sıkıntıdır" veya "egzotik bir ortamda bir kez meydana gelen bir çarpışmadır".

... ancak, sonunda, bir geliştirici (veya yönetici, vb.) olarak, sadece işleri hangi sırada düzeltmeniz / iyileştirmeniz gerektiğini bilmeniz yeterlidir. Yani bir ölçü yeter.

Öncelik ihtiyacı açıktır: hata raporlarının hangi sırayla ele alınması gerektiğini bilmek. Diğeri, her zamanki gibi IMHO, bürokrasi. Neden ihtiyacın var? Görünüşe göre sıralama için işe yaramaz çünkü öncelik bunu yapar. Ve sonuçlar (önem tanımı) yine de hata raporunda açıklanmaktadır.

Zararlı olduğunu bile düşünüyorum, çünkü hangi hatanın daha önemli olduğunu daha az netleştirir:

• Bazıları "kritik" bir hatanın "yüksek öncelikli" bir hatadan daha yüksek önceliğe sahip olduğunu düşünebilir.
• Hata bildiren bazı kullanıcılar önem derecesini ve önceliği karıştırabilir
• ... tamamen, hataların hangi sırayla ele alınması gerektiği konusunda karışıklık katıyor

Diğer yanıtlara ek olarak, şu senaryoyu inceleyin: A hatası düzeltmek için 30 dakika sürecek ve 'düşük' şiddete sahip olacak; hata B'nin düzeltilmesi ve 'yüksek' şiddeti olması 2 hafta sürebilir. Buna ek olarak, B hatası geliştirici ekipte ve belki de ekip dışında çok fazla tartışma ve koordinasyon alabilir; A hatası hemen tek geliştirici tarafından giderilebilir. Hata A'da daha yüksek öncelik belirlemek son derece iyidir.

Elbette 'ciddiyet' ve 'öncelik' farklı şekillerde yorumlanabilir.

Kendi kullanımım için yaptığım küçük bir hata izleyicide, yüksek şiddetli sorunların her zaman en yüksek önceliğe sahip olacağı 'zorluk' ve 'öncelik' tercih ettim ve zorluklara dayanarak üzerinde çalışmayı ertelemeye karar verebilirim.

'Ciddiyet' hakkında sevmediğim bir şey, sadece hatalar için geçerli olması, özellikler için geçerli olmamasıdır. 'Sırada ne yapacağım?' Kararına daha doğrudan yardımcı olacağından, öncelik ve zorluk derecesine göre sıralanan tüm sorunların tek bir listesine sahip olmak daha iyi olabilir.

ISO9001: 2007 sertifikalı bir yazılım şirketinde süreçler tasarladım ve uyguladım. 2007'den beri standartta güncellemeler yapıldı, bu yüzden farkında olmadığım ek gereksinimler olabilir ... ancak:

ISO9001 standardı, şirketinizin ürün ve süreç kusurları tespit edildiğinde süreci iyileştirmek için geri besleme döngülerine sahip süreçler tasarlamasını ve uygulamasını sağlar.

Tasarım aşamasında gereksinimler, doğru bir şekilde uygulandığında önerilen çözümün tasarım özetini (doğrulama) gerçekten çözüp çözmeyeceğine ve uygulamanın gerçekte hatasız mı uygulandığını (doğrulama) kontrol etmeye odaklanır.

Geri bildirim döngüsünde, hatalar tanımlandığında, bunların kaydedilmesi yeterli değildir. Bir kusurun ciddiyet açısından da değerlendirilmesi ve yeniden işleme öncelik verilmesi gerekir.

Kilit nokta, şirketinizin önem derecesini değerlendirmeye ve öncelik hakkında kararlar vermeye nasıl karar verdiğinin ISO standardı tarafından tanımlanmadığıdır. Şirketin karar vermesi ve belgelemesi ticari ve yönetişim meselesidir.

Standart olarak bir gereklilik olarak yazıldığı için, sertifikalı herhangi bir şirketin bir kusurun ciddiyetini değerlendirme süreci ve hatayı düzeltmek için çalışmanın önceliğini belirleme süreci olacaktır. Kesinlikle alınması gereken iki ayrı karar.

Hatanın ciddiyeti sadece bir veri noktasıdır. Müşteri etkisi Başka bir veri noktasıdır. Ayrıca, ürünün kalan ömrünü, ticari ömrünü ve şirketin karar verme sürecine dahil etmeye karar verdiği diğer faktörleri düzeltme, kusurlama çabası da vardır. “Önceliğe karar vermek için ürün yöneticisine şimdiki kusur” olarak yazılmaması gereken tek şey, yalnızca karar verme yetkisini tanımlaması ve karar vermek için izledikleri süreci tanımlamamasıdır.

Genel ürün güvenilirliğini en iyi şekilde artırdığı için yüksek oranda küçük ve önemli değişiklikler sunmaya yönelik önyargılı bir önceliklendirme tercihim var. Bu, düzeltmek için çok fazla iş gerektirecek ciddi bir hatanın, planlanması için yeterli önceliği elde etmek için çalışmasının daha küçük parçalara bölünmesi gerektiği anlamına gelir.

Öncelik ve şiddeti büyük ölçüde farklılaştırmak için:

Basit bir örnek. Sisteminizin ölçeklenmesini önleyen dar bir yeriniz olduğunu düşünün - bazı algoritma karmaşıklığı O (N ^ 3), burada N istemci mağaza sayısıdır. Müşteri önümüzdeki yıl 200 yeni mağaza açacağını ve gerekli hesapların (mal dağıtımı, nakliye planlaması vb.) Zamanında tamamlanmayacağını söyledi. Ancak, şu anda bu müşterinin sadece 30 mağazası var ve kaynaklar yeterli. Bu algoritmayı (O (N ^ 2) veya daha iyisine) optimize etme görevi kesinlikle önemlidir (uygulanmazsa istemciyi kaybedersiniz), ancak büyük olasılıkla acil değildir: yeni algoritmayı uygulamak için birkaç ayınız vardır.

Örnek 2: Bir uygulama sistematik olarak kilitleniyor, ancak bu sürüm yükseltme veya taşıma nedeniyle birkaç gün içinde kullanımdan kalkıyor. Düzeltme acil bir durumdur çünkü çökmeler kullanıcı deneyimini gerçekten etkiler, ancak önemi düşüktür.

Elbette, her iki parametre de kısa vadeli bir çalışma planı oluşturmak için bazı metrikler (resmi veya gayri resmi) kullanılarak birleştirilir, çünkü ikincisi tek boyutludur (görev sırası). Ancak uzun vadede birleşmezler.