Yazılım geliştirme verimliliği ve ölçümleme

Yazılım geliştirme ekiplerinin verimliliğini görmek ve iyileştirmek her teknik ekip yöneticisi için problemdir. Burada önemli iki nokta var:

1. Farkındalık: Ekip ne durumda?
2. İyileştirme: Ekip daha iyi duruma nasıl gelir?

Ölçmek ve Gözlemlemek: Ölçmeden geliştiremezsiniz

Bir şeyi değiştirmeye çalışmadan önce, en önemli adım nereden başlanacağı. Verimlilik, sadece çok fazla iş tamamlamak veya daha çok kod yazmak değil, production ortamında yüksek performanslı, hatasız ürünler üretmek; yalın ve bakımı kolay kod yazmak ve sürdürülebilir development ortamı sağlamaktır. Verimlilik üzerine odaklandığımızda 4 ana başlık altında metrikleri takip edebiliriz:

• Development kalitesi ve verimliliği
• Test kalitesi ve verimliliği
• Deployment süreçleri
• Production kalitesi

Aşağıdaki tabloda ana başlıklar altında örnek alınabilecek metrikleri bulabilirsiniz.

Bu metrikler ile nasıl geliştirme yapıldığı, hangi pratiklerin kullanıldığı, testlerin kapsamı ve ne kadar verimli olduğu, deployment süreçlerinin ne kadar sağlıklı olduğu ve ürünün production ortamında ne kadar sorunsuz olduğu ölçülebilir hale getirilebilir. Bu metrikleri kullanmakta olduğunu araç ve metodolojilere göre artırabilirsiniz.

Metrikler ve Örnekler

Development Metrikleri 

Development süreci ne kadar iyi olursa, test ve operasyon ekiplerine düşen yük; uygulamanın test ve production hataları o kadar az olur. Bunun yanında yazılım pratiklerini iyi kullanan ekipler sürdürülebilir koda; bakımı kolay ve yönetilebilir uygulamalara sahip olurlar.

Line of Code: Bir developer’ın belirli zamanda yazdığı kodu ifade eder. Bu metrik tek başına bir şey ifade etmez ancak farklı metriklerle bir araya getirildiğinde faydalı bir değerlendirme aracına dönüşür. Line of code, complexity ile birlikte düşünülürse anlamlı bir sonuç alırsınız.

Örnek değer: 2 haftalık geliştirme süreci 800 satır kod.

Kullanılabilecek araçlar: Gitlab, Bitbucket, Gitwiser kullanarak satır sayısı bilgilerini alabilirsiniz.

Complexity: Line of Code’dan bağımsız yazılan kodun algoritma karşılığı da denilebilir. Bir kod içerisinde her bir if, else, for, while veya farklı method çağırımları complexity değerini bir artırır. Bu durumda 500 satır kod yazmış developerın complexity değeri 100 iken başka bir developerınki 200 olabilir. Bu durumda ikinci developer algoritmasını daha yoğun yazmış olabilir.

Örnek değer : 1000 satırlık 200 complexity değeri bulunabilir.

Kullanılabilecek araçlar : Sonarqube, Gitwiser gibi araçlarla kodun complexity’sini ölçebiliriz.

Technical Debt: Kod içerisinde bulunan hataları düzeltmek için harcanacak zamanı ifade eder. Hatalı yerler genelde Sonarqube gibi statik analiz araçları ile bulunur ve eforlar bu araçlar tarafından otomatik verilir.

Örneğin loglama yerine System.out.println kullanılan bir yeri düzeltmek minör bir hata olarak tanımlanıp düzeltmek için Sonarqube tarafından 2 dakikalık bir süre verilebilir. İşte bu hataları düzeltmek için verilen sürelerin toplam değeri teknik borçlanmayı ifade eder.

Örnek değer: 18 saat 22 dakika teknik borçlanma değeri

Kullanılabilecek araçlar : Sonarqube, Fortify, Cast

Unit Test Coverage: Bu metrik, yazılan kodun ne kadarına karşılık unit test yazıldığını yüzdesel olarak ifade eder. Burada “Line Coverage” ve “Branch Coverage” olmak üzere iki tanım kullanılır. Line Coverage, yazılan testlerin satır sayısının ne kadarına karşılık işletildiğini gösterir. Yani 500 satır kodunuzun 400 satırı için unit test yazılmışsa; unit test coverage’ınız %80 dir. Branch coverage ise satırları değil içeride if, else, for gibi alt kırılımların ne kadarını kapsadığına bakar.

