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.
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.
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:
Ö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 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:
Bu hikayeler, sohbete ve aşağıdaki gibi sorulara davet etmelidir:
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: