Scrum Master’ın notları - 1

Ali Göktaş
Sahibinden Technology
3 min readFeb 10, 2021
iStock.com/oatawa

Yazılım geliştirme yaşam döngümüzü sarıp sarmalayarak ekip içerisinde organize olup farklı iş bölümleriyle daha entegreli ve sistemli çalışmamıza olanak sağlayan, ideal dünyamızın önemli bir çatısı olan “Scrum”ı uygularken karşılaşabileceğimiz problemler ve çözüm önerilerine değineceğiz.

Scrum takımı olabilmek

Scrum çatısına uygun çalışabilmek birçok açıdan sancılı olabilir. Ekibin scrum ile çalışmaya başlamadan önceki dinamikleri, iş bölümlemesi ve hatta toplantı organizasyonlarına kadar radikal değişiklikler görülmesi beklenir. Bu noktada çevik olmanın ilk aşaması kontrollü ve hızlı bir dönüşümle başlar.

Değişim her zaman kolay ve hızlı olmayabilir, buradaki çeviklik faktörü takımın her bir üyesinin bu çatıyı uygulamaya ne kadar hazır ve kararlı olduğu ile doğru orantılıdır.

Scrum çatısı altındaki toplantıların amaçlarını anlayarak uygulamak, bu toplantıların saatler süren verimsiz veya katılımcıların aktif olmadığı toplantılar haline gelmemesi gerektiğinin en önemli karşılığıdır.

Ortak hedefi benimsemek

Sprint süreleri boyunca yapılan işlerin durumlarını, daily scrum toplantılarında her bir takım üyesinin işlerini, tüm ekibin işi gibi benimseyerek dinlemesi ve olası bloklanma durumlarında hızlıca ve tüm takım beyniyle aksiyon alınması hedeflere ulaşma noktasında bir opsiyon değil gerekliliktir.

Daily scrum toplantılarının süresini ve amacını aşmadan optimize etmek her daim mümkündür. Peki ya nasıl?

Kişi başı 3 ana başlık altında anlatımlarımızı yaparız:

Bir önceki iş gününde neler yaptım?

Bugün neler yapacağım?

Beni bloklayan veya bloklayacağını düşündüğüm bir durum var mıdır?

Bu soruların zaman içerisinde bloklayan’ı konuştuğumuz soruyu unutup sadece “Ne yaptım?” ve “Ne yapacağım?” sorularına odaklanmak ve buna alışılması ile birlikte patrona hesap vermek için her sabah uyanan çalışan psikolojisine girmemize neden olabilmektedir.

Bu algıya kapılmamamız için en basit ve doğru yöntemin, hep birlikte bir masayı taşıyoruz ve birimiz eksilirse, birimizin ayağının önündeki taşı göremezsek bu durumda ekibin üzerindeki yükün ağırlığı artacak ve ekibin hızını yavaşlatacaktır. Dolayısıyla sprint başlarında söz verilen hedefe ulaşma noktasında başarısız olacak ve bunun devamlı yaşanması ekip repütasyonunun azalması, yıllık veya çeyrek hedeflerini gerçekleştirememe ve sonraki sprintlerde geriden gelme gibi durumlara neden olacaktır.

Planlama aşamaları

İşlerimizi planlarken toplantılara ayrılan zamanlar ve verim daima göz önünde bulundurulmalıdır. Grooming toplantıları her ne kadar opsiyonel olsa da sprinti planning toplantılarından önce düzenlemek, planninge daha hazır ve işler hakkında fikir sahibi olarak girmemize olanak sağlar. Product Owner’ın bilgilendirmesi ile işlerin kapsamı tüm ekip tarafından anlaşılmalıdır. İşlere story point verme aşamasında teknik ekipte kimsenin kafasında soru işareti kalmamalıdır. Aksi taktirde sprint devam ederken o soru işaretleri olası yanlış gidişatlara kapı aralayabilir.

Sprint planning’in süreleri ideal dünyada tavsiye edilen süresi şöyledir:

4 haftalık sprintte 8 saat

2 haftalı sprintte 4 saat

Product Owner, backlog’daki işlerin içeriklerini takıma aktardıktan sonra eğer gerekli ise işleri bölümlemek ve küçük parçalar halinde sprinte dahil etmekte fayda var. Örneğin: 8 Story point efor gerektiren bir işi, olduğu gibi sprinte almak yerine 5 ve 3 olarak 2 işe bölmek tavsiye edilen bir yöntemdir. Ancak bu, 8 story point işleri sprinte almayın demek değildir. Ekibin velocitysi ve sprint sürelerine göre bu durum değişiklik gösterebilir.

Bunun bizlere ne gibi bir faydası olur?

Velocity puanı 35 olan bir ekip, sıradaki sprintine 36 toplam story point ile başladıysa, sprintin 8 story point olan bu işin tamamlanmamasından kaynaklı başarısız olduğunu düşünelim. Developer bu işin %80'lik bir kısmını tamamlamış ancak sprint süresini yetiştirememiş varsayalım. Böylelikle developer yaklaşık 6–7 story pointlik iş yapmış ancak işi fail etmiş olacaktır.

Bu durumda bu işi 8 story point tek parçada almak yerine örneğin üç parçaya bölerek 1–2–5 olarak puanlandırılsaydı, 2 işi tamamlamış 1'inde başarısız olacaktı.

Dolayısıyla buradaki best practice, yüksek puanı hedeflemek değil hedefleneni tamamlayabilmektir.

Sonraki bölümde görüşmek üzere…

Yapmadığın atışların %100’ünü kaçırırsın.

Wayne Gretzky

--

--