Yazılımcılar için verimlilik ölçütleri: neyi izlemeli, neyden kaçınmalı

Yazılımcı verimliliğini ölçmek, yazılım mühendisliğinin en tartışmalı konusu. Yanlış şeyi ölçerseniz sayıyı şişirmeyi teşvik edersiniz, ekibin motivasyonunu kırarsınız ve elinize daha kötü kod geçer. Hiçbir şey ölçmezseniz de karanlıkta uçarsınız: darboğazın nerede olduğunu göremez, yeni kişi almayı gerekçelendiremez, süreci iyileştiremezsiniz.

Doğrusu ikisinin ortasında duruyor. Yazılımcı verimliliği anlamlı biçimde ölçülebilir, ama yalnızca faaliyeti değil sonucu izleyen ölçütleri seçerseniz. Kod satırı sayısı, commit sıklığı ve çalışılan saat, üretilen değer hakkında neredeyse hiçbir şey söylemez. Cycle time, deployment frequency ve kalite ölçütleri ise neredeyse her şeyi söyler.

Bu yazı yazılım ekipleri için gerçekten anlam taşıyan ölçütleri, bunları gözetim kültürü yaratmadan nasıl ölçeceğinizi ve iyi niyetle başlayan ölçümü kuruma zarar veren bir şeye çeviren yaygın tuzakları anlatıyor.

Geleneksel yazılımcı ölçütleri neden işe yaramıyor

Neyi ölçmek gerektiğine geçmeden önce neyi ölçmemek gerektiği açık olsun, gerekçesiyle birlikte.

• Kod satırı sayısı: 500 satır temiz ve bakımı kolay kod yazan bir yazılımcı, 2.000 satır dolaşık kod yazandan daha verimlidir. Kod hacimle değil, ürettiği değerle ölçülür.
• Commit sayısı: Sık commit ilerleme işareti olabilir, ama meşgul görünmek için işi minik parçalara bölmenin işareti de olabilir. Bağlamından koparılmış commit sıklığı gürültüdür.
• Kayıtlı saat: Başında olmak verimlilik değildir. Kritik bir mimari problemi 4 saatlik kesintisiz bir oturumda çözen yazılımcı, 10 saat boyunca işten işe atlayan yazılımcıdan daha çok iş çıkarır.
• Tamamlanan story point: Story point çıktıyı değil, karmaşıklık tahminini ölçer. Ekipler arasında velocity karşılaştırmak ya da hedefi tutturmak için tahminleri şişirmek, ölçümün amacını tamamen ortadan kaldırır.

Bu ölçütlerin ortak kusuru şu: sonucu değil faaliyeti ölçüyorlar. Amaç yazılımcıları meşgul göstermek değil, ekibin harcadığı emeği kullanıcıya hizmet eden çalışır yazılıma ne kadar iyi çevirdiğini anlamak.

DORA ölçütleri: sektörün ortak standardı

DORA (DevOps Research and Assessment) çerçevesi, binlerce yazılım organizasyonunda yıllara yayılan araştırmaya dayanıyor ve hem mühendislik performansıyla hem de iş sonuçlarıyla güçlü bağ kuran dört ölçüt tanımlıyor. Ekipler bu ölçütlerde dört kademeye ayrılıyor: Elite, High, Medium, Low.

1. Deployment frequency (dağıtım sıklığı)

Ekibinizin kodu üretime ne sıklıkta dağıttığı. Yüksek performanslı ekipler ihtiyaç oldukça, yani günde birkaç kez dağıtım yapıyor. Bu ölçüt, değeri büyük ve riskli paketler hâlinde değil sürekli teslim edebilme becerisini gösteriyor.

• Elite: İhtiyaç oldukça (günde birden çok dağıtım)
• High: Günde bir ile haftada bir arası
• Medium: Haftada bir ile ayda bir arası
• Low: Ayda birden seyrek

2. Lead time for changes (değişikliğin üretime ulaşma süresi)

Kodun commit edilmesinden üretimde çalışmaya başlamasına kadar geçen süre. Bu ölçüt pipeline verimliliğini, yani bir yazılımcının işinin kullanıcıya ne kadar çabuk ulaştığını gösteriyor. Kısa lead time, geri bildirim döngüsünün hızlanması ve değerin daha erken teslim edilmesi demek.

• Elite: Bir saatten az
• High: Bir gün ile bir hafta arası
• Medium: Bir hafta ile bir ay arası
• Low: Bir aydan uzun

3. Change failure rate (dağıtımların hata oranı)

Üretimde arızaya yol açan, yani hotfix, geri alma ya da yama gerektiren dağıtımların yüzdesi. Burası kalite kapınız. Her üçüncü dağıtım bir şeyi bozuyorsa yüksek dağıtım sıklığının hiçbir anlamı kalmaz.

• Elite: %0-15
• High: %16-30
• Medium: %31-45
• Low: %46-60

4. Mean time to recovery (MTTR, ortalama toparlanma süresi)

Üretimde bir arıza olduktan sonra ekibin hizmeti ne kadar çabuk ayağa kaldırdığı. Hızlı toparlanma, sıfır arızadan daha önemli, çünkü arıza kaçınılmaz. MTTR değeri düşük olan ekipler korkmadan dağıtım yapabiliyor, çünkü çıkan sorunu hızla kapatabiliyorlar.

• Elite: Bir saatten az
• High: Bir günden az
• Medium: Bir haftadan az
• Low: Bir haftadan uzun

DORA'nın ötesi: işe yarayan diğer ölçütler

Cycle time

Bir iş üzerinde çalışmaya başlanmasından o işin tamamlanmasına kadar geçen süre. Lead time yalnızca commit ile üretim arasını ölçerken, cycle time geliştirme döngüsünün tamamını kapsıyor. Cycle time'ı aşama aşama izleyin: geliştirmede geçen süre, incelemede geçen süre, testte geçen süre, sırada bekleyerek geçen süre. Darboğazın tam olarak nerede olduğu ancak böyle görünür.

Code review turnaround time (ilk incelemeye kadar geçen süre)

Bir pull request'in ilk incelemeyi almadan önce ne kadar beklediği. Yavaş code review, geliştirme sürecinin tamamına yayılan kuyruklar üretiyor. Yüksek performanslı ekipler pull request'leri 4 saat içinde inceliyor. Ekibinizin ortalaması 24 saati aşıyorsa en büyük gizli darboğazınız büyük olasılıkla burası.

Developer experience (DevEx) ölçütleri

Sayısal ölçütler her şeyi yakalamıyor. Memnuniyeti, algılanan verimliliği ve araç kaynaklı sürtünmeyi soran düzenli geliştirici deneyimi anketleri, sayının veremediği bilgiyi veriyor. DevEx puanı yüksek olan ekipler sayısal ölçütlerde de istikrarlı biçimde önde gidiyor.

• Akış hâline girebilme: "Kolayca akış hâline girebiliyorum" ifadesi, kesinti yükünü ve odaklanmaya ayrılan zamanı ölçüyor
• Bilişsel sürtünme: "Build, test ya da inceleme beklemekle çok az vakit geçiriyorum" ifadesi, araç ve süreç verimliliğini ölçüyor
• Geliştirme ortamı memnuniyeti: "İhtiyacım olan araçlara ve bilgiye sahibim" ifadesi, ortamın kalitesini ölçüyor

Teknik borç oranı

Geliştirme zamanının ne kadarının yeni özellik yerine bakıma gittiği. Sağlıklı oran, zamanın %70-80'inin yeni özellik işine, %20-30'unun bakıma ayrılması. Bakım payı sürekli %30'un üzerindeyse teknik borç, sizin ödeyebildiğinizden hızlı birikiyor demektir.

Ekip kültürünü bozmadan yazılımcı ölçütleri nasıl devreye alınır

Bir mühendislik kültürünü bozmanın en hızlı yolu, ölçütleri kişisel performans değerlendirmesine çevirmek. Ölçümü zarar vermeden yapmanın yolu şu:

• Kişiyi değil ekibi ölçün: DORA ölçütleri ve cycle time ekip düzeyinde ölçülür, kişisel karneye asla dönüştürülmez. Kişi bazlı ölçüm, iş birliği yerine sayıyı şişirmeyi ve rekabeti teşvik ediyor.
• Ölçütü öğrenmek için kullanın, cezalandırmak için değil: Sayıyı yargı olarak değil, bağlamı ve eğilimiyle birlikte sunun. "Bu sprint dağıtım sıklığımız düştü" cümlesi işe yarar. "Sen Sarah'tan az dağıtım yapıyorsun" cümlesi yıkıcıdır.
• Ölçütleri şeffaf tutun: Sayıları açıkça paylaşın ve yorumlamaya ekibi de davet edin. Yazılımcılar çoğu zaman yöneticinin gözünden kaçan kök nedenleri buluyor.
• Anlık değere değil eğilime bakın: Günlük dalgalanmayı değil, çeyrekler boyunca oluşan eğilimi izleyin. Kötü geçen tek bir sprint gürültüdür, düşüş eğilimi ise sinyaldir.
• Niyetinizi açıkça söyleyin: Aracı devreye almadan önce neyi ölçtüğünüzü, neden ölçtüğünüzü ve verinin nasıl kullanılacağını anlatın. Gözetim endişesini geçiştirmeyin, doğrudan konuşun.

