Sprint Sonunda Retrospective Nasıl Yapılabilir?

Agile yazılım geliştirme yaklaşımının öne çıkan özelliklerinden ikisi, değişime cevap verebilme ve değişen şartlara adaptasyondur. Bunu sağlayabilmek için yapılması gerekenlerden birisi de sürekli olarak nerede olunduğunun, nereye gidilmeye çalışıldığının değerlendirilmesi ve alınması gereken aksiyonların alınmasıdır.

Agile manifesto'da bununla ilgili olan prensip; "Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler."

"Her zaman iyileştirilebilecek bir şeyler vardır.", "Hiç bir şey mükemmel değildir ama her şey mükemmelleştirilebilir.", "Agile bir hedef değil yolculuktur." gibi yaklaşımlar bu değerlendirme/iyileştirme toplantılarının sürekli olarak yapılmasını gerekli kılar.

Bu prensip farklı isimlerle anılabilir; Inspect&Adapt, Continuous Improvement, Kaizen, Retrospective gibi. Scrum kapsamında bu prensip retrospective toplantısı adı altında bir pratiğe dönüştürülmüş. Retrospective toplantıları her sprint'in sonunda ekibin yaptığı, scrum master, product owner, takım gibi roller dışında yönetici gibi diğer rollerin de katılabileceği bir toplantıdır. 2haftalık sprintler icin 1-1.5saat civarı olması tavsiye ediliyor.

Retrospective toplantılarının yapılmamasının nedenleri genelde şunlar oluyor;

• İnsanlar iş yapış şekilleri, projeler, süreçler vs. üzerine yeterince kafa yormadığı için iyileştirecek bir şey ortaya koyamıyorlar, diğer bir deyişle umursamıyorlar.
• Retrospective toplantılarında çıkan aksiyonlar takip edilmiyor, yani iyileştirilmesi gereken yerler iyileştirilmiyor, dolayısı ile her toplantıda aynı sorunlar tekrar tekrar konuşuluyor, bu durum bir süre sonra toplantının gereksiz olduğu düşüncesi ile sonuçlanıyor.
• Toplantıda konuşulan konular bireyselleştiriliyor ve çatışmalar çıkıyor. Bir ekip bilinci/ruhu yok ise bu çatışmalar çok kolay tetiklenebiliyor, özellikle test/development çatışmaları.

Yukarıdaki gibi sorunlar yüzünden retrospective toplantıları yapamıyorsanız ama yapmanız gerektiğini, bir şeyleri iyileştirmeniz gerektiğini düşünüyorsanız, ki her zaman iyileştirecek bir şeyler vardır, bu sorunları çözmek birinci derecede scrum master rolünü üstlenen kişiye kalıyor.

Retrospective toplantılarını ferah, insanların rahat edebileceği, beyaz tahtası olan bir toplantı odasında yapmak sağlıklı sonuçlar almanıza yardımcı olacaktır.

Retrospective toplantılarında insanları konuşturabilmek onlardan geri bildirim alabilmek için kullanılan farklı yöntemler var. Biz şu pratikleri kullanıyoruz;

• Sprint puanı
• Mutluluk Indexi
• Yapmaya Başlayalım/Yapmayalım/Yapmaya Devam Edelim Çalışması
• Nokta Puanlama
• Tartışma

Retrospective toplantısına liderlik eden bir kişi oluyor, bizde genellikle bu kişi scrum master oluyor ama bu zorunlu değil, hatta ekib dışından birisinin retrospective toplantısına liderlik etmesi de tavsiye edilen bir pratik.

Toplantının başında toplantının nasıl ilerleyeceği her bölüme ne kadar süre ayrıldığı ile ilgili ekibe bilgilendirme yapılıyor ve sonrasında pratiklere geçiliyor.

İlk iki pratik için ekibe küçük(5x5cm) kağıtlar dağıtıyorum. Bu kağıdın bir tarafı ilk pratik için diğer tarafı da ikinci pratik için kullanılacak.

Sprint puanı ilgili sprint hakkında ekibin genel hissiyatını öğrenmek için kullanılan bir pratik. Bu pratik geçen sprint ile ilgili ne hissediyorsun sorusuna kişinin aklına gelen ilk cevabı aslında, bu cevabı farklı formatlarda alabiliyorsunuz biz puan formatında alıyoruz. Herkes aldığı kağıdın bir yüzüne sprint'e 10 üzerinden kaç puan verdiğini genel hissiyatına göre yazıyor, sonra herkesin verdiği puanlar toplanıp ortalama puan bilgisi bulunup ekip ile paylaşılıyor. Bu puan size üst seviyede, geçirdiğiniz sprint'i diğer sprintleriniz ile de karşılaştırma imkanı veriyor.

