Çevik Yöntemlerde İş Analizi

Çevik (agile) yöntemleri çoğumuz duymuşuzdur.  BT'de yaygın olan çevik yöntemler (ilgili makale: Çevik Yöntemleri Uygulayabilmek) ile ilgili hemen aklımıza hızlı şekilde kodlama gelir. Hep yazılım tarafındaki katkısı ve hızı düşünülür. Aslında çevik yöntemlere bu hızı kazandıran özelliklerden birisi hiç şüphesiz çevik iş analizidir. Peki çevik yöntemler içinde iş analizi nasıl yapılır? Bu sorunun yanıtını arayacağız.

Çevik manifestoda karmaşık dokümantasyon, uzun süreçler, müşteri ile sözleşme pazarlıkları ve katı planlar kabul görmüyor. Bunun yerine çalışan yazılım, etkileşim, müşteri ile işbirliği ve değişime ayak uydurabilme ön plana çıkarılıyor. Bunun karşılığını iş analizinde bulmak mümkün. Birçok dokümandan oluşan kimi zaman yüzlerce sayfayı bulan ve çoğu zaman da okunmayan dokümanlar yerine "Kullanıcı Hikayesi" (User Story) kavramı öne çıkıyor. Kullanıcı hikayesi ise müşteri veya kullanıcı için değerli olan özellik veya kabiliyet olarak özetlenebilir. Her bir özelliği/kabiliyeti ayrı ayrı olmak üzere kartlara yazarak bunların hem planlamada, hem detayları hatırlamada hem de test aşamasında kullanılması sağlanır.


Örnekler:

• Kullanıcı şifre ve kullanıcı adı ile sisteme giriş yapar.
• Kullanıcı x ekranından y verisini girer.
• Kullanıcı z verisini bilgisayarına kaydeder.
• ...

Teknik gereksinimler, altyapı ihtiyaçları gibi müşteriye anlamlı olmayan konular kullanıcı hikayelerinde yer almaz. "Uygulama Java'da yazılır." veya "Spring çatısı kullanılır" gibi bilgiler müşteri için anlamlı değildir.

Bir diğer konu da çok genel ve yüzeysel kullanıcı hikayelerinin yanıltıcı olabileceğidir, örneğin "Kullanıcı sisteme girip işlem yapabilir" gibi. Burada kullanıcının ne tür işlemler yapacağı, neleri yapamayacağı gibi konular havada kalmaktadır. Müşteri için anlamlı olan tüm kabiliyetlerin, teker teker yazılması en ideal yoldur. Yazılanların mümkün olduğu kadar atomik olması, planlamayı ve test işlerini kolaylaştıracaktır. Kullanıcı hikayesinin bağımsız, tahmin edilebilir ve test edilebilir olması da hem planlamayı hem de testi kolaylaştıracaktır. Eğer uygulamayı kullanacak birden fazla tipte kullanıcı varsa bu kullanıcılara göre tasniflenerek kullanıcı hikayesi yazılması en sağlıklısı olacaktır.

Kullanıcı hikayesini, müşteri veya müşteri adına ekipte yer alan iş analisti yazabilir. Yazılanların önceliklendirilmesi de yine müşteri veya onun temsilcisi tarafından yapılır. Her bir kullanıcı hikayesinin maliyeti (story points) işin büyüklüğü ve karmaşıklığı da dikkate alınarak yazılımcılar tarafından belirlenir. Sürüm ve iterasyon aşamalarında bu maliyetler, öncelikler ve yazılım hızı (iterasyon başına düşen ortalama story points) dikkate alınarak planlama yapılır. İterasyona giren kullanıcı hikayelerine dokunulmaz, dışında kalanlarla ilgili müşteri öncelik değiştirebilir veya yenilerini ekleyebilir.

İterasyon boyunca çalışılan kullanıcı hikayeleri için kabul testleri (acceptance testing) senaryoları kartların arkalarına yazılabilir. Bu şekilde istenen neydi, nasıl test edilecek bilgileri tek yerde toplanır. Tabi test için çeşitli araçlar kullanılan kurumlarda araca da girişi yapılabilir.

İterasyonla testi tamamlanıp kullanıma sunulan maddeler iş listesinden (çevik yöntemlerde ingilizcesi burndown chart, türkçe bilişim sözlüklerinde tam karşılığı bulunmuyor) düşülür. Proje boyunda yeni talepler de gelebileceği düşünüldüğünde genel trendi azalan ancak zaman zaman da yeni taleplerle artan bir grafik ortaya çıkar.

Sonuç olarak çevik yöntemlerde iş analizi önemini korur. Buradaki amaç uzun dokümanlar yerine ihtiyaçları basit, anlaşılır, kodlanabilir ve test edilebilir kullanıcı hikayelerine dönüştürmek ve bunları etkin şekilde kullanabilmektir.