Sevdiğimiz metrikler: “throughput”

İşleri küçük parçalara böler, engellerin kaldırılmasıyla ilgili bir akış yakalar, teknik borcu gözünüzden uzak tutmaz, tekrar eden işleri otomatize eder ve WIP’i azaltıp bitirmeye odaklanırsanız diğer metriklerdeki iyileşmeyle birlikte throughput ta artacaktır.

Throughput belli bir zaman dönemi içinde tamamlanan iş adedidir. Belli dönemlerde throughput’a bakılmasının yanında zaman içindeki trendinin izlenmesi teslimatın ritmi ve miktarıyla ilgili fikir verir.

Bizim lTunes’da takımın hız ve üretkenliğiyle ilgilenmemizin iki nedeni var:

  • Geçmiş çıktı adedimizi geleceği tahmin etmek için kullanırız, planlamalara girdi olur.
  • Eldeki işlerin yapılması için kapasitenin izlenmesi ve geliştirilmesine faydası olur.

“Without data, you’re just another person with an opinion.” – W. Edwards Deming

lTunes’un metrik tutma pratikleriyle ilgili yazdığım ilk yazıda da söylemiştim; diğer metrikler gibi, throughput ta yalnızca elinizdeki veriyi samimiyetle doğru tutuyorsanız anlamlı.

 

Öğrendiklerimizden yola çıkarak throughput metriğiyle ilgili faydalı olacağını düşündüğüm bazı önerleri paylaşmak istiyorum:

  • Throughput gibi çıktıya dayalı niceliksel ölçümler süre ve kapsamın sabit olduğu işlerde zaman baskısından ya da takımların çıktılar üzerinden yargılanmasından dolayı kötüye kullanılabilir. Halbuki, yazılım geliştirme karmaşık bir iş ve pek çok tahmin edilmezlik barındırıyor, bir takımın throughput’unun inip çıkması normal.
  • “Throughput”u tek bir rakam gibi düşünmek doğru değil. 1,5 ya da 8 tek başına gerçekten bir anlam ifade etmiyor. Neyin 1’i, hangi durumda 8, neden 5? Tek başına bir rakam kullanmak ve bir rakam peşimde koşmak yanlış yönlendirici olduğu gibi teslimatınızın trendiyle ilgili bir fikir de vermiyor. Bunun yerine gelişime odaklanmak, bağlamı dikkate almak ve rakamı üzerinde konuşmak için bir başlangıç noktası gibi düşünmek daha değerli diye düşünüyorum.
  • Throughput trendine zaman içinde bakmak teslimat kapasitemizin nasıl değiştiğini gösterir. İstikrarlı bir throughput grafiği özellikle gelecekteki şartlar geçmişteki koşullarımıza benziyorsa, gelecekteki teslimat tahminlerimizle ilgili güvenli bilgi verir.
  • Yeni kurulmuş takımlar ya da mevcut ekiplerdeki değişikliklerde takımların doğal ritmini kazanması birkaç hafta alabilir. Böyle durumlarda trendin gittiği yöne bakmak, teslimatın gelecekteki yönüyle ilgili bir fikir verebilir.
  • Throughput’un istediğiniz gibi olmamasının pek çok nedeni olabilir. İşin kendisi değişiyor olabilir, işler farklı şekilde bölünmeye başlamıştır , teslimat pratikleriyle ilgili deneyler yapılıyor olabilir, ekip formasyonu değişmiş olabilir, ekibin etkisi dışında iklimi içinde yüzdüğü, bizim “the soup” dediğimiz ortamda değişimler olabilir vb. Böyle durumlarda retrospective’leri değerlendirip takımca konuyu gündem yapmak iyi olabilir.
  • Teslimatların parça parça belli yerlerde toplanmamasını engellemek gerekiyor. Bu da genelde üretime çıkışta çevik olunamasından, ya da işlerin yapılıp sonunda topluca onay alınmasından kaynaklanır. Eğer takım işlerini istediği zaman üretime çıkabiliyorsa, daha doğru bir tahmin edilebilirlik ve normal bir teslimat deseni ortaya çıkar.
  • Takımları hiç bir zaman metriklerle kıyaslamayın, bu throughput için de geçerli. Takımlar işlerini bölerken farklı yaklaşımlar kullanıyor, teslimatta farklı yöntemler deniyor olabilir. Takımları kıyaslamak, takımların metrikleri kendilerini iyileştirme vesilesi olarak kullanmaları yerine görünmesi istenen yönde kötüye kullanımlarıyla sonuçlanır. Bundan kimse kazançlı çıkmaz, bu oyunun kazananı olmaz.
  • “Özellik fabrikasında çalışıyor olabilir misiniz?” yazısında anlattığım gibi, throughput bize sadece kaç adet “iş”/output yapıldığını söyler, gerçekten değer üretip üretmediğimizi ya da iş sonuçlarını anlamamıza yardımcı olmaz. O yüzden takım performansını takımın sayısal çıktısına bağlamak yerine değeri ön plana koymak, iş sonuçlarına odaklanmak önemli.
  • Tek başına bir metriği iyileştirmek hedefiniz olmasın. Takımın hedefi sürekli iyileştirme olsun, işi yavaşlatacak pratikleri ve süreçleri iyileştirmek olsun. İşleri daha küçük parçalara böler, engellerin kaldırılmasıyla ilgili bir akış yakalar, teknik borcu gözünüzden ayırmaz, tekrar eden işleri otomatize eder ve WIP’i azaltıp bitirmeye odaklanırsanız diğer metriklerdeki iyileşmeyle birlikte throughput ta artacaktır.
İsmail Kırtıllı

Bir Yorum Yazın