Scrum Ekipleri ve Hata Kayıtları

Kimse hata olsun istemez ama hayatımızın bir parçası olan hatalar yokmuş gibi plan yapılması da uygulanabilir değil tabi ki. Entegrasyon noktalarının çokluğu veya projenin büyüklüğüne göre geçiş sonralarında öngörülmeyen hatalarla karşılaşmak mümkün.

İdeal olanı hata kayıtlarının oluşmaması evet ama konumuz o değil. Sürekli hataların geldiği, hatta bunlardan bazılarının çok acil olduğu fırtınalı bir ekipte olduğumuzu varsayalım ve bu durumda neler yapılabileceğini şöyle bir düşünelim.

 

Ölçümleme

Ölçme aslında başarılı olmak isteyen herkesin yapması gereken ilk şey. Bunu sadece yönetime rapor sunmak için düşünmemek lazım. Bir kişinin önünü görmeden koşması mümkün olmadığı gibi durumunu takip etmeyen kişide kendini geliştiremez.

Ölçümleme illa çok detaylı olmak zorunda değil, ölçümlemeye aşırı zaman da ayırmamak lazım. Konumuz olan hata kayıtları açısından düşünürsek, yeni gelen ve kapatılan hata sayısını gösteren bir rapor başlarda bize yeterli olacaktır. Bu şekilde hızımızı ve ne zaman dingin sulara ulaşabileceğimizi az çok kestirebiliriz.

 

Çözüm Yolu

Scrum takımı olarak bizden her Sprint sonunda doğal olarak belli bir ilerleme bekleniyor. Nasıl işlerimizi daha küçük ve dikey parçalara ayırıyor ve sprintlerimize yayıyorsak aynı şekilde belirlediğimiz yolda buna benzer olmalı. Birkaç Sprint içime kapanayım sürekli hata çözeyim deme şansımız yok maalesef.

Öncelikle hata çözümü için ek bir iş gücüne ihtiyacımız olduğu kesin. Ama bu gücü nereden bulabiliriz. İlk akla gelen fazla mesai ve iş yerinde sabahlama düşüncelerini de savurduktan sonra düşünmeye devam ediyoruz. Tabi ki fazla mesai yapılabilir hatta yapılmalı ama öncelikle sistemli ve efektif çalışılmalı.

Bazı öneriler aşağıdaki gibi olabilir:

 

1.1.           Kota Ayırma

Hata kayıtları için belirli bir kota ayrılması düşünülebilir. Mesela ideal hour’umuzun %20si gibi. Bu çözüm, yeni gelen hata sayısı az olan ekiplerde daha uygulanabilir gözüküyor. Hatta hata kaydı haricinde Sprint içinde acil iş yapmak zorunda kalan ekipler tarafından da bu yöntem genellikle tercih ediliyor. Hata ve acil iş için belli bir saat ayrıldıktan sonra her gün Daily Scrum sonunda bu kotadan kullanılan kısım düşülür ve mümkün olduğunca kota aşılmamaya çalışılır.

Bu yöntemin başlıca dezavantajı kotanın kullanılmasında yaşanır. Günlük kullanılmayan kısmın başka işlerle doldurulması veya ayrılan kotadan çok daha fazlasının kullanılması gibi riskleri var. Eğer dikkatli uygulanmazsa hata çözümlerine yoğunlaşıp Sprint backlogunda bulunan PBI’ların ortada kalma ihtimali de var.

 

1.2.           Kişi Belirleme

Önceki yöntemde ayrılan saat tüm takım tarafından gerektiği ölçüde kullanılıyordu. Şimdi ise bu ayrılan saate denk gelecek kadar, sadece hatalar ile ilgilenecek kişilerin belirlenmesini ele alacağız. Bu çözüm yönteminde hata ile ilgilenecek kişiler sırf hata kayıtlarıyla ilgilenerek PBI ile ilgilenen kişilerin gönül rahatlığı ile işlerine odaklanabilmesini hedefleniyor. Bu yöntem, yeni hata sayısı yüksek olan ekipler tarafından tercih edilebilir.

Daily Scrum’larda backlogdan iş eritenler kendi tasklarındaki ilerleme ve durumdan bahsederken hata kayıtları ile ilgilenen kişiler çözdükleri hataları ve ilgilenecekleri hatalar hakkında konuşur. Ayrıca yeni bir hata kaydı geldiğinde ilk değerlendirmeyi yine bu kişiler yapar ve ilgilenir.

Bu yöntemin en büyük dezavantajı hata ile ilgilenen kişilerin üzerindeki yükün büyük olması ve mevcut işlerin içinde olmadıkları için uzaklaşıyor olmaları. Bazı durumlarda takımın angaryasını çekiyor gibi de algılanabilir. Her sprintte hata ile ilgilenen kişilerin dönüşümlü olarak değiştirilmesi bu durumun önüne bir nebze geçebilir.

 

1.3.           Hybrid Çözüm

Hata kayıtları gelmeye devam ettiği fakat kontrol altında tutulabilen ekiplerde ilk iki çözümün birleşimi bir çözüm kullanılabilir. Mesela yeni gelen hatalar ve acil işler için ilgilenecek kişi veya kişiler belirlenir ama tüm ekip birinci yöntemdeki gibi hata kotasından gerektiği ölçüde işleri aksatmayacak şekilde kullanır. Eğer acil veya öncelikli bir hata ortaya çıkarsa belirlenen kişi ilk müdahaleyi yapar.

Bu yöntem belki ideale yakın olsa da kuralları net belli olmadığından uygulanabilirliği diğerlerine göre daha düşük. Ayrıca acil bir iş geldiğinde ilgili kişinin elindeki iş aksayacağından güzel bir şekilde iş birliği yapılması gerekiyor.

 

1.4.           İdeal Durum

Olgun bir sisteminiz var ve geçiş sonrasında çok az geri dönüş alıyorsunuz. Bu durumda tabi ki hatalar için ek bir çaba sarf etmiyorsunuz. Herkes size imrenerek bakıyor. Ama tek tük gelen hataların, ortada kalmaması ve birikmemesi önemli. Her gelen hata anında incelenmeli ve planlı bir şekilde çözüm sürecine giriyor olmalı. Diğer ekiplerdeki gibi hatalar için pay bırakmamış olduğunuzdan, kaydın acilliğine göre ekstra bir çaba harcayarak anında çözüm veya ayrı bir iş olarak sonraki sprinte bırakmayı seçebilirsiniz.

 

Sonuç

Burada bahsettiklerim denenmiş örneklerdir. Takım kendine göre en uygun yöntemi seçer ve gerektikçe yönteminde değişiklik yapar. Takımlar ve hatalar değişiklik gösterebildiği gibi elbette şartlarda değişiklik gösterecektir. Scrum takımı şartlara göre yöntemlerini ve yaklaşımlarını değiştirerek en uygun ve etkili şekilde adapte olur.

Takımların kendine uygun yöntemi bulmasında yardımcı olması dileği ile yazımı sonlandırıyorum. Farklı yöntemler ve çözüm önerileriniz hakkında yorumlarda bulunursanız çok sevinirim.

Muhammed Osman Uçar