Agile (Çevik) İş Analizi’nin en temel özelliklerinden biri basit/hafif (lightweight) teknikler kullanmaktır. Agile geliştirmenin doğasında olan müşterilerle iş birliği, bireyler ve etkileşimleri, değişime açık ve hızlı implemente edebilirliği sağlamak için her tekniği kullanmak pek mümkün olmayabiliyor. Ama bu İş Analistleri’nin alternatif tekniklerden yararlanmayacağı anlamına da gelmiyor. Bu yüzden her Agile Analist, Agile yöntemlere uygun İş Analizi Teknikleri’ni bilmeli ve bunları projelerinde uygulamalıdır.

Peki bu teknikler nelerdir?

Retrospektifler (Retrospectives)

Retrospektif, Agile ekiplerinin her Sprint sonunda yaptıkları bir değerlendirme toplantısıdır. Geriye dönük yapılan bu değerlendirme, ileriye dönük sürekli bir iyilişme ortamı sağlar. Bu toplantılar Lessons Learned (Öğrenilmiş Dersler) olarak da değerlendirilebilir. Ekip, geliştirme sürecinin nasıl gittiğini, neyin doğru, neyin yanlış yapıldığını tartışarak, bir sonrası Sprint’i daha iyiye taşımayı hedefler.

İş Analistleri, Agile ekibi içerisinde Scrum Master olarak rol alabilir. Bu roldeki bir iş analisti retrospektif toplantılarını organize ederek ekibi bir araya getirmeli ve toplantı sırasında ekibin ve yapılan işin istenilen hedefe ulaşmasında yardımcı olmalıdır.

Retrospektif sonunda, bir sonraki Sprint’te uygulanacak kararlar belirlenmeli ve listesi aşağıdaki gibi başlıklar altında gösterilmelidir.

• Start Doing (Yapmaya Başla)
• Stop Doing (Yapma)
• Continue Doing (Yapmaya Devam Et)

Persona

Ürünü geliştirmek ilk önce onu kullanacak kişileri ve onların ihtiyaçlarını belirlemek ile başlar. Kullanıcı türleri veya rolleri belirlerken yapılan en büyük hata, tek tip kullanıcı sınıfı oluşturarak onlara sadece “Kullanıcı (User)” perspektifinden bakmaktır. Oysaki farklı özellikte, konumda veya yetkideki kişiler aynı uygulamayı kullanabilir. Önemli olan geliştirilecek ürünün farklı kullanıcı tarafından da kullanılabilir olmasıdır.

Personalar, gerçek ve potansiyel müşterileriniz arasında çeşitli ihtiyaçları, hedefleri ve gözlenen davranış kalıplarını kapsayan kurgusal, genelleştirilmiş karakterlerdir. Müşterilerinizi daha iyi anlamanıza yardımcı olurlar.

Backlog Planlama ve Yönetimi

Backlog, ekibin üzerinde çalışması gereken her şeyin üst düzey (high-level) bir listesidir. Agile ekibin hangi faaliyetlerle meşgul olacağını belirler ve bu faaliyetlerin hangi sıraya göre yapılacağını gösterir. Gereksinimlerin listelendiği bu listedeki her madde,  gerçekleştirilmek üzere bir sonraki sprint öncesinde tanımlanmalı ve önceliklendirilmesini sağlamak için sürekli olarak yönetilmelidir.

Agile uygulamalar boyunca, backlog düzeni farklı formlarda olabilir. Bu, her ekibin farklı iş yapma şeklinden kaynaklanır. Her ekibin yaptığı iş ve onu uygulama biçimi farklıdır. Bazı ekiplerde backlog, sadece ürün gereksinimlerini içerirken, bazı ekipler gereksinimleri küçük öykülere (user story) çevirerek detaylandırabilir. Planlama sürecindeki bir ekibin backlog’unda riskler ve süreç iyilleştirme maddeleri olabilir veya test sürecindeki bir ekibin backlog listesi hata maddeleri içerebilir. Burada önemli olan kullanılacak olan tekniğin, ekibin iş yapma biçimine göre uyarlanmasıdır.

Workshop

Workshoplar, birden çok paydaş içeren karmaşık projelerde, gereksinimleri ortaya çıkarmanın en hızlı ve düşük maliyetli tekniklerden biridir. Paydaşların fazla olması ve projenin karmaşıklığı bu tekniğin uygulanmasını zorlaştıran etkenlerden olmasına karşılık, iyi bir planlama ile beklenen fayda sağlanmalıdır.

İyi planlanmış bir Workshop aktivitesi, İş Analistinin çakışan iş gereksinimlerini çözmesine, paydaş analizini gerçekleştirmesine ve gereksinimlerin herkesce kabul edildiği bilgisini tek seferde elde etmesine olanak sağlar.

IIBA BABOK®’a göre Workshop aktivitesi şunlar için gereklidir:

• Proje kapsamını belirlemek
• Gereksinimleri çıkartmak (Elicitation)
• Gereksinimlerin önceliklendirmek (Requirements Prioritization)

MoSCoW

Agile geliştirmenin diğer proje geliştirme yöntemlerinden en büyük farkı MVP üzerine kurulu olmasıdır. Nedir bu MVP? “Minimum Viable Product” yani son kullanıcı için değerli olan en yalın ürün. Agile geliştirmede her Sprint için MVP’yi bularak releaseler almak ve böylece iterative çalışmak birçok faydayı da beraberinde getiriyor.

MVP için geçerli olan gereksinimler ancak proje gereksinimlerinin önceliklendirilmesi ile bulunabilir. Bu önceliklendirme için en çok bilinen tekniklerden biri de MoSCoW yöntemidir. Bu teknikte ürün özellikleri işlevsellik ve gerekliliğe göre 4 farklı kategoride incelendir.

Must – Üründe kesinlikle olması gereken özellikler (Bu kategoriye alınan ürün özellikler MVP için belirlenmiş özelliklerdir)

Should – Ürün için kritik değil ama önemli olan özellikler

Could – Ürünü çekici kılan özellikler

Won’t – İhmal edilebilir özellikler

User Story (Kullanıcı Hikayesi)

User Story, Agile proje ekipleri için temel geliştirme kalemlerinden biridir. Bir kullanıcı hikayesi, bir gereksinimin üst düzey (high level) bir tanımlamasıdır. Geliştiricilerin onu uygulamak için makul bir tahmin yapabilmesi için yeterli bilgiyi içermelidir.

User Story, hikayenin yarar sağladığı kullanıcı ve hikayenin doğru bir şekilde uygulandığını belirten kabul kriterleri (Acceptance Criteria) birlikte ifade edilerek yazılır. Genelde kullanılan standatlaşmış bir şablonu vardır.

User Story Mapping

User Story Mapping, ürün gereksinimlerinin belirtildiği User Story’lerin, birbirleri ile ilişkilerini bir bütün içinde gösterildiği haritalardır. Ürün gereksinimlerinin izlenebilirliğini sağlamak ve tüm sistemin işlevselliğini tek bakışta görüntülemek için kullanılan bir araçtır. Ayrıca release planlama oturumları bu harita üzerinde çalışılarak yaplabilir.

Story Mapping, gereksinim toplanmasının top-down (yukarıdan aşağıya) yaklaşımıdır. Treeview (ağaç) yapısına sahiptir. Harita kapsamlı bir vizyonla başlar. Sonrasında ise sırasıyla edefler (goals), aktiviteler (activities), görevler (tasks) ve en son kullanıcı hikayeleri (user stories) belirlenir.

Goals > Activities > Tasks > User Stories

İlkim Dilara Kadakaloğlu