Scrum'da Bir Takımın Kalitesi Nasıl Ölçülür?

Çevik(Agile) yazılımın en iyi uygulamalarından biri olan Scrum'ı tam anlamıyla yönetmek ve işletmek başlı başına bir disiplin sürecinden geçmektedir. Bütün çarklar birbirine bağlı olup tek bir yerdeki aksaklık Scrum sürecini ve kaliteyi düşürür.

Öncelikle şunu söylemeliyim ki her takımın Scrum metodolojisini uygulaması mümkün değildir. Takım kurma sürecinden itibaren başlayan Scrum serüveni hakkında size bazı yaşanmışlıklardan bahsedeceğim. İlk olarak takım kurarken mutlaka ekip Cross Functional olmalıdır. Developer tüm süreçleri analizden teste kadar bilirken, bir testçi analist kadar konuya hakim, bir analist ise detaylı test yapacak kadar kaliteden ödün vermemesi gerekir. Eğer ekip kurarken başlangıçta bu problemler varsa aşağıdaki saydıklarım birçok Scrum Team'in başına gelecektir.

1) İlk olarak PBI Done Date çok önemlidir. Gerçekten Production ortamına çıkacakmış gibi mi Done kriterinden geçiyor yoksa takımın Story Point puanı fazla gözüksün diye mi? Şunu söyleyebilirim; bir Sprint içinde PBI'ların %70'in den fazlası Sprint Review günü Done durumuna anca getirile-biliniyorsa o takım çok kaliteli değildir. Kaliteli yazılımdan ister istemez ödün vermektedir.

2) Yazılımda çok bulgu çıkması ve BUG'ları PBI kapsamı(Acceptance Criteria) ile ilişkilendirme. Bu kaliteli yazılım ve çıkan üründen çok istemediğimiz bir durumdur. Çünkü Done yapacağız diye birçok hata halının altına süpürülüyor demektir. Buda yine kalitesizliği gösterir. Ayrıca Buglar bitmeden hem test hemde Development bitmemiş demektir, bu yüzden kritik hatalara sahip bir PBI her zaman UnDone olarak kalmalıdır.

3) Detaylı olmayan analiz süreçleri tüm akışı olumsuz etkileyebilir. Bir analist bir işi analiz ederken; stratejik iş birimi, kullanıcı veya müşteriden işi alırken işin Bussenies kurallarını ve isteklerini, kullanılacak servis yapısı ve bilgisi, teknoloji ve mimari bilgi, Database akışı ve veri modeli, akışı anlatan Workflow (Visio) hepsi analiz dokümanında olmalıdır. Bu dokuman hem testçiyi hemde Developerları besleyecektir. Dokümantasyon eksiği birçok Scrum takımının ana problemidir.

4) Testlerin son 2-3 güne kalması çok hızlı ve kaliteli ürün çıkaramama durumunu gösterir. Eğer takım çok hızlı ve birim(Unit) testlerini yapmadan UAT ortamlarına atıp test süreçlerini son 1-2 güne bırakıyorsa bu takımdan çok kaliteli ürün beklemeyin. Yanlış Analiz yanlış test senaryo ve süreçlerini doğurur. Takım paydaşlardan iş alırken işin Core kısmında olan Developer mutlaka işin teknik kısmını anlamalı ve Tester, Analist arkadaşlara bunu anlatmalıdır.

5) Developer'ların kendi arasında Code Review yapması gerekir. Eğer Development Team Refactoring (Kod Düzenleme) işlemini geçiştiriyor ve Definition of Done (DoD) kriterlerinde dahi bu madde yoksa o takımdan kaliteli kod yazımı beklemeyin. Kalitesiz kod yazımı mevcut çalışan kodları bozabilir ve Prod-PreProd gibi ortamları kötü etkiyebilir.

6) Bir takım 10 Sprint sonra halen Definition of Done (DoD) kriterleri belirsizse, Sprint Burndown Chart kullanımı ve durumu hakkında bir şey yapılamıyorsa, 5 Sprint öncesinden kalan Kaizen Action halen duvarsa asılıysa o takımda Scrum halen oturmamış demektir.

7) Velocity kriterlerinizi yukarı çıkarın. Kalite bir takımsanız ve Velocity çizginiz doğru kriterler çerçevesinde yukarı doğru ilerliyorsa kaliteyi daha da artırıcı ek maddeler ekleyerek Production ortamına sıfır hatalı ürün verebilirsiniz. Örnekle anlatacak olursam bir testçi tüm sistem testlerini bitirdikten sonra analiz ile Analiz Review(Çapraz Test ve Kontrol) yaparak kaliteyi artırabilir.

8) Sprint ortasında Product Owner tarafından Sprint Goal değiştiriliyor ve bu davranış diğer Sprint'ler için de bir ritüel haline geliyorsa, takımın kendisine güveni ve Commitment etme iradesi maalesef zayıflamıştır. Yine buna paralel Sprint Retrospective toplantılara Product Owner'ın katılmaması da gözle görülür şekilde artabilir.

Kaliteli bir Scrum Team nasıl olmalıdır yazmaya çalıştım. Yaşanmış hataları zamanla bu başlıkta güncel tutmaya çalışacağım. Scrum uygulaması zor ve disiplin isteyen bir metodolojidir. İyi uygulanırsa kaliteli yazılım ve Increment çıkacağından hiç şüpheniz olmasın.

Burak AVCI