- Geliştirici üretkenliğini ölçerken sık yapılan hatalar
- Girdi ölçümünün sorunları
çalışma saati gibi girdilere veya harcanan çabaya dayanmak, yanlış davranışları teşvik eder
- Örneğin, şirket kültürü ekran başında geçirilen süreye değer verip bunu ödüllendiriyorsa, geliştiriciler zamanlarını buna akıtabilir; ancak yapılan işin kalitesini garanti etmek zordur
- Daha sert ortamlarda bu,
en erken gelip en geç çıkan rekabetine dönüşebilir
- Çıktı ölçümünün sorunları
- Kod satırı sayısı veya commit sayısı gibi en kötü metrikler bu kategoriye girer
- Geliştiriciler çok kısa sürede büyük miktarda kod yazabildiği için, bunu ölçmek kolaydır
- Tüm çıktı metrikleri bağlam içinde anlaşılmalıdır
- Sonuç ve etki ölçümünün sorunları
- Bu iki metriğin temel zorluğu,
DevOps ekibinin ne kadar sorumluluğu olduğunu anlamaktır
- İş gelirindeki artışı ölçerken, bunu yalnızca geliştiricilerin sorumluluğuna bağlamak mümkün değildir
12 yorum
Oldukça ürkütücü. Yöneticinin bakış açısıyla sahada çalışan kişinin bakış açısı arasında fark varmış gibi görünüyor,,
Tam da
llmgereken kısım gibi duruyor.Alternatif sunmayan bir yazı olduğu için verilmek istenen anlamın bir ölçüde zayıfladığını düşünüyorum. Çıktı miktarının sonuç ölçümünden çıkarılması gerektiği iddiasına katılıyorum; ancak çalışma saatlerinin girdi ölçümünden tamamen çıkarılması gerçeklikle örtüşmediği için buna katılamıyorum. Sonuçta bilgi emeğine dayalı iş yapılırken zaman akmaya devam eder; bu yüzden karar alma süreçlerinde zamanın mutlaka dikkate alınması gerektiğini düşünüyorum
Geliştirici üretkenliğini tartışmadan önce,
genel ilerleme oranı = (karşılanan gereksinim sayısı / çalışma süresi)gibi öncü göstergeleri ölçmenin hem anlaşılması daha kolay hem de daha verimli olduğunu düşünüyorumBen son zamanlarda bu tür yazılara biraz eleştirel bakıyorum; çünkü insanların sonunda bu yazıları görüp vardığı sonucun hiçbir yönetim yapmamayı seçmek olduğunu düşünüyorum. Hangi metrikle yönetirseniz yönetin, sonuçta benzer sorunlar var. Ayrıca herhangi bir metriği kişiler veya ekipler arasında rekabet ya da karşılaştırma amacıyla kullanmaya başlarsanız yan etkiler ortaya çıkıyor. Bu yüzden tek bir metrikle yönetmemek, birbirini tamamlayan metrikleri birlikte takip etmek gerekiyor; ayrıca metriklerin, ekibin kendi kendini geliştirmesine yardımcı olacak şekilde kullanılmasının doğru olduğunu düşünüyorum.
Anlamlı büyüklükteki PR'ların sayısıyla ölçmeye ne dersiniz?
Aslında yurt içinde adı verilmeyen büyük bir şirkette performans, yazılan kod satırı sayısına göre ölçülüyor ağlama ağlama
Haha, ben de gördüm.
Sürekli değişken adlarını değiştiren commit’ler atıyordu.. hehe
Demek ki code review yapılan bir ortam değil?
Haha, code reviewer da code review almak zorunda ya
Birbirlerine karşılıklı destek oluyorlar..
Hahahah, aman Tanrım...
merhaba cehennem dünya ;)
Bu, sadece lafı dolaşan o LOC verimlilik ölçümü mü yani vay canına