Bence endişelerini karıştırıyorsun. Ve senin tarafında, değişmen gereken hiçbir şey yok .
Verimlilik, bir projenin ne kadar çabuk biteceği konusunda bir ipucu. Proje yöneticileri ve herkes projenin ne zaman teslim edileceğini bilmek ister. Daha yüksek veya daha hızlı üretkenlik, projenin daha erken teslim edildiğini göreceğimiz anlamına gelir.
Hata oranı üretkenliğe değil, projenin boyutuna bağlı. Örneğin, kod satırı Nbaşına hata olabilir Y. Bu metriğin içinde bu kod satırlarının ne kadar çabuk yazıldığını söyleyen (veya umursayan!) Hiçbir şey yoktur.
Bunu bir araya getirmek için, daha yüksek üretkenliğe sahipseniz, evet, böceklerin daha hızlı yazıldığını "görürsünüz". Ama yine de, projenin büyüklüğüne bağlı olduğundan bu kadar çok böcek olacaktı.
Herhangi bir şey varsa, daha yüksek verimlilik, proje sonunda bu hataları gidermek için daha fazla zamana sahip olacağınız veya geliştiricinin yarattığı hataları bulma konusunda daha hızlı olacağı anlamına gelir. 1
Sorunuzun daha kişisel yönlerini ele almak için.
Patronunuz, ürettiğiniz hataların aksine ürettiğiniz hataların sayısına kesinlikle bakıyorsa, bir eğitim oturumu düzenlenir. Oluşturulan hataların sayısı, destek oranı olmadan anlamsızdır.
Bu örneği aşırıya çekmek için lütfen patronuna maaşını iki katına çıkarmak istediğimi söyle. Neden? Ben oluşturduk kesinlikle hiçbir hata projenizde ve bu nedenle senden daha çok üstün programcı değilim. Ne? Projenize fayda sağlamak için tek bir kod satırı oluşturmadığım bir sorunu olacak mı? Ah. Şimdi oranın neden önemli olduğunu biliyoruz.
Ekibiniz hikaye noktası başına hataları değerlendirecek ölçütlere sahipmiş gibi gözüküyor. Başka bir şey değilse, yaratılan ham sayı ile ölçülmekten daha iyidir. En iyi geliştiricileriniz , daha fazla kod yazıyor olmalı çünkü daha fazla kod yazıyorlar. Patronunuza o grafiği attırın ya da en azından hataların yanı sıra kaç tane hikaye puanı (ya da ölçtüğünüz işletme değeri) gösteren bir seri yayınlayın. Bu grafik daha doğru bir hikaye anlatacak.
1
Bu özel yorum, beklenenden çok daha fazla dikkat çekti. Öyleyse biraz sersemletici olalım (sürpriz, biliyorum) ve bu soruya odaklanmayı sıfırlayalım.
Bu sorunun kökü, yanlış şeylere bakan bir yönetici ile ilgilidir. Tamamlanan görevlerin sayısına karşı üretim hızına bakmaları gerektiğinde ham böcek toplamlarına bakıyorlar. “Kod satırı” na veya hikaye noktalarına veya karmaşıklığa veya her neyse ölçmeye karşı saplantılı olmayacağız. Eldeki soru bu değildir ve bu endişeler bizi en önemli sorudan uzaklaştırır.
OP tarafından verilen bağlantılarda belirtildiği gibi, bir projedeki belirli sayıda hatayı yalnızca projenin büyüklüğüne göre tahmin edebilirsiniz. Evet, bu geliştirme hatalarını farklı geliştirme ve test etme teknikleriyle azaltabilirsiniz. Yine, bu sorunun amacı değildi. Bu soruyu anlamak için, belirli bir büyüklükteki proje ve geliştirme metodolojisi için, geliştirme "tamamlandığında" verilen sayıda hata göreceğimizi kabul etmemiz gerekir.
Öyleyse nihayet birkaç yanlış anlaşılan bu yoruma geri dönelim. İki geliştiriciye karşılaştırılabilir boyutta görevler atadıysanız, daha yüksek verimlilik oranına sahip geliştirici görevini diğerinden önce tamamlar. Bu nedenle, daha üretken geliştirici, geliştirme penceresinin sonunda daha fazla zamana sahip olacaktır. Bu "fazladan zaman" (diğer geliştiriciye kıyasla), standart bir geliştirme süreci boyunca sızacak kusurlar üzerinde çalışmak gibi diğer işler için kullanılabilir.
OP'yi, diğer geliştiricilere göre daha üretken oldukları sözleriyle almak zorundayız. Bu iddiaların hiçbiri OP ya da daha üretken geliştiricilerin işlerinde kayıtsız olduğu anlamına gelmez. Özelliğe daha fazla zaman harcarlarsa ya da hata ayıklamanın bu geliştirme zamanının bir parçası olmadığını öne sürerek daha az hata olacağına işaret etmek, sorulanı kaçırır. Bazı geliştiriciler diğerlerinden daha hızlıdır ve karşılaştırılabilir veya daha iyi kalitede işler üretir. Yine, OP'nin sorularına yerleştirdiği bağlantıları görün.