Eğitim Teknolojileri
_Yazilim_Gelistirme_Sureci-min.jpg)
Enocta kurumsal eğitim ve 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 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;
Bunların haricinde elde ettiğimiz faydaları da şöyle listeleyebiliriz;
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ı maalesef ama isimlendirmenin oldukça uygun olduğunu düşünüyorum.
Süreçte temel olarak 3 rol vardır:
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.
Ü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 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:
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.
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/
Teknolojideki yenilikler ve değişen iş ortamları, proje yöneticilerinin rollerini ve hedeflerini dönüştürüyor. Bu dönüşümle birlikte Project Management Institue (PMI), Project Management Professional (PMP) sertifika sınavının içeriğini bu yılın başında değiştirdi.
Öğrenme şeklimizin kişiliğimize, beynimizin çalışma şekline, bulunduğumuz ortama ve kültüre bağlı olduğunu biliyor muydunuz?
Kişisel liderlik, yaşamın her alanında bireysel olarak bir üst noktaya çıkmamızı sağlayan en önemli yeteneklerden. Bu yeteneğin içinde bulunduğumuz dönemde aldığı kritik hal, hayatımızın direksiyonuna nasıl geçeriz gibi birçok soruya yanıt bulduğumuz webinarımızda, Kemal İslamoğlu bizlerle buluştu.