Mutluluk Indexi, ilk başta biraz garip geliyor isim olarak, bireysel bir geri bildirim alıyorsunuz ekip arkadaşlarınızdan. Bu pratik her ekip üyesinin özel olarak 3 farklı soruya verdiği cevaptan oluşuyor;

• Genel olarak burada çalışmaktan ne kadar mutlusun? (5 üzerinden puan)
• İleriye dönük olarak mutlu olacağına/kalacağına inanıyor musun? (5 üzerinden puan)
• Seni mutlu edeceğine inandığın 3-5 kelime yazar mısın?

 Herkes verilen kağıdın bir yüzünü 3'e bölerek bu 3 soruya cevabını bölmelere yazıyor. Bu pratik için kimin ne yazdığının scrum master tarafından bilinmesi gerekiyor, dolayısı ile bu kağıtlara ekip üyeleri isimlerini de yazıyor.

Scrum master, veya ekip lideri, bu kağıtları toplayıp daha sonra, mümkünse diğer sprint'in retrospective toplantısına kadar, her bir ekip arkadaşıyla kağıda yazdığı bağlamda konuşuyor. Çözülmesi gereken problemleri çözüyor veya çözülmesi için girişimlerde bulunuyor. 

Bu pratik size her bir ekip arkadaşınızın ne kadar mutlu olduğu, ne kadar umutlu olduğu, neleri istediği veya istemediği ile ilgili bilgi veriyor. Ekip arkadaşlarınızın hangi seviyede olduğu hakkında bilginiz oluyor, mesela birisinin iş yerinde maaş/kariyer gibi problemleri var ise o kişiden kendini geliştirmesini, ekip ile teknik anlamda bir şeyler paylaşmasını beklemek çok gerçekçi olmayabiliyor. Normalde çok iyi iş çıkaran bir ekip arkadaşınızın performansındaki düşüşün nedenini anlayabiliyorsunuz. Bu tür konuları bu şekilde formal bir girdi alarak yapmak bu işin tek yolu değil elbet, ekip arkadaşları ile düzenli olarak konuşan bir lider bu şekilde bir girdi almadan bu süreci iyi bir şekilde yönetebilir. Yazılı iletişim ile bir ön çalışma sonra onun üzerine sözlü iletişim ile yazılanları açma olan bu yöntem bana daha kolay ve etkin geliyor.

Yapmaya Başlayalım/Yapmayalım/Yapmaya Devam Edelim çalışması için renkli post-it'ler kullanıyoruz. Her kategorinin bir rengi oluyor, bunları tahtaya kategori isimlerinin altına yapıştırıyorum. Daha sonra 5dakika boyunca her ekip üyesi bu kategoriler ile ilgili olarak geçen sprint için düşüncelerini post-it'lere yazıyor. Kategorilerin anlamları şu şekilde;

• Yapmaya Başlayalım; Yapmıyoruz ancak yaparsak şu şekilde faydalar olacağını düşünüyorum, bir sonraki sprint'de bunun yapılmasını istiyorum.
• Yapmayalım; Bunu yapıyoruz ancak bu bize şu şekilde zarar veriyor o yüzden artık bunu önümüzdeki sprint'den itibaren yapmayalım istiyorum.
• Yapmaya Devam Edelim; Bunu yapıyoruz, şu şekilde faydalarını görüyoruz, o yüzden bunu yapmaya devam edelim. Sprint kapsamında bir çok şey yapıyor ve hepsinin devam etmesini istiyor olabilirsiniz, buraya yapmaya yeni başladığınız veya kritik gördüğünüz şeyleri yazabilirsiniz.

5 dakikanın sonunda, ekip üyeleri sıra ile tahtaya çıkıp post-it'ler üzerine yazdığı notları tahtada ilgili kategoriye yapıştırıyor ve yazdığı şeyi okuyor, belki 2-3 cümle ile de bir açıklama yapıyor, ama tartışılmıyor. Her ekip üyesi bunu yaptıktan sonra biz, eğer tahtada çok fazla konuşulması/tartışılması/aksiyon alınması gereken post-it var ise nokta puanlama yöntemi ile öncelikleri belirlemek için oylama yapıyoruz. Eğer post-it sayısı az ise hepsini konuşabileceksek bu oylamayı yapmıyoruz.

