Çevik projelerde iş analizi: analiz sprint içinde nasıl yapılır?

Çevik ortamda iş analizi neden farklıdır?

Geleneksel projede gereksinimler başta toplanır, dokümana yazılır ve onaylanır; uygulama bundan sonra başlar. Çevik ortamda belirsizlik kabul edilir: ihtiyacın tamamı baştan bilinmez, kullanıcı geri bildirimi geldikçe öğrenilir. Bu yüzden analiz tek bir aşama olmaktan çıkar ve ürün geliştirme boyunca devam eder.

Bu, analizin azaldığı anlamına gelmez. Tersine, daha sık ve daha küçük parçalarla yapılır. Ekip her sprint'te küçük, tamamlanabilir ve kullanıcıya değer taşıyan bir parçayı hedefler; bu parçanın doğru tanımlanması için analiz becerisi sürekli gerekir.

BABOK'un çevik bakış açısı da bu ayrımı vurgular: teknikler aynıdır, ancak ne zaman ve ne ayrıntıda kullanıldığı değişir. Süreç modelleme, kullanıcı hikayeleri, önceliklendirme ve kabul kriteri yazımı çevik ekiplerde de iş analizinin temel araçlarıdır.

Ayrıntı seviyesi tam zamanında artar

Çevik analizin temel ilkelerinden biri, ayrıntıyı ihtiyaç anına kadar ertelemektir. Ürün vizyonu ve hedefleri nettir; yol haritası kabadır; yaklaşan sprint'lerin adayları daha ayrıntılıdır; sprint'e alınan öğeler ise ekibin hemen çalışmaya başlayabileceği netliktedir.

Ayrıntıyı erken yazmak iki şekilde zarar verir: önceliklerin değişmesi halinde emek boşa gider, ve öğrenilenler plana yansımaz. Çok geç yazmak ise ekibi belirsizlikle çalışmaya iter. Dengeyi sağlayan, sürekli yapılan backlog iyileştirmedir.

Bir öğe sprint planlamasına gelmeden önce anlaşılır olmalıdır: kimin için, neden, hangi koşulda tamamlanmış sayılır, bağımlılığı var mı ve ekibin yapabileceği kadar küçük mü?

Sprint ritmi içinde iş analisti ne yapar?

Scrum Rehberi'ndeki sorumluluklar ürün sahibi, geliştiriciler ve Scrum Master ile sınırlıdır; iş analisti ayrı bir Scrum rolü değildir. Pratikte birçok ekipte iş analizi yetkinliği ya ürün sahibine ya da ekibe katılan bir iş analistine aittir. Bu kişi ürün sahibine ve geliştiricilere analiz desteği verir.

Sprint öncesinde ve sprint boyunca sürekli backlog iyileştirme yapılır: paydaşlarla konuşulur, ihtiyaçlar hikayelere çevrilir, kabul kriterleri yazılır, bağımlılıklar ve riskler belirlenir, büyük öğeler bölünür. Sprint planlamasında ekip, öğenin kapsamını ve kabul kriterlerini birlikte gözden geçirir; sorular burada yanıtlanır.

Sprint sırasında analiz desteği devam eder. Geliştiriciler soru sorar, yeni bir istisna ortaya çıkar, kabul kriterinin yorumu netleştirilir. Sprint incelemesinde paydaşlardan gelen geri bildirim yeni backlog öğelerine dönüşür. Retrospektifte ise analiz sürecinin kendisi iyileştirilir: hikayeler yeterince net miydi, kabul kriterleri test edilebilir miydi?

Kullanım araçları: hikaye, kabul kriteri, hikaye haritası

Kullanıcı hikayesi, bir ihtiyacı kullanıcı bakışıyla ve gerekçesiyle ifade eder. "Satış yöneticisi olarak ekibimin aylık satışını görmek istiyorum, çünkü hedef sapmalarına zamanında müdahale etmek istiyorum" gibi. Hikaye tek başına yetmez; kabul kriteri, hikayenin tamamlandığını gösteren koşulları yazar ve ekibin ortak anlayışını sağlar.

Hikaye haritası, hikayeleri kullanıcı yolculuğu boyunca yatay, önceliğe göre dikey dizerek bütünü görünür kılar. İlk sürümde hangi dilimin yeterli olduğunu belirlemeye yardım eder. Büyük hikayeler küçük, dikey dilimlere bölünür; her dilim kullanıcıya uçtan uca bir değer taşır.

Önceliklendirme, değer, risk ve bağımlılık birlikte değerlendirilerek ürün sahibiyle yapılır. Analist verileri ve seçenekleri hazırlar; sıralama kararı ürün sahibindedir.

Sık yapılan hatalar