Örnek değer : %60 unit test coverage

Kullanılabilecek araçlar : Cobertura, JaCoCo, Sonarqube

Cyclometic Complexity: Complexity büyüklük değerini verirken Cyclometic Complexity karmaşıklık değerini verir. Karmaşıklık değeri ne kadar yüksekse bir kodu okuması veya bakımını yapması o kadar zordur. Aynı zamanda sektörde kabul edilmiş bir gerçek vardır: Cyclometic Complexity değeri yüksek kodlarda hata çıkma olasılığı da yüksektir. Her bir if, case, for gibi kod bloğu Cyclometic Complexity değerini bir artırır. Cyclometic Complexity değerlerinin fonksiyon bazında verilmesi beklenmektedir ve sektörde Cyclometic Complexity değerinin 10 üzerinde olması kabul edilir değildir.

Örnek değer : 0 – 10 kabul edilir Cyclometic Complexity değerdir.

Kullanılabilecek araçlar: Sonarqube, Cast, Fortify

Duplication: Yazılan kodların benzerlik oranıdır. Copy-paste kodlar olarak da değerlendirilebilir. Bu değerin yüksek olması hem re-usability hem de bakım anlamında bir dezavantaj doğurur. Duplication değeri yüksek uygulamaların değişimi zordur. Aynı zamanda duplication değeri yüksek uygulamalar satır sayısını negatif etkiler. Yani 1.000 satır kodun duplication oranı %40 ise kod yazılmaktan çok copy-paste yapıldığı anlaşılır.

Örnek değer : %26.5 Duplication

Kullanılabilecek araçlar : Sonarqube, Cast, Fortify

Code Review: Yazılan kodları static analysis’dan geçirebiliriz ancak hem kuralların kısıtlı olması hem de gözden kaçma olasılığını minimize etmek için başka bir developer veya takım tarafından gözden geçirilmesi ve yorum yapılması talep edilir. Code review süreci için genelde bir review check-list hazırlanır.

Kullanılabilecek Araçlar: GitLab, Bitbucket, Crucible

Refactoring Practice: Yazılan kodun fonksiyonalitesini etkilemeden tekrar düzenleyerek okunabilir ve bakımı kolay hale getirilmesidir. Hızlı yazım anında gözden kaçan veya okunması zor adımları görebilmemizi sağlar. Refactoring check-list çıkarılması beklenen ilk adımdır.

Kullanılabilecek Araçlar: IntelliJ, Visual Studio

Security Bugs: DevOps veya SDLC süreci içerisinde kullanılan güvenlik araçlarının verdiği güvenlik zaafiyeti sayılarını ifade eder. Doğru, okunabilir ve beklenilen fonksiyonaliteyi karşılayan kod yazmanın yanında güvenli kod yazmak da önemlidir. Bu süreç güvenlik hatlarının kimler tarafından yapıldığını görmemizi sağlar.

Kullanılabilecek Araçlar: Sonarqube, Fortify, Cast, Veracode

Test Metrikleri

Test ortamının yeterli olgunlukta olması ürünlerin production geçişi öncesi yeterli kalite olması demektir. Ayrıca sürekli ve yeterli sayıda koşulan testler ile ne kadar sık geri bildirim verilirse takım olası hatalardan o kadar erken haberdar olur ve önlemini alır.

Test Coverage: Fonksiyonel testlerin, ürünün tüm fonksiyonlarının ne kadarını kapsadığının oranıdır. Bu oran sadece otomasyondan oluşmak zorunda değildir; manuel testler de bu değer içerisine dahil edilebilir. Sayısal bir değer yerine risk yüzdesi verilmelidir.

Örneğin 1.000 senaryo içerisinden koşulan 300 senaryo size %70 coverage sağlayabilir. Risk hesaplaması “hata olasılığı x önem derecesi” veya direk “hata maliyeti” olarak verilebilir. Bu durumda bir senaryo 4 risk değerini taşırken başka bir senaryo 20 değerini taşıyabilir.

Kullanılabilecek Araçlar: XRay, Zephyr, Test Rail

Automation Coverage: Koşulan testlerin ne kadarının test otomasyon ile yapıldığını gösterir. Burada beklenen testlerin olabildiğince otomasyona alınıp sık koşulması ve sürekli geri bildirim vermesidir. Kullanılabilecek Araçlar: Testinium, Test Complete, Ranorex

