Jira Olmadan Mühendislik Metrikleri
Önemli olanı ölçmek için Jira'ya ihtiyacınız yok. Git, CI ve ekibinizin zaten kullandığı araçlardan mühendislik sağlığını nasıl takip edeceğinizi öğrenin.
By Ellis Keane · 2026-03-23
En iyi mühendislik görünürlüğüne sahip küçük ekipler, genellikle Jira'nın takip etmelerini istediği metriklerin peşini bırakanlardır.
Bunun sadece muhalefet olsun diye muhalefet ettiğim gibi göründüğünün farkındayım; belki biraz öyledir – ama sprint board'ları sadakatle yönetmek, backlog'ları düzenlemek ve o sabah kimse Jira'yı açmadan önce zaten yarı bitmiş olan ticket tahminlerini güncellemek için üç yılın büyük bölümünü harcadım. Her iki haftada bir bir odada (aslında Zoom'daydık – 2023'tü) oturup birbirimizle konuşarak zaten bildiğimiz hiçbir şeyi söylemeyen bir velocity grafiğine bakakaldık. Jira olmadan mühendislik metrikleri aradığım bir şey değildi. Velocity grafiklerinin bana gerçekten yararlı bir şey söylediğini kabul etmeyi bıraktığımda ortaya çıktı.
Ekibiniz tek bir masanın etrafına sığacak kadar küçükse, nasıl gittiğinizi anlamak için muhtemelen Jira'ya ihtiyacınız yoktur. Zaten kullandığınız araçlardan daha iyi sinyaller almanız gerekir.
Bu bir "Jira kötü" yazısı değil. Jira, Jira şeklinde takip gerektiren kuruluşlar için iyi bir araçtır (ve belirli bir ölçekte gerçekten gerektirirler). Ama 10–40 kişilik bir girişimde mühendislik yöneticisiyseniz, yalnızca velocity grafikleri üretmek için Jira'ya para ödemek, öğle yemeğinizi ısıtmak için endüstriyel fırın satın almak gibidir.
"Yalnızca velocity grafikleri üretmek için Jira'ya para ödemek, öğle yemeğinizi ısıtmak için endüstriyel fırın satın almak gibidir." attribution: Chris Calo
Jira metrikleri aslında neyi ölçer
Açıkça söyleyeyim: Jira metriklerinin çoğu mühendislik çıktısını değil, Jira kullanımını ölçer. Story point'ler ekibin story point tahmin etme yeteneğini ölçer. Velocity, ekibin sprint'leri yaklaşık aynı kapasitede ne kadar tutarlı doldurduğunu ölçer. Burndown chart'lar ise birinin Perşembe öğleden sonra ticket'ları board üzerinde sürüklemeyi hatırlayıp hatırlamadığını ölçer.
Bunların hiçbiri tam olarak işe yaramaz değildir. Ama hepsi developer productivity metrikleri kılığına girmiş süreç metrikleridir ve ikisi arasındaki boşluk, mühendislik yöneticilerinin konuyu kaybettiği yerdir.
Paydaş toplantısından önce neredeyse bir saat harcayarak Jira verilerini "yolda gidiyoruz" gösteren bir slayt destesine dönüştüren EM bendim. Paydaş başını sallar, geçen Salı'dan kalan login bug'ı hakkında bir soru sorar ve toplantı biter. O saat slayt destesi içindi. Gerçek cevap "mühendise sor"du.
Metrikleriniz, ölçtükleri işten daha fazla bakım gerektiriyorsa, sorun metriklerin kendisidir.
Git'ten cycle time, ticket board'lardan değil
Küçük ürün ekipleri için cycle time, genellikle takip edebileceğiniz en yüksek sinyalli metriktir. İlk commit'ten production deploy'una kadar geçen süreyi ölçer ve tamamen Git geçmişinizden ve CI pipeline'ınızdan türetilebilir – ticket board gerekmez.
Bileşenler:
- Bir branch veya PR üzerindeki ilk commit zaman damgası
- PR merge zaman damgası
- Deploy zaman damgası (CI/CD'nizden – GitHub Actions, CircleCI veya ne kullanıyorsanız)
1 ile 3 arasındaki fark cycle time'ınızdır. Bunu segmentlere ayırın – coding time (1'den PR açık'a), review time (PR açık'tan merge'e) ve deploy kuyruğu (merge'den production'a) – ve işin gerçekte nerede durduğunu söyleyen bir tanı elde edersiniz.
Bunu ekibimiz için ilk kez yaptığımda sayılar gerçekten şaşırtıcıydı. Review time'ın darboğazımız olduğunu varsaydım (herkes her zaman review time'ın darboğaz olduğunu varsayıyor, değil mi?). Meğer coding-to-PR aşamamız gayet iyiydi, review'lar da iyiydi ve merge ile deploy arasında staging ortamımız kararsız olduğu ve kimsenin düzeltmeyi öncelik haline getirmediği için ortalama iki gün kaybediyorduk. Bir velocity grafiği bunu hiçbir zaman ortaya çıkaramazdı.
Nasıl ölçülür
GitHub kullanıyorsanız bunu CLI ile çekebilirsiniz:
```bash
Get merged PRs for the last 30 days
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
Deploy zaman damgaları için çoğu CI sistemi bunu API veya webhook aracılığıyla sunar. PR merge SHA'larını deploy event'lerine eşleyin ve fazlara göre segmentlenmiş cycle time'ı elde edersiniz.
İpucu: CI'ınız deploy zaman damgalarını temiz bir şekilde sunmuyorsa, son derece basit bir yaklaşım commit SHA'sıyla birlikte #deploys kanalına gönderen bir Slack bot'udur. Zaman damgaları, insan tarafından okunabilir bir log ve yan etki olarak ne sıklıkta gönderdiğinizi söyleyen bir kanal elde edersiniz.
Code review throughput
Review throughput – haftalık mühendis başına incelenen PR sayısı ve PR açık'tan ilk review'a kadar geçen medyan süre – herhangi bir sprint metriğinden daha fazlasını ekip sağlığı hakkında anlatır. Değeri göz ardı edilmektedir.
Neden? Çünkü review davranışı bir öncü göstergedir. Review süreleri uzamaya başladığında bu genellikle mühendislerin aşırı yüklendiği, aşırı bağlam değiştirme yaptığı veya (ve bu rahatsız edici olanıdır) birbirinin kodundan kaçındığı anlamına gelir. Bunların herhangi biri, iki hafta sonra kaçırılan bir son teslim tarihi olarak ortaya çıkmadan önce bilinmeye değer.
GitHub bu veriyi API'si aracılığıyla sunar. Temel alanlar PR üzerindeki createdAt ve ilk review event'indeki submittedAt'tır.
İzlediğim sayı ilk review'a kadar geçen medyan saattir. Birkaç küçük ekipteki deneyimimize göre, sağlıklı review ritmi yaklaşık 8 saatin altında seyreder. Tutarlı biçimde bir günü aştığında, yapısal bir şeyin değiştiği anlamına gelir – ve ne olursa olsun, Jira'da görünmezdir.
Toplantı-karar oranı
Bu geleneksel bir mühendislik metriği değildir ve açıkça söylemeliyim: bir KPI değil, kaba bir buluşsal yöntemdir. Ancak küçük ekipler için şaşırtıcı derecede açıklayıcı olduğunu gördüm.
Bu haftaki ekip toplantılarınızı sayın. Bunlardan çıkan somut kararları sayın ("X'e bakmalıyız" değil – sahibi ve sonraki adımları olan gerçek kararlar). İkincisini birinciye bölün.
Toplantılarınızın yarısından azı bir kararla sonuçlandıysa, bu toplantıların zamanlarını kazanıp kazanmadığını sormaya değer. Bazı toplantılar riski azaltmak veya bağlamı paylaşmak için vardır ve bu meşrudur – her şeyin bir çözümle bitmesi gerekmez. Ancak bunu gayri resmi bile olsa takip etmeye başladığınızda (ben gerçekten not defterimde tally tuttum), hangi toplantıların üretken olduğunu ve hangilerinin kimsenin sorgulamadığı ritüeller olduğunu hissedeceksiniz.
Bunu yaklaşık bir ay boyunca takip ettim ve toplantıları nasıl planladığımı, herhangi bir üretkenlik makalesinin yaptığından daha fazla değiştirdi. Pazartesi standup'ınızın üst üste üç haftadır tam olarak sıfır karar ürettiğini görebildiğinizde, onu iptal etmek radikal hissetmeyi bırakır.
Jira olmadan mühendislik metrikleri oluşturma: hafif bir dashboard
Bunun için bir BI aracına ihtiyacınız yoktur. Bir Notion sayfası, bir Google Sheet veya dört sayı içeren haftalık bir Slack gönderisi yeterlidir:
- Medyan cycle time (Git/CI'dan) – daha hızlı mı yoksa daha yavaş mı gönderiyoruz?
- İlk review'a kadar geçen medyan süre (GitHub'dan) – ekip zamanında review yapıyor mu?
- Deploy frequency (CI veya #deploys kanalından) – ne sıklıkla gönderiyoruz?
- Toplantı-karar oranı (manuel tally) – toplantılarımız değerini kazanıyor mu?
Dört sayı, hepsini zaten sahip olduğunuz araçlardan türetilebilir, hiçbiri Jira board bakımı gerektirmez. Haftalık olarak güncelleyin. Bir sayı iki hafta üst üste yanlış yöne hareket ederse araştırın. Sabit kalıyorsa, bırakın.
Mesele bir gözetim sistemi kurmak değildir (lütfen kurmayın – mühendisleriniz sizi sevmeyecek ve bunu yapmakta haklı olacaklar). Mühendislik ekibi görünürlüğü, iş hakkında insanlardan rapor istemekten değil, işin kendisinden gelmeli.
En iyi mühendislik metrikleri toplaması ucuz, manipüle edilmesi zor ve üzerine harekete geçilebilecek bir şey söyleyen metriklerdir. Story point'ler her üç kriterde de başarısızdır.
Gerçekten ticket board'a ihtiyaç duyduğunuzda
Bunun bir "Jira kötü" yazısı olmadığını söyledim ve bunu kastederek söyledim. Proje yönetim aracı olmadan metrikleri takip etmenin gerçekten sorumsuz hale geldiği meşru durumlar vardır:
- Görev durumu üzerindeki denetim izlerinin yasal olarak zorunlu olduğu yoğun uyumluluk gerektiren sektörler
- Ekipler arası bağımlılıkların gayri resmi koordinasyonu olanaksız kıldığı büyük mühendislik organizasyonları
- Ekipler arasında yetkili bir gerçek kaynağına ihtiyaç duyan özel proje yönetimi fonksiyonlarına sahip organizasyonlar
Durum buysa, Jira (veya Linear ya da Shortcut) doğru tercihtir. Benim savunduğum şey, küçük ekipler için yalnızca metrikler amacıyla ağır bir aracı sürdürmenin kötü bir takas olduğudur. Ekibinizin gerçek çalışması yerine aracın iş modelini optimize etmeyle sonuçlanırsınız.
Ve dürüst olmak gerekirse? Jira kullanan ekipler bile yukarıdaki Git kaynaklı metriklerle board verilerini tamamlamaktan fayda sağlayacaktır. Jira size insanların ne yaptıklarını söylediklerini anlatır. Git size gerçekte ne yaptıklarını anlatır. Her ikisi de faydalıdır, ama yalnızca biri durum güncelleme tiyatrosuna karşı bağışıktır.
Girişiminizde metrik sorusu gündeme gelmeye devam ediyorsa, bir ay boyunca dört sayılık dashboard'u deneyin. Jira olmadan mühendislik metrikleri, güvenlik ağı olmadan gitmek gibi gelebilir – ama Git geçmişinizde ve CI pipeline'ınızda ne kadar sinyal yaşadığını gördüğünüzde, ticket board'un ne kattığını merak edersiniz.
Cycle time'ı, takılı kalan PR'ları ve review darboğazlarını otomatik olarak ortaya çıkarın – özel betikler veya Jira board olmadan.
Q: Proje yönetim aracı olmadan anlamlı mühendislik metrikleri elde edilebilir mi? A: Evet. Cycle time (ilk commit'ten deploy'a), review throughput ve deploy frequency'nin tamamı Git geçmişinizde ve CI pipeline'ınızda bulunur. Yaklaşık 40 mühendisten küçük ekipler için bunlar, bir ticket board'un ürettiği her şeyden daha keskin ve manipüle edilmesi daha güç olma eğilimindedir ve doğru kalmaları için kimsenin kartları board üzerinde sürüklemesini gerektirmez.
Q: Sugarbug mühendislik metriklerini otomatik olarak ortaya çıkarıyor mu? A: Sugarbug, ekibinizin etkinliklerinden bir bilgi grafiği oluşturmak için GitHub, Linear, Slack ve takvimlere bağlanır. Takılı kalan PR'lar, review darboğazları ve çözümsüz kalan kararlar gibi örüntüleri işaretler – GitHub API'sine karşı özel betikler yazıp sürdürmenizi gerektirmeden burada açıklanan sinyallerin çoğunu kapsar.
Q: Jira'yı metrikler için kullanmayı bırakmak için nasıl onay alabilirim? A: Bunu bir isyan olarak değil, bir deney olarak çerçevelendirin. Git kaynaklı metrikleri mevcut Jira dashboard'larınızla birlikte dört hafta boyunca çalıştırın, ardından hangi sayıların gerçek değişiklikleri tetiklediğini karşılaştırın. Git metrikleri daha uygulanabilir olduğunu kanıtlarsa (ve deneyimimize göre genellikle öyle olurlar), dava kendiliğinden ortaya çıkar.
Q: Süreç metrikleri ile performans metrikleri arasındaki fark nedir? A: Süreç metrikleri (story point'ler, velocity, burndown) bir ekibin iş akışını ne kadar tutarlı takip ettiğini ölçer. Performans metrikleri (cycle time, deploy frequency, review throughput) ekibin gerçekte ne gönderdiğini ve ne kadar hızlı gönderdiğini ölçer. Küçük ekipler neredeyse her zaman ikincisinden daha fazla sinyal alır, çünkü performans metrikleri manuel durum güncellemelerinden değil işin kendisinden türetilir.