Agile nedir diye başlarsak, Agile geleneksel proje yöntemine alternatif olarak ortaya çıkmış daha çok yazılım geliştirmesinde kullanılan bir metodolojidir. Temelinde artırımlı ve döngüsel olarak geliştirme düşüncesine sahiptir. Özetle Agile metodolojisi ve Scrum hakkında genel bilgi vermeye çalışacağım.

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.

Prototipin kullanıcılara açılışı farklı steplerde olabilir. Bu aşama aşağıdaki 3 step’den oluşmaktadır.

• Validation
• Limited
• Production

Production adından da anlaşılacağı üzere tüm kullanıcıya açılmış bu Release sürecinin son aşamasıdır. Bu sebeple ona değinmeden diğer iki steple devam ediyorum. Validation, aslında Learning Release olarak da tanımlanabilir. 1 ya da 2 kere yapılabilir. 2 ya da 3 Sprint’den sonra Validation Release çıkmak zaman olarak uygundur. Bu aşamada Release içeriye yapılır. Amaç bir şeyler öğrenmektir. İçeriye açıldığı için de risk düşüktür. 2. Aşama biraz daha ciddi bir aşamadır. Burada ürün, hem içeriye hem dışarıya açılmaya başlanır. Örneğin, bir Android uygulaması için Alpha, Beta testerlar belirlenerek belki sonrasında Google Play’in sunduğu Stage Rollout seçeneği kullanılarak Limited Release yapılabilir. Artık ürün hem içeriye hem dışarıya açıldığı için hem kontrol edilebilir olan hem de kontrol edilebilir olmayan kullanıcıdan söz ediyor olmuş oluruz. Böylece kullanıcıdan aldığımız feedbacklere göre ilerlemiş oluyoruz.

Süreci anlatmaya biraz sondan başlamış oldum ama yazılım tarafında olanlar için geliştirme belki de en bilindik kısım süreci daha geniş bir çerçeveden aldığımızda bu şekilde özetleyebiliriz. Tabi geliştirme en alışkın olduğumuz bölüm derken ilerlenen süreç alışık olduğumuza oranla biraz daha farklı.

Detaylara inmeden Scrum ekipleri, proje ekipleri değil product ekipleridir. Bu ne demektir dediğimizde ise şöyle ayrımı sağlayabiliriz. 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 ise en basit agile süreci olarak tasarlanmıştır. Product team kavramı ise Agile’ın 3. jenerasyonuyla beraber ortaya çıkmıştır. İlk jenerasyon küçük developer takımlarından oluşuyordu. Tüm güç developerlara ait düşüncesi hakimdi. 2. jenerasyonda bunun yerini product development akışı kavram olarak yerini aldı. 3. jenerasyonda ise product ekipleri oluşmuş oldu.

Peki Scrum tam olarak nedir dersek, 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. Scrum Master ekibin bir elemanı olabileceği gibi, ekip dışından da olabilir. SM yönetici ya da proje yöneticisi değildir. Agile prensipleri ve değerlerinin uygulanmasını sağlar, süreci takip eder. Scrum Framework’unu, rollerin en iyi nasıl uygulanacağını herkese öğretir. Hizmet elemanıdır ama bunu çay, kahve taşıyan, gelip omzumuza masaj yapan kişi olarak düşünmemeliyiz. Ekibin dedike bir şekilde, dış etkenlerden etkilenmeden çalışmaya devam etmesini sağlar. Aynı zamanda hem ekip elemanları hem de PO için Change Agent olarak görev alır. Riski yönetir. Süreçte bir sorun gördüğünde müdahale eder. Scrum ekipleri ortalama 5-9 arası sayıda kişiden oluşur.

Scrum’da 5 tip toplantı vardır.

• Sprint Planning (Her Sprint’e başlarken)
• Daily Stand-ups (Her gün max 15 dk, ayakta)
• Backlog Grooming(1 sprint’de 2 ya da 4 defa)
• Sprint Demo (Sprint sonunda)
• Sprint Retrospective(Sprint sonunda , süreci değerlendirmek için)

Süreç Product Backlog‘un oluşturulmasıyla başlamaktadır. Product backlog kabaca development ekibi için işlerin önceliklendirildiği bir todo listesidir. Product Backlog’un oluşturulmasında temel görev Product Owner’a düşmektedir ama bu süreçte Development Team’in de fikrini alabilir. Her bir Product Backlog çok sayıda PBI (Product Backlog Item) içermektedir.Her bir PBI birden çok Epic, Feature, Story ve Task’dan oluşuyor olabilir. Bir ürün 1-7 epic’e sahip olabilir. Her bir epic, feature’lara sahiptir. Her bir feature için de çoklu sayıda story’ler ve bu storylere de kabul kriterleri hazırlarız. Kabul kritlerini aynı zamanda test case’leri gibi de düşünebiliriz. PBI’yı scope olarak düşünebiliriz. Her bir PBI ise çok sayıda Sprint Backlog içermektedir. Sprint Backlog’lar Sprint Planning sonrasında oluşur. Sprint Planning sırasında PO neyi neden istediğini söyler. Team bu istekleri analiz eder ve sonrasında PO ve Team arasında bir anlaşma kararı alınır. Böylece Sprint’e başlanabilir.