CI/CD Integration: Test sürecinin CI/CD entegrasyonunu belirtir. Bu sürecin manuel olması ve sürekli işletilmesi zor bir konu. Bu disiplinden ziyade sürecin CI/CD entegrasyonunun yapılması beklenmektedir.

Kullanılabilecek Araçlar: Jenkins, Bamboo, Azure DevOps, GitLab

Peformance Test: Uygulamalar sadece fonksiyonalite açsından değil performans olarak da test edilmeli ve KPI’lar istenilen seviyeye ulaştıktan sonra sonra devreye alım yapılmalıdır. Çok iyi kodlanmış ve fonksiyonalite açısından herhangi bir hataya sahip olmayan ürünler belirli bir yük altında yanıt veremez hale gelebilir. Bu durum sizi hedeflediğiniz gelire ve garanti ettiğiniz müşteri deneyine ulaşmakta engeller.

Kullanılabilecek Araçlar : JMeter, Gatling, Loadium, Blazemeter

Integration Tests: System entegration testi de denen bu adımda ürünle entegrasyonda olan tüm ürünlerinde senaryoları test edilmelidir.

Test Koşum Sayısı: Testlerin amacı olası fonksiyonalite ve/veya fonksiyonel olmayan hatalar konusunda müşterileriniz fark etmeden takıma geri bildirim vermektir. Geri bildirim ne kadar erken verilirse o kadar hızlı aksiyon alınır, hatanın büyümesi engellenir. İki haftada bir koşulan testler geri bildirim vermek için yavaş kalır. Bu yüzden beklentinizden daha hata çıkarsa çözmek için yeterli zamanınız kalmayabilir. Amaç önce günlük sonra ise commit sayısı kadar test koşmak olmalıdır.

Test Data Management: Testleri sabit veri ile koşmak hataları yakalamak için yeterli değildir. Farklı veri setleri ile karşılaşılabilecek farklı durumlar test edilmeli ve tek kullanımlık verileri yönetmek için de test verisinin dinamikleştirilmesi sağlanmalıdır.

Kullanılabilecek Araçlar: Informatica, Delphix, CA Test Data Manager, Microfocus TDM

Deployment Metrikleri

DevOps metrikleri, DevOps sürecinin her bir adımının olgunluğunu artırmak için kullanılmaktadır. Devops olgunluğu arttıkça daha güvenilir ve sorunsuz ürünler ortaya çıkar. Bu süreçleri kişilerin insiyatifine bırakmak süreçteki herhangi bir adımın atlanmasına ya da insiyatif sahibi takımdan ayrıldığında neden olabilir.

Automated Deployment: Süreçlerin atlanmadan her bir adımının kesin olarak işletilmesini ifade eder. Bu süreci işleten ekiplerin olgunluğunun yüksek olması beklenir.

Kullanılabilecek Araçlar: Jenkins, Bamboo, Azure DevOps, GitLab

Deployment Sayısı: Bu sayının yüksek olduğu ekipler DevOps sürecindeki adımları sürekli işletiyor ve sürekli ürün çıkabiliyordur. Bu hem iş birimlerine sürekli geri bildirim hem de olası hatalarda erken aksiyon alma seçeceği verir.

Deployment Süresi: Deployment sürelerinin uzun olması geri bildirimleri düşük olmasına neden olur. Aynı zamanda takım farklı işler yapmak yerine süreci takip etmek zorunda kalır. Bu sürelerin minimum tutabilecek aksiyonların alınması beklenmektedir.

Production Metrikleri

Development ortamının iyileştirilmesinden test olgunluğunun artırılmasına kadar yapılan yatırımların en önemli çıktısı, müşteriye verilen hizmetin iyileştirilmesidir. Bizim buradaki önerimiz: New Relic, Dynatrace, Appdynamics gibi APM (Application Performance Monitoring) araçlarını verimli kullanmaktır. Bu sayede production ortamınızı ölçümleyebilir, değişiklikleri trend halinde takip edebilir ve iyileştirebilirsiniz.

Avarage Response Time: Uygulamanın yanıt verme süresini ifade eder. APM tarafından ölçülebilir. Özellikle sunucu tarafında geçen sürenin analiz edilmesinde kullanılması beklenir. Yanıt verme süresi, performansı iyi olan uygulamalar için 1.2 saniyenin altında olması beklenir. Yanıt verme süresinin 4 saniye altında olması ortalamada kabul edilebilir olduğunu gösterir.

Kullanılabilecek Araçlar: New Relic, Dynatrace, Appdynamics, Riverbed, Datadog