Nokta puanlamada her ekip üyesinin her kategoride 3 nokta'dan ibaret olan bir puanlama hakkı oluyor. Toplamda 3 kategori var, yani her ekip üyesinin elinde 9 adet noktası oluyor. Ekip üyeleri tahtaya çıkıp her kategoride kendine göre öncelikli olan post-it'lere puan veriyor, isterse tüm puanını(3nokta) tek bir post-it'e de verebilir veya dağıtadabilir. Burada amaç öncelikli olan, en çok puan alan, konuları belirleyip onlara öncelikli olarak odaklanmak.

Son olarak tahtadaki post-it'ler, toplantıya liderlik eden kişi öncülüğünde ekip ile tartışılıyor ve yeterince net değilse, farklı görüşler varsa bunlar ortaya çıkarılmaya çalışılıyor. Burada herkesin eşit süre alarak fikir beyan etmesine imkan verilmesi, faydasız çatışmaların önüne geçilmesi, konuların bireyselleştirilmesine izin verilmemesi gibi konulara dikkat etmek gerekiyor. Burada eğer alınması gereken aksiyonlar çıkar ise onları da not etmek gerekiyor.

Elbette bir ekipde bireysel sorunlar da olabilir, ekibi rahatsız eden, ekip motivasyonunu düşüren çalışanlar olabilir. Bu tip sorunların retrospective toplantılarında konuşulması çok doğru bir yaklaşım değil, çatışma çıkma veya bireysel olarak bir ekip üyesinin rencide edilme ihtimali çok yüksek olduğu için. Scrum master veya ekip liderinin bu tip sorunların farkında olması ve bu tip ekip üyeleri ile bire bir konuşması, bir birleri arasında sorun yaşayan insanların bire bir konuşmasını sağlaması gerekiyor. Bireysel sorunları ve sonuclarını net olarak ortaya koyması, çözüm üretmesi veya çözüm beklemesi gerekiyor.

Bu son pratik ile birlikte retrospective toplantısı sonlandırılıyor.

Toplantı sonrasında biz retrospective toplantısının çıktılarını(sprint puan, mutluluk indexi, Yapmaya Başlayalım/Yapmayalım/Yapmaya Devam Edelim notları, aksiyonlar) yazılı olarak online bir ortamda(JIRA) tutuyoruz. Takip edilmesi gereken aksiyonları bir kanban board üzerinden online herkesin görebileceği şekilde takip ediyoruz.

Retrospective toplantısı sonucunda çıkan aksiyonların takip edilmesi, delegasyonu, yapılması scrum master veya ekip liderinin sorumlulugunda oluyor. Mutluluk Index'lerinde çıkan konuların ekip üyeleri ile bire bir görüşülmesi de yine aynı kapsamda.

İlk başta söylediğimizi tekrar edelim; unutmayalım her zaman iyileştirecek bir şeyler vardır.

Retrospective pratikleri ile ilgili faydalandığımız bir kitap;

• Agile Retrospectives: Making Good Teams Great, by Esther Derby, Diana Larsen

Agile Maliyetlendirme

Yapılacak olan işlerin önceden maliyetlendirilmesi yazılım geliştirme sektöründeki kritik işlerden birisidir ve bu konuda function point, uzman görüşü(expert judgement), story point kullanımı vb. çeşitli yöntemler günümüzde kullanılmaktadır. Her yöntemin olumlu olumsuz yönleri olduğu için tek bir standart model yok(yazılım dünyasının en büyük derdi standartlar yoktur çok fazla).

Agile dünyada maliyet hesabı için kullanılan yöntemlerden birisi de story point kavramı ile maliyetlendirmedir. Burada kritik kavramlar ekip, büyüklük, hız, süre ve takvimdir. Kısaca story pointler kullanılarak maliyetlendirmenin nasıl yapılacağından bahsetmeye çalışacağım.

Agile yöntemlerde maliyetlendirme ile ilgili önemli kurallardan birisi, “İşi kim yapacak ise en iyi maliyeti o verir” mantığıdır. Yazılım geliştiriyorsak da geliştirme ekibi ya da scrum takımı(developer, testci, DBA, mimar vs. takımda kim var ise hepsi dahildir) maliyeti verir.

İşlere örnek olarak şu gözle bakılır;

İş: Ankara’dan İstanbula otomobil ile Ankara-İstanbul otobanı kullanılarak gidilecek

Büyüklük: 400km

Hız: 100km/h(ortalama)

Süre: 4Saat

Takvim: 08:00–12:00