İlk hata, çevik çalışmayı doküman yazmamak diye anlamaktır. Dokümantasyon azdır ama gereklidir; kararlar, kabul kriterleri ve izlenebilirlik kayıtları tutulmalıdır.

İkinci hata, analizi ekipten ayrı yürütmektir. Analist tek başına ayrıntılı spesifikasyon yazıp ekibe teslim ederse, mini şelale kurulur; geliştiriciler soru soramaz ve öğrenme gecikir.

Üçüncü hata, hikayeyi çözüm tanımı yapmaktır. "Açılır liste ekle" gibi yazılan bir iş, ihtiyacı değil çözümü söyler.

Dördüncü hata, kabul kriterlerini sprint'in sonunda yazmaktır. Kriter başta bilinmezse tamamlanma tartışması sprint incelemesine kalır.

Örnek: iade talebi hikayesini sprint'e hazırlamak

Kurgusal bir örnek: bir çevrim içi mağaza için "Müşteri olarak teslim aldığım ürünü iade talebi oluşturarak geri göndermek istiyorum, çünkü ürün beklentimi karşılamadı" hikayesi backlog'a girmiştir. Hikaye bu haliyle bir sprint'e sığmayacak kadar geniştir; ayrıca içinde cevaplanmamış sorular vardır: kısmi iade mümkün mü, iade süresi nedir, ürün nedeni zorunlu mu, kargo etiketini kim üretir? Analist bu soruları ürün sahibi, müşteri hizmetleri ve depoyla konuşarak netleştirir. İade süresi gibi iş kuralları, kurumdan teyit edilmeden varsayılmaz.

Sonra hikaye dikey dilimlere bölünür: önce teslim edilmiş siparişten tam iade talebi oluşturma, sonra iade nedeni seçimi, sonra kargo etiketi, en son durum takibi. Her dilim tek başına kullanıcıya değer taşır. İlk dilim için kabul kriterleri şöyle yazılır:

• Teslim edilmiş bir sipariş için iade talebi oluşturulabilir.
• Teslim edilmemiş siparişte iade seçeneği görünmez.
• İade nedeni seçilmeden talep gönderilemez.
• Talep oluşunca müşteri bir onay mesajı görür.

Sprint planlamasında ekip bu dilimi gözden geçirir; geliştiriciler "iade süresi dolmuşsa ne olacak" diye sorar ve bu soru yeni bir kabul kriterine ya da ayrı bir backlog öğesine dönüşür. Sorunun sprint'in ortasında değil planlamada sorulması, hazırlığın işe yaradığını gösterir.

Hikayeyi bölme yolları ve hazır olma ölçütü

Büyük bir öğeyi küçültmek için birkaç yol vardır ve her birinde kural aynıdır: dilim yatay bir teknik katman değil, kullanıcıya uçtan uca değer veren dikey bir parça olmalıdır. Sık kullanılan bölme yolları şunlardır:

• İş akışı adımına göre: önce akışın en kısa ve en sık kullanılan yolu, sonra istisnalar
• İş kuralına göre: önce temel kural, sonra kuralın özel durumları
• Kullanıcı türüne göre: önce en yaygın kullanıcı, sonra diğer roller
• Veri türüne göre: önce en yaygın veri biçimi, sonra diğerleri
• Basit ve karmaşık ayrımına göre: önce basit sürüm, sonra gelişmişi

Bir öğenin sprint'e alınmaya hazır olup olmadığını denetlemek için çoğu ekip kendi hazır olma ölçütünü yazar. Bu, Scrum Rehberi'nin zorunlu kıldığı bir araç değildir; ekibin kendi çalışma düzenini kolaylaştıran bir uzlaşmadır. İyi bir hikaye genellikle bağımsız, müzakereye açık, değerli, kestirilebilir, küçük ve test edilebilir olarak tarif edilir. Bu sıfatlar bir kontrol aracı gibi kullanılabilir: hikaye test edilemiyorsa kabul kriteri eksiktir, kestirilemiyorsa içinde cevapsız soru vardır, küçük değilse bölünmelidir.

Ölçüt katı bir kapıya dönüşmemelidir. Amaç, sprint planlamasında öğeyi baştan anlatmak yerine ekibin zamanını gerçek soruları çözmeye ayırmasıdır.

Bu beceriyi Mindset programlarında nerede çalışırsınız

İş analizi uzmanlığı programındaki bakış açıları başlığı çevik yaklaşımı ayrı bir ders olarak ele alır; iş analistliği BABOK çerçevesi eğitimi ise çevik ve geleneksel ortamlarda BABOK'u karşılaştırmalı olarak işler. Çevik ekibe geçen ya da orada çalışan iş analistleri için uygulama odaklı bir zemin sunar.