Akademik Bilişim 2016, Aydın, Bildiri Sunumu

1. Scrum Takımlarında Performans
Ölçüm Yaklaşımı
Necmettin Özkan, Erol Emir Erdaş,
BS Kalite, Performans ve Süreç Servisi,
Bilgi Sistemleri Kurumsal Gelişim Müdürlüğü,
Turkiye Finans Katılım Bankası

2. Genele Açık / Public
İçerik
• Scrum
• Scrum’ da Ölçüm
• Scrum Metrikleri
• Değerlendirme ve Öneriler
2

3. Genele Açık / Public
Scrum (Model)
• Scrum tekrarlı ve artırımsal bir
model üzerinden çalışan
yazılımı erken ve sürekli olarak
müşteriye sunmayı hedeflerler.
• Artırımsal tasarım geliştirilen
sisteme organik büyüme özelliği
katar
• Tekrarlı modellerde, her bir
süreç adımına sadece bir kez
uğramak yerine her adım sistem
tamamlana kadar birden çok kez
yinelenir
• Her sprint çalışan bir yazılım ile
sonlanır.
3

4. Genele Açık / Public
Scrum (Roller)
• Scrum takımı, ürün sahibi, geliştirme ekibi (bu çalışma
boyunca takım olarak adlandırılmıştır) ve Scrum
üstattan oluşur.
• Scrum üstadı, Scrum toplantılarından ve takımın
önündeki engellerin çözerek pürüzsüz bir geliştirme
sürecinin işletilmesini garanti edilmesinden
sorumludur.
• Ürün sahibi, sahip olduğu ürünün en yüksek değere
ulaşmasından sorumludur ve müşteri ile geliştirme
takımı arasındaki bağlantıyı sağlar.
• Geliştirme takımı her sprintin sonunda potansiyel
olarak kullanıma hazır ürünün geliştirilmesinden
sorumlu olan uzmanlardan oluşur.
• Takımın içinde bir hiyerarşik kısıt yoktur ve takım
dışından yönetilmek yerine kendi işi ile ilgili en iyi
kararları kendi vermeye çalışır
M1
M3
M2
ÜS GT
SMScrum Takımı
4

5. Genele Açık / Public
Scum’ da Ölçüm
• İnsanı odağına alan Scrum yapısında, ölçüm
seviyesi, bilgi piramidinde enformasyondan,
ölçülmesi daha zor olan, insan tarafına (bilgi
seviyesine) kaymıştır.
• İnsan merkeziyetçiliği ile gelen insanların
çeşitlilik ve öngörülemez özelliği ölçümü
zorlaştırır.
• Bireyler ve aralarındaki yüz yüze iletişim ile
süreçlerin standart işletilmesi ile araçlar ve
dokümanlar üzerinde oluşacak standart
izlerden ve buna bağlı sayısal ölçüm
yeteneğinden uzaklaşılmış olur.
• Takıma takımın kendi durumlarını
yansıtacak ölçüm verilerini üretme
kapsamında güven duyulmalıdır.
• Bireysel başarı yerine müşterek hedefler ön
plandadır.
• Scrum’ da plan (hedef) belirsiz ve elastiktir.
• Birçok Scrum metriği ürün bakış açısıyla
oluşturulmuştur.
5

6. Genele Açık / Public
Scrum Metrikleri
6
• Kullanım İndeksi (Usage Index)
• Sprint Tüketme (Sprint Burndown)
• Hız (Velocity)
• Teslimat Oranı (Delivered/Committed)
• Teknik Borç (Technical Debt)
• Yenilik Oranı (Innovation Rate)
• Hizmet Seviye Anlaşmalarına Uyum Oranı
• Müşteri Memnuniyeti
• Takım Değerlendirmesi

7. Genele Açık / Public
Kullanım İndeksi (Usage Index)
• Scrum, değer ve kullanım ilişkisi
• Geliştirilen uygulama ve
özelliklerin son kullanıcı
tarafından kullanım
yoğunluğunu ölçen indekstir.
▫ Müşterinin doğru
gereksinimler üretmesi
▫ Ürün sahibinin bunları
takıma doğru ve doğru sırada
aktarması
▫ Takımın bekleneni, beklenen
kalite ve zamanda üretmesi
ile beklenir
7

