Yazılım geliştirme ekiplerinin verimliliğini bakmak ve iyileştirmek her teknik takım yöneticisi için problemdir. Burada kayda değer iki nokta var:

Farkındalık: Takım ne durumda? İyileştirme: Takım daha iyi duruma nasıl kazanç?

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

Bir şeyi değiştirmeye çalışmadan önce, en manâlı adım nereden başlanacağı. Verimlilik, yalnızca çok fazla iş bitirmek veya daha fazla kod yazmak yok, production ortamında yüksek performanslı, kusursuz ürünler üretmek; yalın ve bakımı basit kod yazmak ve sürdürülebilir development ortamı sağlamaktır. Verimlilik üzerine odaklandığımızda 4 asıl başlık altında metrikleri peşine düşüp takip edebiliriz:

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

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

Bu metrikler ile nasıl geliştirme yapıldığı, hangi pratiklerin kullanıldığı, testlerin kapsamı ve ne dek verimli olduğu, deployment süreçlerinin ne dek dinç olduğu ve ürünün production ortamında ne değin sorunsuz olduğu ölçülebilir ışık halkası getirilebilir. Bu metrikleri kullanmakta olduğunu vasıta ve metodolojilere tarafından artırabilirsiniz.

Metrikler ve Örnekler

Development Metrikleri 

Development süreci ne değin iyi olursa, test ve işlem ekiplerine düşen ağırlık; uygulamanın test ve production hataları böylece eksik olur. Bunun yanında yazılım pratiklerini iyi kullanan ekipler sürdürülebilir koda; bakımı kolay ve idare edilir uygulamalara sahip olurlar.

Line of Code: Bir developer'ın açıklanmış zamanda yazdığı kodu açıklama eder. Bu metrik kimsesiz bir şey ifade etmez oysa öbür metriklerle bir araya getirildiğinde yardımsever bir değerleme aracına dönüşür. Line of code, complexity ile birlikte düşünülürse manalı bir netice 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 diğer bir developerınki 200 olabilir. Bu durumda ikinci developer algoritmasını daha yoğun yazmış olabilir.

Örnek değerinde : 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 yer alan hataları düzeltmek için harcanacak zamanı ifade eder. Yanlış yerler başlıca Sonarqube gibi sabit çözümleme araçları ile bulunur ve eforlar bu araçlar kadar 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 göre 2 dakikalık bir vakit verilebilir. İşte bu hataları düzeltmek için bahşedilen sürelerin toplam değeri teknik borçlanmayı ifade eder.

Misal bedel: 18 saat 22 dakika teknik borçlanma değeri

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

Unit Deneme Coverage: Bu metrik, yazılan kodun ne kadarına karşılık unit test yazıldığını yüzdesel olarak açıklama eder. Burada “Line Coverage” ve “Branch Coverage” almak üzere iki tanımlama 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 deneme yazılmışsa; unit deneme coverage'ınız %80 dir. Branch coverage ise satırları yok içeride if, else, for gibi daha aşağı kırılımların ne kadarını kapsadığına bakar.

Misal değer : %60 unit test coverage

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

Cyclometic Complexity: Complexity soylu davranış değerini verirken Cyclometic Complexity karmaşıklık değerini verir. Karmaşıklık değeri ne dek yüksekse bir kodu okuması veya bakımını yapması öyle zordur. bununla beraber 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.

Misal değerinde : 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ı ayrıca re-usability keza 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ı olumsuz etkiler. Yani 1.000 satır kodun duplication oranı %40 ise kod yazılmaktan çok copy-paste yapıldığı anlaşılabilir.

Misal bedel : %26.5 Duplication

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

Code Review: Yazılan kodları static analysis'dan geçirebiliriz ancak keza kuralların kısıtlı olması ayrıca de gözden kaçma olasılığını minimize etmek için başka bir developer veya ekip kadar 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 bitmiş düzenleyerek okunabilir ve bakımı kolay ışık halkası getirilmesidir. Hızlı imlâ hemen gözden kaçan veya okunması zorlama adımları görebilmemizi sağlar. Refactoring check-list çıkarılması beklenen birincil adımdır.

Kullanılabilecek Araçlar: IntelliJ, Visual Studio

Security Bugs: DevOps ya da SDLC süreci içerisinde kullanılan emniyet araçlarının verdiği emniyet zaafiyeti sayılarını ifade eder. Doğru, okunabilir ve beklenilen fonksiyonaliteyi tedarik eden kod yazmanın yanına güvenli kod yazmak da önemlidir. Bu işlem emniyet hatlarının kimler kadar yapıldığını görmemizi sağlar.

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

Deneme Metrikleri

