Kullanıcı Hikayeleri Nasıl Yazılır: Eksiksiz Bir Kılavuz

Kullanıcı hikayeleri, uygun çevik yazılım geliştirmenin hayati bir parçasıdır: Rollerine bakalım ve kullanıcı hikayelerinin nasıl yazılacağını öğrenelim.

Çevik çerçeveler, yazılım geliştirmeyi yapılandırmanın ve görevleri devretmenin popüler ve etkili bir yoludur. Kullanıcı öyküleri yazmak (bir referansın nasıl yazılacağıyla karıştırılmamalıdır), geliştiricilerin ne yapılması gerektiğini ve bir gereksinimi nasıl yerine getireceklerini anlamalarına olanak tanıyan çevik geliştirmede bir araçtır. Bu onları çok önemli bir başlangıç ​​noktası yapar ama aynı zamanda dikkatli bir şekilde inşa edilmeleri gerektiği anlamına gelir. İşte bilmeniz gerekenler.

Kullanıcı Hikayesi nedir?

Çevik bir çerçevede yazılım geliştirmede kullanılan bir terimdir. Kullanıcı hikayesi, genellikle çevik projedeki en küçük birim veya bir gereksinimi karşılamanın ilk adımı olarak kabul edilir. Bir proje tamamen planlandığında oluşturulurlar.

Peki bu tam olarak ne anlama geliyor? Her yazılım özelliği, bir projeye eklendiğinde belirli bir amaca sahiptir (veya sahip olmalıdır). Bu amaç, tüm gelişimini ve genel çerçeveye nasıl dahil edildiğini etkilemelidir. Geliştiriciler, özellikle hedeflerin nasıl parçalara ayrılacağı ve neye öncelik verileceği konusunda karar vermek için gerektiğinde bu amaca başvurabilir. "Kullanıcı hikayesi", basitçe bir özelliğin amacını açıklamanın bir yoludur.

Kullanıcı hikayeleri, bir kullanıcının bakış açısıyla, genellikle sadece bir veya iki cümleyle yazılır. Kullanıcının bakış açısını ve kullanıcının ne yapmak istediğini yakalarlar. Tamamlandığında, iyi kullanıcı hikayeleri, stratejik hedefler, hangi özelliklerin güvenli bir şekilde atılabileceği veya eklenmesi gerektiği ve çok daha fazlası hakkında konuşmanın kolay bir yoludur.

Kullanıcı Hikayesi Nasıl Yazılır?

Adım 1. Girdi Alın

Sahiplerden, olası kullanıcılardan ve proje yöneticilerinden Görüş Alın. Güçlü bir kullanıcı öyküsünün doğru olması için çok fazla girdiye ihtiyacı vardır. Bu gruplardan ne yapmak istediklerine dair net açıklamalar alın. Bunun doğrudan kullanıcı hikayesine çevrilmemesi gerektiğini, ancak gerekli bilgileri sağlayacağını unutmayın. Bir sahip, "Uygulamam üzerinde PayPal ile ödeme yapabilmek için insanlara ihtiyacım var" diyebilir, bu çok yararlıdır, ancak kullanıcı öyküsünün kendisi değildir.

Adım 2. Kullanıcı Hikayelerinin Nasıl Oluşturulacağına Karar Verin

Bu, iş akışınıza bağlıdır. İlk aşamalarda, genel çerçeve planlanırken kullanıcı hikayeleri dizin kartlarına veya post-it'lere kaydedilir. Daha sonra, proje yönetimi yazılımına dahil edilirler. Bazı ekip üyeleri post-it aşamasını atlarken diğerleri sizin için hangisi uygunsa ona güveniyor.

Adım 3. Tanımla, Tanımla, Tanımla

Kullanıcıyı tanımlayın: Giriş ile artık kullanıcıyı tanımlayabilirsiniz. Bu kişinin her zaman ürün özelliklerinin son kullanıcısı olmadığını unutmayın; kullanıcı tipine göre değişebilir. Gerekirse kullanıcı karakterleri oluşturun. Kullanıcının gerçekleştirdiği eylemi tanımlayın ve kullanıcının bu eylemi gerçekleştirmekteki amacını belirleyin. Hedef kitlenizle konuşmak için kullanıcı hikayenizi oluştururken bu önemli bilgileri ekleyin.

