Günümüz yazılım geliştirme ekiplerinin birçoğu geleneksel yazılım geliştirme metodolojisi Waterfall’ a ek olarak, kısa iterasyonlarla hızlı çözümler geliştirmeye imkan sağlayan Agile (Çevik) metodolojileri uygulamaya başladı.
Waterfall bir projede, iş analistinden beklenen proje başında ihtiyacı doğru bir şekilde anlayarak gereksinimleri tanımlaması ve analizini yapmasıdır. Konu Agile bir proje olduğunda ise akla; iş analistinin rolü nedir?, analiz dokümanı yazılmalı mı? ya da ne kadar detayda olmalı? gibi çok fazla soru gelmektedir.
Agile projelerde Product Owner, Scrum Master ve Team vardır ve Product Owner iş birimlerini temsil eden bir kişi olmalıdır. Fakat bu yaklaşımla yola çıkan bir çok IT organizasyonu, iş birimlerinden Product Owner rolü için yeterli destek alamadığı için tecrübeli iş analistlerini bu pozisyona getirmeye başladılar. Team dediğimizde ise içerisinde sadece yazılımcılar değil, gereksinimleri analiz etmesi amacıyla iş analistleri ve testler için test uzmanlarının da yer almakta olduğunu görüyoruz.
Product Owner olduğu halde neden iş analistlerine ihtiyaç duyuyoruz?
Product Owner dediğimiz kişi üründen sorumlu, yapılacak geliştirmeler için WHY (Business requirement) ve WHAT (User requirement) sorularının cevabını verebilecek yani ihtiyacı üst seviyede anlayarak şirket stratejilerine göre önceliklendirmesini yapabilecek olan kişidir. Agile söylemle Product Owner, geliştirilecek fonksiyonların ve özelliklerin yani geliştirme ihtiyaçlarının üst seviye detayda listelenip Product backlog dokümanında kayıt altında tutarak yönetmekle sorumlu olan kişidir. Agile, detaylı analiz ve dokümana gerek yok dese de Product backlog’da tutulan bu gereksinimler Waterfall’da alışık olduğumuz detayda olmadığı için çoğu zaman yazılımcılara aktarılırken detay analizi ihtiyacını beraberinde getirmektedir.
Detay analiz yapmak Agile Manifestosuna aykırı değil midir?
“Working software over comprehensive documentation”
Buna karar verirken dikkat edilmesi gereken en önemli nokta, gerçekten Agile uygularken iş birimleri ile ne kadar birlikte çalıştığınızdır. “Dokümantasyona gerek yok” demek için iş birimlerinizin geliştirme sırasında yazılımcılarınız ile birlikte oturup tüm detay gereksinimleri aktarmış olması gerekir. Böyle bir ortam sağlanmadığı sürece -ki bir çok organizasyonda iş birimlerinin bu derece dahil olması mümkün olmamaktadır- HOW sorusunun cevabı olan detay gereksinimlerinin (fonksiyonel ve fonksiyonel olmayan gereksinimler, iş kuralları) tanımlanması şart olmaktadır. Bu seviyede detay yoksa kullanıcı kabul testlerinde değişiklik taleplerinin gelmesi ,projelerin başarısız sonuçlanması kaçınılmazdır.
Agile ekiplerde çalışan iş analistlerinin “elicitation” dediğimiz gereksinim tanımlama sürecinde daha hızlı bir şekilde User Story, User Story Mapping gibi Agile analiz tekniklerini ve daha klasik olmasına rağmen hala çok etkili olan Use Case modelleme gibi analiz tekniklerini uygulayarak detay gereksinimleri tanımlaması gerekir. İyi bir iş analisti, analiz tekniklerini iyi bilmeli ve ‘A picture is worth, a thousand words’ sözünü hatırlayarak çok uzun analiz dokümanları yerine modelleme yaparak ihtiyacı görselleştirebilmelidir.
Waterfall’da proje yetişmezse zaman kazanmak amacı ile ilk kısılan süreç nasıl test aşaması ise, Agile projelerde de genellikle sıkışınca analiz süresi kısaltılır. İterasyonlar ne kadar kısa olursa olsun mimimum seviyede de olsa analiz yapmak sizi sonradan çıkabilecek değişiklik taleplerinden, kodda refactoring gibi sonradan zaman kaybedeceğiniz olumsuzluklardan korur. İş analistleri olarak Çevik yazılım geliştirebilmek için de şunu unutmamamız gerekir, amacımız mükemmel dokümanlar hazırlamak değil, ihtiyacı net bir şekilde anlayarak o ihtiyacı karşılayacak çözümleri üretebilmektir.
Lean İş Analizi Nedir?
Agile gibi, son dönemlerde popüler olan LEAN’de ise analiz süreçleri ile ilgili iki önemli prensip vardır; ‘Just Enough’ ve ‘Just in Time’. Lean der ki: iteratif yazılım geliştirirken sadece bulunduğun iterasyon için (Just in time) ve yeterli detay seviyesinde (Just Enough) – mükemmel detayda olmasına gerek yok! – analizler yapmalısınız. Lean’de iteratif geliştirmeyi destekler, ‘waste’ denilen boşa harcanan eforu minimize etmeye odaklanır.
Waterfall, Scrum, Agile…?
Günümüzde IT organizasyonlarında Waterfall, Agile, Scrum, Lean, Kanban, Scrumfall, Waterscrum gibi isimlerde metodolojiler duyabilirsiniz. Önemli olan metodolojinin adından çok sizin kurum kültürünüze ve ortamınıza uygun olması, kullanıcının ihtiyaçlarını doğru anlayarak ihtiyaca yönelik faydalı çözümler geliştirmenize destek olacak bir framework sunabilmesidir.
Hangi projelerde hangi tip metodolojiler kullanılması gerekir merak ediyorsanız size Business Analysis Methodology Book kitabını öneririz.