Deneme ortamının yeterli olgunlukta olması ürünlerin production geçişi öncesi tatmin edici kalite olması demektir. Keza aralıksız ve tatmin edici sayıda koşulan testler ile ne kadar sık geri bildirim verilirse takım muhtemel hatalardan öyle erken farkında olan olur ve önlemini alır.

Test Coverage: Fonksiyonel testlerin, ürünün bütün fonksiyonlarının ne kadarını kapsadığının oranıdır. Bu oran yalnızca otomasyondan meydana gelmek zorunda değildir; manuel testler de bu değer içerisine dahil edilebilir. Sayısal bir değerinde yerine tehlike yüzdesi verilmelidir.

Mesela 1.000 mantıksal bağ içerisinden koşulan 300 devamlılık size %70 coverage sağlayabilir. Risk hesaplaması “hata olasılığı x ağırlık derecesi” ya da direk “hata maliyeti” olarak verilebilir. Bu durumda bir süreklilik 4 risk değerini taşırken başka bir akıcılık 20 değerini taşıyabilir.

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

Automation Coverage: Koşulan testlerin ne kadarının deneme 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, Deneme Complete, Ranorex

CI/CD Integration: Deneme sürecinin CI/CD entegrasyonunu belirtir. Bu sürecin manuel olması ve kesintisiz 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 yalnızca fonksiyonalite açsından değil performans olarak da deneme edilmeli ve KPI'lar istenilen seviyeye ulaştıktan sonra daha sonra devreye alım yapılmalıdır. kodlanmış ve fonksiyonalite açısından herhangi bir hataya sahip olmayan ürünler belirtilen bir önem aşağı cevap veremez ayla gelebilir. Bu durum sizi hedeflediğiniz gelire ve garanti ettiğiniz alıcı 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ı deneme edilmelidir.

Test Koşum Sayısı: Testlerin amacı mümkün fonksiyonalite ve/veya işlevsel olmayan hatalar konusunda müşterileriniz fark etmeden takıma geri bildirim vermektir. Geri bildirim ne dek erken verilirse böylece çabuk 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 tatmin edici zamanınız kalmayabilir. Hedef önce jurnal sonra ise commit sayısı kadar deneme koşmak olmalıdır.

Test Veri Management: Testleri sabit veri ile koşmak hataları tutmak için yeterli değildir. Öbür veri setleri ile karşılaşılabilecek farklı durumlar deneme 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 vazgeçmek 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 kesinkes işletilmesini açıklama 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ı kesintisiz işletiyor ve aralıksız mahsul çıkabiliyordur. Bu keza iş birimlerine kesintisiz geri bildirim ayrıca de olası hatalarda erken aksiyon alma seçeceği verir.

Deployment Süresi: Deployment sürelerinin uzun olması geri bildirimleri düşük olmasına niçin olur. bununla beraber takım öbür 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 dek yapılan yatırımların en kayda değer çıktısı, müşteriye bahşedilen 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 açıklama eder. APM göre ölçülebilir. Bilhassa sunucu tarafında geçen sürenin çözümleme edilmesinde kullanılması beklenir. Cevap verme süresi, performansı iyi olan uygulamalar için 1.2 saniyenin aşağı olması beklenir. Cevap 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 spiker tarafındaki hata oranını belirtir. APM den alınabilir. Bu hatanın yüksek olması uygulamanın spiker tarafında aralıksız 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: Başvuru içerisinde önemli işlemleri açıklama eder. genel olarak APM'ler kadar çı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ı olarak 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 kusur veya problemleri raporlamamızı sağlar. Mesela, yerleştirme 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: Kullanım cevap süresi yeterli performansta olsa da yanıt verilen sayfanın browser üzerindeki işlenme süresi uzun olabilir ya da kusur 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 öbür araçlar ile analiz edilebilip iyileştirilebilir. En sık rastlanan problemler:

Yüksek boyutlu ve optimize edilmemiş resimler Çok artı DOM iterasyonu yapilması CSS seçicilerinin ve dosya boyutlarının alışılagelenden uzun olması Gereğinden pozitif 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 üstünde 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. Cevap süreleri ve hataları göz önüne alarak hesaplanır. Hesaplaması aşağıdaki gibidir. (İyi cevap süresi x 1.0) + (makul cevap süresi x 0.5) + (Kabul edilemez Yanıt süresi x 0.0) + Yanlış 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 ekip üyeleri için izlenebilir olmalıdır. Bunun en kayda değer 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 ayrı farklı gösterge panelleri metrikleri takip etmek yerine tüm metrikleri tek bir mahsul içinde takip etmeye ne dersiniz? QA Dashboard için bütün 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 irtibat 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 üstünde Sonarqube, Git, Azure DevOps, New Relic gibi araçlardan alınmış bilgiler yer alıyor. Bu sayede bütün 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. Daha Aşağı tarafta ise New Relic'ten gelen Average Response Time ve Error Rate bilgileri yer alıyor. Adi ş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 ya da sprint bazlı ele alıp takımla tartışabilirsiniz. Maksat iki haftada development, test ve production da neleri iyi yaptık ya da daha iyi yapabiliriz bunu konuşabilmek.

