developen

Bu yazıda, ürün yada süreç metrikleri olarak ayrılan metrikleri, başka bir biçimde de sınıflandırıp incelemek niyetindeyim. Yeni sınıflandırmamızdaki ayrım yaklaşımdan kaynaklandığı için, siz okurlara aradaki farklar pek net gelmeyebilir diye çekiniyorum. Bu yüzden uzun bir yazı olabilir. Nefesinizi tutun, başlıyoruz…

Metrikler bir şekilde ürün yada süreçlerimizi ölçmek amacıyla kullandığımız kantitatif değerlerdir. Biz kendi üretim sürecimiz içerisinde, neleri ölçmek ihtiyacı hissediyorsak, bu konu ile ilgili metrikleri oluşturur ve sürekli takip ederiz. Kimi ekipler için önemli olan bir metrik, diğer ekipler için önemli olmayabilir. Bu sebeple, metrikler kullanıldıkları ekip içerisinde ve amaçlarıyla anlam kazanırlar.

Metrikleri süreçlerimizi yada ürünümüzü “kontrol etmek” yada “denetlemek” için kullanırız.

“kontrol” ve “denetleme” arasındaki farkı belirtmekte yarar var tabii.  Kontrol, bir şeyi sürekli gözetim altında tutmak demektir. Denetleme ise, süreli ve kesikli gözlemler ile bir şeyin durumundaki değişikliklerin gözlemlenmesidir.

Gündelik dilde kullandığımızın aksine, yönetim bilimine baktığımızda, kontrol ve denetleme böylesine keskin bir ayrıma sahip iki farklı kavram olarak karşımıza çıkar. Bir süreci, sistemi yada metayı yönetmek maksadıyla bu yöntemlerden birine başvurulabilir. Yönetim bilimi, genelde sürekli kontrolü lanetlese de, değişim noktalarında kontrol, denetlemenin ötesinde vazgeçilmez bir araç olarak karşımıza çıkmaktadır.

Bizler de ürünümüzün yada süreçlerimizin kalitesini yönetilebilir kılmak için değişik noktalarda kontrol yada denetim yöntemlerinden birini tercih ederiz. Nasıl, gündelik hayatımızda kullandığımız araçları amaçlarımız belirliyor ise, kullandığımız metrikleri de yönetim biçimimiz belirler. Hatta yönetim için kullandığımız yöntemin, denetleme yada kontrol olması bile kullanacağımız metriklerin özelliklerini değiştirecektir.

Genelde denetlemek için kullandığımız metrikler, bağıl metriklerdir. Bağıl metrikler, iterasyonlar arasındaki farkları şeffaf kılmak amacıyla oluşturulurlar. İterasyonlar arasında bulunan yeni hatalara ait metrikler bu tip metriklere örnek olabilir. Farkedeceğiniz gibi süreç metriklerinin çoğu bağıl metriklerdir, zira süreçler kendilerini tekrarlar niteliktedir. Ürün üzerindeki değişikliklerin kontrolü için bağıl ürün metrikleri olduğunu da ayrıca belirtelim.

Kontrol için kullandığımız metrikler ise durum metrikleridir. Kontrol metrikleri, sürecin neresinde bulunduğumuzdan bağımsız olarak, bir ürünün yada sürecin o anki durumu ile ilgili bilgiler sunar bizlere. Örneğin üründe bulunduğu bilinen, düzeltilmemiş hatalar ile ilgili metrikler, kontrol metriklerine örnek olabilir. Genelde ürün metrikleri, kontrol metrikleridir ama yine de istisnalar mevcuttur. Yani kontrol metriği olan süreç metrikleri de vardır.

Evet, bizler için metrikler çok güzel ve kullanışlı araçlar olabilir. Lakin her mühendislik konusu gibi,  hangi metriklerin hesaplanması gerektiği de, zamanla gereken bilgilerin toplanması sorunu yüzünden bir optimizasyon problemine dönüşecektir.

Metrikleri oluşturmak için basitçe şöyle bir yol izleriz;

Önce kullanılacak metrikleri belirleriz. Bu bizlerin ürünün hangi parametrelerini, yada hangi sürecin hangi özelliklerini daha yönetilebilir kılmak istediğimize dair vereceğimiz kararın sonucudur.

Daha sonra bu metrik ile ilgili hedeflerimizi saptarız. Ne yazık ki düzeltme çarpanları gibi güzel şeyler olsa da, çoğu durumda bir metriğin değeri  1,22489003 çıkabilmektedir. Bu sebeple, “geçer notumuzu” da ihtiyaçlarımız dahilinde biz belirleriz.

