Agile geliştirme süreçlerinden Scrum, Kanban, Lean, XP gibi herhangi
birinin uygulandığı projelerde çalışan bir analistin en çok duyacağı,
konuşacağı ve üzerine çalışacağı kavramlardan biri de STORY, Türkçesiyle ifade
edecek olursak HİKÂYE’dir.
Klasik Analiz yöntemlerinde Hikâyenin tam karşılığı olmasa
da yakın olarak anılan ifade edilebilecek birçok karşılığı vardır. Kimi Fonksiyon, kimi Bileşen, kimi İhtiyaç,
kimi de daha global ifadeyle Requirement derken, çoğu platformda da adına, doğrudan ANALİZ denir.
Agile süreçlerdeki kavramlar, Waterfall süreçlere göre daha
belirgin çerçevelerle ifade edilir ve uygulama noktasında da daha kesin
sınırarda ilerler. Bu anlamda HİKÂYE de Agile süreç içerisinde daha olgun ve
ayakları yere basan bir kavram olarak karşımıza çıkar.
Hikâye: Projenin bir parçasıdır. Bu parça; en fazla bir iterasyon süresinde
yapılabilecek kadar kısadır. Müşteri için katma değeri olup, tek başına bir
ürün özelliği taşır.
Hikâye ve proje ilişkisini şöyle
örnekleyecek olursak;
Bir müşteri inşaat firmasından 6 ayda kendisi için bir ev
yapmasını ister. Fakat, müşteri, ev tamamlanmadan önce ayda bir kendisi için anlamlı ve tamamlanan bir
parçayı görmek ister. Firma bu isteği karşılayabilmek için bir plan yapar.
Projeyi 6 parçaya böler. İnşaat projelerinde işler nasıl parçalara bölünür bilmiyorum ama kabaca planı şöyle yapılmış olsun.
- Mimari Plan Tasarım: 1 ay
- Jeolojik araştırmalar: 1 ay
- Temel yapma: 1 ay
- Duvar örme: 1 ay
- Boya dekorasyon: 1 ay
- Anahtar Teslim:1 ay
Müşteri her
ay sonunda projeye uygun parçaları görür ve gerekli bildirimlerini yapar.
Böylece proje tamamlanmadan önce gerekirse revizyonlar ve projede güncellemeler
yapılır.
Burada
projeyi dilimlerine bölerken müşteri için anlamlı olması önemlidir. Örneğin
Müşteri 2. ay projenin ne aşamada olduğunu görmek için geldiğinde Jeolojik Araştırmalar kendisi için hiçbir anlam ifade
etmeyecekse burada müşteri tamamlanan ve
kendisi için anlamlı bir parçayı göremez.
Bu yüzden Projede tamamlanan parçanın bir Değeri (Valuable) olmalıdır.
Hikâye Nasıl Oluşturulur:
Yazılım
dünyası reel ekonomi dünyasının yardımcılığı görevini görür. Bir anlamda piyasa
değiştiği için yazılım değişmek zorundadır. Yazılıma göre piyasa şekillenmez.
Bu yüzden hız ve değişebilmek Yazılım dünyasında oldukça önemlidir. Müşterinin taleplerinin her an yön
değiştirebileceği hesaba katılmalıdır. Hikâyenin temelinde yatan asıl konu
değişime adaptasyondur.
Hikâye
oluşturmak diyoruz. Yazmak değil. Çünkü hikâye yazmak ve bir formata oturtmak
işin en son ve Agile süreçler için daha az öncelikli kısımdır.
Hikâye
oluşturulurken yukarıdaki ev örneğindeki gibi projenin müşteriye sunulabilir
parçalara ayrılması gereklidir. Peki, bu parçalar nasıl belirlenmelidir. Projeyi
Parçalara ayırdığımızda ortaya çıkan Hikâye oluşturmak özelde Analist ve genelde
de Agile Takım’ın yetenekleriyle ilişkili olsa da bu süreç Bill Wake tarafından
oluşturulan INVEST kuralına göre oluşturulmalıdır.[1]
INVEST
İngilizce
Independence, Negotiable, Valuable, Estimetable, Sized(Small), Testable
kelimelerinin baş harflerinden oluşan bu yöntem hikaye oluşturulurken oldukça
yol göstericidir. Bu kavramları kısaca özetleyelim.
INDEPENDENT: Bağımsızlık ilkesi. Proje parçalarına
ayrılırken her bir parça diğer bir parçanın bitmesine veya başlamasına mümkün olduğunca bağımlı
olmamalıdır. Mümkün Olduğunca diyoruz çünkü yazılımda bunu tamamen sağlamak
mümkün olmayabilir. Fakat hedef projeyi parçalarken aşağıdaki hunide her bir
parça bağımsız bir şekilde proje havuzunu dolduran fonksiyonlar kümesine
dökülmeli ve projede birikim oluşturabilmelidir.
 | |
