Kullanıcı (User Story ) Hikayesi Nedir?
Kullanıcı Hikayeleri Çevik Süreçlerde ( en başta XP'de ) özellikle fonksiyonel gereksinimlerin toplanmasında kullanılan bir tekniktir. Bir Kullanıcı Hikayesi özetle oluşturulacak sistemi kullanacak veya satın alacak kişiler için faydalı olacak , yaptıkları işe değer katacak sistem işlevlerini , yeteneklerini tanımlar.
Kim Tarafından Yazılır?
Kullanıcı Hikayeleri müşteriler tarafından yazılır.Kullanıcı hikayeleri ile ilerleyen bir projede, müşteriler ve kullanıcılar proje boyunca geliştirme takımıyla projeye dahil olur. Müşteriler ve kullanıcıların projenin herhangi bir safhasında “ortadan kaybolmasına” izin verilmez.Bu tür geliştirmede hikayeler geliştirme takımı yerine, müşteriler tarafından yazılır.Çünkü:
- Ürünün temel vizyonunu ortaya koyan müşteri olduğu için, ürüne ait davranışı en iyi tanımlayabilcek konumda olan yine müşteridir.
- Bu hikayelerin müşteri tarafından ilgili iterasyon ve sürümler için kolay bir şeklilde önceliklendirilmesi için, teknik jargondandan uzak bizzat ilgili iş alanına ait bir dil kullanılarak yazılması gerekmektedir.
Formatı Nasıldır?
Müşterinin bizzat kendi iş alanına ait terimleri kullanarak isteğini özellikler bazında ifade ettiği bir kaç cümle şeklinde yazılır.İyi bir Kullanıcı Hikayesi istenilen işlevi (Ne isteniyor),bunu kimin istediğini (Kim istiyor), ve ilgili işlevin / özelliğin ne için kullanacağını (Neden isteniyor) tanımlar.
Yaygın olarak kullanılan formatlar:
As a (role) I want (something) so that (benefit).
X olarak [rol] , (Y) özelliğini/işlevini istiyorum [ ne isteniyor] böylelikle.. [Neden]
Başka bir format:
In order to
will need
.
(X) işlemlerini yapilmeleri için [niteliği yapılan işe değer katan]
(Y) kişilerinin [Rol]
(Z) özelliğine ihtiyaçları olacak [Ne istiyor]
Diğer bir format:
In order to
As a I want
to .
(X) işlemlerini yapilmeleri için [niteliği yapılan işe değer katan]
(Y) olarak [Rol] Z'nin [Rol ]
(T) işlemini yapmasını,kullanmasını veya belirli özellikler bazında sınırlandırılmasını istiyorum.[Ne istiyor]
Bu formatlar sadece Kullanıcı Hikayelerini bulmanıza yardım için verilmiştir.Başka formatlar kullanabilir veya herhangi bir formata uymadan Kullanıcı Hikayelerinizi doğrudan yazabilirsiniz.Kullanıcı hikayaleri genellikle elle, küçük karton not kağıtlarına yazılır.( low tech high touch) Ayrıca kullanıcı hikaye kartlarına küçük notlar ekleyebilirsiniz.
Kullanıcı Hikayeleri Ne kadar detay içerir?
Kullanıcı hikayelerinin temel amacı ( klasik SRS ten farklı olarak) müşteri isteklerini kayıt altına almak değildir. Kullanıcı hikayeleri bu nedenle detaylı eksiksiz hikayeler yazılması yerine, detayların geliştirme takımı ile müşteri arasındaki görüşmelerle ortaya çıkarılmasını salık verir. Kullacı hikayeleri bir bakıma “müsteriyle” daha sonra detaylandırın alınması gereken bir “gereksinim” için yapılacak görüşmeler için bir “bilet” niteliği taşır. Size “müşteriyle” yapmanız gereken bir “görüşmeyi” hatırlatır.
Asansör Testi : Bir asansörde takım arkadaşınızla karşılaştınız ve 30 saniyeniz var. Bir kullanıcı hikayesi bu 30 saniyede arkadaşınıza anlatılabilcek "detayda" olmalıdır.
Bu hikayelerin Sistem Tarfından Gerçeklendiği Nasıl Kontrol Edilir?
İlgili iterasyonla beraber geliştirme takımı, ilgili kullacı hikayesini kodlamaya başlar ve bu arada müşteri / müşteri takımı testleri belirlemeye başlar. Bu test belirtimi kullanıcı hikayesi kartları arkasına yazılabilcek basitlikte olabileceği gibi testleri otomatik test araçlarına vermeye kadar uzanabilir. Testle ilgili teknik karmaşıklıklar için gerektiğinde müşteri takımına bir yetenekli ve bu iş için ayrılmış bir testçi verilmelidir. Bu testler mümkün olduğunca iterasyonun başında erken zamanlarında yazılmalıdır.
Kullanıcı hikayeleri “test edilebilir” şekilde yazılmalıdır. Örnekler:
"Bir Kullanıcı olarak sistemdeki işlevlere kolay ve hızlı bir şekilde ulaşabilmeliyim". Buradaki “kolay” göreceli bir kavram olduğundan daha net ifadeler kullanılabilir. Örneğin: "Bir kullanıcı olarak sistemdeki harhangi bir işleve en fazla 3 fare tıklaması veya 2 klavye tuşuna dokunarak ulaşabilmeliyim” [ Test edilebilir]
Peki Fonksiyonel olmayan gereksinimler veya sistem işlevleri üzerindeki özel kısıtlamalar [Constraints] nasıl ifade edilecek?
Gereksinimler farklı şekilde sınıflandırılabilmektedir. Kullanılan yaygın sınıflandırmalardan birisi gereksinimleri şağıdaki şekilde ikiye ayırmaktır:
- Fonksiyonel Olan (İşlevsel): Sistemin yerine getireceği işlevler, sahip olması gereken “özellikler”.
- Fonksiyonel Olmayan : Sistemin işlevlerinin “kalitesine” ilişkin gereksinimler. Örneğin:
- Kullanilabilirlik (Usability)
- Güvenilirlik (Reliability)
- Performans
- Bakim , Destek (Supportability)
- += geriye kalan hersey
Örnekler:
- Veriler MySql Veri tabanında tutulacak.
- Sistem Java dilinde yazılacak.
- Sistemde yapılan sorgu sonuçları son kullanıcıya 1 dakikadan daha az bir sürede iletilmelidir.
- Sistem 100 bin kullanıcıya kadar olan kullanıcı kaydını -performans kriterlerini sağlayacak şekilde- tutubilmelidir.[Performans kriterlerinin ayrı bir yerde tanımlandığını varsayıyoruz]
- Sistem Windows 98/NT4/2000/XP ya da daha yüksek bir versiyonunda çalışabilmelidir
Bu tür gereksinimlerin hepsi biraz “zorlama" biraz da “yapay” şekilde kullanıcı hikayelerine çevrilebilir. Eğer şablonu kullanmak garip bir ifade tarzı yaratıyorsa şablonu bir kenara bırakın,pragmatik olun,vaktinizi bunla boşa harcamayın.Bu bilmeniz gereken bir gereksinim mi? Evet ise hikaye kartınıza aynen yazın : yani basitce hikaye kartlarınıza "Veriler MySql Veri tabanında tutulacak" diyebilirsiniz.
Ama bazı durumlarda bu hikayeyi şablona uygun şekilde ifade etmek sistem üzerinde kısıtlama oluşturan bu tür fonksiyonel olamayan gereksinimlerin arkasında yatan “motivasyonu” ve "kaynağı" gösterebilir.
Fonksiyonel olmayan gereksinimlerin bir kısmı, fonksiyonel olan (işlevesel) gereksinimlerin bağlamında var olurlar.Bu durumda ilgili işlevle ilgili "kaliteye" yönelik özellikleri doğrudan işlevsel gereksinim içine gömülebilir
veya ilgili işlevin "kabul testi" olarak kayıt altına alabilirsiniz.
Dikkat ederseniz örnekte “ortalama” ve “çoğunlukla” sözcükleri hala ortada daha detaylandırılması, araştırılması gereken terimler olarak durmaktadır. Bu tür kabul kriterleri test edilebilir olmadıkça gerçekten geçerli koşullar olarak görülemezler: bu nedenle tam ve net olarak ifade edilmelidirler.
Fonksiyonel olmayan gereksinimlerin bir kısmı ise sistemin belirli bir özelliği veya işlevine yönelik olmayıp, tüm sistem üzerindeki bir kısıtı ifade eder. Bu tür gereksinimler sistemin tümüne yayılmış olduğundan bir kez eklendimi projenin “ömrü” boyunca takip edilmesi gereken gereksinimlerdir. [ Bu itersayonda bitti, hikaye kartı çöpe diyemezsiniz] Bu tür gereksinimlerin sağlanıp sağlanmadığının kotrolünü yapan otomatik testler oluşturabilirsiniz. Her itersayon sonunda bunları çalıştırmanız gerekebilir. Bunlar çok maliyetli olduğundurumlarda maliyet ve yararı baz alan dengeli bir çözüm uygulamalısınız.
"Sistem Java dilinde yazılacak" gibi fonksiyonel olmayan bir gereksinimin sağlanıp sağlanmadığının kontrolü ve takibi nispeten kolay olmakla beraber ""Sistem Windows 98/NT4/2000/XP ya da daha yüksek bir versiyonunda çalışabilmelidir" gibi bir fonksiyonel olmayan gereksinim sağlanıp sağlanmadığının kontrolü ve takibi zorlu ve maliyetli olabilir.
Dikkat : Bu tür Fonksiyonel olmayan, kaliteye ilişkin gereksinimleri yazarken gerçekçi olun:
- Mevcut kaynaklar, zaman ve bütçe çerçevesinde bu kaliyete ilşkin unsurları gerçekleştirebilir misiniz?
- Bu kaliteye ilişkin senaryoları kim, nasıl test edecek? Kimsenin dikkate almayacağı, test etmiyeceği, sofistike (kaliteye ilişkin) gereksinimleri yazmanın hiçbir anlamı yoktur.
- Bunların yazılması kolay olmakla birlikte esas zorlu unsur bunların gerçekleştirilmesidir.
Kullanım Durumu (Use-Case) ve Kullanıcı Hikayeleri (User Stories) Arasındaki Ortak Yanlar ve Farklar Nedir?
Ortak Yanlar:
- Kullanım Durumları (Use-Case) ve Kullanıcı Hikayeleri (User Stories) fonksiyonel gereksinimlerin belirlenmesinde kullanılmaktadır.
- Her ikiside kullanıcı perpektifinden bakmakta ve kullanıcıların amaçlarına odaklanmaktadır.
- Her ikisininde "standart" bir şablonu veya formatı yoktur.
- Her ikiside temelde "basit" teknikler olmasına rağmen uygulamada "ciddi" zorluklar gösterebilmektedirler.İyi use-case'ler veya kullanıcı hikayeleri yazmak zannedildiği kadar kolay değildir.
Farklar:
- Bir kullanıcı hikayesi [user story] sisteme ait bir işlevin / özelliğin kullanıcı tarafından görüldüğü şekliyle kısa tanımıdır. Kullanıcı ile sistem arasındaki etkileşimi göstermez.İsminin aksine kullanıcı hikayeleri ardışık adımlardan oluşan bir "hikaye" anlatmaz.Sisteme ait özellikleri gösterir.Use-case'ler belirli bir amaca ulaşmak isteyen kullanıcıların sistemle etkileşimlerinin "hikayesini" bir dizi ardışık adım halinde anlatır.Yani birden fazla adımdan oluşur.
- Use-case’ler genel olarak bir “analiz” faaliyetinin sonucunda yazılırken[use-case’lerini çıkartmak istediğiniz sistemi önceden tahlil etmeniz gerekmektedir].kullanıcı hikayeleri ise [user stories] analiz faaliyetini / görüşmesini başlatmak üzere yazılırlar.Kullanıcı Hikaye kartlarının ilgili özelliğin daha sonra tartışılması / konuşulması için oluşturulmuş bir “hatırlatıcı” dır.İlgili hikayenin gerçeklenmesi /kodlanması vakti geldiğinde geliştiriciler müşteriden gereksinime ait detayları yüz yüze alacaklardır.
- Kabaca büyüklükleri farklıdır. Kullanıcı hikayeleri, planlamada kullanılabilmesi için özellikle küçük tutulurlar.(genellikle bir itersayonda bitecek şekilde). Buna karşılık bir use-case’nin kapsamı genelde daha büyüktür.(bazı use-case'lerin gerçeklenmesi birden fazla iterasyona yayılabilir).Tam doğru olmasada çok kabaca kullanıcı hikayeleri kullanım durumlarındaki bir “senaryo başlığına” denk gelmektedir.Bir kullanım durumu ise bir veya daha fazla senaryoyu içeriği ile beraber barındırır.
- Kullanım Durumları (Use cases) Unified Process, Kullanıcı Hikayeleri (User Stories) eXtreme Programming ile popüler hale gelmiş tekniklerdir.
Kullanıcı Hikayesi "gerçek" bir hikaye (story) değildir.
"Bir iş arayan üye olan Ali,İşkolik sitesine açar ve iş arama bölümüne girer.Ali bu bölümde,detaylı yada basit arama yapabilir.Ali basit arama yapmak istediğinde sisteme iş alanı, şehir veya genel arama kriterlerini girebilir.Detaylı aramada Ali sisteme ücret, pozisyon, işverenin sektörü, şehir, tarih bilgilerini girebilir. Ali arama sonucunda uygun bulduğu işlere başvurabilir. Bu durumda sistem Ali'den kullanıcı ismi ve porolası isteyecektir. Ali bunları doğru girdiğinde sistem Ali'nin başvurusunu kabul eder. İlgili başvuru iş veren tarafından artık değerlendirilebilir hale gelir...."
Bazı kişilerin kullanıcı hikayesi adı altında [user stories] bu tür "gerçek" hikayeler oluşturdukları görülmektedir.Bu XP'nin tanımladığı kullanıcı hikayesi[user stories] değildir.Bunları “concrete scenarios”, “usage narratives” şeklinde de adlandıranlarda vardır. [ Aslında bu tür "gerçek" hikayeler iyi bir şekilde yapılandırılmamış birer "Kullanım Durumu" [ use case] olarakta tanımlanabilir]
Dikkat Edilmesi Gerekenler
Kullanıcı hikayeleri temel olarak müşterinin isteklerinin öneceliklendirilmesinde, sürüm ve iterasyon planlamasında kullanılırlar.Kullanıcı hikayesi sadece ilgili hikayenin gerçeklenmesinin ne kadar süreceği tahminini kabul edilebilir düşük bir kestirim riskiyle verecek kadar detaylandırılmalıdır.İlgili hikakayenin gerçeklenmesi /kodlanması vakti geldiğinde geliştiriciler müşteriden gereksinime ait detayları yüz yüze alacaklardır.Bu nedenle Kullanıcı hikayaleri genellikle elle, küçük karton not kağıtlarına(indeks kağıtlarına) yazılır.( low tech high touch). [Bunları elektronik ortamda tutan yazılımlarda vardır.]Bunun temel espirilerinden birisi sizi fiziksel olarakta klasik bir detaylı "gereksinim faaliyetinden" uzak tutmaktır. Unutmayın bunlar detaylı analiz çalışmaları olmayıp, sadece ileride müşteri ile üzerinde daha sonra detaylandırılmak üzere üzerinde anlaşılmış sisteme ait işlev , özellik veya yetenekleridir.Dolayısıyla müşteriler ve kullanıcıların projenin herhangi bir safhasında “ortadan kaybolmamalıdırlar” Kullanıcı hikayelerinin belirli şablonları yoktur.Kullandığınız hikaye kartlarına işinize yarar ek bölümler koyabilirsiniz.Ama abartmayın.Daha fazla alanın detayın size net olarak ne kazandıracağını iyice sorgulayın.
Eğer fırsat olursa kullanıcı hikayelerinin sürüm ve iterasyon planlamasında nasıl kullanıldıkları, öncekliklendirildikleri, ne kadar zaman alacaklarının kestiriminin nasıl yapıldığı ile ilgili ek bilgiler vermeye çalışacağım.
Hamiş:
Çevik süreçlerde gereksinim analizi için "use-case" leri kullanabilirsiniz.Use-case'lere "saf çevikçilerin" çok yüz vermemesinin, en azından soğuk karşılanmasının temel nedenlerinden biri ,genellikle iteratif geliştirmeyi kavrayamamış kişilerce uygulanan "use-case" analiz çalışmalarının hantal olması ve "israfa" ( zaman, emek) yol açmasıdır.Ama bu böyle olmak zorunda değil.İteratif bir biçimde uygulanan [ ki öyle olması gerekir] use-case çalışmaları çok daha faydalı bile olabilir.
Kabaca:
Kullanıcı Hikayesi + Müşteri İle Yapılan Konuşmalar + Kabul Kriterleri / Testleri = Use-Case Analiz Modeli diyebiliriz. [ İteratif Bir Şekilde Yapılan]
İlgi Çekici Kaynaklar: