Sprint Planlama Toplantısı Nasıl Yapılır? NASIL Bölümü…
Sprint Planlama Toplantısı’nın ikinci bölümü olan NASIL kısmında Geliştirme Takımı işin nasıl yapılacağına dair analiz ve tasarım yaptı mı?
Çevik Koçluk yaptığım Scrum Takımlar’ında üyelerin en çok sıkıntı yaşadığı yer Sprint Planlama Toplantısı’nın NASIL bölümüdür. Bu bölümünde gerçekleştirilmesi gereken analiz ve tasarım aktiviteleridir. NASIL bölümde yapılan analiz ve tasarım aktivitesi Geliştirme Takımı üyeleri tarafından gereksiz olarak görülmektedir. Bunun nedeni ise Geliştirme Takımı üyelerinin bunu daha önce denememiş olmalarıdır. Böyle takımlarla karşılaştığımda ilk önerim bebek adımlarıyla ilerlemeliridir. Bebek adımlarından anlaşılması gereken ise Sprint’e aldıkları İş Listesi Maddeleri’nin sadece yarısı ya da üçte biri için bu aktiviteyi gerçekleştirmeye çalışmalarıdır.
Toplantının bu bölümü yeni başlayan Scrum Takımları için gerçekten sıkıcı olabilir. 7 Geliştirme Takımı üyesinin 1 Scrum Master ve 1 Ürün Sahibi’nin bulunduğu toplantıda 9 kişinin basit bir İş Listesi Maddesinin nasıl gerçekleştirileceğine dair konuşması sıkıcı ve zaman kaybı olarak görülebilir. Halbuki burada erişilmek istenen nokta konuşulan maddeler hakkında bilgi paylaşımı, yapılan planlamanın herkes tarafından bilinmesi ve mümkün olduğunca kusursuza yakın bir planlama yapmaktır. İnsanlara bunu göstermenin en iyi yoluysa fazla sıkılmalarını engelleyerek birkaç tane maddenin analiz ve tasarımını yapıp Sprint içinde bu işlerin nasıl ilerlediğini görmelerini sağlamaktır. Seçilen maddelerle ile ilgili gözlemlerin bir sonraki Sprint Retrospektif Toplantsı’nda konuşulması, analiz ve tasarımı yapılan maddeler ile yapılmayan maddelerin geliştirilmesi arasındaki farkların ortaya çıkarılması insanların daha kolay ikna olmasını sağlayacaktır.
Gelecek Sprint’lerde Scrum Takımı üyeleri göreceklerdir ki bu işler çok daha çabuk ve kolay geliştirilecektir. Bebek adımları için ilk önerim bir NASIL dokümanı oluşturulmasıdır. Sprint’e alınan maddelerin üçte birinin analizi ve tasarımı bu dokümanda açık bir şekilde belirtilmelidir. Sprint içinde bu maddeler ile ilgilenecek geliştirici NASIL dokümanını açıp nasıl geliştirme yapacağı bilgisine ulaşabilmelidir. Böylece hızlıca geliştirme işine başlayacaktır. Ayrıca bu doküman hazırlanırken ilgili madde ile ilişkili olan riskler ve karmaşıklık ortaya çıkacak ve Sprint riske atılmamış olacaktır. Sprint Planlama Toplantısı’nın NASIL bölümü Sprint’in kalbidir.
NASIL bölümünde Geliştirme Takımı, kalem, kağıt, beyaz tahta gibi materyaller kullandı mı?
Geliştirme Takımı’nın toplantının NASIL bölümünde Sprint içinde gerçekleştireceği işi görselleştirmesi çok iyi bir pratiktir. Görselleştirme sayesinde yapılan işi herkes çok daha kolay şekilde ve aynı seviyede anlayabilir. Özellikle Geliştirme Takımı içinde farklı yetkinliklere – geliştirici, analist, testçi- sahip kişiler varsa herkesin yapacağı işin diğer kişiler tarafındanda anlaşılması ve bir dar boğaz anında başkalarının işi üstlenmesi açısından çok faydalıdır.
Sprint içinde gerçekleştirilecek olan maddeler daha küçük işlere(task’lara) ayrılabilir ve test yapmakta bu işlerden biri olabilir. Eğer bir testçi işe gelmediyse ya da üzerindeki iş bitmeyecek ve ona devam etmesi gerekiyorsa geliştirme veya analiz yetkinliği fazla olan biri test işlerinden birini çekebilir. Çektiğindeyse test yetkinliği fazla olan kişinin ne yapacağını bilmesi işi daha kolay yapmasını sağlayacaktır. Bunu gerçekleştirebilmenin yolu ise işin görselleştirilmesinden geçer.
Sprint’e alınan işlerin bitirilmesinden bir Geliştirme Takımı üyesi değil Geliştirme Takımı’nın tamamı sorumludur.
NE bölümünde söz verilen İş Listesi Maddeleri, toplantının NASIL bölümünde adım adım maddenin geliştirileceği işlere(task’lara) bölümündü mü? Bitti Tanımı’nda var olan ve yapılan işin kalitesinin belirlendiği adımların dışına çıkılabildi mi? İşler 8-10 saat olacak şekilde küçük parçalara ayrıldı mı?
Bu konular yine sıkça karşılaştığım ve sürekli itirazların geldiği konulardır. İş Listesi Maddeleri daha küçük işlere bölünmeye başlandığında genellikle Bitti Tanımı’nda bulunan adımlar baz alınır ve o şekilde parçalara ayrılır. Örnek:
Bitti Tanımı
- Dokümente Etme
- Kodu Geliştirme
- Kodu Gözden Geçirme
- Birim Testi Yapma
- Fonksiyonel Testi Yapma
- Kullanıcı Kabul Testi Yapma
- Üretim Öncesi Ortamda Testi Yapma
- Teslim
Örnek Bitti Tanımı yukarıdaki gibi olsun. Bir İş Listesi Maddesini küçük parçalara ayırırken yukarıda bulunan Bitti Tanımı adımlarına göre ayırmak bir pratiktir. Daha iyi bir pratik ise bu adımların dışına çıkarak işleri en büyüğü 8-10 saat sürecek şekilde küçük parçalara ayırmaktır. Geliştirme yaptığınız maddenin geliştirme işi gerçekten 40 saat sürebilir. Bu geliştirme işini en kötü şekilde Procedure1, Procedure2 olarak bölmeniz bile hiç bölmemenizden daha iyidir. Böylece yapılan işin takibini daha kolay yapabilirsiniz. Procedure1 bitti, sıradaki task Procedure2’yi oluşturmak olabilir ya da Procedure1 bitmedi ve hangi nedenlerden bitmediğini gördüğünüzde buradan elde ettiğiniz bilgiyi riski azaltmak ve aynı sorunlarla Procedure2, Procedure3’te karşılaşmamak için önlem alabilirsiniz. Böylece hem Bitti Tanımı’nda bulunan adımların dışına çıkmış olursunuz hem işi takip edilebilir küçük parçalara bölmüş olursunuz.
Benim gözümde işin takip edilmesi hassas bir konudur. İşi takip etmesi gereken kişi Yönetici, Müdür, Ürün Sahibi ya da Scrum Master değildir ve bu roldeki kişiler iş takibi yapmamalıdır. İşin takibini Geliştirme Takımı yapmalıdır. Geliştirme Takımı bu takibi yapmadığındaysa bahsettiğim roldeki kişiler iş takibi yapmaya başlayacaktır. Konu dışında ama önemli olduğunu düşünüyorum.
Toplantının bu bölümünü İş Listesi Maddelerini Bitti Tanımı’ndaki maddelere bölmek ve bu maddelere saat vererek aktiviteyi bu şekilde tamamlamak çok büyük yanlıştır! Bunu yapmayın! Nasıl doğru yapabiliriz konusunda bilginizi derinleştirin…
Sprint Planlama Toplantısı’nın NASIL bölümünde İş Listesi Maddeleri’nin detayına girildikçe ve İş Listesi Maddeleri hakkında daha fazla bilgi sahibi oldukça maddelere yeniden Hikaye Puanı verildi mi?
Sprint Planlama Toplantısı’nın NASIL bölümünde işlerin detayına girilir. Bu bölümde Geliştirme Takımı üyeleri işleri daha iyi görebilir. NE bölümünde gözden kaçırılan ya da düşünülmeyen şeyler işin detayına girildiğinde görülebilir. Bu gibi durumlarda işin karmaşıklığı ve zorluğu daha iyi anlaşılabileceği için verilen hikaye puanlarında değişiklik yapılması gerekebilir. Bu gibi durumlarda yeniden Geliştirme Takımı üyelerinin hikaye puanı vermesi gerekir. Geliştirme Takımı üyeleri yeniden değerlendirme ihtiyacı duyuyorsa bu değerlendirme yapılmalı ve Ürün Sahibi toplantıda değilse bu durumdan haberdar edilmelidir. Gerekli durumlarda toplantının NE bölümünde Sprint’e alınacağı belirtilen işlerden bazıları toplantının NASIL bölümünde Ürün Sahibi ile görüşülerek anında Sprint İş Listesi’nden çıkartılabilir. Bu sıkça yaşanan bir durum değildir. Yaşandığındaysa Sprint’i tehlikeye atmayacak şekilde bir yaklaşım sergilenmelidir.
Toplamda üç makaleden oluşan serinin sonuna geldik. İlk iki makalede Sprint Planlama Toplantısı’nın genelinde ve Sprint Planlama Toplantısı’nın NE bölümünde nelere dikkat edilmesi gerektiğini anlattım. Bu bölümdeyse Sprint’in kalbi olan Sprint Planlaması’nın nasıl en verimli olabileceğine dair konuştuk. Unutmayın, aklınıza takılan her konuda bana yazabilirsiniz.