Çevik (Agile) Yazılım Geliştirme Süreci

Enocta yazılım geliştirme ekibi olarak Mayıs 2015 başında, “Waterfall” olarak tanımlanabilecek yazılım geliştirme süreçlerimizi değiştirerek , farklı disiplinlerde de kullanılan çevik (agile) proje yönetim metotlarından “Scrum” yöntemini kullanmak üzere adımlarımızı attık.

 

Genel olarak çevik yöntem, özel olarak da Scrum metodu ile ilgili açıklamaları, Enocta’da uyguladığımız yöntemle ilgili detaylarla birlikte bu yazıda bulabilirsiniz.

 

Kökenleri  1980’lerin ortasına kadar gitmekle birlikte, manifestosu 2001 yılında yazılan Çevik (Agile) yazılım geliştirme yöntemi, gün geçtikçe yazılım geliştirme süreçlerinde daha yoğun kullanım alanı bulmakta. Beklentilerdeki ve ihtiyaçlardaki değişikliklere, diğer kullanılan yöntemlerden daha hızlı yanıt verebilmek üzere kurulmuş olan çevik yöntemin manifestonuna bir göz atalım.

 

Manifestoda belirtildiği üzere, çevik yazılım geliştirme yöntemi, ekip içi ve ekipler arası iletişimi, çalışan ve kendini anlatan ürünü, geliştirme sürecine dahil olan müşteri profilini ve bunların sonucunda ortaya çıkan plan ve üründeki değişimlere hızlı tepki vererek ürünü ortaya çıkarmaya odaklanan bir sistem.

 

Enocta’da Scrum Süreci

 

Enocta’da Scrum yöntemi, Mayıs 2015 başında kullanılmaya başlandı. Sprint süreleri 2 hafta olarak planlanan Scrum yöntemine geçişle birlikte iyileştirilmesine katkıda bulunulan başlıklar şu şekilde sıralanabilir;

 

1-scurm

 

  • Analiz aşamasındaki eksiklere daha erken müdahale edilebilmek,
  • Ürün geliştirme süreci bitmeden müşterilere sunulacak geliştirmeleri erken safhada incelemeye alabilmek,
  • Projelendirme aşamasında üründe ciddi altyapı değişikliklerine neden olma ihtimalini azaltmak.

Bunların haricinde elde ettiğimiz faydaları da şöyle listeleyebiliriz;

  • Günlük Scrum toplantıları sayesinde ekipteki kişiler içinde bulunmadıkları projelerdeki durumu da takip edebilmeye başladı ve farkındalık arttı.
  • Sprint toplantılarıyla birlikte yazılım kalitesinin tüm ekibin sorumluluğu olduğu fikri pekişti ve yazılım ekibiyle ürünleri arasındaki bağ güçlendi.
  • Planlama modelinin değişmesiyle, farklı müşterilerin geliştirme isteklerine daha hızlı yanıt verilebilmeye başlandı.

 

Scrum Modeli

 

Scrum kelime anlamı olarak “itişip kakışma” anlamına geliyor. Bu ismin, günlük Scrum toplantılarının, Amerikan futbolunda topun oyuna sokulması sırasındaki hücum ve defans oyuncuları arasındaki hengameyi andırması sebebiyle verildiğini okumuştum. Kaynak için yaptığım incelemeden bir sonuç çıkmadı malesef ama isimlendirmenin oldukça uygun olduğunu düşünüyorum.

 

Roller

 
Süreçte temel olarak 3 rol vardır:

 

Ürün Sahibi: Ürünle ilgili stratejik üretim kararlarını vermekten sorumludur. Kullanıcı işlevselliğini göz önünde bulundurur ve kararları bağlayıcıdır.

 
Takım: Ürün sahibinin istekleri doğrultusunda doğru ürünü geliştirme görevine sahip ekiptir. Scrum yönteminde bireysel sorumluluklar kabul edilmez, doğru veya yanlış yapılan şeyler, tüm ekibin sorumluluğundadır. Genelde 5 ile 9 kişi arasındadır.

 

