Scrum'da Kullanıcı Hikayeleri: Bilmeniz gereken her şey

Amaç net: Müşterilere yüksek katma değer sağlayan bir ürün geliştirmek istiyorsunuz. Ekip üyelerinin ve paydaşların memnun olduğu bir sonuç elde etmek istiyorsunuz. Peki bu hedefe nasıl ulaşırsınız? Bir ürünün tüm gerekliliklerini küçük ve kapsamlı adımlarla nasıl yerine getirebilirsiniz? 

Agile’de kullanıcı hikayelerinin bunun için etkili bir araç olduğu kanıtlanmıştır. Sizi ilk fikirden satışa hazır bir ürüne kadar adım adım götürürler. Size kullanıcı hikayelerinin ne olduğunu, nasıl oluşturulacağını ve bunlardan nasıl yararlanabileceğinizi göstereceğim.

Agile’deki kullanıcı hikayeleri tanımı, bir ürünün gereksinimlerini kullanıcının bakış açısından tanımlar. Başka bir deyişle, kullanıcı hikayeleri size bir ürünün hangi özelliklere ve işlevlere sahip olması gerektiğini söyler. Bu da onları, kullanıcıların ihtiyaçlarını tartışmak, doğrulamak ve ortak bir anlayışla bunların uygulanması üzerinde çalışmak için merkezi bir araç haline getirir. 

Kullanıcı hikayeleri ekip üyelerinin, paydaşların ve müşterilerin anlayabileceği ve konuşabileceği evrensel bir dil sağlar. Pratikte bu, müşterinin istediği ürün hakkında yanlış anlamaya çok az yer bırakan bir anlayış geliştirmek için kullanıcı hikayelerini kullanabileceğiniz anlamına gelir. 

Birkaç kullanıcı hikayesi birlikte bir kullanım senaryosu oluşturur. Kullanıcı hikayelerinin kökeni Agile Yazılım Geliştirme’ye dayanır.

Kullanıcı hikayeleri, müşteri veya kullanıcı perspektifinden oluşturulacak bir proje sonucu için gereksinimleri ve istekleri tanımlar. Çevik kullanıcı hikayeleri bu temel yapıya sahiptir:

DSÖ (rol), istiyor NE (hedef/arzu) NEDEN (katma değer)?

Şimdi kullanıcı hikayelerinin bileşenlerine daha yakından bakalım:

KİM (KULLANICI)

WER yer tutucusunu müşterinizle veya hedef grubunuzun tipik bir temsilcisiyle doldurursunuz. Kullanıcı Agile Hikayesinde DSÖ’yü ne kadar ayrıntılı tanımlayacağınız Kullanıcı Hikayesinin kendisine ve projenin ilerleyişine bağlıdır. Bu nedenle, anlamlı bir kullanıcı hikayesi oluşturmak için yeterince ayrıntılı olun.

NE (FONKSIYON)

Burası kullanıcının isteklerini yerleştirdiğiniz yerdir. Kendinize kullanıcının ne beklediğini veya neye ihtiyaç duyduğunu sorabilirsiniz. Ürününüz henüz erken geliştirme aşamasındaysa, kullanıcının hangi işlevleri beklediğine dair deneyimlerinize dayalı varsayımlar oluşturabilirsiniz. Piyasada halihazırda benzer bir ürününüz varsa, bu ürünle ilgili geri bildirimlerden de istenen işlevleri türetebilirsiniz.

NEDEN (KATMA DEĞER)

Kullanıcının bir fonksiyonu neden önemli bulduğunu ancak katma değer gösterir. BU NEDEN, bu nedenle bir müşterinin gereksinimlerini ne kadar iyi bildiğinizi dürüstçe yansıtmanızı sağlar. Çünkü: Bir gereksinimi bir kullanıcı hikayesine dahil etmek kolaydır - örneğin, müşteri bunu talep ettiği için. Ancak, müşterinin buna neden ihtiyaç duyduğunu anladığınızda, gereksinimin uygulanması için bağlama sahip olursunuz. Ancak o zaman, müşterinin önerisinin/isteğinin gerçek ihtiyacını verimli bir şekilde karşılayıp karşılamadığını veya daha akıllı bir yol olup olmadığını sorgulayabilirsiniz. Şimdi bir örneğe bakalım: 