Error Rate: Uygulamanın sunucu tarafındaki hata oranını belirtir. APM den alınabilir. Bu hatanın yüksek olması uygulamanın sunucu tarafında sürekli hata aldığını gösterir. Hataların APM ile adreslenerek minimum seviyeye çekilmesi beklenir.

Kullanılabilecek Araçlar: New Relic, Dynatrace, Appdynamics, Riverbed, Datadog

Business Transactions: Uygulama içerisinde önemli işlemleri ifade eder. Genel olarak APM’ler tarafından çıkarılır. Satın alma, rezervasyon tamamlama gibi önemli iş akışlarını ifade eden işlemlerdir. Başarım oranlarının 100% yakın olması beklenir. Önerimiz ayrı ayrı raporlanarak takip edilmeleridir.

Kullanılabilecek Araçlar: New Relic, Dynatrace, Appdynamics, Riverbed, Datadog

Funnels: Bir süreci ifade eder ve başarım oranını azaltan hata veya problemleri raporlamamızı sağlar. Örneğin, sipariş verme senaryolarını uçtan uca inceler ve süreci tamamlamayı engelleyen herhangi bir problem olup olmadığını tespit edebilirsiniz.

Kullanılabilecek Araçlar: New Relic, Dynatrace, Appdynamics, Riverbed, Datadog

Rendering Time: Uygulama yanıt süresi yeterli performansta olsa da yanıt verilen sayfanın browser üzerindeki işlenme süresi uzun olabilir veya hata alabilir. Bu durumda kullanıcının sayfayı geç görüntülediğini atlıyor olabiliriz. APM'lerin istemci modülleri veya istemci analizi yapan farklı araçlar ile analiz edilebilip iyileştirilebilir. En sık rastlanan problemler:

• Yüksek boyutlu ve optimize edilmemiş resimler
• Çok fazla DOM iterasyonu yapilması
• CSS seçicilerinin ve dosya boyutlarının alışılagelenden uzun olması
• Gereğinden fazla kütüphane bağımlılığı
• Projenin mobil dostu kurgulanmaması
• Algoritması doğru geliştirilmemiş döngüler
• Eskide kalmış teknolojilerin güncellenmemesi

Kullanılabilecek Araçlar: New Relic, Dynatrace, Appdynamics, Riverbed, Datadog

Crash Rate: Mobil uygulamalar üzerinde uygulamanın kapanmasına neden olacak hataların oranını belirtir. Bu hataların minumum seviyeye çekilmesi istenir.

Kullanılabilecek Araçlar: Firebase Crashlytics, Countly, New Relic

Apdex Score: 0.0 ile 1.0 arasında değişen production kalite puanıdır. Yanıt süreleri ve hataları göz önüne alarak hesaplanır. Hesaplaması aşağıdaki gibidir. (İyi yanıt süresi x 1.0) + (Kabul edilebilir yanıt süresi x 0.5) + (Kabul edilemez Yanıt süresi x 0.0) + Hatalı Transactionlar x 0.0 ve bunların toplamının toplam transaction sayısına bölümü.

Kullanılabilecek Araçlar: New Relic, Dynatrace, Appdynamics, Riverbed, Datadog

Metriklerin İzlenmesi

Metrikler geliştirici takım, yöneticiler ve takım üyeleri için izlenebilir olmalıdır. Bunun en önemli kısmı takımların metrikleri konuşabiliyor olmaları diyebiliriz. Agile ekipler için burn down grafikler, Developer'lar için Sonarqube gösterge paneli, operasyon ve yine takım için APM Dashboard'lar gibi alternatif gösterge panelleri olarak kullanılabilir. Peki farklı farklı gösterge panelleri metrikleri takip etmek yerine tüm metrikleri tek bir ürün içinde takip etmeye ne dersiniz? QA Dashboard için tüm bu metrikleri tek bir dashboard üzerinden takip edebilirsiniz.

QA Dashbord ile Sonarqube, Git, Jira, Azure DevOps, New Relic, Dynatrace gibi bir çok araca bağlanıp proje, takım ve kişilere ait dashboard lar oluşturabilirsiniz; takımlara ve yönetimi yönelik iletişim aksiyonları alarak onları up to date tutabilirsiniz.

Biz özellikle Agile çalışan ekiplerin daily'lerine ve retrospective toplantılarına bu dashboard ve metrikleri eklemesini öneriyoruz.

