STORY-HİKÂYE

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.

Her bir Hikâyenin Projenin tamamlanmasında doğrudan Katkısı olmalıdır

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" 

---

[1] http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/