Müşteri bisiklete binmek için bir yağmurluk istiyor. Bu nedenle şimdi “yağmur pelerini” gereksinimini ekleyebilirsiniz. Ya da müşteriye neden bir yağmur pelerinine ihtiyacı olduğunu sorabilirsiniz. Diyelim ki müşteri “Çünkü ıslanmak istemiyorum” yanıtını verdi. 

Bu, mutlaka bir yağmurluk sağlamanız gerekmediği anlamına gelir. Entegre çatılı bir bisiklet de sağlayabilirsiniz. Önemli olan, müşterinin ihtiyacının veya sorununun çözülmesidir - yani ıslanmamak. “Neden”i ne kadar iyi anlarsanız, kullanıcı hikayenizi o kadar iyi tasarlayabilirsiniz.

Agile’de Kullanıcı Hikayeleri nedir (örnek)?

Artık Agile kullanıcı hikayelerinin bireysel bileşenlerini biliyorsunuz. Bir Agile kullanıcı hikayesi örneği aşağıdaki gibi görünebilir: 

As MÜŞTERİ İsterim ki GÜVENLI BIR ŞIFRE***,*** BÖYLECE MÜŞTERI VERILERIM KORUNUR.

İşte “MÜŞTERİ” kullanıcı, “GÜVENLI BIR ŞIFRE” fonksiyonu ve “BÖYLECE MÜŞTERI VERILERIM KORUNUR” katma değer. 

Scrum’da kullanıcı hikayeleri ile çalışırken, onlara kabul kriterleri eklersiniz. Kabul kriterleri, kullanıcı hikayelerinin kabul sırasında yerine getirmesi gereken teknik gereksinimleri tanımlar. Başka bir deyişle: Kabul kriterleri, bir kullanıcı hikayesinin değer yaratması için ihtiyaç duyduğunuz gereksinimlerdir.

Agile kullanıcı hikayelerinin backlog içindeki anlamı daha farklılaştırılabilir. Çünkü: Backloglarda kullanıcı hikayeleri sadece gereksinimleri tanımlamakla kalmaz, aynı zamanda özel bir hiyerarşi tipini de temsil edebilir. Bu 3 hiyerarşi tipi vardır:

Destanlar: Destanlar, bir ürünün somut kapsamı hala belirsiz olabilen geniş tanımlı işlevsel alanlarıdır.

Özellikler: Özellikler, bir destan içindeki belirli performans özellikleridir.

Hikayeler: Hikayeler, teknik Agile kullanıcı hikayeleri ve bir özellik içindeki kullanıcı hikayeleridir.

Bu hiyerarşi türlerini bir sprint içinde uygulayabilirsiniz. Kullanıcı için somut bir fayda yaratırlar. 

Çevik proje yönetiminde faydalı kullanıcı hikayeleri yazmak için tüm paydaşlarla ayrıntılı görüşmeler yapmak çok önemlidir. Bu görüşmeler size hedef kitle ve oluşturulacak ürün hakkında kapsamlı bir anlayış kazandırmalıdır. Bundan sonra, örneğin personalar türetebilirsiniz. 

Buna ek olarak, sözde YATIRIM kriterleriikna edici bir kullanıcı hikayesi oluşturmak için:

Bağımsız: Bir kullanıcı hikayesi diğer kullanıcı hikayelerinden bağımsız olmalıdır. Bu, bir hikayenin uygulanmasının başka bir hikayenin önceden uygulanmış olmasını gerektirmemesi gerektiği anlamına gelir. Bu, kullanıcı hikayelerini istediğiniz zaman önceliklendirebilmeniz veya biriktirme listesinden çıkarabilmeniz avantajına sahiptir. 

Bisiklet örneğine bir kez daha bakalım. Diyelim ki bisikletin selesinin üzerine yağmur pelerini yerine küçük bir çatı kurmaya karar verdiniz, böylece müşteri artık ıslanmayacak. İşte bu bir kullanıcı hikayesi olurdu. Ancak şimdi, öncelikle çatının takılabileceği daha sağlam bir sele geliştirmeniz gerektiğini fark ettiniz. Bu farklı bir Kullanıcı Hikayesi olacaktır. Her iki hikaye de birbirinin üzerine inşa edilir. Önlemeniz gereken şey tam olarak budur.

Elbette, bazen bir kullanıcı hikayesini diğerinden önce yapmanız kaçınılmaz olabilir. Ancak genel bir kural olarak, öncelikle 20 başka kullanıcı hikayesini uygulamanız gereken kullanıcı hikayelerinden kaçının.

Pazarlık edilebilir: Kullanıcı hikayeleri yazmak bazen oldukça uzun sürebilir - bu nedenle daha sonra taşa kazınmamalıdır. Bu şu anlama gelir: Ürün Sahibi Paydaşlar ve geliştiriciler her zaman bir kullanıcı hikayesini birlikte tartışmalı ve geliştirmelidir. 

Değerli: Çevik proje yönetiminde kullanıcı hikayelerinin sonucu müşteri için katma değere sahip olmalıdır.

Tahmin edilebilir: İkna edici bir kullanıcı hikayesi, geliştirme ekibinin bunu uygulamak için ne kadar çaba harcayacağını tahmin etmesini sağlar.

Küçük: Bir kullanıcı hikayesi, tek bir sprintte gerçekleştirilebilecek kadar “küçük” olmalıdır.

Test edilebilir: Scrum’daki kullanıcı hikayeleri test edilebilir olmalıdır. Pratikte gerçekten uygulanıp uygulanamayacaklarını kontrol etmenin tek yolu budur.

Agile’de kullanıcı hikayeleri yazmaya aşina değilseniz, bunlar size fazladan iş gibi görünebilir. Ancak kullanıcı hikayeleri, ekiplere görevleri için önemli bir bağlam sağlayarak her bir görevin önemini daha da netleştirir.

Temel olarak, Kullanıcı Hikayelerinden bu şekilde faydalanırsınız:

Kullanıcı odağı: Kullanıcı hikayeleri, sorun odaklı bir yapılacaklar listesi gibidir. Ekibiniz bunları görevlerini takip etmek ve kullanıcıların ihtiyaçlarını tam olarak nasıl karşılayacağını bilmek için kullanabilir.

Bütünsel işbirliği: Kullanıcı hikayeleri, ilgili herkese bir bakışta işlerin nereye gittiğini gösterir. Bu şekilde, herkes bir araya gelerek kullanıcının nasıl özellikle yüksek katma değer elde edeceğine tekrar tekrar karar verebilir. 

Yaratıcı çözümler: Agile Yazılım Geliştirmede Kullanıcı Hikayeleri Oluşturma yaratıcı sonuçlar . Çünkü: Ekiplerin nihai ürün için en iyi çözüm hakkında eleştirel düşünmelerini sağlarlar.

Tutarlı başarılar: Her Kullanıcı Hikayesi küçük bir meydan okumadır. Bu nedenle ekipler her hikayeden sonra küçük bir başarıyı kutlayabilirler. Bu da tüm geliştirme süreci boyunca motivasyon sağlar.

Kullanıcı hikayeleri, çevik ekiplerin çalışmalarında önemli bir araçtır. Kimin için neyi neden geliştirdiğinizi size tekrar tekrar ayrıntılı olarak gösterirler. Bu sadece hedef kitleye uygun yüksek kaliteli bir ürün yaratmanıza yardımcı olmakla kalmaz, aynı zamanda ekibin tüm süreç boyunca motive olmasını sağlar. 

Çevik çalışmanın bu makro düzeyinde başarılı olabilmeniz için kuruluşunuzun bir bütün olarak çevik bir şekilde düşünmesi ve çalışması gerekir. Sizi ve kuruluşunuzu bu konuda desteklemek için, tanınmış uzmanlarla birlikte çalışarak şunları oluşturduk Scagile Projesi tasarlanmıştır. Bu, çeşitli web seminerlerinde size çevik bir dönüşüme nasıl doğru bir şekilde yaklaşacağınızı gösterir. Eğitim ücretsizdir. Bir göz atmaktan çekinmeyin!

Geriye dönük incelemeleriniz için daha çeşitli sorular istiyorsanız, bu konudaki yazımıza göz atın: 54 yeni başlayanlar ve profesyoneller için yeni retrospektif teknikleri (diğerlerinin yanı sıra Mario Kart Retro, Marathon Retro ve Elon Musk Retro ile).

Ekip üyelerinin çevik düşünce yapısını sürdürülebilir bir şekilde geliştirmenin en iyi yöntemlerinden biri, çevik bir Sağlık Kontrolü uygulamaktır. Bizim ücretsiz Team-Health Check yapım kiti doğru soruları sormanıza yardımcı olabilir - sadece tıklayın.