Yazılımcı verimliliğini ölçmek için araçlar

• Sürüm kontrolü analitiği: Pull request süreleri, dağıtım sıklığı ve code review ölçütleri için GitHub ve GitLab'ın kendi analitiği
• Mühendislik analitiği platformları: DORA ölçütleri ve mühendislik görünürlüğü için LinearB, Jellyfish ya da Swarmia
• Proje yönetimi analitiği: Cycle time ve iş akışı analizi için Jira, Linear ya da Shortcut
• Zaman ve verimlilik takibi: Geliştirme akışı boyunca zamanın nereye gittiğini, odaklanma süresini ve verimlilik örüntülerini görmek için Worktivity

Akılda kalması gerekenler

Birincisi, faaliyeti değil sonucu ölçün. DORA ölçütleri, yani deployment frequency, lead time, change failure rate ve MTTR, gerçek iş sonuçlarıyla bağ kuruyor. Kod satırı sayısı ve kayıtlı saat kurmuyor.

İkincisi, kişisel ölçüt yerine ekip ölçütü. İstisnasız. Kişi bazlı ölçüm ters teşvikler üretiyor ve iş birliğini bozuyor, ekip ölçümü ise sistemi iyileştiriyor.

Üçüncüsü, bağlam sayıdan daha önemli. Dağıtım sıklığı düşük olan bir ekip karmaşık bir altyapı göçünün ortasında olabilir. MTTR değeri yüksek olan bir ekip devraldığı eski sistemlerle uğraşıyor olabilir. Bağlamsız sayı tehlikelidir.

Dördüncüsü, geliştirici deneyimi öncü göstergedir. Kendini verimli, desteklenmiş ve donanımlı hisseden ekipler sert ölçütlerde de istikrarlı biçimde önde gidiyor. DevEx'e yatırım yapmak süs değil, çarpan.

Yazılımcı verimliliğini Worktivity ile izleyin

Geliştirme ekibinizin zamanının nereye gittiğini anlamak, anlamlı bir iyileşmenin ilk adımı. Worktivity zamanın nasıl dağıldığını, odaklanmaya ayrılan süreyi ve verimlilik örüntülerini gösteriyor, yani mühendislik yöneticisine gözetim kültürü kurmadan görünürlük veriyor.

Ücretsiz denemenizi useworktivity.com adresinden başlatın →

Sık sorulan sorular

Tek bir yazılımcı verimlilik ölçütü seçmek zorunda kalsam hangisi olmalı?

Tek bir tane seçmeniz gerekiyorsa deployment frequency. Genel mühendislik performansı ve iş sonuçlarıyla en güçlü bağı o kuruyor. Ama tek başına hiçbir ölçüt tabloyu tamamlamıyor, DORA ölçütlerini birlikte kullanın.

Yazılımcı verimliliğini mikro yönetime kaçmadan nasıl ölçerim?

Kişi takibi yerine ekip düzeyindeki ölçütlere bakın. DORA ölçütlerini ve cycle time'ı zaten kullandığınız araçlardan (GitHub, Jira) çıkarın. Üzerine üç ayda bir DevEx anketi ekleyin. Amaç kişiyi gözetlemek değil, sistemi iyileştirmek.

Yazılımcıların saatlerini takip etmeli miyiz?

Zamanın nereye gittiği verisi emeğin dağılımını anlamak için işe yarıyor, ama verimlilik ölçüsü olarak asla kullanılmamalı. Çalışılan saat, üretilen değer hakkında hiçbir şey söylemiyor. Zaman verisini kişileri değerlendirmek için değil, kesinti örüntülerini görmek ve odaklanma süresini korumak için kullanın.

Yazılımcı ölçütlerini ne sıklıkta gözden geçirmeliyiz?

DORA ölçütlerini aylık retrospektiflerde gözden geçirin. Cycle time'ı darboğazı erken yakalamak için haftalık izleyin. DevEx anketini üç ayda bir yapın. Günlük ölçüt toplantısından kaçının, kaygı üretiyor ve sayıyı şişirmeye davet ediyor.