Scrum Master’ın Notları -2

Product Backlog’u Yönetebilmek

Product Owner, Product Backlog’a hakimiyet ve planlama konusunda daima ekibin önünde olmalıdır. Planlama aşamalarında takımın alacağı işlerde birbirine bağımlı olan işlerin planlanması, önceliklerinin belirlenmesi, takımın sahip olduğu velocity puanını göz önünde bulundurmak gibi konulara hakim olması Product Backlog’un sağlıklı ve dengeli erimesini sağlar.

Product Backlog’dan sprint içerisine dahil olan bir iş, developer tarafından geliştirilmeye hazır hale gelmeden önce gereksinimlerinin çalışılmış ve net ifadelerle açıklanıp dokümante edilmiş olması gerekir.

Product Backlog’u parçalı bir pasta gibi görüp sprintleri de öğün olarak düşündüğümüzde, tüm paydaşların bir öğünde sindirebilecekleri pasta miktarı ve büyüklükleri belirli olup gerekli sıralamaya göre Product Owner tarafından tabaklara koyulmalıdır.

O tabakların neden bitip bitmediği daha sonra review ve retrospective toplantılarında konuşulabilir.

Teknik İletişimin Önemi

Bu alt başlıkta iletişimin teknik boyutunu ele alacağız. Business, Development, Test gibi iş bölümlerinin scrum çatısı altında birbiri ile olan ilişkilerinin gerekliliklerinden daha önce bahsetmiştik. Bu noktada development takımının birbiri ile olan teknik iletişim kısmı karşımıza çıkıyor.

Pair programming kavramının scrum çatısı ile bağdaştığı noktada en çok dikkat çeken kısım ise daily scrumlardaki aktarımların tüm teknik takıma anlamlı gelmesi. İki developerın sprint işlerinde gerektiği noktalarda pair gidebilmeleri bununla epey mümkün oluyor.

İşlerin gereksinimlerinin development esnasında değişme ihtimallerinin daha erken fark edilmesi ve teknik açıdan beyin fırtınası yapılıp tüm takıma taşınarak nihayete erdirilmesi açısından iyi bir avantaj olabilmektedir. Akabinde sprinte alınan işleri pasta dilimlerine benzettiğimizi hatırlarsak her bir dilimi yeme deneyiminin paylaşıldığı bir dünyada, tüm pastanın lezzetine paydaşların ortak olacağını varsayabiliriz.

Elbette ki pair çalışılarak kodlanan işlerin takım velocitysini pozitif yönde etkilemesi de göz ardı edilemeyecek seviyede önemli olacaktır.

Böylelikle birbirinden çokça haberdar ilerleyen teknik ekip, çevik yazılım geliştirme felsefesini o kadar iyi sindirmiştir diyebiliriz.

Scrum Scrum İçindir

Yazılım sektöründe birçok firma scrum çatısını uygulamak için girişimleri yıllar önce yapmaya başladı. Bu konuda kendini yetiştirmiş profesyonellerden kendi takımlarına danışmanlık alıp bünyelerine scrum çatısını en kısa ve pratik şekilde yedirmeyi hedeflediler. Kimi firmalar scrum popüleritesine kapılıp her yerde doğru yöntem olup olamayacağı sorularını kendilerine sormadan giriştiler.

Bu konuya, gündeme uyum sağlamaktan ziyade ekiplerin ihtiyaçlarını analiz edip scrum çatısını tam anlayarak, uygunluğunu tartışmak en doğru yaklaşım oldu.

Yanlış algı : Bu palto bu sene çok moda o halde bana çok yakışır.

Doğru algı : Bu palto bu sene çok moda, peki ya benim tarzıma uygun mu ?

“A şirketi uyguluyor bizim de uygulamamız lazım” düşüncesiyle başlayan tüm atılımlarda kısa vadede gelecek olan “biz neyi yanlış yaptık?” sorusu takip edecektir.

Yöneticilerin daha çok kazanç ve maddi verimlilik elde etme amacına hizmet etmesi için takıma scrum çatısını kazandırmaya çalışması sonucunda şirketin üst yönetimindeki çalışan ile stajyerin scrum anlayışı farklı olacaktır.

Bir product, scrum çatısı altında geliştirilmeye hedeflendi ise o product ile temasa sahip tüm paydaşların aynı felsefeyi benimsemiş olması gerekmektedir. Yazılım takımlarından scrum çatısının pozitif çıktılarını beklerken, sprintte planlanmamış ve sprint ortalarında analiz ve planlaması yapılmamış “Acil” temalı işlerin türetilmesi bunun doğru anlaşılmadığının bir örneği olabilir.

Bu noktada scrum bir ekibin rehberi olacak ise sadece kod veya business üreten kişilerin değil tüm product temaslılarının olmalıdır.

Daima ürün için en doğruyu arayıp bulup onu da en doğru biçimde yapmayı hedeflemeliyiz ki kullanıcılara da konforlu bir deneyim sunabilelim. Bunun yöntemi scrum çatısı olsa da olmasa da…

Mutluluk başarıya, başarı ise zamanı değerlendirmeye bağlıdır.

Lucius Annaeus Seneca