8. Genele Açık / Public
Sprint Tüketme (Sprint Burndown)
• Sprint içinde tamamlanması beklenen
işlerin toplamıdır.
• Mevcut sprint boyunca ilerleme durumunu
günlük izlemeye yardımcı olan bir metriktir.
• Düşük performansın nedeni:
▫ yeni işlerin eklenmesi
▫ tahminlemenin hatalı yapılış olması,
▫ takımın ilerlemesine engel durumların
oluşması,
▫ takımın yeni olması,
▫ takımın performansının beklenenin
altında olması olabilir.
• Takımın kendi içindeki işleri yönetmek için
bu atomiklikte ve frekansta kullandığı bir
metrik müşteriye pek manalı değildir. Bu
nedenle bu metrik yerine takım bu
manadaki performansını “teslimat oranı”
üzerinden ölçmek tercih edilebilir.
8

9. Genele Açık / Public
Hız (Velocity)
• Bir sprint’ te tamamlanan iş
miktarıdır ve üretkenliğin
göreceli ölçüsüdür.
• Takımın değişmeyen üyeler ile
devam etmesi durumunda
manalı sonuçlar üretir.
• Başka bir takım ile
kıyaslanamaz.
• Hedef vermek zordur.
• Yerine teslimat oranı
kullanılabilir (müşteri açısından
daha manalı, takım bireylerinin
değişimine bu metrik kadar
bağlı değil)
9

10. Genele Açık / Public
Teslimat Oranı (Delivered/Committed)
• SBI’ ların sprint sonunda tamamlanma
oranıdır.
• Düşük performansın nedeni:
▫ Tahminlemenin hatalı yapılış olması,
▫ PO, DT’ ye iş kalemi ile ilgili yeterli
bilgiyi aktarmaması
▫ Net olmayan kapsamdan dolayı işin
beklenenden fazla zaman alması,
▫ Takımın yeni olması,
▫ Takımın ilerlemesine engel durumların
oluşması,
▫ Takımın iş üretme kapasitesinde düşüş
olabilir.
• Yüksek performansın nedeni:
▫ Takımın taahhüdüne uyması
▫ Takımın kapasitesinin altında
taahhüt verilmesi
▫ Teknik borca karşın hızlı geliştirme
10

11. Genele Açık / Public
Teknik Borç (Technical Debt)
• Teknik borç, kalitesiz yazılım
geliştirme sonucu oluşan maliyettir.
• Üretilen hata sayısı, kod kalite puanı
ve yapılan acil geçiş oranı teknik
borcun ölçüm noktaları olabilir.
• Nedeni:
▫ Gereksinimlerin yönetilmesi ve
analiz edilmesindeki eksiklikler,
▫ “Definition of Done” tasarımında
ve bu alana dair pratiklerdeki
eksiklikler,
▫ Sprint içinde takımın, takım
dışından veya eş zamanlı işler ile
bölünmesi,
▫ Kalitesiz tasarım veya kodlama
▫ Yönetim veya zaman baskısından
dolayı kaliteden verilen tavizler
11

12. Genele Açık / Public
Yenilik Oranı (Innovation Rate)
• Uygulamaya yeni fonksiyon veya
yeni yetenek kazandırmak için
harcanan eforun uygulamanın
bakımına harcanan efor dahil
toplam geliştirmeye oranıdır.
• Etkileyen hususlar:
▫ Ürünün yaşam döngüsündeki
yeri
▫ Takımın sorumluluk alanı
(bakım, proje)
• Takımdan daha geniş bir
perspektifte ürün alanları
bazında ölçülmesi önerilir.
12

13. Genele Açık / Public
Hizmet Seviye Anlaşmalarına Uyum Oranı
• Ürün ve hizmet
• Sprint ortasında gerçek
ortama dair kritik bir
kesintinin düzeltici
aksiyonunun standart Scrum
süreçlerini izlemesi??
• Daha çok bakım takımları için
geçerli.
13

