Agile Business Analyst Roles

Agile Business Analist Roles and Responsibility diagram

Agile İş Analistinin Rol ve Sorumlulukları şeması

Bu roller aynı zamanda waterfall süreçlerde analiz yapanlar için de geçerlidir ama agile süreçlerde bazı fazlalıklar vardır. Umarım faydalı olur. 

Business Analyst Roles

Acceptance Criteria-Senaryo

-----------------------------

Analistlerin en büyük problemlerinden biri de aynı dil üzerinde henüz bilimsel bir uzlaşının tam olarak yerleşmemiş olmasıdır. Bu anlamda yazılım ilke ve prensiplerine yetişmemiz ve ortak dil konusunda aynı şeyleri konuşuyor olmamız gereklidir.

-----------------------------
Bu bağlamda en sık karıştırılan, karışıtılmadıında da doğru tanımlanmayan iki kavram vardır. Acceptance Criteria  ve Scenario (Senaryo).

-----------------------------

Burada ortak dil adına uluslararası kabul görmüş isimleri kullanmakta da fayda vardır. Böylece literatür tarama ve karşılıklı iletişimde de aynı dil üzerinden gidilir. Bu yüzden Acceptance Criteria kavramını türkçeleştirmedim. Yoksa bugün ingilizce bir kavramı çeviremeyecek kadar ingilizce bilmeyen analist olduğunu pek sanmıyorum. Bir kavramı çevirmek için ingilizcenin akıcı olması gerekmez.

-----------------------------

Önce kavramları kısaca tanımlayalım. Özetle formülize edecek olursak şöyle tanımlarız.

Acceptance Criteria "should be" der. Emreder. Requirement'in bir parçasıdır. Bir ihtiyacı karşılamak için en küçük kural parçasıdır. Adından da anlaşılacağı üzere bir ihtiyacı karşılamak için kabul kriterimizdir. AC tam olursa kabul edilir. AC tam olmazsa kabul edilmez ve testten kalır.
Senaryo Acceptance criteria'yı dinler ve emrin yerine gelip gelmediğini test eder. Test için birkaç farklı yol kullanabilir. Senaryo genellikle aşağıdaki şekilde tanımlanır.

Given: Senaryonun ön şartı
When: Senaryonun aksiyonu
Then: Senrayonun sonucu


Örnek verelim. Acceptance Criteria'yı AC olarak yazalım bundan sonra.

AC = Log out butonuna basıldığında kullanıcı sistemden çıkmalıdır.

AC gayet açık. buna 2 senaryo yazalım.

Senaryo1 = Müşteri login et. (given) Log out butonuna bas. (when) Müşteri hesaplarım menüsünü görmemelidir. (then)

Senaryo2 =  Ekrandaki linki kopyala (given), müşteriyi logout et (given). Linki browser adress bara yapıştır (when). Müşteri login ekranı çıkmalıdır. (Then)

Bu örneği incelediğimizde bir AC için birden fazla senaryo ihtiyacı olabileceğini görüyoruz. Bu da şöyle bir basit kural karşımıza çıkarır. Senaryolar AC'den türer ve her zaman senaryo sayısı AC'den büyük ya da eşittir.

Örnekteki diğer bir özellik ise bir senaryo içerisinde given, when ve then kalıbı her zaman kullanılabilir. Ve her biri birden fazla sayıda olabilir. Senaryo2'de 1 given 2 when ve 1 then vardır. Bu sayılar da ihtiyaca göre farklılık gösterir.

Rol ve Sorumluluk açısından da iki işin sahibi farklıdır. AC'ler Story'nin parçalarıdır. AC'ler Analist veya Product Owner tarafından belirlenir. Senaryo ise Test Uzmanı (QA) tarafından belirlenir ve her test adımında kullanılabilir. (Fonksiyonel Test, UAT veya Sign-off gibi testler kastediliyor)

Ve önemli bir NOT: Test uzmanının olmadığı yerde Analist Test uzmanı görevini yapar. Yapmalı mı? Elbette ki hayır. Senaryo çıkarmak ve test için gerekli sabır ve çok yönlülük apayrı bir yetkinlik gerektirir ki 1 analist ve 3 yazılımcının olduğu her yerde 1 Test uzmanına ihtiyaç vardır.

