YAZILIMDA AGILE VE WATERFALL MODELLEME
Yazılım dünyasında en çok kullanılan kavramlardan biri de SDLC(Software Development Life Cycle). Peki SDLC yani Türkçe adıyla Yazılım Geliştirme Yaşam Döngüsü nedir? Kısaca ürünün geliştirilmesi, tasarlanması ve testlerini içeren süreçlerdir diyebiliriz.
Yazılım geliştirme süreçlerini anlamak bir test mühendisi için en az test kalitesi, çeşitleri ve test araçları kadar önemlidir. Bu yazıda en yaygın SDLC süreçleri olan Agile ve Waterfall modellemeleri sizlere kısaca aktarmaya çalıştım. :)
AGILE MODEL
Agile model geleneksel yazılım geliştirme modellerine göre daha esnek olan, kullanıcıyı da yazılım geliştirme sürecinin içerisine katan bir yöntemdir.
Agile modelde görevler küçük parçalara bölünerek ilerletilir, bu şekilde kullanıcının önüne ürünü daha hızlı çıkarmayı hedefler. Agile modeldeki bu esneklik sayesinde kullanıcının değişiklik isteklerine çabuk cevap verilebilir.
Birey değil takım mantığı öne çıkar, takım ruhu baskındır. Test ve geliştirme ayrı parçalar olarak görülmez. Yapılan geliştirmenin kalitesinden tüm ekip sorumlu olarak görülür.
Agile modellemeyle ilerleyen süreçlerin en yaygınları ise Scrum ve Kanban’dır.
Scrum
Karmaşık yazılım projelerinin yönetimi için kullanılan yönetim modelidir. Sadelik baz alınır, bu nedenle anlaması basittir. Scrum ürüne ve ürünü sürekli iyileştirmeye, geliştirmeye odaklanır. Takımlar az sayıda kişiden oluşur.
Scrum takımı product owner, scrum master ve geliştirme takımından oluşur.
Product Owner: Geliştirilen ürünü yöneten, ürünün değerini maksimum noktasına çıkarmakla sorumlu kişidir. Takım ile bağlı olduğu yönetim arasında iletişimi sağlayan kişidir ancak takımın yöneticisi değildir.
Scrum Master: Hem takıma hem ürün sahibine hem de organizasyona hizmet eden liderdir. Takımın agile felsefeyi anlamasını ve kavramasını sağlar, yüksek değerli ürün geliştirmesinde ve takım önündeki engelleri kaldırma konusunda koçluk eder.
Development Team: Test mühendisi, geliştirici ve iş analistinden oluşan takımdır. Ürünün geliştirilmesinden sorumlu kişilerdir. Çapraz işlevsellikle çalışan kişilerden oluşur. Ürünün kalitesi, sorumluluğu tüm geliştirme takımına aittir.
Scrum süreçlerde planlama “sprint”lere bölünerek yapılır. Sprint; süresi 1 ay ya da daha kısa olan proje geliştirme döngüleridir. Sprint içerisinde ürünün kalitesine odaklanılır, amaç sadece çalışan bir ürün teslim etmek değildir. Sprintlerin süreleri sabittir, bir sprint bitince diğeri başlar.
Her sprint içerisinde yapılan belirli toplantılar aşağıdaki gibidir;
Daily Scrum: Her gün yapılarak gün içerisinde yapılması hedeflenen görevlerle ilgili paylaşımlar yapılır. Gün sonunda hedeflenen görevlerin bitmiş olması beklenir. Bu şekilde sprint sonunda hedeflenen ürün geliştirmesi sağlanmış olur.
Sprint Review: Her sprint bitişinde bir sprint değerlendirme yapılarak hangi görevlerin tamamlandığı, hangi görevlerde neden problem yaşandığı takım içinde paylaşılır.
Sprint Planning: Yapılacak görevler ve bitiş zamanları takıma uygun şekilde önceden belirlenir. Sprint planlama içinde product backlog ve sprint backlog bulunur. Product backlog ürüne dahil her gereksinimi içerirken, sprint backlog sadece o sprintte çalışılacak kısımdır.
Sprint Retrospective: Sprint planlamadan sonra her sprint bitişinde bir retrospektif toplantısı yapılır. Retrospektifte amaç takımı ve takım çalışmasını iyileştirmektir. Retrospektifte ayrıca takımdakilerin çalışmasını daha eğlenceli hale getirmek için çeşitli etkinlikler de yapılır, takım üyeleri birbirlerine önerilerde bulunur.
Kanban
Proje süreçlerini görselliğe dayalı şekilde ilerleten bir yöntemdir. (Scrum metodolojiyle farklılıklarından biri de görevlerin Kanban Board aracılığıyla takip edilmesidir.) Kanbanda görev yükü takımdaki kişilerin yoğunluğuna göre esnetilebilir. Kanbanda tanımlı rol dağılımları bulunmamaktadır, ancak bu değiştirilebilir bir durumdur. Ürünün geliştirilmesinden tüm takım sorumludur. Takım kendi kendini koordine edebilen kişilerden oluşur.
Kanban metodolojide süreç yukarda da bahsettiğimiz gibi bir Kanban Board(Kanban Tahtası) aracılığıyla ilerler. Ofiste ortamlarında gerçekten bir tahta üzerinde iş akışları görebiliriz, ancak çoğunlukla JIRA gibi online araçlar üzerinden iş takibi yapılır. Planlamalar aşağıdaki şekilde yapılır;
To Do: Burada yapılacak görevler listelenir. Bu listeleme görevler küçük modüllere ayrılır ve hangisi için ne kadar zamana ihtiyaç duyulduğu önceden belirlenir.
In Progress: Geliştirme aşamasında olan görevler burada listelenir.
Test: Geliştirmesi tamamlanan, test edilebilir görevler burada listelenir. Geliştirme bittikten sonra ürünün test edilmesi için ortam stabilizasyonu yapılmalıdır. Ayrıca test için gerekli datalar hazır olmalıdır. Aksi takdirde testler gecikecek ve ürünün kullanıcıya tesliminde gecikmeler oluşacaktır.
Done: Geliştirmeleri ve testleri başarılı şekilde tamamlanmış görevler listelenir. Bu noktadan sonra, geliştirilen ürün kullanıcıya teslim edilmeye hazırdır.
WATERFALL MODEL
Geleneksel yazılım test süreçlerinde en yaygın olanı waterfall süreçlerdir. Waterfall süreçlerde başlangıç ve bitiş zamanları önceden belirlenir ve değiştirilemez. Geliştirme ürünün bir parçasına değil tamamına uygulanır. Kullanıcı sürecin başında istediği ürün geliştirmesini iletir ve sürecin sonunda çıktıyı teslim alır, süreç içerisine dahil edilmez. Waterfall işleyen süreçler doküman üzerinden ilerler, bu çalışma projelerin sonraki fazlarında kolaylık sağlamaktadır. Proje yönetimi Agile modellemeye göre daha kolaydır.
Herkesin belirli bir görev tanımı vardır ve bunun dışına çıkılamaz. Rol dağılımı aşağıdaki gibidir;
Project Manager: Projenin hedeflerinden ve nasıl yürütüleceğinden sorumludur. Projeyi ve sürecin ilerleyişini aktif olarak takip ederek bilgi akışını sağlar. Ekibin önündeki engelleri kaldırır.
Analyst: Kullanıcı ile ürünü geliştiren takım arasında köprü görevi gören kişidir. İstenilen ürün geliştirmesinin analizini yapar, gerekli dokümanları hazırlar ve diğer ekiplere iletir.
Developer: Belirtilen gereksinimlere göre ürünün tasarımı ve geliştirmesini yaparlar. Geliştirme yapılırken proje kısıtlamalarını, ne kadar zaman gerektiğini göz önünde bulundurarak ürün için en iyi tasarım seçilir.
Tester: Ürünün geliştirmesi tamamlandıktan sonra belirtilen gereksinimlere göre ürünü ve ürünün kalitesini test eden kişidir. Ürünü kullanıcının gözünden test eder. Üründe bulunan hataları geliştirici ekibe iletir, sonrasında çözümlendiği belirtilen hatalı kısımları tekrar kontrol eder. Böylece ürünün kullanıcı önüne sağlıklı şekilde çıkmasını sağlar.
Waterfall modellemede süreç aşağıdaki şekilde ilerler;
Planning: İlk önce planlama yapılır. Projenin amacı, çıktısı, hangi aşamanın ne kadar sürede tamamlanacağı belirlenir.
Analysis: Planlama tamamlandıktan sonra projenin analizi yapılır. Projenin detayları araştırılarak ihtiyaçları belirlenir.
Design and Development: Projenin tasarımı yapılır. Ürünün mimarisi belirlenerek projeye en uygun şekilde tasarımı belirlenir. Ardından yapılan tasarıma uygun şekilde kodlama yapılır.
Test: Geliştirmenin tamamlanmasının ardından ürünün beklenilen şekilde, başarılı olarak çalışıp çalışmadığı kontrol edilir. Bu aşama yapılan geliştirmeye de bağlı olarak birden fazla test yapılmasını gerektirebilir. Birim testi, regresyon testi, entegrasyon testleri gibi.
Deployment and Maintenance: Ürünün testleri başarılı şekilde tamamlandıktan sonra kullanıma açılır. Bu adımda teslimden sonra da ürünün kontrollerine devam edilmeli, canlı ortamda da problemler hızla tespit edilip çözüme kavuşturulmalıdır.
KAYNAKLAR
Scrum Kılavuzu — Ken Schwaber ve Jeff Sutherland
https://softwarehut.com/blog/it-project-management/waterfall-101