Scrum Ustası: Scrum yönteminin kurallarının uygulandığından emin olmak ve süreçte takım üyelerinin karşılaştıkları engelleri kaldırmak görevleri vardır. Bir nevi “hizmetkar yönetici” modelidir.

 

Toplantılar

 

Sprint Planlama Toplantısı – 1: Ürün sahibinin, takımla birlikte ürün içeriği ve kullanıcı hikayelerini değerlendirerek geliştirme başlıklarının öncelik sırasını belirlediği, adımdır. Bu adımda, sprintin tamamlanması ile ilgili olarak kabul kriterleri (definition of done) belirlenir.

 

Sprint Planlama Toplantısı – 2: “Ne?” yerine “Nasıl?” sorusunun öne çıktığı toplantıdır. Yapılacak başlıkların detayı belirlenir ve bu başlıklar çalışma tahtasına (taskboard) yazılır.

 

Günlük Scrum: Gün başlamadan önce  takım üyelerinin çok kısaca, bir gün önce yaptıkları, o gün içinde yapmayı planladıkları ve hesapta olmayan ve ekip üyesinin sürece devamını engelleyen bir durum olup olmadığını dile getirdikleri toplantıdır. 15 dk’yı geçmemesine özen gösterilir.

 

Sprint Değerlendirmesi: Sprint içinde yapılmış olan başlıkların, ürün sahibi tarafından değerlendirilmesi ve eğer uygunsuzluk bulunursa ilgili maddenin tekrar planlanmasını içeren toplantıdır.

 

Sprint Retrospektif: Geçmiş olan sprintte doğru yapılan ve yapılmaya devam edilmesi gereken başlıklarla yanlış yapıldığı düşünülen, iyileştirme potansiyeli olan süreçlerin belirtildiği ve karar verilen bir iyileştirmenin yapılması ile ilgili karar alınan toplantıdır.

 

Sprint

 

Sprint, Scrum modelinde, anlamlı bir ürün ortaya çıkaracak şekilde planlanmış süreler, adımlardır. Tipik olarak 1 hafta ile 4 hafta arasında değişebilir. Sprint süreleri prensip olarak aynı projeler için değiştirilmezler. Örneğin belli bir proje için sprint süresi 2 hafta olarak belirlenmişse, proje sonuna kadar buna sadık kalınır. Hedefe ulaşımın mümkün olmadığına karar verilirse, takım veya ürün sahibi spirinti durdurmaya karar verebilir. Sprint durdurulması durumunda, en kısa sürede yeni sprintin planlaması yapılır.

2-scrum
Scrum modeli iş akışı 1

 

Yapı Taşları

 

Ürün İçeriği: Ürün içeriği, taleplerin oluşturulması için farklı kaynaklardan gelen istek, talep ve fikirlerin derlenerek toplandığı ve yönetildiği alandır. Toplanan kullanıcı hikayeleri, ürün sahibi tarafından önceliklendirilir ve tamamlanmalarının ne kadar süreceği ile ilgili olarak tahminler not edilir. Liste dinamiktir, ekleme, çıkarma, tahmini süre düzenleme işlemleri yapılabilir.

 

Sprint İçeriği: Sprint içeriğinde tamamlanması planlanmış olan maddelerin listelenmesiyle oluşur. Çalışılacak maddeler “Yapılacaklar” başlığında, üstündeki çalışma devam eden maddeler “Devam Ediyor” durumda, tamamlanmış maddeler “Tamam” durumunda bulunur.

 

İş Bitim Grafikleri: Sprint içeriği ile ilgili başlıklar için tahmini kalan süre bilgisinin günlere göre dağılımı ile oluşan grafiktir. Scrum yöntemi içinde, önemli olan harcanan değil işin bitimine kalan süre olduğu için sprint sonuna doğru azalma gözlenmesi beklenen bir grafiktir.

 

Scrum Modelinde Test Süreçleri

 

Scrum modelindeki test süreçlerinin yapılanmasını anlatmak için önce waterfall modelindeki klasik yapıyı inceleyelim.

Waterfall modelinin temel adımlarını aşağıdaki grafikte görebiliriz:

 

waterwall
Waterfall modeli iş akışı 1

 

