Yazılım Projelerinde Performans Analizi

Yazılım projelerinde performans geleneksel yöntemlere göre ya da yazılım metodolojilerine göre metrikler belirleyerek analiz edilerek ölçülebilir.

Agile manifestosunu benimseyen Agile Koçları yazılımcıların performanslarını Agile dışı metrikler oluşturarak ölçmeye karşı çıkıyorlar.

Geleneksel bakış açısına göre aşağıda yer alan 5 başlık altında oluşturacağınız metrik ile yazılımcıların performansını ölçebilirsiniz.

Kapsam, Zaman, Yazılımcı, Kalite — Müşteri Memnuniyeti, Metadolojiye Uyum başlıklarının önemi üzerine yapacağınız bilimsel araştırmalar neticesinde genel tabloya etkisini yüzde olarak belirleyebilirsiniz.

Örneğin Kapsam sizin araştırmalarınız neticesinde %32’lik bir öneme sahip ise bu başlıktan gelen 0,475’lik puanı bu dilim ile işleme sokarak bu dilimin puanını hesaplayabilirsiniz.

1.Geleneksel Bakış Açısına Göre Yazılımcıların Performans Analizi:

1.1 Kapsam

İşte yer alan işlerin ne kadarının tamamlandığını ve belirlenen hedeflere ne kadar yaklaşıldığını izlemek için kullanılabilir. Örneğin, iş öğelerinin tamamlanma oranı, belirlenen hedeflere ulaşma oranı gibi metrikler bu kategoriye dahil olabilir. Bu aşamada JIRA’daki verilerden yararlanabiliriz.

Sprint başında kapsama ilişkin yazılımcının toplam 40 puanlık işin olduğunu varsayalım.
Sprint sonunda da 19 puanlık iş kapatıldığı varsayılsın. Bu KPI dan bu sprintlik alınabilecek puan 19/40 = 0,47

1.2 Zaman

İşlerin tamamlanma süreleri, teslim tarihlerine uyum, geçikmeler ve işlerin sürekli olarak ne kadar sürede tamamlandığını ölçmek için bu metrik kullanılabilir.Bu aşamada JIRA’daki verilerden yararlanabiliriz.

Gecikme oranı = (gerçekleşen bitiş — planlanan bitiş) / planlan bitiş süresi (JIRA)

Örneğin 60 dakikada biteceği varsayılan bir iş 70 dakikada bitiyorsa

(70–60)/70 = %14,2 geç kalındığını hesaplayabiliriz.

%0 < Gecikme oranı <= % 5 ise 25 puan;
%5 < Gecikme oranı <= % 10 ise 20 puan;
%10 < Gecikme oranı <= % 20 ise 15 puan;
%20 < Gecikme oranı <= % 30 ise 10 puan;
%30 < Gecikme oranı <= % 50 ise 5 puan ve
%50 < Gecikme oranı ise 0 puan olarak hesaplanabilir.

1.3 Yazılımcı

Yazılım projelerinde performansı değerlendirmek için kullanılabilir. Bu kategoriye ait metrikler, yazılımcıların iş öğelerini tamamlama hızı, hataların sayısı, kod yazma kalitesi gibi metrikler içerebilir. Bu aşamada Yazılımcı’nın da kendine ait alt metriklerinin olduğunu düşünebiliriz.

1.3.1 İş Süresini Tahminleme/Tamamlama oranı (JIRA)

%0 < gecikme oranı <= % 5 ise 5 puan;
%5 < gecikme oranı <= % 10 ise 4 puan;
%10 < gecikme oranı <= % 20 ise 3 puan;
%20 < gecikme oranı <= % 30 ise 2 puan;
%30 < gecikme oranı <= % 50 ise 1 puan
Ve %50 < gecikme oranı ise 0 puan olarak hesaplanabilir.

1.3.2 Kapatılan Story Puanı / Toplam Story Puanı (JIRA)

%90 < Kapatılan Story Oranı <= %100 ise 5 puan;
%80 < Kapatılan  Story Oranı <= % 90 ise 4 puan;
%70 < Kapatılan  Story Oranı <= % 80 ise 3 puan;
%60 < Kapatılan  Story Oranı <= % 70 ise 2 puan;
%50 < Kapatılan  Story Oranı <= % 60 ise 1 puan
Ve %50 < Story Oranı ise 0 puan olarak hesaplanabilir.

1.3.2 Hata sayısı

5+ hata: 0 Puan
4 hata: 1 Puan
3 hata: 2 Puan
2 hata: 3 Puan
1 hata: 4 Puan
0 hata: 5 Puan

1.3.3 Dökümantasyon

(JIRA ya da diğer ortamlarda yazılmış olan kodun açık ve anlaşılır dokümantasyonunun olması)
1’den 5’e puanlanabilir.

1.3.4 Kodun açıklığı

1’den 5’e puanlanabilir.

1.3.5 İletişim yeteneği

1’den 5’e puanlanabilir.

1.3.6 Yazılımcının kendisine iletilmiş olan analiz dokümanındaki gereksinimleri sağlaması (%)

1’den 5’e puanlanabilir.