Örneğin yukarıda yer alan dashboard üzerinde Sonarqube, Git, Azure DevOps, New Relic gibi araçlardan alınmış bilgiler yer alıyor. Bu sayede tüm bilgileri tek bir ekranda görebilmenizi ve hedefli çalışabilmemizi sağlar.

Dashboard’un solunda Sonarqube’ten gelen Technical Debt ve Unit Test Coverage bilgileri bulunuyor. Alt tarafta ise New Relic’ten gelen Average Response Time ve Error Rate bilgileri yer alıyor. Normal şartlarda bir retrospective toplantısında tüm bu metrikleri ayrı ayrı dashboardlardan görüyor ve raporluyor olmak zorunda kalacaktır. Bu metrikleri haftalık veya sprint bazlı ele alıp takımla tartışabilirsiniz. Amaç iki haftada development, test ve production da neleri iyi yaptık veya daha iyi yapabiliriz bunu konuşabilmek.

Metriklerin izlenmesindeki amaç takım üzerinde iş baskısı kurmak değil; tam tersi takımın olduğu ve ulaşması beklenen yeri sayısal değerlerle konuşmaktır. Örneğin bir takım uygulama kalitemiz ne olmalı diye düşünmeye başladığında önünde ilgili metrikleri ulaşabiliyor ve hedefleri görebiliyor olması önemlidir. Aksi durumda her ekip kendisine uyan veya en kolay olan değerlere odaklanıyor olacaktır. Bir unit test coverage hedefi olmasa ekibin çoğunun unit test yazmak istememesi gibi bir durumdur.

Ekibin olması gerektiği yeri hedefleyip planlamada bu metrikleri nereye taşıması gerektiği ve bununla ilgili aksiyonları ile retrospective toplantılarında hedefin ne kadarını gerçekleştirebildiklerini görmeleri sağlanmalıdır. Bizim önerimiz bu süreçlere QA Dashboard gibi bir ürünü dahil etmenizin faydalı olacağıdır.

Bu dashboardlarda bulunan bir diğer önemli özellik Developer Scorecardlardır. Score cardları takımdaki kişilerin kendi performanslarını izleyebileceği ve hedeflere yakınlıklarını görebilecekleri objektif bir ortam sunar. Örneğin bir Developer yöneticisi ile konuşurken kendi scorecard’ından yararlanabilir veya bir takım lideri kendisine bağlı olan bir developer’ın verimliliğini ve iyileşmesi gereken noktalarını scorecard’ı baz alarak net aktarabilir.

Kalitenin Artırılması

Bir ürünün kalitesinin artırılması, evet bu metriklerle ölçülebilir. Bizim bu konuda birkaç aksiyon önerimiz daha olacak. Bir takımın kalitesini nasıl artırabiliriz?

Agile süreçlerden vazgeçmeyin

Agile süreçlere geçiş kültürel bir dönüşüm gerektirdiği için kolay olmayacaktır. Ekipler bir süre direnç gösterseler de bu direnci kırmak ve geçişi sağlamak oldukça önemlidir. Bu size kısa zamanda çıktı almanızı ve daha işletilebilir süreç işletmenizi sağlayacaktır.

Projelerinizi Git’ e taşıyın

Eski tip SVN ve TFS gibi gibi code repository ortamlarındansa iletişimi ve entegrasyonu daha yetenekli Git ortamlarına geçmeyi deneyin. Bu aynı zamanda birçok aracı da daha verimli kullanmanızı sağlayacaktır.

DevOps süreçlerinizi olgunlaştırın

DevOps sadece bir işi otomatik ve hızlı yapmak için gerekli değildir. Sürecinizi garantili bir şekilde işletmenizi de sağlar. Tüm araç setinin dahil olduğu bir DevOps süreci oluşturup buradaki olgunluğu artırmaya çalışın.

Code Review yapın

Yazılan kodların farklı bir göz tarafından incelenmesi ve buna yorum yapılması kod kalitesini inanılmaz şekilde artırıyor. Bununla birlikte ekip üyelerinden geri bildirim alınmasını sağlıyor. Her zaman ikinci bir göz kalitenin artmasında etkilidir. Code Review süreci kesinlikle geliştirme sürecinizin içerisinde yer almalıdır.

TDD uygulayın

TDD (Test Driven Development) sadece Unit Test yazmak değildir. Test öncelikli kod geliştirmek, yazılım ekibin kültüründe olmalıdır. Direnç gösterilse de daha sonra yazılan kodun kalitesi, refactoring gibi süreçlere sağladığı fayda açısından vazgeçilmez bir proses olarak yerini alır.