Bu kavramların özellikleri ve aralarındaki ilişkiler; büyüklük herkese göre aynıdır, değişen bir bilgi degildir, hız aractan araca veya kişiden kişiye değişir, süre hıza bağlıdır, takvim de süreye bağlıdır. Dolayısı ile bu kavramlardan büyüklük ve hız asıl belirleyici olanlardır.

Bu kavramlar kullanılarak maliyetlendirme yapılacak ise büyüklük hesabı yapılacak olan işin anlamlı bir büyüklükte olması gerekir. Anlamlı bir büyüklükten kasıt ekibin o işi anlayıp, o işi gerçekleştirmek için yapılması gerekenleri kafasında kabaca canlandırabilmesi gerekir. Çok fazla belirsizlik içermemesine dikkat edilir.

Scrum’da işlerin belirlenmesinden sorumlu kişi product owner rolünü üstlenen kişidir, bu kişi müşteridir veya müşteriyi temsil eden kişidir, yapılacak olan işin/projenin user story olarak maddelere bölünmüş halinden oluşan product backlog olarak adlandırılan gereksinim listesini yönetir. Scrum takımı product backlog’daki user story’lere büyüklük maliyeti verir. Örnek bir user story “Kullanıcı olarak kullanıcı adı ve şifremle sisteme login olmak istiyorum” şeklindedir. User story’ler maliyet vermek için çok büyük ise(epic, theme) çeşitli yöntemlerle maliyet verilebilecek daha küçük parçalara bölünürler veya maliyet vermek için küçük user story’ler var ise bunlardan bazıları birleştirilebilir.

Product backlog hazır ve büyüklük maliyeti verilmesi gerekiyor, product owner ve scrum takımının olduğu bir toplantı düzenlenir. Bu toplantıda poker planning denilen bir yöntemle scrum takımı product backlog maddelerine(user story) maliyet verirler. Açık olmayan noktalar hakkında product owner’dan bilgi alırlar, user story’ler parçalanıp, birleştirilebilir.

Büyüklük maliyeti verilirken birim olarak story points denilen bir birim kullanılır ve işler göreceli büyüklüklerine göre puanlanır. Bunu büyüklüklerine göre t-shirt’lerin S, M, L, XL gibi işaretlenmesi olarak da düşünebilirsiniz. Story point olarak genellikle fibonacci serisine benzer 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 gibi rakamlar kullanılır, aradaki sayılar kullanılmaz. Bunun iki önemli nedeni var birincisi aradaki sayılar olursa çok fazla karmaşa olur, 5 mi yoksa 6 mı şeklinde, bunun yerine 5 mi 8 mi ayırımı daha kolay karar verilebilir bir durumdur. Diğer bir neden işlerin büyüklükleri ile o işteki belirsizlik veya belirsizlik çıkma olasılığı da doğrusal olarak artar o yüzden sayılar arasındaki farklar da giderek artıyor, mesela 40 ile 100 arasında ciddi bir fark var. Bu büyüklükteki sayılar genelde belirsizlik içeren ve bölünemeyen user story’ler için kullanılır.

Göreceli büyüklük kavramı için referans noktası veya noktaları olması gerekir, ilk defa poker planning yapmıyorsanız zaten daha önceden verdiğiniz büyüklük maliyetleri sizin için referanstır ancak ilk defa yapıyorsanız kendinize referans orta seviye bir iş seçip ona orta seviye bir puan vermelisiniz(3,5 gibi), sonraki işlerinizin maliyetlerini hep o referans işle karşılaştırarak vermelisiniz. Örneğin referans işe 5puan dedik, sonraki iş bu referans işten çok az daha büyük bir iş o zaman bu işe de 8puan diyorsunuz, ya da sonraki iş referans işten küçük bir iş o zaman bu işe 3puan yada 2puan diyorsunuz şeklinde ilerleniyor.

Poker planning şu şekilde yapılır; user story puanları (0,1,2,3,5,8 vb) poker kartlarına bastırılmış şekilde her scrum takımı üyesinin elinde bir deste puan kartı olur. Product backlog’daki maliyet verilecek iş her ekip üyesi maliyet verebilecek hale gelinceye kadar kabaca irdelenir. Sonra her ekip üyesi ilgili iş için belirlediği puan kartını ters bir şekilde masaya kapatır, herkes kartını koyduktan sonra kartlar açılır. Yani maliyet verirken ekip üyeleri bir birinden etkilenmesin diye ilk önce kimse kimsenin verdiği maliyeti görmez. Kartlar açıldıktan sonra çok farklı puanlar var ise en küçük puan veren ekip üyesi ile en büyük puanı veren ekip üyelerine neden bu puanı verdikleri sorulur. Bu noktada diğer ekip üyelerinin gözünden kaçan bir nokta var mı yok mu bu anlaşılmaya çalışılır. Gerekli tartışmalar yapıldıktan sonra ekip benzer bir puan üzerinde anlaşıncaya kadar bu seans devam eder. Ekip ortak bir puan üzerinde anlaştığında o işin büyüklük maliyeti verilmiş olur. Takım bu şekilde product backlog’daki tüm maddeleri puanlar.