İHTİYAÇLARIN ÖNCELİKLENDİRİLMESİ: LEGO TIME

İHTİYAÇLARIN ÖNCELİKLENDİRİLMESİ: LEGO TIME

Kapsamlı projelerde hangi ihtiyaçların önce yapılacağı çok önemlidir. Şöyle düşünebiliriz. 300 parçalık bir lego setimiz var ve bu setten bir ev yapmak istiyorsanız sivri parçaları çatı yapmak için sona bırakırsınız. Pencere ve kapı şeklindeki parçaları en başta kullanırsanız evin ortalarına geldiğinizde yerleştirecek kapı bulamazsınız.  Bu yüzden bu parçaları evin  temelini oluşturduktan sonra kullanırsınız.  Bir projenin kapsamı da belli olduktan sonra ihtiyaç listesi (requirements) üzerinden bir önceliklendirme yapılmalı ve bu öneliklendirmeye göre projeye start verilmelidir. Projeye başlandığında özellikle en yüksek öncelikli ihtiyaçların hangileri olduğu belli olmalıdır.

Peki, nasıl önceliklendiririz?  Agile ve Sürekli teslim (Continious Delivery) metodolojileri uygulanan yerlerde bu soru daha da önemlidir. Çünkü belirli dönemlerde ürünün biten kısımları live ortama alınabildiğinden müşteri için öncelikli olan fonksiyonlar belirlenmelidir. Diğer metodlarda da teknik mimarinin doğru kurulması ve sonraki ihtiyaçların daha hızlı deliver edilmesi açısından doğru önceliklendirme yapılmalıdır. Önceliklendirme için birçok teknik olmakla beraber bana göre en efektif yöntemler aşağıdakilerdir.

MoSCoW: Bu yöntemde herbir requirement önemine göre Must, Should, Could, Would modalları ile belirlenir. Buradaki önem, işi isteyen kişinin verdiği önem derecesidir. Teknik ve mimari öncelikler ikinci plandadır. Must olandan başlanır. Should olanlar ardından bitirilir. Could olanlar kaynak ve zaman sorunu yoksa en sonda tamamlanır. Would olanlar yapılmaz fakat bu fonksiyonların ileride olacağı varsayılarak projenin teknik ve iş mimarisi kurgulanır. 

Must Have	Kritik task. Workaroundu olmayan ve proje için kritik task. Yapılmadığında proje tamamlanmış sayılmaz.
Should Have	Yapılması oldukça önemli olan konu. Yapılmadığında proje başarılı sayılmaz.
Could Have	Yapılması istenen fakat kritik olmayan tasklar. Yapılmadığında müşteri memnuniyeti düşebilir. Proje tamamlanmış ve başarılı sayılır.
Would Have (Won’t)	Yapılması planlanan fakat bu aşamada projenin dışına atılan tasklar. Bir anlamda bu faz dışındaki maddeler

HI/LO Etki-Zorluk Düzlemi: Buna Affinity Chart da diyenler vardır. Bu yöntem XY düzleminde Etki ve Zorluk düzeyine göre tüm ihtiyaçların gruplanması esasına dayanır.  Etki iş biriminin önceliği iken, Zorluk ise yazılım sürecinin zorluk derecesini ifade eder. Projelerin kritik parçalarının müşteriye gösterilmesi gereken projelerde oldukça etkin bir yöntemdir.  Düzlemde Yeşil bölge en başta Kırmızı bölge en sonda yapılır. Diğerleri ise tamamen müşterinin isteğine göre önceliklendirilir.

HLO Düzleminde Önceliklendirme

Bu iki yöntem sonunda ortaya aşağıdaki gayet basit bir sıralama listesi ortaya çıkacaktır. Önemli olan bu listenin her an müşteriye göre yeniden düzenlenmesidir. Bir projede belki de en güncel tutulması gereken bilgi “ÖNCELİK” bilgisidir.

Öyle projeler olacaktır ki, müşteri en başta gördüğü ihtiyaçlara göre tüm projeyi şekillendirecektir.

Sonuç olarak; 

ÖNCELİKLENDİRME EN ÖNEMLİ ÖNCELİĞİMİZ ARASINDA OLMALIDIR