Waterfall metodolojisinden sonra Agile (Çevik) metodolojisi hayatımıza girdiğinden beri yazılım geliştirme süreçlerinde değişiklikler yaşanmaktadır.
Temel analiz süreçleri açısından Agile süreçler ve Waterfall süreçler çok farklılık göstermez. Her iki süreçte aşağıdaki yöntemleri takip eder;
Ön Analiz (Bilgi Toplama)
Süreç Analizi (As-is)
İhtiyaç Analizi& Detaylandırma
Süreç Tasarımı (Yeni tasarım)
Waterfall ve Agile süreçler arasındaki fark, analiz yapılırken müşterinin taleplerinin her an değişebilmesi veya gelişebilmesi ihtimaline bağlı olarak, analizin tek bir parça halinde değil küçük parçalar halinde yapılmasıdır. SDLC (Software Development Life Cycle) süreci de buna bağlı olarak küçük parçalar halinde yürütülür.
Örneğin, beş farklı modüle sahip bir ürünün analizini bir bütün olarak yapmak yerine, modülleri tek tek ele almak hem müşterinin değişen ihtiyaçlarını ürüne yansıtmayı hemde etki analizini daha iyi yapabilmeyi sağlar. Bunun yanısıra müşteriye küçük küçük çıktılar sunmak hem müşteriyi memnun ededecektir hemde zaman planlamanızı daha iyi yapmanızı sağlayacaktır.
Agile süreçlerde iş analisti ve Product Owner farkını bilmek gerekir. Agile projelerde (Scrum metodolojisinde), Product Owner (Ürün Sahibi), Scrum Master ve Team (Takım) vardır. Product Owner (Ürün Sahibi ), esasında ürünü iyi bilen müşteriden biri olmalıdır (bazen bu iş birimi de olabilir) fakat Türkiye’de bu rol tam anlamıyla karşılanamadığı için iş analistleri müşteri desteğiyle bu rolü üstlenmektedir. Product Owner, üründen sorumlu, yapılacak geliştirmeler için Why (Business requirement) ve What (User requirement) sorularının cevabını müşteriyle birlikte verebilecek,bunları product backlog dokümanında kayıt altında tutup, yönetebilen kişidir. Scrum Master, Scrum’ın teori, pratiklerine hakim olan ve yönetebilen, takım içi iletişimi sağlayan, takımı etkileyen dış engellere çözüm bulabilen kişidir. Team (Takım) ise, yazılımcılar, analistler ve test uzmanları gibi kişilerden oluşur.
Agile manifestosunun 4 ilkesi aşağıdaki gibidir;
Süreçler ve araçlardan ziyade bireyler ve aralarındaki etkileşim
Sözleşme pazarlıklarından ziyade müşteri ile işbirliği
İş Analistlerini ilgilendiren ikinci maddeye gore; Agile, Waterfall gibi kapsamlı döküman yerine sonuç odaklıdır fakat bu Agile’in dökümantasyonu tamamen gereksiz bulduğu şeklinde algılanmamalıdır. İhtiyaçları yazmak, doküman üzerinde müşteri ile uzlaşmak gerekir. Agile süreçte esas olan Waterfall’daki gibi dokümanın nasıl yazılacağı değil, istenen ürünün beklenen özelliklerde teslim edebilmesidir. Hatta bazen iş birimi yada müşteriyle aynı ortamda çalışılmıyorsa, Waterfall’daki gibi Agile’da da detaylı döküman yazılması gerekebilir.
Agile süreçlerde (Scrum Metodolojisi baz alınmıştır) analiz yapılırken izlenen ana adımlar aşağıdaki gibidir;
İş analisti müşteri (iş işbirimi) ile ürün hakkında temel bilgileri toplar.
Üründen beklenen temel fonksiyonların detayları olmaksızın sadece ana fonksiyonları çıkarılır. (Product Backlog)
Ürün için belirlenen temel fonksiyonlar doğrultusunda Story’ler belirlenir.
Story öncelikleri belirlenir. (Önceliklendirme)
Önceliklendirilmiş story’lerden ilk iterasyonda(Iteration) ihtiyaç analizi yapılacak olanlar belirlenir (Sprint Backlog) ve analizine başlanır.
Storylere ait Kabul Kriterleri (Acceptence Criteria) belirlenir.
Tüm detayları ile hazırlanan Story’ler yazılım ile paylaşılır.
Yazılım iterasyon süresince iş analisti ile sürekli iletişim içinde kalarak doğru ilerlediğini teyit eder. Bu sırada iş analisti bir sonraki iterasyon story’lerinin analizini yürütür.
Iterasyon bittikten sonra yazılım, yapılan çalışmaları önce analiste iletir. Analist testler sonrasında kabul onayını verdikten sonra müşteri ile paylaşır.
Bu iterasyon sonunda yeniden önceliklendirme varsa yeni ihtiyaçlar için Change Request (CR) olarak Story’ler çıkarılır.
Süreç 4. adımdan tekrar ederek ürünün tamamlanmasına kadar bu şekilde ilerletilir.