Elimizde büyüklükleri puan olarak belirlenmiş bir product backlog var, bu product backlog’daki işlerin ilgili ekip tarafından ne kadar sürede yapılabileceğini bulmamız gerekiyor ki süre ve takvim olarak müşterimiz ile anlaşalım. Süre için bize hız bilgisi gerekli. Buradaki hız scrum takımının birim zamanda ne kadar puanlık iş yapabildiğidir. Örneğin product backlog’daki işler 1000puan çıktı bizim scrum takımımız 15günde 50puanlık iş yapabiliyor, o zaman product backlog’daki işlerin bu scrum takımı tarafından tamamlanması  ((1000/50)*15)= 300gün sürer, şeklinde bir hesap yapılır. Buradaki kritik nokta bu hız bilgisinin nasıl elde edildiği eğer ilk defa story point’lerle maliyet verip iş yapmıyorsanız hız bilgisi için ekibin tarihsel verileri kullanılabilir, geçmişte kac puanlık işler ekip tarafından ne kadar sürede yapıldı şeklinde ortalama bir hesap yapılıp hız bilgisi elde edilebilir. Ancak geçmiş verileriniz yok ise hız bulmak veya tahmin etmek için farklı yöntemler kullanmanız gerekiyor, bunlardan birisi müşteriniz ile anlaşabiliyorsanız bir iterasyon yapıldıktan sonra hız bilgisi elde edilip müşteriye bu hız bilgisi üzerinden maliyet dönülür. Müşteri ile bu konuda anlaşamıyorsanız tahmini bir hız seçmeniz gerekir başlangıç için.

Agile yöntemlerde gereksinimler, süreler, maliyetler vs. bir defada alınan ya da başlangıcta kesin rakamlarla belirlenen şeyler olarak kabul edilmez. Aslında tüm yöntemlerde bu böyle olmalıdır, çünkü belirsizliklerin en fazla olduğu projenin başlangıç aşamasında verilen süre, maliyet gibi bilgiler çok büyük oranda projenin ortasında, sonunda sapar, projenin başlangıcında gereksinimleri sabit olarak almak, süreleri, maliyeti sabit olarak vermek çoğu zaman gerçekçi bir yaklaşım olmamakla birlikte firmalar kendilerini garanti altına almak için bu sabit kapsam, sabit fiyat, sabit süre yöntemini tercih ediyorlar.

Agile yöntemlerde süre, maliyet gibi sayılarla ifade edilen kavramlar için aralık kullanılması da tercih edilen bir yöntem. Aynı şey scrum takımının hız bilgisi için de geçerlidir. Hız ile verimlilik bir birine paralel kavramlar değildirler, bir takım ne kadar hızlıysa o kadar verimlidir diyemeyiz. Hızları düşük diye eleştirdiğiniz bir takımın hiç bir extra efor sarfetmeden hızını arttırması gayet kolay, story point’leri daha fazla verirler. O yüzden bu kavramlara doğru yaklaşmak çok önemlidir. Hızın artması değil sağlıklı bir aralıkta olması önemlidir. Bazen artar, bazen azalır.

Burada yazılım maliyetlendirmesinde çok kullanılan adam gün, adam ay vb. içinde zaman bilgisi barındıran kavramlardan hiç bahsetmedik. Bir ekip bir projeye maliyet verirken ekipden zaman bazlı maliyet almak sizin o işin gerçek büyüklüğünü bilmemenize neden olur. Aynı işi bir ekip elamanı 1günde yapar, başka bir ekip elemanı 3günde yapar ancak sonucta yaptıkları iş aynıdır. Peki bu 1günlük bir iş midir, 3günlük bir iş midir? Neye göre, kime göre? Bu yüzden kişiden kişiye çok fazla değişiklik göstermeyen büyüklük kavramı ile maliyetlendirmek daha sağlıklı bir yaklaşımdır.

Agile maliyetlendirme ile ilgili Mike Cohn’un Agile Estimating and Planning kitabı okunabilecek güzel bir kaynak.