Sprint planning’de yazılan her bir story’nin ne kadar sürede tamamlanacağını ya da zorluk derecesini ölçümlemek için estimation yapılır. Her bir story’ye story pointler verilir. Burada puanlama poker kartları ya da fibonacci numaralarıyla yapılabilir. Story’lerden biri ortalama zorlukta olarak seçilir ve mesela 5 puan verilir. Diğer story’lere ise buna oranla bir puan verilir. Estimation yapılırken ise, mesela poker kartlarınız kullandığımızı varsayalım. Story’ye tüm ekip üyeleri bakar sonrasında herkes düşündüğü zorluk için bir poker kartı seçer. 3 dk sonunda herkes poker kartlarını gösterir. Eğer değerler birbirine yakınsa ortalama bir sayıda konsensusa varılabilir. Ya da en düşük ve en yüksek kartı gösterenler sebeplerini açıklarlarlar ve tekrar oylama yapılır. Burada toplu bir karar alınması yerine herkesin düşündüğü rakamı göstermesinin sebebi, farklı bakış açılarının farklı riskleri düşünebilme ihtimalidir.

 Yukarda yer alan chart, cone of uncertainity’dir. Estimationları yaparken eğer daha öncesinden hiç bilgi ve deneyimimiz yoksa, hiç bir analiz yapma şansımız olmadıysa, verdiğimiz estimationların da gerçekçiliği söz konudur değildir. 5 story pointlik bir işe 400 verme ihtimalimiz vardır. Eğer biraz analiz yapma şansımız olduysa ya da kısmen bir bilgi sahipbiysek, yukarıdaki eğride orta kısımlara denk gelen bir tahminleme yaparız. Hem bilgi sahibiysek hem de analizimi yaptıysak eğer yaptığımız estimation son kısımlara denk gelmektedir.

Sprint’de her gün max 15 dk’lık stand-up meetingler yapılır. Bu stand-up meetinglerin max 15 dk ayakta olmasının aslında sebepleri vardır. Ayakta olduğu için kişi kendisini çok rahat hissetmez ve böylece de kısa süre içerisinde anlatmak istediklerini bitirmek ister. Max 15 dk denmesinin sebebi ise, belli bir şeye belli bir noktadan fazla zaman ayırdığımızda verimde artma değil başlangıçta düzleşme ardından da düşme başlar. Eğer yarım sa konuşulacak denseydi de en az yarın sa konuşulurdu.  Her gün yapılan bu standup meetinglerde son 24 sa içerinde bu Sprint’den amacına ulaşmak için ne yaptım. Bundan sonraki 24 sa içerisinde Sprint’in amacına ulaşmak için ne yapabilirim. Beni engelleyen herhangi bir şey var mı gibi konulardan oluşur.

Her bir Sprint’de 1 ya da 2 kere Backlog Refinement(Grooming) yapmak faydalıdır. Backlog Refinement’lar PO, SM, DT ve gerekliyse uzmanların katılımıyla sağlanır. Herkes için uygun bir zamanda yapılabilir. Özel bir zamanda yapılmasına gerek yoktur. 2 haftalık bir Sprint için, 60, 90 dk’lık bir toplantı yeterlidir. Temel olarak PO’yu aydınlatmak için yapılır. Bu toplantıda bazı story’lerde değişiklik bölünmeler gerçekleşebilir. Yenileri eklenebilir.

Sprint Planning’le açılışı yaptık. Artıkdan Daily Standup’lar ve Backlog Refinement’lar yaptık. Her bir Sprint’in sonunda ise Sprint Review (Actual Performance), Sprint Demo(Actual Software Features) ve Sprint Retrospective (Process Improvement)yapılmalıdır.

Peki bir Sprint’de işimizi tamamladığımızı, amacımıza ulaştığımızı nasıl ölçeriz. Sprint’e ilk başlarken yapılması gereken bir Definition of Done tanımı vardır. DoD’da yer alan metrikler ise,

• Forecast vs. Accepted
• Sprint içerisinde bulunan bug’lar
• Outstanding buglar
• Build’in başarısız olma sayısı
• Ekibin ivmesi
• Burndown-Burnup chart’lar

Dev. tamamlandı, test tamamlandı, PO tarafından kabul edildi. Release Planning’i ise yazımın başında anlanmıştım.

Umarım genel bir fikir sahibi olabilmenizi sağlamışımdır. İyi hafta sonları 🙂