Metriklerin izlenmesindeki maksat takım üstünde iş baskısı koymak değil; bütün tersi takımın olduğu ve ulaşması beklenen yeri sayısal değerlerle konuşmaktır. Mesela bazı başvuru kalitemiz ne olmalı diye düşünmeye başladığında önünde ilgili metrikleri ulaşabiliyor ve hedefleri görebiliyor olması önemlidir. Huysuz durumda her ekip kendisine uyan ya da en basit 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 yardımcı olacağıdır.

Bu dashboardlarda bulunan bir diğer önemli nitelik Developer Scorecardlardır. Score cardları takımdaki şahısların kendi performanslarını izleyebileceği ve hedeflere yakınlıklarını görebilecekleri objektif bir ortam sunar. Mesela bir Developer yöneticisi ile konuşurken kendi scorecard'ından yararlanabilir ya da bir takım lideri kendisine ast 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 vakit dayanıklılık gösterseler de bu direnci canını yakmak 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 alıcı SVN ve TFS gibi gibi code repository ortamlarındansa iletişimi ve entegrasyonu daha kabiliyetli Git ortamlarına geçmeyi deneyin. Bu bununla birlikte çoğu arabulucu da daha bereketli kullanmanızı sağlayacaktır.

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

DevOps yalnızca bir işi otomatik ve seri yapmak için gerekli değildir. Sürecinizi garantili bir şekilde işletmenizi de sağlar. Bütün 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 bambaşka bir göz göre incelenmesi ve buna yorum yapılması kod kalitesini şahane şekilde artırıyor. aynı zamanda takım üyelerinden geri bildirim alınmasını sağlıyor. defalarca ikinci bir göz kalitenin artmasında etkilidir. Code Review süreci kuşkusuz geliştirme sürecinizin içerisinde yer almalıdır.

TDD uygulayın

TDD (Test Driven Development) yalnızca Unit Test yazmak değildir. Test öncelikli kod , yazılım ekibin kültüründe olmalıdır. Direnç gösterilse de sonradan yazılan kodun kalitesi, refactoring gibi süreçlere sağladığı menfaat 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 fazla gördüğümüz kodun birincil hali ile son hali arasındaki farkın harika büyük olduğu. Kendi kodunu okumakta zorlanan bir developer, diğer bir developerın kodunu okuması güç olabilir

Sonarqube gibi static kod çözümleme araçları kullanın

Code Review öncesinde içeride belirlenen standartları denetlemek için static analysis araçlarından faydalanmak oldukça önemli. bununla beraber SonarLint gibi araçlarla bunu development sürecine dahi taşıyabilirsiniz. Sonarqube gibi araçların en kayda değer gereksinimi içten konfigürasyon ve rule-set ler ile amaçlamak. Dolayısı ile bu araçları sürece dahil ederken iyi bir konfigürasyon desteği almanızda avantaj var.

Test otomasyona geçin

Deneme sürecinizi otomatize etmeden kaliteli bir DevOps süreci kurmanız ya da Continuous Deployment hedeflemeniz çok muhtemel değil. Kaldı ancak manuel olarak koştuğunuz bir regresyon setini beklemek ve harcanan efor dek üzüldüğümüz konu fazla azdır. Testlerinizi birazcık önce kayıtlı bir kapsamda otomasyona almanız fazla önemli.

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

Hakiki ortam çağırmak çalışan mahsul ve herif ile irtibat demektir. Bu ikisini izleyebilir ve ölçebilir olmadan ne sunduğumuzu görmek o kadar muhtemel yok. 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 reel 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ı epeyce kayda değer. 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 çoğaltmak için tercih ettiğimiz usul 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 birey bazında uygulayabileceğiniz Gamification modelleri mevcut. Özellikle hangi ekip şu anda nerede ve nereye geldi. Nereyi hedefliyor ve ne sözler veriyor bakmak için bu sayısal verileri bir araya getirerek kesintisiz geri bildirimde bulunmak kayda değer.

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 üstteki sıralara çıkar.

Aşağı 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 çoğu maddesi açık olduğu için olgunluk seviyesi 0 olarak görüntüleniyor.

Lig kullanmamızın nedeni gerçekten bir rekabet ortamı yaratmak ve takımların OKR'ın neresinde olduğunu göstermek.

Bu OKR maddelerini gösteren 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 karşılıklı bir gaye belirlenerek de yapılabilir. En nihayetinde her bir ekibin kullandığı teknoloji ve metodolojiye kadar bu modelleri çeşitlilik gösterecektir.

Kaynak: webrazzi.com