- Kullanıcı hikayelerini yazmak için farklı şablonlar ve konseptler kullanılabilirsiniz. “As a … I want to … so that …” formatının dışında, kullanıcı hikayelerini daha çeşitli ve detaylı bir şekilde ifade etmek için alternatif yaklaşımlar da mevcuttur.
1. Role-Feature-Reason Şablonu
As a …, I want to …, so that … Yöntemi
Bu şablon, kullanıcı hikayelerini formüle etmek için Agile geliştirme süreçlerinde yaygın olarak kullanılır. Temel olarak üç bileşenden oluşur:
– As a ( Rol): Bu, hikayenin kim tarafından kullanılacağını belirtir ve genellikle spesifik bir kullanıcı rolü veya kişi tipi ifade eder.
– I want to (İstek): Bu, kullanıcının gerçekleştirmek istediği eylemi veya elde etmek istediği özelliği tanımlar. Yani kullanıcı tarafından talep edilen özellik veya işlevsellik net bir şekilde ifade edilir.
– So that (Neden): Bu, kullanıcının belirli bir eylemi gerçekleştirmek istemesinin altında yatan sebebi, yani bu eylemin veya özelliğin kullanıcıya sağlayacağı faydayı açıklar.
Bu şablon, kullanıcı hikayelerini yazarken kullanıcının perspektifinden düşünmeyi teşvik eder ve geliştirme ekibinin, özellikleri sadece teknik gereksinimler olarak değil, aynı zamanda gerçek insanların ihtiyaçlarını karşılayan çözümler olarak görmelerine yardımcı olur. Bu yaklaşım, ürünün kullanıcı odaklı geliştirilmesini sağlar ve sonuçta daha yüksek kullanıcı memnuniyeti ve ürün başarısına katkıda bulunur.
Who, What, Why Yöntemi
Bu şablon, biraz daha genel bir yaklaşım sunar ve çeşitli bağlamlarda kullanılabilir. Temelde aşağıdaki bileşenleri içerir:
– Who (Kim): Kullanıcı hikayesinin kim tarafından kullanılacağını belirtir, yani hedef kullanıcı veya rol.
– What (Ne): Kullanıcının ne yapmak istediğini açıklar, yani istenen eylem veya özellik.
– Why (Neden): Kullanıcının bu eylemi gerçekleştirmek istemesinin sebebini açıklar, genellikle bu, bir sorunu çözmek veya belirli bir ihtiyacı karşılamak için olabilir.
As a …, I want to …, so that … şablonu, Agile yazılım geliştirme süreçlerinde daha sık kullanılır ve genellikle daha spesifik ve işlevsel kullanıcı ihtiyaçlarını ifade etmek için tercih edilir.
Who, What, Why ise daha geniş bir kullanım alanına sahiptir ve iş analizleri, pazarlama stratejileri, ürün geliştirme ve diğer alanlarda kullanılabilir. Bu format, kullanıcı hikayelerini biraz daha genel bir bakış açısıyla ele alır.
Her iki format da etkili kullanıcı hikayeleri oluşturmak için faydalıdır, ancak kullanıldıkları bağlama ve ekip tercihlerine göre seçim yapılabilir.
Bu şablon, kullanıcı hikayelerini biraz daha farklı bir biçimde ifade eder:
– Who (Kim): Kullanıcı kim?
– What (Ne): Kullanıcı ne yapmak istiyor?
– Why (Neden): Kullanıcı bunu neden yapmak istiyor?
Örnek:
– Who: Bir iş gezisine çıkan profesyonel
– What: Otelde iş odası rezervasyonu yapmak
– Why: İş görüşmelerini otelde rahatça yapabilmek için
2. Gherkin Dilinde Kullanıcı Hikayeleri
Gherkin, davranış odaklı geliştirme (Behavior-Driven Development – BDD) süreçlerinde kullanılan, senaryo tabanlı bir test dili. Kullanıcı hikayelerini, gerçekleştirilecek test senaryolarıyla birlikte tanımlar:
– Given (Verilen): Başlangıç durumu
– When (Ne zaman): Bir eylem gerçekleştiğinde
– Then (O zaman): Beklenen sonuç
Gherkin, cucumber ile test senaryosu yazımı yapılırken kullanılan gramer yapısının genel adıdır. Gherkin dili günlük konuşma diline oldukça yakındır, basit ve anlaşılması kolay bir dildir.
Örnek:
– Given: İş gezisi için otel ararken
– When: İş odası seçeneği seçildiğinde
– Then: Oda rezervasyonu iş odası özellikleriyle gerçekleşmeli
3. Job Story Şablonu
Kullanıcının hangi durumda ne tür bir iş çözmeye çalıştığını ifade eder:
– When (Ne zaman): Kullanıcı hangi durumda
– I want to (İstiyorum): Kullanıcı ne yapmak istiyor
– So I can (Böylece yapabilirim): Bu eylemin sonucunda kullanıcı ne elde eder
Örnek:
– When: Yeni bir şehre iş seyahati için geldiğimde
– I want to: Kolayca check-in yapabileceğim bir otel bulmak
– So I can: Zamanımı en verimli şekilde kullanarak dinlenebilir ve hazırlıklarımı yapabilirim
Bu farklı şablonlar, kullanıcı hikayelerini yazarken ekibin gereksinimleri daha iyi anlamasına ve farklı bakış açılarından ürün veya servis geliştirmesine olanak tanır. Kullanılan şablon veya konsept, projenin ihtiyaçlarına ve ekibin tercihlerine göre seçilebilir.
Kullanıcı Hikayeleri Değişkenlik Gösterir mi?
Her kullanıcı hikayesi şablonunun kullanımı, projenin özelliği, takımın ihtiyaçları ve hikayenin anlatıldığı bağlam gibi faktörlere bağlı olarak değişebilir. Farklı şablonlar, farklı durumlar ve amaçlar için daha uygun olabilir.
Role-Feature-Reason Şablonu
Bu şablon, kullanıcı rollerini ve bu rollerin işlevsel ihtiyaçlarını net bir şekilde tanımlamak istediğinizde kullanışlıdır. Özellikle, kullanıcıların kim olduğu ve ne istedikleri açıkça bilindiğinde ve bu ihtiyaçların nedenlerini belirtmek istediğinizde tercih edilir.
Tercih Edilme Sebebi:
– Kullanıcı gruplarını ve bu grupların ihtiyaçlarını net bir şekilde belirtmek istediğinizde.
– Kullanıcıların rollerine ve bu rollere bağlı işlevselliklere odaklanmak istediğinizde.
Gherkin Dilinde Kullanıcı Hikayeleri
Gherkin dili, Behavior-Driven Development (BDD) yaklaşımının bir parçası olarak kullanılır. Bu dil, kullanıcı hikayelerini senaryo tabanlı bir yapıda ifade etmek ve test süreçlerini bu hikayelere göre şekillendirmek için idealdir.
Tercih Edilme Sebebi:
– Test senaryolarını, kullanıcı hikayeleriyle bütünleşik bir şekilde planlamak istediğinizde.
– Yazılımın her özelliğinin, belirli başlangıç koşulları altında nasıl tepki vermesi gerektiğini açıkça belirtmek istediğinizde.
– Hikayelerin test edilebilir olmasını ve doğrudan kabul testlerine dönüştürülebilir olmasını sağlamak istediğinizde.
Job Story Şablonu
Job story yaklaşımı, kullanıcıların belirli bir durumda ne tür işler yapmaya çalıştıklarını anlamaya odaklanır. Bu yaklaşım, özellikle kullanıcıların motivasyonlarını ve hedeflerini ön plana çıkarmak istediğinizde kullanışlıdır.
Tercih Edilme Sebebi:
– Kullanıcıların ürünü veya hizmeti kullanma motivasyonlarını ve bağlamlarını daha derinlemesine anlamak istediğinizde.
– Özelliklerin veya işlevlerin kullanıcı deneyimi üzerindeki etkisini vurgulamak istediğinizde.
– Kullanıcıların gerçek hayattaki senaryolarını ve bu senaryolarda karşılaştıkları problemleri çözmek istediğinizde.
Her bir şablon, kullanıcı hikayelerini farklı bir perspektiften yaklaşarak ifade eder ve takımlara kullanıcı ihtiyaçlarını, motivasyonlarını ve işlevsellikleri farklı açılardan değerlendirme imkanı tanır. Bu nedenle, hangi şablonun kullanılacağına karar verirken projenin gereksinimleri, takımın çalışma tarzı ve hedeflenen son kullanıcı deneyimini dikkate almak önemlidir.
Role-Feature-Reason Örneği
Aşağıdaki örnekte bulunan “As a … I want to … so that …” ifadesi, Agile yazılım geliştirme süreçlerinde kullanılan bir kullanıcı hikayesi şablonudur. Bu şablon, bir özelliğin veya işlevin kim tarafından kullanılacağını, ne amaçla kullanılacağını ve bu işlevin kullanıcıya hangi faydayı sağlayacağını açık ve öz bir şekilde ifade etmek için kullanılır.
Aşağıdaki örnek kullanıcı hikayesi ve ona uygun kabul kriterlerini ve bu konseptlerini iyi anlamanızı sağlar
Kullanıcı Hikayesi Örneği:
Başlık: Online Kitapçıda Kitap Satın Alma
Hikaye:
- As a: Kitap sever kullanıcı,
- I want to :Online kitapçıdan kitap satın alabilmek,
- So that: istediğim kitapları kolayca bulup satın alarak hemen okumaya başlayabilirim.
Bu kullanıcı hikayesi, bir online kitapçı kullanıcısının bir kitap satın alma işlemi yapma ihtiyacını tanımlar. Bu hikaye, kullanıcının niyetini ve elde etmek istediği sonucu açıkça ifade eder.
Kabul Kriterleri Örneği:
1. Kitap Arama Özelliği:
– Kullanıcı, ana sayfada arama çubuğuna kitap adı, yazar veya ISBN numarası girerek arama yapabilmelidir.
– Arama sonucunda, ilgili kitapların listesi (kitap kapağı, yazar adı, fiyatı) gösterilmelidir.
2. Kitap Seçimi ve Satın Alma İşlemi:
– Kullanıcı, arama sonuçlarından bir kitap seçip onun detay sayfasına erişebilmelidir.
– Detay sayfasında kitabın açıklaması, fiyatı, kullanıcı yorumları ve benzer kitap önerileri bulunmalıdır.
– Kullanıcı, “Sepete Ekle” butonuna tıklayarak kitabı alışveriş sepetine ekleyebilmelidir.
– Kullanıcı, alışveriş sepeti sayfasından “Satın Al” butonu ile ödeme işlemine geçebilmelidir.
3. Ödeme İşlemi:
– Ödeme sayfasında, kullanıcının adres bilgilerini ve ödeme bilgilerini (kredi kartı veya başka ödeme yöntemleri) girebilmesi gerekmektedir.
– Ödeme bilgileri güvenli bir şekilde işlenmeli ve kullanıcıya ödemenin başarılı olduğuna dair bir onay mesajı gösterilmelidir.
– Kullanıcıya e-posta yoluyla sipariş özeti gönderilmelidir.
4. Kullanıcı Deneyimi:
– Tüm işlemler sırasında kullanıcı arayüzü net ve kullanıcı dostu olmalıdır.
– Kullanıcı, her adımda geri dönebilir veya işlemi iptal edebilir seçeneklere sahip olmalıdır.
Bu kabul kriterleri, kullanıcı hikayesinin başarıyla tamamlanmasını sağlamak için gerekli olan spesifik ve ölçülebilir adımları tanımlar. Kullanıcı hikayesi ve kabul kriterleri birlikte, geliştirme ekibine net bir rehber sunarak projenin belirlenen gereksinimleri karşılamasını sağlar.
Turizm sektörüne uygun farklı bir örnekle devam edelim.
Kullanıcı Hikayesi Örneği:
Başlık: Otelden Online Rezervasyon Yapma
Hikaye:
– Bir tatilci olarak,
– Otelden online rezervasyon yapmak istiyorum,
– Böylece tatil planlarımı hızlı ve kolay bir şekilde gerçekleştirebilirim.
Bu kullanıcı hikayesi, tatil planı yapmak isteyen bir kişinin, otel rezervasyonunu online olarak yapma ihtiyacını tanımlar. Hikaye, tatilcinin niyetini ve bu işlemi gerçekleştirme nedenini açıkça belirtir.
Kabul Kriterleri Örneği:
1. Rezervasyon Arayüzü:
– Tatilci, otelin web sitesine girdiğinde, rezervasyon yapmak için net ve anlaşılır bir arayüz bulabilmelidir.
– Rezervasyon arayüzünde, tarih seçimi, oda tipi seçimi ve kişi sayısı gibi gerekli bilgiler sorulmalıdır.
2. Oda Seçenekleri ve Bilgileri:
– Tatilci, farklı oda tiplerini görebilmeli ve her oda tipi için sunulan olanaklar, fiyat bilgisi ve müsaitlik durumu açıkça belirtilmelidir.
– Seçilen oda için rezervasyon yapılabilmelidir.
3. Ödeme İşlemi:
– Tatilci, güvenli bir ödeme sayfasında kredi kartı bilgilerini girerek ödeme yapabilmelidir.
– Rezervasyon ödemesi tamamlandıktan sonra, tatilciye ödemenin başarılı olduğuna dair bir onay mesajı gösterilmelidir.
– Tatilciye, rezervasyon detaylarını içeren bir e-posta gönderilmelidir.
4. Kullanıcı Dostu Deneyim:
– Tüm işlemler sırasında tatilcinin karşılaşacağı arayüzler net, hızlı ve kullanıcı dostu olmalıdır.
– Tatilci, herhangi bir aşamada geri dönebilir veya işlemi iptal edebilir seçeneklere sahip olmalıdır.
Bu kabul kriterleri, turizm sektöründe bir otel rezervasyon sisteminin başarıyla işlemesini sağlamak için gerekli olan spesifik ve ölçülebilir adımları tanımlar. Kullanıcı hikayesi ve kabul kriterleri birlikte, geliştirme ekibine net bir rehber sunarak sistemin belirlenen gereksinimleri karşılamasını sağlar.
Tabii ki, turizm sektöründe kredi kartı ile 3D ödeme akışı için bir kullanıcı hikayesi hazırlayacağım. Bu örneği Role-Feature-Reason şablonunu kullanarak aşağıdaki gibi oluşturabiliriz:
Kullanıcı Hikayesi Örneği:
Başlık: Online Rezervasyon Sırasında 3D Güvenlikli Kredi Kartı Ödemesi Yapma
Hikaye:
– Kim (Who): Online tatil rezervasyonu yapan müşteri
– Ne (What): 3D güvenlikli kredi kartı ödemesi yapmak istiyorum
– Neden (Why): Ödememin güvenli olduğundan emin olmak ve dolandırıcılık riskini azaltmak için
Detaylı Açıklama:
Müşteriler, tatil paketlerini online olarak rezerve ederken ve ödeme yaparken güvenliklerinden emin olmak istemektedir. 3D Secure, hem müşterilerin hem de işletmelerin çevrimiçi kart dolandırıcılığına karşı korunmasına yardımcı olur. Bu kullanıcı hikayesi, müşterinin rezervasyon işlemi sırasında kredi kartı bilgilerini güvenle kullanabilmesini ve 3D Secure doğrulaması ile ödeme yapabilmesini sağlamayı amaçlamaktadır.
Kabul Kriterleri:
1. Ödeme Arayüzü Erişilebilirliği:
– Müşteri, ödeme yapmak için kolayca erişilebilen ve anlaşılır bir ödeme arayüzüne sahip olmalıdır.
2. 3D Secure Doğrulama Süreci:
– Müşteri, ödeme bilgilerini girdikten sonra, 3D Secure doğrulama sayfasına yönlendirilmelidir.
– Müşterinin, kendi bankası tarafından sağlanan 3D Secure doğrulama ekranında bir güvenlik kodu girmesi gerekmelidir.
3. Doğrulama Sonrası İşlem Onayı:
– Doğrulama başarılı olduktan sonra, müşteriye ödemenin başarıyla gerçekleştiğine dair bir onay mesajı gösterilmelidir.
– Başarısız doğrulama durumunda, müşteriye hata mesajı gösterilmeli ve ödeme işlemini tekrar deneyebilmesi için yönlendirilmelidir.
4. Güvenlik Önlemleri:
– Tüm ödeme ve doğrulama bilgileri güvenli bir şekilde işlenmelidir.
– Müşteri bilgileri, yalnızca ödeme işlemi için gerekli olan süre boyunca saklanmalı ve işlem tamamlandıktan sonra güvenli bir şekilde silinmelidir.
Bu kullanıcı hikayesi, turizm sektöründe, müşterilerin online rezervasyon sırasında 3D Secure özelliği ile güvenli bir şekilde ödeme yapmalarını sağlamak için gereken işlevselliği ve süreçleri tanımlar. Özellikle güvenlik hassasiyeti yüksek olan turizm işletmeleri için bu tür bir ödeme sistemi, müşteri memnuniyetini ve güvenini artırmada kritik bir role sahiptir.
Yine turizm sektöründe kredi kartı ile 3D ödeme akışı için doğru Job Story formatında bir örnek hazırlayalım.
Job Story Örneği:
Başlık: Online Otel Rezervasyonu Sırasında 3D Secure ile Ödeme Yapma
Hikaye:
– Ne zaman: Bir otel rezervasyonu sırasında ödeme yapmam gerektiğinde
– İstiyorum: Ödeme işlemimi 3D Secure doğrulaması kullanarak gerçekleştirmek
– Böylece: Finansal bilgilerimin güvenliğinden emin olabilir ve olası dolandırıcılık risklerini azaltabilirim.
Açıklama:
Bu Job Story, özellikle online otel rezervasyonu yaparken karşılaşılan güvenlik endişelerini ele alır. Müşteriler, genellikle çevrimiçi ödemelerde güvenlik konusunda hassastır ve 3D Secure gibi ek güvenlik önlemleri, bu endişeleri hafifletmeye yardımcı olur. Bu hikaye, ödeme sürecinin bir parçası olarak 3D Secure doğrulamasının nasıl entegre edileceğini ve müşterilerin neden bu özelliği kullanmayı tercih edeceğini vurgular.
Kabul Kriterleri:
1. Kolay Erişim ve Kullanıcı Dostu Arayüz:
– Müşteriler, ödeme sırasında 3D Secure doğrulamasını kolayca etkinleştirebilmelidir.
– Doğrulama süreci, kullanıcı dostu ve anlaşılır adımlarla yönlendirilmelidir.
2. Güvenlik ve Doğrulama:
– Müşterilerin kendi bankalarından bir güvenlik kodu alma ve bu kodu ödeme formuna girme süreci sorunsuz işlemelidir.
– Doğrulama başarılı olduğunda, müşterilere ödemenin güvenli bir şekilde tamamlandığına dair bir onay gösterilmelidir.
3. Başarısız Doğrulamalarda Yönlendirme:
– Başarısız doğrulama durumunda, müşterilere hata nedenleri açıkça belirtilmeli ve ödeme işlemini güvenli bir şekilde yeniden deneyebilmeleri için yönlendirilmelidir.
Bu Job Story, müşterilerin güvenli bir ödeme deneyimi yaşamalarını sağlamak için 3D Secure teknolojisinin önemini ve kullanımını detaylandırır. Aynı zamanda, bu teknolojiyi entegre ederken müşteri deneyimini nasıl iyileştireceğinizi ve güvenlik önlemlerinin nasıl optimize edileceğini açıklar.
Gherkin Dilinde Kullanıcı Senaryosu Oluşturma
Gherkin dili, Behavior-Driven Development (BDD) sürecinde kullanılan, senaryo tabanlı bir dil olarak özellikle test senaryolarını yazmak için kullanılır. Gherkin dilinde senaryolar, genellikle “Given”, “When” ve “Then” anahtar kelimeleri ile oluşturulur.
Gherkin, aslında hem kullanıcı hikayelerini tanımlamak hem de bu hikayelere dayalı test senaryoları yazmak için kullanılan bir dildir. Kullanıcı hikayesi ve test senaryosu arasındaki çizgi Gherkin dilinde bazen bulanık olabilir çünkü aynı format hem gereksinimi tanımlamak hem de bu gereksinimi doğrulamak için kullanılır.
Gherkin dilinde “Given”, “When”, “Then”, “And”, “But” gibi anahtar kelimeler kullanılması zorunlu değildir, ancak bu anahtar kelimeler, senaryoların okunabilirliğini ve anlaşılmasını kolaylaştırmak için tercih edilir. Bu anahtar kelimeler sayesinde, senaryoların hangi bölümünün durumu set ettiğini (“Given”), hangi eylemin gerçekleştiğini (“When”), ve bu eylemin sonuçlarının ne olduğunu (“Then”) net bir şekilde ifade edebilirsiniz. “And” ve “But” ise ek bilgiler veya koşullar eklemek için kullanılır.
Turizm sektöründe kredi kartı ile 3D ödeme akışı için Gherkin dilinde bir kullanıcı hikayesi örneğine bakalım.
Gherkin Dilinde Kullanıcı Hikayesi Örneği:
Özellik (Feature): 3D Secure ile Online Otel Rezervasyonu Ödeme Güvenliği
Kontekst (Background):
“`
Given kullanıcı online otel rezervasyonu sayfasında bulunuyor
And kullanıcı seçtiği oda için rezervasyon bilgilerini girmiş
“`
Senaryo (Scenario): Kullanıcı ödeme yaparken 3D Secure doğrulamasını tamamlar
“`
When kullanıcı ödeme bilgilerini girer
And kullanıcı “Ödeme Yap” butonuna tıklar
Then kullanıcı 3D Secure doğrulama sayfasına yönlendirilir
When kullanıcı 3D Secure doğrulama kodunu girer
And “Doğrulayıp Devam Et” butonuna tıklar
Then ödeme başarılı bir şekilde işlenir
And kullanıcıya bir onay mesajı gösterilir
“`
Senaryo (Scenario): Kullanıcı yanlış 3D Secure doğrulama kodu girer
“`
When kullanıcı ödeme bilgilerini girer
And kullanıcı “Ödeme Yap” butonuna tıklar
Then kullanıcı 3D Secure doğrulama sayfasına yönlendirilir
When kullanıcı yanlış 3D Secure doğrulama kodunu girer
And “Doğrulayıp Devam Et” butonuna tıklar
Then doğrulama başarısız olur
And kullanıcıya hata mesajı gösterilir
And kullanıcıya doğrulama kodunu tekrar girmesi için fırsat tanınır
“`
Bu Gherkin senaryoları, kullanıcının 3D Secure ile ödeme yapma sürecinin farklı aşamalarını adım adım açıklar. İlk senaryo başarılı bir ödeme işlemi için beklenen adımları, ikinci senaryo ise yanlış bir doğrulama kodu girildiğinde beklenen durumu test etmek için kullanılır. Her “Given”, “When”, “Then” adımı, uygulamanın bu özel durumlarda nasıl davranması gerektiğini belirler ve bu sayede yazılımın davranışını net bir şekilde tanımlar.