Hedeflerimiz de belli olduktan sonra, bu metriklerin hesaplanabilmesi için gerekli verilerin neler olduğunu tanımlarız. Örneğin ekibimizin elemanları başına düşen ortalama kahve miktarına yönelik bir metrik tanımlıyor isek (nedense??), ekip üyeleri ve günlük olarak kimlerin kaç fincan kahve içtiği bilgisine ihtiyacımız olacaktır.

Ardından, tabii ki süreçlerimizin bu metrikleri toplayabilecek hale getirilmesi gerekmektedir. Yukarıdaki örnekten devam edersek, belki de bu verilerin toplanması için, kahve makinamızın personel kimlik kartları ile kahve vermesi ve bu bilgilerin merkezi bir ortamda toplanması gerekecektir.  

Tabii ki ürettiğimiz metriğin ne kadar kritik olduğu, bu verilerin ne şekilde toplanacağı konusunda bazı soruları gündeme getirebilir. Aynı örnekten yola çıkarsak, eğer söz konu metrik bizim için çok kritik ise, eşe dosta kahve alan arkadaşlar için bir çözüm geliştirmemiz gerekebilir.

En son verilerimizi toplar, metriklerimizi oluştururuz.

Buraya kadar elimizde 3.456456 gibi bir değerden öte hiçbirşey yoktur. Bu değerin “iyi” yada “kötü” olduğu ile ilgili de bir fikrimiz mevcut, evet. Ama şimdi en önemli noktaya sıra geldi. Günün aforizması geliyor: “Metrikler not vermek için değil, iyileştirmek için kullanılmalıdır”.  Bu yüzden bir sonraki çevrimde metriğimizin alacağı değer ile ilgili bir hedef koyup, metriği hesapladığımız veriler üzerinden de bu hedefimizi destekler aksiyonlar almamız doğru bir pratik olur. 

Sonunda artık işler bir metriğimiz mevcut.

Birçok ön bilgiyi karmakarışık biçimde verdikten sonra, belki de asıl anlatmak istediklerimi buradan başlayarak sıralayacağım. Peki metrikleri oluşturmak ve toplanması gereken verileri belirlemek için nasıl bir yöntem izlemeliyiz?

Bir yazılım hatasını bildirirken hangi bilgileri hata kontrol sistemimize giriyoruz? Niye? Bir yazılım hatasını tanımlamak için “hatayı oluşturmak için gerekli minimum adımlar”,”olmasını beklediğimiz durum” ve “gerçekleşen durum” bilgilerini vermemiz yeterli değil midir? Peki örneğin neden hatanın saptandığı “Platform” ile ilgili bilgileri de sağlamamız beklenir? Her hata belirli platformlara mahsus mudur? Yoksa bir hatanın, sadece raporlanan platform için çözüldüğünden mi emin olunması gerekir?

Kocaman bir hayır. Eğer hata platforma özel ise, emin olun bunu test mühendisi raporunda “Hatayı oluşturmak için gereken minimum adımlar” kısmında belirtecektir. Eğer hatalarınızın platformlara göre dağılımı ile ilgili bir metriğiniz yoksa, hatanın hangi platformda oluştuğu bilgisini zorunlu hata raporlarından çıkarın. Yoksa gereksiz birçok veriyi toplar ve karar mekanizmanızı sulandırırsınız. Bu bir bilgi kirliliğidir.

Geliştirme sürecinde bazı verileri toplamadan önce süreçlerinizi ve ürününüzü ne şekilde yönetmeniz gerektiğinin kararını vermelisiniz. Bu yönetim için gerekli metriklerinizi belirleyip, bu metriklerinizin gerektirdiği verileri toplamanız yeterli olacaktır. Metrikleri hiçbir zaman olduğu hali ile yada ilk formları ile kullanmak zorunda değilsiniz! İhtiyaçlarınız dahilinde onları geliştirin yada basitleştirin.

Üretim sürecinizin herhangi bir aşamasında, süreçleriniz yada ürününüz için takip ettiğiniz metrikleri oluşturmak için gerekenden fazla bilgi toplamayı bırakmak doğru bir adım olacaktır. Projenin başında ürün ile ilgili kontrol metriklerinizi, kabul şartları ve üretim sürecinizin gerekleri uyarınca belirlemeniz ve sadece bu verileri takip etmeniz işinizi her zaman görür. Eğer bazı veriler toplanmadığı için ileride bazı gerçekleri göremeyeceğinizi düşünüyorsanız, bağıl metriklerin varlığı sizleri rahatlatsın.

Çünkü SuperKalite A.Ş.’de bunu yapıyor..

SuperKaliteli A.Ş. içerisinde bir yazılım ekibinde çalışan test mühendisleri ellerindeki test vakalarının başarımlarını ölçmek istiyor. Eğer ellerindeki test vakalarının başarımı düşer ise, yazılı test yerine keşif temelli bir yöntem ile ilerlemek niyetindeler.

İlk olarak şöyle bir kontrol metriği tanımlıyorlar

TVB (Test vakaları başarımı) = #Bulunan Hata / #Test Vakası

Bu metriği hesaplamak için, bulunan hatalarının sayısını ve ellerindeki test vakalarının sayılarını bilmeleri  gerekiyor. Bunu hata takip sistemlerinden ve test vakaları yönetim sistemlerinden edinmeleri kolay. Her gün, yazdıkları basit bir JScript betiği ile TVB değerini hesaplayıp bir Excel tablosuna işletiyorlar.

Buldukları değer  0,34 civarında çıkıyor. Ekip bir sonraki iterasyonda hedeflerini 0,40 değerine çekmek istiyor  ve bu hedefi tutturmak için test ekibimiz içinde bir toplantı yaparak durumu değerlendiriyorlar. Çıkan fikir, bulunan hata tipleri incelenerek, geliştirme ekibinin genelde yaptığı hatalar çerçevesinde yeni test vakalarını depolarına eklemek yönünde oluyor.

Gerekli çalışmaları yapıp, testlerine devam ediyorlar. Bir sonraki iterasyonda değer gerçekten de 0,41 değerine ulaşmış görünüyor. Fakat bu durumda, ne yazık ki ürün yönetimi, bulunan hataların nedense daha az kritik tipte hatalara doğru kaydığını görüyor ve test ekibine konu ile ilgili fikirlerini iletiyor.

Ekip tekrar bir araya gelerek, TVB metriğini ağırlıklandırmak konusunda bir fikir birliğine varıyor. Yeni yapıda TVB artık şu şekilde hesaplanacak.

TVB-Yeni = (#Bulunan Kritik Hata X 5)  + (#Bulunan Önemli Hata X 4) + (…) / (#Test Vakası X 2,5)

Bulunan hata deposuna, hataların ağırlığı ile ilgili ek alanlar ekleniyor, önceden bulunan hatalar kabul sınırında hatalar (Normal Hata, 2) olarak işaretleniyor ve artık ekibimiz ağırlıklı olarak test vakalarının etkinliğini ölçebilir durumda. Dikkatli gözlerden kaçmadığı gibi, bizim eski kontrol metriğimiz, hali hazırda bulunmuş hataların ağırlığı hakkında yapılan bir kabul ile ürün (test vakalarımız da bir ürün) denetim metriğine döndü bile. Artık yine o eski TVB ile test vakalarının başarımını, TVBYeni ile hata ağırlıklı başarımın gidişatını ölçebiliyorlar.

Fakat bu çalışmalar ilerlerken, test vakası depolarının şiştiğini de gözlemliyorlar. Artık iterasyonların sonlarına doğru işletmeleri gereken testleri tamamlamak için zor anlar yaşamaktalar.

Ekip toplanarak konuşmaya başlıyor:

“O halde” diyor ekip üyesi, “başarımı düşük test vakalarını saptayıp bu vakaları iyileştirelim. Gereksiz vakalardan ise kurtulalım!”

İşte bu soruya yanıt için bir süreç denetim metriğine ihtiyaç duyuluyor.

TVİ (Test Vakaları İyileştirme) = (#Son iterasonda değiştirilen vakaların bulduğu hatalar) + (#Çıkarılan Test vakaları sayısı) / (#Son iterasyonda değişen ve çıkarılan test vakaları sayısı)

Bu metriğin hesaplanabilmesi için test vakalarının en son düzenlenme tarihleri belirtilmeye ve bulunan hataların hangi test vakası ile bulunduğunun takibine karar veriliyor. Böylece belirli bir süre hata bulamayan test vaka tipleri belirlenip bunlar iyileştirilip depo güncelleniyor. Bazı vakalar ise depodan tamamen çıkarılıyorlar. TVB ve TVİ metriklerini ölçerek ekip, ellerindeki test vakalarının başarımlarını ve bu başarımı arttırmak yönündeki aktivitelerinin etkinliğini görebiliyorlar.

Siz de SuperKalite A.Ş. gibi, kontrol metriklerini proje başında belirleyerek, metriklerinizi zaman içerisinde geliştirebilirsiniz. Bunun dışında gereksiz veri toplamak ile ilgili bahsettiklerimizi de lütfen aklınızdan çıkarmayın.