Yaklaşık 1 yıl kadar önce Agile & Scrum’la ilk tanıştığımda aldığım kısa eğitimin ardından, genel kuralların, konseptlerin, işleyişin neler olduğuna dair bir yazı yazmıştım. Şimdi 1 yıllık deneyim, Agile Yazılım Geliştirme Süreçleri üzerine bir MBA bitirme projesi ve bu sefer Scrum Master olarak bir kere daha yazının üstünden geçmekte fayda var 🙂
“…Agile’da yapılmak istenen müşteriye minimum eforla ve maksimum öğrenimle; optimum ürünü verebilmektir. Öğrenim dendiğinde ise risklerin azaltılması, ideal market riskinin alınması gibi konular söz konusu olmaktadır. Tüm fazların hepsi birden markete alındı ve aslında kullanıcımızın buna ihtiyacı yoktu. Bu durumda olan hem zaman hem de insan gücü kaybıdır. Çok büyük bir maliyetle minimum kazanım elde edilmiş olur. Bunun yerine ürünün küçük bir prototipiyle ilerleyip kullanımını incelediğimizde ve kullanıcının ilgisine göre ilerlediğimizde kazancımız çok daha fazla olacaktır. Az önceki durumda, başarısız olacak bir projeyi en başında fark edeceğimiz için kaynaklarımızı başka yöne yönlendirebileceğiz. Bu durum büyük firmalar çok büyük kayıp olmayabiliyorken; yaptığı işi satmak zorunda, aksi takdirde yaşamına devam edemeyecek olan firmalar içinse gerçek bir zorunluluktur ki ortaya çıkma sebebi de zaten budur…”
Yukarıdaki paragraf, ilk yazımdan alıntı ve doğru olmakla beraber, aslında tamamen kitap cümleleri. Evet aynen aslolan MVP’yi sağlamak ve en zor olan da bu aslında. Şimdiye kadar waterfall düzende çalışmaya alışmış insanlar olarak, iş teoriden pratiğe geçtiği anda hepimizin en çok zorlandığı konu aslında tam olarak bu – işi anlamlı küçük parçacıklara bölmek. Burada zor olmasının sebebi, anlamlı parçacıklar üretmek istememiz. Eğer ki sistemsel bir ihtiyaç değilse, her bir Product Backlog Item(PBI) kullanıcı açısından anlamlı bir sonuç üretmeli. Bir kullanıcı olarak … yapmalıyım ki … olsun. Bu da waterfall’da alıştığımız önümüze tüm analizi yapılmış olarak gelmiş ve işe göre belki önce backendini sonra client’ını ya da tam tersi sonuç olarak kocaman bir işi bütün olarak bitirme kavramından tamamen uzaklaşmamızı gerektiriyor. Tabi bu noktada amaçtan da uzaklaşmamak gerekiyor. Yavaş yavaş Agile düşünmeyi öğreniyoruz.
Görsellerle ilerlemek anlatımda her zaman yardımcı olmuştur. Eğer ki bi yerlerde MVP duyduysanız, yukarıdaki imajı da görmemiş olmanız imkansız. Peki bu görsel bize ne anlatıyor?
Bizim bir amacımız var o da kullanıcımıza bir ulaşım aracı sunmak. Arabayı üretmek için eğer ki araba parçalarını üretmekten başlarsak, ortaya çıkardığımız ürünler araba tamamen bitene kadar kullanıcı için hiç bi anlam ifade etmeyecektir. Üstelik kullanıcının bir ulaşım aracına ihtiyacı olup, olmadığını, varsa da bunun araba gibi bir araç mı yoksa daha basit bisiklet gibi bir araç mı olduğunu asla bilemeyiz. Oysaki kullanıcıya ulaşım için kullanabileceği, kaykayla başlayan süreçte en son arabayı sunsaydık, kullanıcı 100% memnun olmasa da ulaşımını yapabilecekti. Belki de ihtiyacı olan motorsiklet burada feedback’i aldık ve araba yapmamıza gerek kalmadı. Böylece geliştirme maliyeti çok uzun sürecek bir işten kurtulmuş olduk.
İşte Agile sayesinde hem müşterinin memnuniyeti maksimize edip, hem de maliyeti minimumda tutmuş oluyoruz. Tabi bu geliştirme ve feedback alma sektöre ürüne göre değişebilir. İç müşteriye açılabilir, stage rollout gibi yöntemler kullanılabilir, vs.
Artık MVP’yi Agile’ın neden varolduğunu kavradığımıza göre, devam edebiliriz.
“… Scrum ekipleri, proje ekipleri değil product ekipleridir. … Proje ekipleri, proje yeterli para kazandırdığında sonlandırılırken Product ekipleri ürün istenen değere ulaştığında dağılır. Agile’da sürecin kendini değil, ürün önemlidir. …
…Scrum Agile methodlarından biridir. Kendi kendine organize olan ekiplerden oluşur. Her 2 ya da 4 haftada bir ise bir ürün ortaya çıkarılır. Scrum’da 3 rol vardır. Bunlardan ilki Product Owner’dır. Product Owner vizyonu taşıyan kişidir. Product Backlog’dan temel olarak PO sorumludur. Bir diğeri sürekli bahsettiğimiz Scrum Team‘dir. Son olarak da Scrum Master vardır. ”
Yukarıdaki paragrafda ilk yazımda yanlış kullandığım bir kelime var. Scrum ekibi değil Scrum takımı olmalı. Burda ekip mi takım mı konusunda hep bir karmaşaya düştüğümüzde Agile Koç’umuzun kullandığı bir örnek var. Bunu kullanarak açıklamak isterim. Takım belli bir amaç uğrunda bir araya gelen tek bir ruh olan insan topluluğudur. Birbirlerini çok iyi tanırlar, açıklarını da bilirler, iyi yönlerini de. Ve bunu birbirlerini tamamlamak, bütünü ortaya çıkarmak için kullanırlar. Birbirlerine güvenirler. Örneğin; futbol takımı. Ekip’e örnek ise uçak mürettabatı gösterilebilir. Uçağa binmeden önce tanışır bir ekip olurlar ve uçuş sonrasında dağılırlar.
Yine alıntıdaki bir diğer önemli nokta, Scrum takımlarının proje değil, product takımları olmasıdır. Scrum takımının başarısı ortaya çıkardıkları ürünün başarısıdır. Waterfall dünyaya geri dönelim. Bir developer olarak; waterfall’da yapmam gereken önüme gelen analizi gerçekleştirmek. Tabi bu noktada ufak katkılarım olabilir ya da teknik olarak gerçekleştirilemeyecek istekleri revize edebilirim ama Scrum’da işler biraz değişiyor. Herkes, herşey için elini taşın altına koyuyor. Korkutucu olduğu kadar mükemmel de. Ürünün en başından en sonuna her bir akışda, her bir metinde, verilen her kararda analist, tasarımcı, testçi ve yazılımcının hep beraber kafa yorup, mükemmeli ortaya çıkarma çabası yadsınamaz. Tabi bu ürüne olan sahiplenmeyi de kesinlikle arttırıyor. Business tarafından bakıldığında ise ürünün her aşaması hakkında bilgi sahibi, her sorusunu cevaplayabilecek bir takım bir adım ötesinde. Sanırım her zaman istenen şey aslında 🙂
Bir önceki yazımda bahsetmemişim ancak product’dan bahsetmişken Scrum’ın en önemli maddelerinden biri olan multi tasking vs single task üzerinde de biraz durmakta fayda var. Şu an aynı anda kaç projede çalışıyorsunuz, 2-3-5-10 ? 3’den az değildir sanırım. Aşağıdaki grafik aynı anda çalıştığımız projelerin sayısı arttıkça context switching’den dolayı kaybettiğimiz zamanı gösteriyor. Tabi bu durum herkeste birebir aşağıdaki gibi olmayabilir, değişiklik gösterebilir. Scrum’da ise tek bir şey üzerine, sadece ürüne focus oluyoruz. Biraz takımdan bahsederek bu konuyu detaylandırmakta fayda var. Az önce dediğimiz gibi, bir Scrum takımı içerisinde geliştirilen ürüne göre yazılımcı, testçi, analist, tasarımcı bir arada yer alır. Ama her bir takım üyesinin de ürünün her bir aşamasında söz sahibi olduğunu söyledik. Peki bu nasıl oluyor?
Scrum’da amaçlanan Cross-Fuctional takımlar oluşturmak. Yani örneğin, bir yazılımcı olarak ben yazılım ana uzmanlık dalım olsa da kullanıcı deneyimini de düşünmeliyim, analiz de, test de yapmalıyım. İşte aslında Scrum’da single focus böyle oluşuyor. Dolayısıyla hiç kimse hiç bir zaman boş kalmıyor aslında. 🙂 Sadece yeni bir projeye geçme yerine üzerinde çalışılan PBI’ın tamamlanması için gerekeni yapıyor. Mesela sprint için planlamada 5 PBI alındı diyelim. Herkes kendi sevdiği PBI’dan başlayıp işine devam etmiyor tabi ki. PBI’yı bir kişinin sahiplenip içerisinde yer alan bütün taskları yapıp tamamlaması en büyük yanlış olurdu ve Scrum içinde yine küçük waterfall’lar yapıyor olurduk. Bunun yerine mümkün olduğunda ‘1 PBI in a time‘ prensibiyle ilerlenerek, her bir takım üyesinin üzerinde çalışılan PBI’ın DONE olabilmesi için yapabildiği her şeyi yapması gerekir. Eğer başka yazılım taskı yoksa, yeni PBI’a geçmemeli test yapmalıyım örneğin.
PBI’ın DONE olması dedik, onu da biraz daha açmakta fayda var. Bir PBI’ın done olabilmesi için geçmesi gereken iki kriter dizisi var. İlki testler tamamlandıktan sonra, Product Owner’ın belirlediği kabul kriterlerini sağlayıp sağlamadığını kontrol etmesi ve OK vermesi. Bir diğeri de Definition of Done (DoD) maddelerini sağlaması. Her bir takımın bir DoD listesi olmalıdır. Örneği birim test yazmak, automated olarak ürünü çıkarmak vs. olabilir. Bu listeyi sağladığından emin olmalıyız. Örneğin, birim test yazmak bizim DoD listemizde varsa, birim testi yazılmayan bir PBI done olamaz. Aslında anlaşıldığı üzere, ürünün her bir geliştirme biriminde o kadar çok kontrol edilerek ilerlenir ve bunlar standart haline gelir ki olabilecek en kaliteli şekilde ürün ortaya çıkarılmış olur.
Artık Scrum’ın neden başarılı olduğu hakkında biraz daha fikir sahibiyiz. 🙂 Son olarak; eventlerden de bahsetmekte fayda var.
“Scrum’da 5 tip toplantı vardır.
- Sprint Planning (Her Sprint’e başlarken)
- Daily Scrum (Her gün max 15 dk, ayakta)
- Product Backlog Refinement(1 sprint’de 2 ya da 4 defa)
- Sprint Review (Sprint sonunda)
- Sprint Retrospective(Sprint sonunda , süreci değerlendirmek için)“
Ben bunlardan her günümün ilk işe başlarken ilk 15 dk’sını alması sebebiyle Daily Scrum‘la başlamak istiyorum. Neden 15 dk, neden ayakta, neden hergün aynı yerde? “consistency reduces complexity”Ayakta olmasının sebebi, kişilerin ayaktayken otururkene göre daha rahatsız olmaları, bir önceki gün naptığını, o gün napacağını ve ilerlemesine engel bir durum olup olmadığı bilgisini özet bir şekilde paylaşacak olması. Time-box çok önemli. Daily Scrum’ın amacı, herkesin aynı noktaya gelmesi ve ilerlemeye engel bir durum varsa, problemi çözmek için aksiyon alma kararı oluşturulması. Eğer ki başka herhangi konuşulması gereken bir konu varsa, bu Daily-Scrum bittikten sonra konuşulmalıdır. Ayrıca bu event’in hergün aynı saatte, aynı yerde olması da çok önemlidir. Bu konuda herhangi bir belirsizlik olmamalıdır. Bir diğer yandan tüm scrum eventleri için time-box ve event’e başlanılacak zaman, buna uyulması çok önemlidir. Takım içinde eventlere geç kalınmaması için late-box koyup geç kalanlardan kaldığı süre kadar para alabilirsiniz 😀 Ya da sizin yaratıcılığınıza kalmış. Böylece herkes zamanında eventlere katılım sağlayacaktır.
Product Backlog Refinement‘le devam edelim. Backlog Refinement’de backlog item’lar üzerine tartışılır, detaylandırılır. İlk sprintlerde Refinement’a ayrılacak süre biraz daha fazla olabilmekle beraber genelde kapasitenin %10 una kadardır. Yeni itemlar da gerekirse eklenebileceği gibi, varolan üzerinde sizing işlemi yapılır. Sizing dedik, bu nedir? Waterfall dünyaya geri döndük. Yöneticiniz size bir proje verdi ve ne kadar zamanda yaparsın diye sordu? Siz de örneğin 3 gün dediniz. Elma-Armut bir şekilde bir PBI’ın geliştirilmesi içi bir maliyet vermemiz gerekli. İşte sizing dediğimiz bu aslında ama bunu biraz daha farklı yapıyoruz. En yaygın yöntem poker kartlarını kullanmak 🙂 İlk sprint’de oranlayabileceğimiz küçük ama çok da küçük olmayan bir PBI’ı referans olarak seçeriz. Örneğin 5 diyelim. Sonrasında aldığımız PBI’ları ise poker kartlarıyla buna oranla zorluk, süre, bilinmezlik gibi kıstasları göz önüne alarak size ederiz. Ve sadece poker kartlarında yazan değerlerle bunu yaparız. Burada biraz değişik bir seromoni vardır. Product owner PBI anlatır. Tüm takım, birbirine göstermeden bir kart kaldırır. Eğer ki herkes aynı sayıyı kaldırmışsa sorun yok. O rakam o PBI’ın değeridir. Ama diğer taraftan biri 3 biri 34 de kaldırmış olabilirdi. İşte bu durumda, neden birbirimize göstermeden ya da yönlendirmeden size ettiğimizin güzelliği ortaya çıkıyor. 3’ü veren aslında çok basit bir noktayı görmüş ve süreci hızlandıracak bir detayla gelebileceği gibi, 34 veren de aslında kimsenin akıl edemediği çok farklı bir nokta düşünmüş olabilir. En yüksek ve en düşük verenler neden bu rakamları kaldırdığını açıklar, ya bir ortak sayı seçilir ya da tekrar oylama yapılır.
Sprint Review ve Sprint Retrospective’ler sprint’in sonunda. Planning ise adından da anlaşılacağı üzere başında yapılır. Sprint Review’de tüm stakeholder’lar, ürünü görmek isteyen herkes gelip ürünün geldiği aşamayı görebilir. Stakeholder’lar ürünle ilgili yorumlarını dile getirir. Bunlar ürünün amacıyla ters düşmüyorsa, değerlendirilir ve planning’de backlog’a girerler. Retro’lar ise sadece takımın katılımıyla yapılan, dışarı kapalı eventlerdir. Takım sprinti ve kendini değerlendirir.
Teoriden pratiğe geçişte Scrum’ın yaşam döngüsünü aktarmaya çalıştım. Umarım okuması keyifli ve aydınlatıcı bir yazı olmuştur. İyi haftalar 🙂
