Görevleri / hataları değişiklik riskine göre kategorilere ayırma

Şu anda üzerinde çalıştığım projenin bir sorunu var: hatalar ve görevler genellikle çok yeni veya çok deneyimsiz insanlara atanıyor ve çalışmaları yolda daha fazla hata üretiyor. Sorun, yazılımımızın parçalarının kod kalitesi sorunları nedeniyle üzerinde çalışmak için diğerlerinden daha "tehlikeli" olmasıdır. Görevlerle ilişkili riski tahmin ederek ve geliştiricilerin hangi görevlere atandığına dikkat ederek bu sorunla mücadele etmeye çalışıyorum.

JIRA kullanıyoruz, bu yüzden bu tahmini takip etmek için etiketleme konularına başladım. Bir hatayı / görevi kategorilere ayırmak için birkaç metrik kullandığımı fark ettim:

• Ne kadar açık / anlaşılır. Örneğin, çok fazla tasarım çalışması veya sadece basit bir UI hata düzeltmesi gerektiren bir şey.
• Kodun etkilenen alanının ne kadar sürdürülebilir olduğu. İyi tasarlanmış bir alan mı yoksa büyük bir çamur topu mu?
• Programın ne kadarının gerekli değişiklikten etkileneceğini düşünüyorum.

Etiketlerim biraz dağınık çünkü olası kategorilerin ne olacağına dair net bir fikrim yoktu ve hala bilmiyorum. Yeni bir alanın ("Risk" gibi bir şey) eklenmesini istemeyi düşünüyorum, böylece işi birisine atamadan önce bir tahminde bulunmamız gerekebilir.

Daha önce bu tür şeylerle ilgilenen var mı?

Çoğu hata izleme yaklaşımının başarısızlıklarından biri, denklemin sadece bir tarafı ile ilgilidir - son kullanıcının sistem görüşü. Bu düzeltmek için kritik bir hatadır bu bir hafta bekleyebilir (öncelik), bu hata bu acı verici birs bir çoğullama aksaklık (şiddet).

Çok boyutlu hata izlemeyi açıklayan bir blog yazısı , geliştirici görünümü de dahil olmak üzere bu sorunu ele almaktadır: PEF ve REV.

PEF değerleri kullanıcının görüşüdür:

• P ain - karşılaşıldığında, hata ne kadar acı olduğunu?
• E - fort - etrafında çalışmak için ne kadar çaba gerekiyor?
• F requency - ne sıklıkta hata meydana gelir?

REV tarafı geliştiricinin görüşüne göre:

• R isk - düzeltme kadar riskli olduğunu?
• E ffort - bu düzeltme alacak ne kadar çaba?
• V erifiability - ne kadar kolay bu hata düzeltildi olduğunu doğrulamak için mi?

Bunların her biri 1..9 ölçeğinde ölçülür; 1 düşük / kolay ve 9 yüksek / sert olur. Sayılar, PEF ve REV için bir puan vermek üzere birlikte eklenir.

Açıklanan bitleri ele alan bölüm:

• Ne kadar açık / anlaşılır. Örneğin, çok fazla tasarım çalışması veya sadece basit bir UI hata düzeltmesi gerektiren bir şey.
• Kodun etkilenen alanının ne kadar sürdürülebilir olduğu. İyi tasarlanmış bir alan mı yoksa büyük bir çamur topu mu?
• Programın ne kadarının gerekli değişiklikten etkileneceğini düşünüyorum.

Bu faktör REV'de açıklanan çaba ve riske girer.

Evet, daha önce savaşılmış bir şey. (Geçmişte) bu modeli Redmine'daki özel alanlar için kullandım ve oldukça başarılıydı.

Bunun büyük avantajı, PEF ve REV puanlarını karşılaştırdığınızda ortaya çıkar. 21 PEF ve 7 REV varsa, bu büyük bir kazanç olabilir bir şey. 7'lik bir PEF ve 21'in REV'si bir süre için kaçınılması gereken bir şey olsa da, risk ve çaba tarafı büyük olasılıkla bunu düzeltmenin yararından daha ağır basmaktadır.

Daha sonra REV puanına bakılabilir ve daha az deneyimli geliştiricilere Düşük Riskli şeyler atayabilirsiniz (düşük risk, yüksek çaba genellikle bu durum için idealdir).

Burada bahsettiğiniz şeylere “karmaşıklık” denilebileceğini söyleyebilirim. Tabii ki, bir değişiklik ne kadar karmaşıksa, 'risk' ne kadar yüksek olursa, deneyimsiz bir programcı tarafından bazı yeni hataların ortaya çıkabileceğidir. Gerçek bir konu ise böyle bir alanı tanıtmak kötü bir fikir değildir.

Ancak, yazdıklarınızdan yola çıkarak iki konunuz var gibi görünüyor:

1. Yeni veya deneyimsiz programcılar ile uğraşıyorsunuz.
2. Kodunuzun (çok / bazı) kalitesi şüpheli görünüyor.

Bir 'karmaşıklık' alanı (işinizi yönetmenize ve önceliklendirmenize yardımcı olacak) gibi bir şey eklemenin yanı sıra, yukarıdaki iki sorunun riskini azaltmaya odaklanmanızı öneririm.

İlk sorunu ele almak için, yeni programcıların hata üzerinde çalışmadan önce tüm yeni hataları daha deneyimli bir programcı ile tartıştığı bir süreç oluşturacağım. Ayrıca, hem yeni hataların ortaya çıkma riskini azaltmak hem de yeni programcıların daha hızlı hızlanması için koçluk fırsatı olarak kullanmak için kesinlikle kod incelemeleri sunacağım.

Kod kalitesi ile ilgili olarak, iki şey yaparım. İlk olarak, çürüyen süreci durdurun: herhangi bir yeni alt kodun girmesini engelleyecek kodlama standartları ve uygulamaları üzerinde anlaşın. Önerilen kod incelemeleri burada da yardımcı olacaktır. İkincisi, kodunuzun en kötü kısımlarını belirleyeceğim ve bunları yeniden düzenlemeye ve temizlemeye başlayacağım.

Evet, deneyimsiz geliştiricilere çok karmaşık problemler vermemek iyi bir fikirdir. Ama tersi, sadece kolay şeyleri yapmalarına izin verirseniz, o zaman öğrenmeyecekleridir.

Alternatif bir stratejinin kod gözden geçirme rejimi kurmak olduğunu düşünüyorum. Yeni başlayanların zor şeyler üzerinde çalışmasına izin verin (akıl içinde), ancak çalışmalarını iyice gözden geçirin.

Kısa vadede, bu herkes için daha fazla iştir. Uzun vadede, karmaşık şeyleri işleyebilen ve kod kalitesi söz konusu olduğunda "aynı sayfada" olan bir geliştiriciler ekibiyle sonuçlanacaksınız.