Scrum Yazılım Geliştirme Projelerinde Refinement Çeşitleri Nelerdir?

Refinement Nedir?

Bir Product Backlog iyileştirme aktivitesi olan refinement hakkında Scrum Guide’ın tanımı şöyledir:

‘Ürün İş Listesini iyileştirme (refinement), Ürün İş Listesindeki kalemlere ayrıntı, tahmin ve sıra özellikleri ekleme eylemidir. Ürün Sahibi ve Geliştirme Takımının Ürün İş Listesi kalemlerinin ayrıntıları üzerinde çalıştığı devamlı bir süreçtir. Ürün İş Listesi iyileştirme çalışması esnasında kalemler gözden geçirilir ve güncellenir. Scrum Takımı iyileştirmenin ne zaman ve nasıl yapılacağına karar verir. İyileştirme işlemi genellikle Geliştirme Takımının kapasitesinin %10’undan fazlasını almaz. Ancak Ürün İş Listesi kalemleri Ürün Sahibi tarafından veya onun takdiriyle her an güncellenebilir.’ (2017, Scrum Guide).

Scrum Guide 2020 sürümünde ise 2017 sürümünden farklı olarak zaman sınırlaması kaldırılmıştır.

Scrum Guide içerisinde bilinçli bir şekilde daha fazla detaylandırılmamış bu kıymetli etkinliği pratikte nasıl değerlendiriyoruz? Aslında adına refinement dediğimiz fakat içeriği birbirinden farklı olan birçok formatta toplantı yapıyoruz. Bu yazımda ‘Kaç farklı refinement toplantısı yapıyoruz ve bunların içeriğinde neler konuşuyoruz?’ sorularına cevap bulmaya çalışacağım. Özellikle takıma yeni katılan bir takım üyesi için bu toplantının nasıl geçeceği ve neler konuşulacağı oldukça belirsiz olabilir. Hem bu belirsizliği gidermek hem de diğer takımlara ilham olmak adına gelin birlikte refinement toplantılarımızı nasıl değerlendiriyoruz bakalım.

Pratikte Takımlar Kaç Tipte Refinement Yapıyor?

1. İş Birimlerinin Dahil Olduğu

Product Backlog’a en büyük katkıyı sağlayan, yapacağımız işlerin detayını temin eden ve nihayetinde ürünü kullanan kullanıcılarla buluştuğumuz değerli zamanları ifade eder. Fonksiyonel tasarımın başladığı toplantıdır. Bu toplantı öncesinde kapsam ve toplantıya davet edilecek paydaşlar çok net belirlenmeli ve planlama buna göre yapılmalıdır. Bu toplantılar şu konuları görüşmek için idealdir:

• Yeni iş taleplerinin değerinin ve amacının anlaşılması
• Mevcut iş süreçlerindeki problemli noktaların tespit edilmesi
• Plana alınan işlerin detaylarının görüşülmesi, fonksiyonel analiz yapılması
• Kullanıcılardan gelen kritik hataların detaylarının görüşülmesi ve birlikte kök neden analizinin yapılması
• Ekran taslaklarının kullanıcılara sunulması ve geri bildirim alınması
• Kullanıcı eğitimlerinin verilmesi ve ilk deneme kullanımlarında kullanıcılara anında destek sağlanması
• Devreye alınan ancak kullanıma geçilememiş süreç ve sistemler varsa bunların kullanıcılarla birlikte incelenmesi ve kullanımı sağlamak için alınacak aksiyonların belirlenmesi

2. Product Backlog’daki Büyük İşlerin Küçük Parçalara Ayrıldığı

QBR (Quarterly Business Review) kapsamında plana alınan projelerin hayata geçirilmesi için öncelikle PO (Product Owner — Ürün Sahibi)’dan ve gerekliyse iş biriminden proje detaylarını dinledikten sonra işin küçük parçalara ayrılması gereklidir. İşleri yeterince küçük parçalara ayırmadığımız müddetçe hem işin kapsamı doğru olarak çıkarılamamakta hem iş planları doğru oluşturulamamakta hem de zaman tahminleri doğru yapılamamaktadır. Bir işin başarıya ulaşabilmesi için işlerin olabilecek en küçük parçalara kırılması oldukça kritiktir. Bu toplantılarda işlerin tüm detayları konuşulmaz, ana hatlarıyla çerçeve oluşturulur ve işin alt parçalara bölünmesi sağlanır. Bu etkinlik, çevik yaklaşımda oldukça kritik olan MVP (Minimum Viable Product) üretmek için ürünün en değerli, çalışan ve küçük parçasını bulmayı sağlayan çok kıymetli bir aktivitedir. Ürünün tamamını geliştirmek 10 birimlik efor gerektirecekse MVP’yi doğru belirleyerek belki sadece 2 birim efor harcayıp hedeflenen kazanımın yarısından çoğunu elde etmemiz mümkün olabilir. Diğer taraftan ürünün piyasada kendine bir yer bulup bulamayacağından emin değilsek ‘fail fast’ yaklaşımıyla hızlıca ürünü test etme fırsatı da sunar. MVP’yi en doğru şekilde ortaya çıkarabileceğimiz bu aktivite doğru değerlendirildiğinde büyük kazanımlar sağlamaktadır.

3. Product Backlog’daki İşlerin Detaylandırıldığı