Adım 4. Hikayeyi Yazın

Kullanıcı hikayenizi yazmaya başlayın, okuyucunun dikkatini çekmek için sadece bir veya iki cümle uzunluğunda olmalıdır. Burada kesin ve teknik olmak cezbedicidir, ancak misyon ifadeleri gibi geniş bir dil yardımcı olabilir. Hikayeyi netleştirin ve çözülebilir veya tamamlanabilir olduğundan emin olun, böylece geriye bakıp "Evet, kullanıcılar artık bunu yapabilir!"

Adım 5. Diğer Adımlara Bölün

Kullanıcı hikayeleri, nihai hedefe ulaşmak için birden fazla adım gerektirebilir ve bu, kullandığınız çevik çerçeveye bağlı olarak biraz yeniden yapılandırma gerektirebilir. Unutmayın, kullanıcı hikayesi her zaman çerçevedeki en küçük birimdir. Bu ayrıntılı düzeyde, kullanıcı hikayelerinin uygulanması birkaç gün sürmelidir.

Önemli ölçüde daha uzun sürecek gibi görünüyorsa, bu, kullanıcı deneyiminin daha fazla parçalanması ve yeniden yapılandırılması gerekip gerekmediğini yeniden gözden geçirmek için bir işarettir. Yeni gereksinimler eklenirse, bunların da kullanıcı hikayelerine bölünmesi gerekir. Bu birkaç cümle, etkili kullanıcı hikayelerinin özü olsa da, geliştirme ilerledikçe genişletilebilir. Buna daha yakından bakalım.

Kullanıcı Hikayelerindeki 3C nedir?

Kart : Kart aşaması, geliştirme ekibi için bir veya iki cümlelik kullanıcı hikayeleri yazmayı ifade eder. Buna kart denmesinin nedeni, kullanıcı hikayelerinin orijinal olarak dizin kartlarına yazılması ve birçok takımın hala bu şekilde yapmayı tercih etmesidir. Kart, özel yazılım gereksiniminin özü ve tüm tartışmaların başlangıç ​​noktasıdır. Kullanıcı hikayenizin çok uzun olup olmadığını kontrol etmek de kolaydır - herkesin okuyabileceği bir dizin kartına sığmıyorsa, kısaltılması gerekir.

Konuşma : Kart cümleleri oluşturulduktan sonra, ayrıntıları belirleme zamanı. Bu genellikle geliştiriciler arasında "Bunun uygulanması ne kadar sürer?" gibi bir dizi soru olarak başlar. veya "Bu eylemi nasıl dahil edebiliriz?" veya "Bu kullanıcı hikayesi burada önemli mi?" Ve bunun gibi.

Kullanıcı hikayesinin bu yakından incelenmesi, gerektiğinde konuşmaya dahil edilmesi gereken proje yöneticilerine ve ürün sahiplerine sorulacak ek sorular ortaya çıkaracaktır. Konuşma devam ederken, herkes aynı sayfada olana kadar kullanıcı hikayeleri değiştirilebilir, rafine edilebilir, birleştirilebilir veya kaldırılabilir. Kullanıcı hikayeleri sonlandırıldıkça, uygulamaya taşınırlar, bu da Konuşmanın esasen bittiğinin bir işaretidir.

Onay : Onay tamamen kabul testleri, yani kabul kriterleri ile ilgilidir. Değişiklik uygulandıktan ve geliştiriciler hazır olduğunu, yani kullanıcı öyküsünün tatmin edildiğini bildirdikten sonra, şimdi onu test etme zamanı.