|
NEGOTIABLE:
Tartışılabilir, anlaşılabilir. Hikâye sadece Analist veya Product Owner
insiyatifinde oluşturulamaz. Her bir hikâyenin projenin sponsoru, müşterisi ve
yazılım ekibi tarafından kabul edilmesi ve üzerinde anlaşılması gerekir. Bu
durumda sadece proje detayları üzerinde değil aynı zamanda Hikâye parçalarının
oluşturulmasında da ilgili paydaşlar ile mutabakat sağlanmalıdır.
VALUABLE: Müşteri için değer ifade etmeli.
Müşteri bir hikâyeyi proje ilerlerken ilgili iterasyonda tek başına görebilmeli
ve buna göre bir karar alabilmelidir. Bu da en önemli ilkelerden biridir.
Örneğin, Kurumsal Web Sitesi isteyen bir müşteriye için şöyle bir HIKÂYE anlam
ifade eder mi? “Şirket kampanyaları için bir Web Servis oluşturulması”… Etmez.
Müşteri sonuçta elinde bir işlev görmek ister ve bu işlevin ona bir anlam ifade
etmesi gerekir. O zaman Valuable bir Hikâye şöyle olabilir mi diye tekrar
soralım. “Müşteriler Şirketin Devam eden kampanyalarını anlık olarak
görebilmelidir.” Evet bu kez oldu. Bu Hikâyeyi herhangi bir iterasyon anında
müşteriye bir ekranda gösterebileceğiniz gibi Kampanya bölümü müşteri için
değerli bir parçadır.
ESTIMETABLE:
Tahmin edilebilmeli. Hikâye oluşturulurken bu hikâye için ne kadar
kaynak ayrılması gerektiği önceden tahmin edilmesi gerekecektir. Bu yüzden bir
Hikâyenin ne kadar yazılım, test ve diğer IT kaynaklarını meşgul edeceği ilk
bakışta tahmin edilebilir olmalıdır.
SIZED-SMALL:
Yeterince Küçük olmalı. Müşteri
için Değer ifade ettiği müddetçe Hikâye mümkün olduğu kadar küçük olmalıdır.
Buradaki Kısıt Valuable ilkesine göre hareket etmektir.
Hikâye küçük olmazsa Kompleks ve
Tahmin Edilemez bir hale gelebilir. Bir hikâyenin bu kurala uydurulabilmesi
için Agile Projelerin INCEPTION adımında BACKLOG GROOMING işleminin yapılması
oldukça faydalı olacaktır.
 |
| Hikâyenin Değer ve Tahmin Edilebilirliğine göre Hikaye Boyutu |
TESTABLE:
Test edilebilir olmalı. Hikâyede istenen fonksiyonlar net olmalı.
Yoruma açık veya tartışılabilir olmamalı. Ayrıca Hikâyede testi mümkün
kılmayacak fonksiyonlar içermemeli. Örneğin Web Sitesi tasarımında “İlk bakışta
Kampanya bölümü göze çarpacak bir bölümde olmalıdır” gibi bir Hikâye muğlak bir
ifadedir ve test edilemez. Bunun yerine “Kampanya Bölümü Ekranın üstünde
bulunan Haberler bölümünün sağ tarafında bulunmalıdır” gibi bir ifade kullanılabilir.
Hikâye INVEST özellikleri taşımasının yanında ayrıca Rol/iş,aksiyon/sonuç olarak ifade edilebilmelidir. Bu daha çok Hikâye özetlendiğinde paydaşların hemen fikir edinebilmesi için bir anlamda Hikâyeyi özetleyen bir kalıptır.
Örneğin internet sitesi tasarımı için şöyle bir Hikâye detaylarını bilmeden önce açıklayıcı olacaktır.
"Bireysel Müşteri olarak sisteme login olduğumda, siparişlerimin hangi aşamada olduğunu görmek istiyorum"
Rol: Bireysel Müşteri
Aksiyon : Sisteme login olduğumda
Sonuç: Siparişlerimin hangi aşamada olduğunu görmek istiyorum"