Bir önceki adımda alt parçalara kırılmış olan işlerin teker teker detaylandırıldığı toplantıdır. Fonksiyonel tasarımın en yoğun şekilde gerçekleştirildiği toplantıdır. Bu toplantılardan birine maksimum 1 ya da 2 PBI (Product Backlog Item) detaylandırma çalışması sığar. İlgili işin amacı, fonksiyonel ve fonksiyonel olmayan ihtiyaçlar, iş akışları, roller, story point tahminleme vb. birçok detay üzerine görüşme sağlanır. Bu detayların tamamını tek bir toplantıda tamamlamak mümkün olmayabilir. Takım olarak fikir birliğine varmak amaçlanır, üzerine bir kere daha düşünme ve değerlendirme ihtiyacı konular varsa muhakkak ek seanslar düzenlenir. Bu tipteki toplantıların nihai çıktısı DoR (Definition of Ready)’e uygun PBI’lar hazırlamaktır. Bu adımdan sonra hazır hale gelmiş PBI’lar rahatlıkla Sprint Planlama etkinliğinde Sprint’e alınabilir.

4. Ekran Tasarımı Yapılan

Bir önceki adımda tariflenen işlerin detaylandırıldığı refinement toplantılarının bir alt türüdür. İş ihtiyaçları ve akışları belirlendikten sonra yeni bir ekran geliştirme ihtiyacı doğduysa ya da mevcut bir ekran üzerinde değişiklik yapılacaksa Geliştirme Takımı’nın beyin fırtınası yaparak birlikte ekran tasarımlarını oluşturduğu toplantıdır. Tasarımlar bu toplantı neticesinde final hale geldiğinde farklı bir refinement toplantısında (1.adımda tariflenenen türde bir refinement) ekran taslakları kullanıcılara sunulur ve geri bildirimler toplanır. Revizyonlar kullanıcılarla birlikte ya da yeni bir seansta Geliştirme Takımı tarafından yapılabilir.

5. Teknik Tasarım Yapılan

İşlerin detaylandırıldığı refinement toplantılarının bir alt türüdür. İş ihtiyaçları ve akışları belirlendikten sonra Geliştirme Takımı teknik tasarım yapar. Yine bu toplantıda da beyin fırtınası yaparak tüm takım üyelerinin katkı sağlaması beklenir. Yazılım geliştirmenin ilk ve en önemli adımı olan bu aşamada mimari oluşturulur. Yazılımın nasıl işleyeceği bu adımda ortaya konur. Takımdaki her geliştiricinin birbirinden bağımsız tasarım yapması yerine ortak bir platformda birlikte tasarım yapılması kurumsal mimari standartlarına da uygunluk sağlar.

6. Başka Bir Geliştirme Takımıyla Birlikte Yapılan

Birden fazla Geliştirme Takımı’nın katkısını gerektiren bağımlılık içeren işler çoğu zaman risk barındırır. Entegrasyon işleri bağımlılığın yüksek olduğu işlere en güzel örnektir. Bağımlılık yönetimi konusu projelerin başarıya ulaşmasının önündeki engellerin başında gelir. Bağımlılık demek yüksek iletişim demektir. Takımlar kimi zaman ortak zaman bulmakta zorlanır kimi zaman da bağımlılıkların yüksek iletişim gerektirdiğini görmezden gelir. Nihayetinde varsayımlarla ilerlemek kolaydır. Ancak bu kolay yolun sonu zamanında ve başarıyla bitmeyen projelere çıkmaktadır. Bir Geliştirme Takımı’nın düzenli scrum ritüelleri olduğundan iletişim eksikliği gibi bir problem genelde yaşamazlar. Ancak işin için birden fazla Geliştirme Takımı dahil olduğunda takımlar arası düzenli scrum ritüelleri yoktur. İletişimi sürdürmenin en güzel yolu birden fazla Geliştirme Takımı’nın bir araya geldiği refinement toplantılarıdır. Bu toplantılar şu konuları görüşmek için idealdir:

• Ortak çalışılacak proje üzerinde üzerinde fonksiyonel ve teknik analiz yapılması
• Takımların birbirlerinden beklentilerinin netleştirilmesi
• Ortak bir zaman planı oluşturulması ve bu plana uyumun takibi

Öneriler

Elbette burada listelediğim refinement çeşitlerine her gün bir yenisi eklenebilir. Mühim olan aktivitenin en verimli şekilde geçirilmesidir. Etkinliğin ana amacı olan ‘PBI iyileştirme’ hedefini unutmadan çeşitli varyasyonlarda refinement toplantıları düzenlenebilir. Son olarak bu etkinliğin verimliliğini ciddi anlamda etkileyecek birkaç noktaya dikkat etmek gerekir. İçeriği bu kadar farklı şekilde oluşturulabilen bu toplantılar öncesi toplantının formatı, amacı, katılımcıları mutlaka belirlenmeli ve katılımcılarla ajanda paylaşılmalıdır. Davetlilerin ne konuşulacağını bilmedikleri bir toplantıya gelmeleri ön hazırlık yapmadan katılmalarına neden olacaktır. Toplantı esnasında ve sonrasında toplantı notlarının ve kararlarının dokümante edilip katılımcılarla paylaşılması ise bir o kadar kritiktir.