Not: Testler sırasında çıkan buglar eğer analiz dokümanında anlatılmamış  ise bu analistin KPI’na eklenmeli, yazılımcı için eksi bir puan oluşturmamalı.

1.4 Kalite, Müşteri Memnuniyeti

Yazılan kodun kalitesini, hata oranlarını bu metrik kullanılabilir. Kalite’yi bir mal veya hizmetin müşteri beklenti ve gereksinimlerini karşılama yeteneğidir diye açıklayabiliriz. Dolayısıyla yazılımcının yazılım projelerindeki  performasını ortaya çıkardığı ürünün kalitesini müşteriye sorarak belirlemek en doğru yöntemdir. Bu doğrultuda bu başlık altında belirleyeceğimiz metrikler ile doğru bir analiz yapmaya çalışabiliriz. Yazılımcı başlığına koyduğumuz Hata Sayısı metriği burada da yer alabilir.

1.4.1 Proje çıktısı beklentilerinizi karşılıyor mu? (Kullanılabilirliği, Bakımının yapılabilirliği)

1’den 5’e puanlanabilir.

1.4.2 Projede karşılaşılan sorunlar hızlıca çözümlendi mi? (Onarım için ortalama harcanan süre)

1’den 5’e puanlanabilir ya da Zaman başlığı altında yaptığımız puanlama gibi aralıklar belirterek aşağıdaki formülü uygulayabilir puan/puanlar elde edebiliriz.

* Hızlılık = (gerçekleşen bitiş — planlanan bitiş) / planlan bitiş süresi (JIRA)

1.4.3 Genel anlamıyla projeye vereceğiniz puan ?

1’den 5’e puanlanabilir.

1.4.4 Uygulama bozulma oranı

1’den 5’e puanlanabilir.

1.5 Metadolojiye Uyum

Proje yönetim metodolojilerine (örneğin, Scrum, Kanban) ne kadar uyulduğunu ölçmek için kullanılabilir. Örneğin metodolojide uyulması gereken adımların kaçta kaçına uyulduğu kontrol edilebilir.

(Projede uygulanan metodoloji adım sayısı / Proje tipine göre uygulanması gereken metodoloji adım sayısı)

2. Agile Bakış Açısına Göre Yazılımcıların Performans Analizi:

Yazının başında yazdığım gibi eğer süreçlerinizi Agile ile yürütmek istiyorsanız buraya kadar ki yazı size bir şey ifade etmiyor olacak. Çünkü Agile bu tarz sayısal metriklerle ilgilenmiyor.

Agile’dan bahsedecek olursak;

• Agile manifestosu şeffaflık içinde ekibin kendi kendine deneyen, öğrenen ve gelişen takımlar yaratabilmeyi hedefler.
• Agile manifestosunda takım kendi performans metriklerini kendi belirler. Örneğin metrikler basit, ölçülebilir ve yaklaşık 5–6 tane olmalıdır.
• Metrikler yaklaşık 2–3 aylık olmalı. 2–3 ayda takım metrikleri takım tarafından değişmeli.
• Metrikleri gerçekleştirdiklerinde veyahut gerçekleştiremediklerinde ödül ya da ceza yok.

2.1 Agile KPI’ları (%50)

2.1.1 Müşteri Memnuniyeti Oranı

2.1.2 Yenilik Oranı

2.1.3 Lead Time

2.1.4 Hata Oranı

2.1.5 Kod Kalitesi

2.2 Müşteri Memnuniyeti Anketi (%50)

• Proje çıktısı beklentilerinizi karşılıyor mu? Mesela KullanılabilirliK, Bakımının Yapılabilirliği örnek verilebilir.
• Projede karşılaşılan sorunlar hızlıca çözümlendi mi? Mesela Onarım için ortalama harcanan süre.

Hızlılık = (gerçekleşen bitiş — planlanan bitiş) / planlan bitiş süresi (JIRA)

• Yeni eklenen fonksiyonların kullanımı için A/B Testi yapılabilir. Örneğin Kullanıcı Deneyimleri.
• Yeni eklenen fonksiyon müşteri tarafından kullanılıyor mu?
• Yeterince A/B testi yapıyor muyuz?
• Genel anlamıyla projeye vereceğiniz puan ?

Son olarak söylemeliyim ki bu yazılım projelerinde performans konulu bu araştırmayı stajımda yapmış olduğum bir sunum için yapmıştım. Yararlandığım kaynakları da aşağıda belirteceğim lakin sayısal olarak belirtilen yüzdeleri ya da metriklerdeki ölçüm puanlarını fikir olması açısından yazmış bulunuyorum. Bilimsel araştırmalara dayandırılmışlığı yoktur.

Geleneksel Yöntemler kısmında Erkan Çinko’nun Projelerde Performans Yönetimi adlı yazısından faydalandım, büyük pay onun diyebilirim. Sitesindeki diğer yazılarınızı okumanızı da tavsiye ederim.

Ayrıca maillerimi cevaplayıp tavsiye veren — yine — Erkan Çinko, Sadi Evren Seker ile Agile konusunda değerli fikirlerine basvurduğum Mehmet Yitmen Hocalarımıza da teşekkür ederim.