Kabul testleri, ürün sahibinin girdileri ile oluşturulmalı ve doğrudan kullanıcı hikayesine bağlanmalıdır. En iyi senaryoda, kullanıcı hikayesinin gösterdiği şeyi yapmaya çalışan ve yapıp yapamayacağını gören bir kullanıcıdır. Ancak kabul testleri değişebilir ve her zaman olması gerektiği gibi kullanıcı hikayeleri göz önünde bulundurularak yapılmaz. Bu bir sorun yaratırsa, kabul testleri ve kullanıcı hikayeleri uygun şekilde hizalanana kadar Konuşma adımına geri dönme zamanı. Tüm kabul testleri tamamlanırsa, kullanıcı hikayesi memnun olur. Şimdi ya ürün geliştirmede bir sonraki adıma geçme ya da özelliği yayınlama zamanı.

4.C mi? : İlginç bir şekilde, bazıları temel bir 4. C: Bağlamı olduğunu iddia ediyor. Bu durumda, kullanıcı hikayesi, projenin daha büyük çerçevesindeki diğer kullanıcı hikayeleriyle birlikte görüntülenir. Burada geliştiriciler, kullanıcı hikayesinin diğer kullanıcı hikayelerini sorunsuz bir şekilde tamamlayıp tamamlamadığını veya boşluklar olup olmadığını (kullanıcının yapması veya anlaması gereken, kullanıcı hikayeleri arasında gözden kaçan şeyler) olup olmadığını sorar.

İdeal olarak, bu, Konuşma aşamasında fark edilir, ancak bu her zaman olmaz. Bazı geliştirme ekipleri, tamamlanan kullanıcı öyküsünün daha büyük bütüne nasıl uyduğuna ve daha fazla çalışma yapılması gerekip gerekmediğine dair son bir inceleme isteyebilir.

Bir Kullanıcı Hikayesi İçin İyi Bir Format Nedir?

Kullanıcı hikayesi cümleleri oluştururken çok yardımcı olan iki biçimlendirme tekniğini inceleyelim. İlki çok basit: “Kim, Ne ve Neden?” Bir cümle şablonunda bu şu şekilde açıklanabilir:

[Kullanıcı kimdir] olarak, [Kullanıcı Ne İstiyor] istiyorum (böylece [Kullanıcı neden istiyor]).

Bu şablon aynı zamanda basitleştirilmiş terminoloji için "[rol] olarak, [eylem] yapmak istiyorum (böylece [fayda])," şeklinde çerçevelenebilir. Bu temel formatı takip etmek, kullanıcı hikayelerinin çoğunu oluşturmak için yeterlidir. Genellikle ihtiyacınız olan tek şey budur ve her kullanıcı hikayesi için kullanıldığında çok zaman kazanmanıza yardımcı olabilir.

Ancak bazen, daha karmaşık projelerde kullanıcı hikayelerini tanımlamak daha zordur. Bu durumda, ikinci bir kullanıcı hikayesi şablonu tekniği yararlı olabilir. Buna, şu anlama gelen bir kısaltma olan INVEST denir:

• Bağımsız : Hikayeler birbirinden tamamen bağımsız olmalı ve sonuç olarak hikayeler sıra dışı çalışabilmelidir.
• Tartışılabilir : Hikayeler, sürecin Konuşma bölümünde değiştirilecek şekilde tasarlanmalıdır.
• Değerli : Kullanıcı hikayesi, proje için net bir değer göstermelidir. Eğer yapamazsa, kaynak israfı olabilir.
• Tahmin edilebilir : Önem sırasına göre neyin üzerinde çalışılacağına karar vermeye yardımcı olması için bir kullanıcı öyküsünün değeri ve önceliklendirmesi ölçülmelidir.
• Küçük : Kullanıcı hikayeleri, işlevselliğin en küçük birimi olmalıdır ve aksi takdirde daha fazla parçalanmalıdır.
• Test Edilebilir : Onay sürecinde kullanıcı hikayesi test edilebilir bir şekilde belirtilmelidir.

Kullanıcı Hikayelerinin Nasıl Yazılacağına İlişkin SSS

Nasıl oyun incelemesi yazılacağına ilişkin rehberimiz de ilginizi çekebilir.