Kullanıcı Hikayelerini Tanımlama ve Çevik Geliştirme
Modern geliştirme süreçlerinin temel ilkesi çevik geliştirmedir . Bu geliştirme metodolojisi, bir sistemin ne yaptığını teknik açıdan değil, kullanıcı açısından tanımlamak için küçük, küçük kullanıcı hikayeleri kullanmayı vurgular. Bir kullanıcı, bir ürünün hızlı, kullanımının kolay olup olmadığını önemser ve sorununu çözer. 3 katmanlı bir mimariye sahip olması, Mongo DB'ye sahip olması veya Rails veya Asp.net kullanması umurlarında değil.
Kullanıcı hikayeleri:
- Anlaşılması kolaydır ve herkes katılabilir
- Yinelemeli çalışın; sık sık değiştirilebilir veya değiştirilmelidirler
- Geliştiricileri, kullanıcıları ve iş uzmanlarını ortak hedefler ve beklentiler etrafında hizalayın
- 400 sayfalık gereklilik belgelerini okumaktan çok daha kolaydır
Storyboard That , çevik kullanıcı öyküleri oluşturmak ve bir metin duvarından çok daha az zahmetli bir biçimde sohbet başlatmak için ideal bir platform sağlar.
Epik
Kullanıcı hikayeleri bağlamında, bir "epik" , daha sonra birçok belirli kullanıcı hikayesine bölünecek olan çok geniş bir hikayedir. Bir destanla başlamak, herkesi tek, üst düzey bir vizyonla hizalar. Destansı hikaye, bir projeyi tepeden tırnağa demirler ve bir destan inşa etmek mantıklı değilse, destekleyici çalışma da boşa çaba olacaktır.
Bu hikayede uzun vadeli vizyonun ne olduğu ve başarının nasıl olması gerektiği çok açık. İyi bir epik hikaye şunları içermelidir:
- Ayar veya Bağlam
- Aktörler veya Kullanıcılar
- Amaçlar ve hedefler
- Faaliyetler ve Etkinlikler
Kullanıcı Tanımlama
Özellikle yazılım tasarlarken, kullanıcıların nasıl olacağına dair iyi bir vizyona sahip olmak önemlidir. Her kullanıcı bu vizyona tam olarak uymayabilir ve birden çok kullanıcı kategorisi olabilir, ancak bu ayrık vizyonların ifade edilmesi gerekir. Kullanıcıları düşünmek, öncelikle aşırı mühendislik ve aşırı karmaşıklığa karşı koruma sağlar, yeni bir ürünün herkes için bir şeye sahip olmasını ve kimseye yararlı olmasını engeller.
Bir Hikaye Yaratmak
Bir destan oluşturulduktan ve kullanıcılar tanımlandıktan sonra, belirli kullanıcı deneyimleri hakkında daha küçük, daha spesifik hikayeler oluşturulabilir. Aşağıdaki hikayeler, yukarıda özetlenenleri iki anlatıya ayırır: bir siparişi aramak ve bir ürünü yeniden sipariş etmek.
Bu anlatımlar teknik bilgi içermez; İstenen görevleri yerine getirdiği sürece sonuçların nasıl elde edildiği kullanıcılar için önemli değildir. Benzer şekilde, yeniliği boğmaktan veya bir yolu zorlamaktan kaçınmak için UX genel olarak tasvir edilmiştir. Genel olarak, hikayeler şöyle olmalıdır:
- Küçük – 10 günden az çalışma
- Değerli - Tamamlandıktan sonra kullanılabilir bir şey teslim etmelidirler
- Tahmin edilebilir – Ne kadar efor sarf edildiğine dair bir tahmin oluşturabilme
Sipariş Arıyorum
Yeniden Sıralama Gerçekleştirme
Konuşma ve Test İçin Planlama
Bu hikayeler, sohbete ve aşağıdaki gibi sorulara davet etmelidir:
- Bunlar bizim destanımıza uygun doğru hikayeler mi?
- Başka hangi hikayeler yaratılmalı?
- Bu hikayeler, kullanıcılarımız hakkında bildiklerimizle tutarlı mı?
Pek çok hikaye yaratmak tamamen mantıklıdır; aslında teşvik edilmelidir. Bu hikayelerden bazıları asla kullanılmayacak, ancak koydukları yolu görmek önemlidir. Bu hikaye koleksiyonu, ek gereksinimleri ortadan kaldıracak ve testi etkileyecektir.
Hikayeler, yazılımın nasıl test edileceği ve hangi iş kurallarının açıkça tanımlanması gerektiği hakkında tartışma başlatmalı ve bilgi vermelidir. Örneğin:
- Bir aramanın ne kadar hızlı olması gerekir?
- Yeniden siparişlerde bir zaman sınırı var mı?
- İkinci yeniden sipariş ise sistem ne yapmalıdır? Beşinci?
- Hangi testler ve takip soruları olurdu?
© 2024 - Clever Prototypes, LLC - Tüm hakları Saklıdır.
StoryboardThat , Clever Prototypes , LLC ticari markasıdır ve ABD Patent ve Ticari Marka Ofisi'ne kayıtlıdır.