Bu modelde ürünün tamamlanması öncesinde test ve hata gidermeler için ayrılmış başlı başına bir adım var. Adımın kodlama aşamasının tamamının tamamlanması sonrası olması, hataların tespit edilmesinin gecikmesini ve belli durumlarda birbiri üstüne inşa edilmiş modüllerden en alttakinde tespit edilen bir hata nedeniyle ciddi iş kayıplarına neden olabilme riski taşımakta. Çevik yöntemler bu riskleri daha erkenden tespit edebilmek ve proje sonu yaklaşırken, tüm projeyi riske atabilecek hata ve planlama yanlışlarını daha önceden tespit edebilmek için yöntemler sunuyor.

 

Scrum metodunda, yapılacak sprint içerik başlıkları mümkün olduğunca küçük test edilebilir parçalara ayrılır. Bunun sonucunda, kodlanan yazılım black-box veya white-box yöntemlerle test edilebilir hale geldiği anda, sprintin çok erken safhalarında test sürecin girebilir. Bu akışkanlık sağlandığı anda da eğer tanımlı bir yazılım test ekibi varsa, bu ekip için genelde proje sonlarına yığılan yük daha homojen şekilde dağılmaya da başlar.

 

Bunun yanında, tüm Scrum süreci aslında doğru zamanda doğru soruların sorulmasına odaklandığı, ürünün yalnızca neyi yaptığı değil, bunu neden yaptığını da sorgulattığı için ürün farkındalığı ve sahiplenme hissini arttırdığı da bizim tecrübelerimizdir. Yalnızca sprint değerlendirme toplantıları dahi, tüm ekibin ürüne karşı hissettiği sorumluluğu ciddi şekilde arttırmakta.

 

Test Otomasyonu

 

Scrum yöntemi ile birlikte son kullanıcıyı etkileyecek değişikliklerin yapılma sıklığı diğer yöntemlere göre çok fazla artıyor. Bu da test süreci özelinde entegrasyon ve regresyon testi yükünü arttıran bir unsur. Örneğin 3 ayda bir majör bir versiyonu çıkarılan bir yazılım ürünü, 2 haftalık sprintlerle üretilmeye başlandığında tek regresyon testi yerine altı regresyon testi yapılması gerekiyor.

 

Burada test otomasyonu devreye giriyor. Özellikle build sürecine dahil edilecek unit test koşturulması işlemi ile birlikte regresyon testlerinin uygun framework’lerle otomatize edilmesi insan kaynaklı hata riskini azaltıyor, test süresini kısaltıyor, hem de doğası gereği “sıkıcı” bulunan regresyon testlerinin yükünü test ekibi üstünden alıyor. Bu nedenle test otomasyonu gün geçtikçe popülerleşiyor. Hatta “test otomasyon uzmanı” adıyla yeni bir uzmanlık alanının doğuşuna da şahit olmuş durumdayız.

 

Elbette test otomasyonu, özellikle son kullanıcı deneyiminin kritik olduğu uygulamalar için tek ve kalıcı çözüm değil. Örneğin sosyal ağlarda belli bir fonksiyonun programatik olarak doğru çalışması kadar kullanıcıya sunduğu deneyim de çok kritik. Bu nedenle test otomasyonunun tüm test işlemleri için uygulanması ve tek yöntem olması gerçekçi bir hedef olmaktan çıkıyor. Manuel test işlemi ile birlikte planlanan test otomasyonunun optimum faydayı sağladığı farklı sektörlerdeki deneyimlerle artık neredeyse ortak kabul görüyor.

 

Kaynaklar:

 

https://en.wikipedia.org/wiki/Scrum_(software_development)
https://tr.wikipedia.org/wiki/Waterfall_model
https://en.wikipedia.org/wiki/Agile_software_development
http://www.agilemanifesto.org/iso/tr/
http://www.infolla.com/cevik-agile-yazilim-surecleri
http://www.keytorc.com/blog/devops-yaklasiminda-yazilim-testi_3625/

Tüm uzaktan eğitim ihtiyaçlarını tek bir çatı altında sunan 15 yıllı aşkın sektör deneyimiyle Türkiye'nin lider firmasıdır.

Leave a reply:

Your email address will not be published.

Site Footer

Enocta Enocta