Refactoring süreci ekleyin

Refactoring bir kodun fonksiyonalitesini etkilemeden değiştirilmesidir. Refactor edilen kodlarda en çok gördüğümüz kodun ilk hali ile son hali arasındaki farkın inanılmaz büyük olduğu. Kendi kodunu okumakta zorlanan bir developer, başka bir developerın kodunu okuması zor olabilir

Sonarqube gibi static kod analiz araçları kullanın

Code Review öncesinde içeride belirlenen standartları kontrol etmek için static analysis araçlarından faydalanmak oldukça önemli. Aynı zamanda SonarLint gibi araçlarla bunu development sürecine dahi taşıyabilirsiniz. Sonarqube gibi araçların en önemli gereksinimi doğru konfigürasyon ve rule-set ler ile çalışmak. Dolayısı ile bu araçları sürece dahil ederken iyi bir konfigürasyon desteği almanızda fayda var.

Test otomasyona geçin

Test sürecinizi otomatize etmeden kaliteli bir DevOps süreci kurmanız veya Continuous Deployment hedeflemeniz çok mümkün değil. Kaldı ki manuel olarak koştuğunuz bir regresyon setini beklemek ve harcanan efor kadar üzüldüğümüz konu çok azdır. Testlerinizi biraz önce belirli bir kapsamda otomasyona almanız çok önemli.

APM'ler ile production ortamınızı izleyin

Gerçek ortam demek çalışan ürün ve müşteri ile iletişim demektir. Bu ikisini izleyebilir ve ölçebilir olmadan ne sunduğumuzu görmek pek mümkün değil. Bunun için APM (Application Performance Monitoring) araçlarını kullanabilirsiniz. En yaygınları New Relic, Dynatrace, Appdynamics ve Riverbed gibi araçlardır. Bu araçlar ile son kullanıcıların uygulamanızda yaşadığı deneyimi, karşılaştığı hataları ve sistemin yanıt verme sürelerini gerçek zamanlı olarak görme şansınız var.

KPI'lar belirleyin

Ölçemezseniz iyileştiremezsiniz mottosu ile ne durumda olduğumuzu ve nereye gideceğimizi belirleyen KPI ların olması oldukça önemli. Bunun olmadığı yerlerde özellikle test tarafında kendi kendine çalışan bir ekip ile karşılaşabiliyoruz. KPI’lar için QA Dashboard içinde görütüleyebilir, trendini takip edebilirsiniz.

Gamification ve OKR (Objectives and Key Results) İle Kaliteyi Artırın

Kaliteyi artırmak için tercih ettiğimiz yöntem OKR (Objectives and Key Results)’dır. OKR öncelikle ölçülebilir hedefler ile nereye gideceğimizi ve bunun sonunda ne elde edeceğimizi gösterir. OKR modelini takım ve kişi bazında uygulayabileceğiniz Gamification modelleri mevcut. Özellikle hangi ekip şu anda nerede ve nereye geldi. Nereyi hedefliyor ve ne sözler veriyor görmek için bu sayısal verileri bir araya getirerek sürekli geri bildirimde bulunmak önemli.

Gamification yöntemi olarak takımlar ve kişilerden oluşan bir lig belirledik. Her bir lig kendi içerisinde puan alabileceği OKR maddelerine sahip. Bu OKR maddelerini tamamlamayanlar 0 puan, başlayanlar 1 puan ve tamamlayanlar 3 puan alıp ligde üst sıralara çıkar.

Aşağıda QA Dashboard gamification modülü içerisindeki lig sonuçlarını görebilirsiniz.

Yukarıda Platform Team, 56 puan ile en süt seviyede yer alırken en sağda yer alan olgunluk seviyesi değeri 3 olarak görünüyor. Son ekip ise Mobile Team’in birçok maddesi açık olduğu için olgunluk seviyesi 0 olarak görüntüleniyor.

Lig kullanmamızın nedeni aslında bir rekabet ortamı yaratmak ve takımların OKR’ın neresinde olduğunu göstermek.

Bu OKR maddelerini belirten aşağıdaki gibi değerlerimiz var.

Bu maddeleri çeşitlendirebilir ve yeni maddeler ekleyebilirsiniz. Burada yer alan olgunluk seviyesinin direkt bir anlamı yok. TMMI referans alınarak ya da ortak bir hedef belirlenerek de yapılabilir. En nihayetinde her bir ekibin kullandığı teknoloji ve metodolojiye göre bu modelleri farklılık gösterecektir.