14. Genele Açık / Public
Müşteri Memnuniyeti
• Teslim edilen ürünün müşterinin
beklentilerini karşılama niteliğidir.
• Sprint değerlendirme toplantılarında
müşteri geri dönüşlerinin alınması
esnasında yapılacak bir puanlandırma ile
ölçülebilir.
• Puandaki düşüşün nedeni:
▫ Müşteri isteğini tam olarak
aktaramamış,
▫ Müşteri kabul kriterlerini tam olarak
aktaramamış,
▫ Müşteri sürece gerektiği kadar dahil
olmamış,
▫ Ürün sahibi müşterinin isteğini tam
olarak aktaramamış,
▫ Geliştirilen uygulama bekleneni
karşılayamamış olabilir.
• Anket sorularının geliştirme takımının
performansını ölçmeye yönelik tasarlanması
önem kazanır
14

15. Genele Açık / Public
Takım Değerlendirmesi
• Takımın bireyleri kendilerini, ürün
sahibi ve müşteri takımı
değerlendirerek bir puan üretilir.
• Müşterinin ürün odaklı
değerlendirmesinden farklı olarak
burada takım, takımın yürüttüğü
süreçler ve takıma dair olgular
hakkında genel bir kanı elde edilmiş
olur.
• Ölçüm kriterleri takımın Scrum
değerlerine, pratiklerine kurallarına,
çeviklik ruhuna, işlettikleri sürece
bağlılıkları, iletişim olgunlukları,
şeffaflık derecesi, sürekli iyileştirmeye
açıklık gibi birçok madde olabilir.
• Doğu ve batı arasıbdaki kültür
farklılıkları
15

16. Genele Açık / Public
Metrikler Değerlendirme
16
Metrik
Takım
Performansı
Kullanımı
Scrum’a
Özel
Zaman
Bütçe
Kalite
Kapsam
Kullanım İndeksi Hayır x x
Sprint Tüketme Evet x x
Hız Evet x
Teslimat Oranı Evet x x
Teknik Borç Hayır x
Yenilik Oranı Hayır x
Hizmet Seviye
Anlaşmalarına Uyum Oranı
Hayır x
Müşteri Memnuniyeti Hayır x x x
Takım Değerlendirmesi Hayır x x x

17. Genele Açık / Public
Değerlendirme ve Öneriler
Öneriler Scrum’ da Ölçüm Zorlukları
• Scrum takımlarında performans ölçümü için
ilgili süreçlerin ve çevik kültüründe belirli bir
olgunluk seviyesine ulaşması gereklidir.
• Aksi durumda:
▫ İşin yapılmasından ziyade işin yapıldığının
gösterilmesi,
▫ Scrum takımlarının elindeki özgürlüğü
kurum değil bireyler lehine kullanılması
▫ Nihai performans değerlendirmesi yapan
mercilerin hiyerarşik ayrıcalıklarının
oluşması
▫ Güven ve şeffaflık ortamının yara alması
gibi birçok yan etkinin görülmesi olasıdır.
• Ölçme yerine değerlendirme
• Takımın genel performansı iyi olsa bile bu,
takımın tüm bireylerinin performansının iyi
olduğu manasına gelmeyebilir. Kişi özelinde
müdahaleler dikkat gerektirir.
• Doğru zamanda doğru yaklaşımlarla
performans ölçüm süreçlerine başlanmak
gerekir. Özellikle Scrum’ da.
• İnsanı odağına alan Scrum yapısında, ölçüm
seviyesi, bilgi piramidinde enformasyondan,
ölçülmesi daha zor olan, insan tarafına (bilgi
seviyesine) kaymıştır.
• İnsan merkeziyetçiliği ile gelen insanların
çeşitlilik ve öngörülemez özelliği ölçümü
zorlaştırır.
• Bireyler ve aralarındaki yüz yüze iletişim ile
süreçlerin standart işletilmesi ile araçlar ve
dokümanlar üzerinde oluşacak standart
izlerden ve buna bağlı sayısal ölçüm
yeteneğinden uzaklaşılmış olur.
• Takıma takımın kendi durumlarını
yansıtacak ölçüm verilerini üretme
kapsamında güven duyulmalıdır.
• Bireysel başarı yerine müşterek hedefler ön
plandadır.
• Scrum’ da plan (hedef) belirsiz ve elastiktir.
• Birçok Scrum metriği ürün bakış açısıyla
oluşturulmuştur.
17

18. Genele Açık / Public
Teşekkürler…
18