Kullanıcı hikayesi, özellik ve epik arasındaki ilişki?

Hala çevik olmak için yeni olan biri olarak, kullanıcı hikayesi, özellik ve epik arasındaki ilişkiyi veya farkı tamamen anladığımdan emin değilim.

Bu soruya göre , bir özellik hikaye koleksiyonudur. Cevaplardan biri bir özelliğin aslında bir epik olduğunu gösteriyor. Öyleyse, özellikler ve destanlar aynı şey olarak mı kabul edilir?

Proje yöneticimiz hiyerarşik bir yapı olduğuna ısrar ediyor:

Epic -> Özellikler -> Kullanıcı hikayeleri

Ve temel olarak, tüm kullanıcı hikayeleri bu yapıya girmelidir. Bu nedenle, tüm kullanıcı öyküleri bir şemsiye özelliğinin altına girmeli ve tüm özellikler bir destan altına düşmelidir.

Bana göre bu kulağa garip geliyor. Birisi lütfen kullanıcı hikayelerinin, özelliklerinin ve destanlarının nasıl ilişkili olduğunu netleştirebilir mi? Yoksa farklılıkları açıkça belirten bir makale var mı?

Aslında çok genel bir terimdir. Onları yorumlamanın, edebiyatta ve insanların onları nasıl gördüğünü değiştirmenin birçok yolu vardır. Söylediğim her şeye kocaman bir tuz damlası al.

Genellikle, bir Epic yazılımınızda çok küresel ve çok iyi tanımlanmamış bir işlevsellikten oluşur. Çok geniş. Bunu anlamayı ve çevik bir yinelemeye uydurmayı denediğinizde genellikle daha küçük kullanıcı hikayesi veya özelliğine bölünür. Örnek :

Epic
- Müşterinin Web üzerinden kendi hesabını yönetmesine izin ver

Özellik ve Kullanıcı Hikayesi, kabul testleriyle kolayca test edebileceğiniz daha özel işlevlerdir. Genellikle tek bir yinelemeye sığacak kadar granül olmaları önerilir.

Özellikler genellikle yazılımınızın ne yaptığını açıklama eğilimindedir:

Özellik
- Müşteri bilgilerini web portalı üzerinden düzenleme

Kullanıcı hikayeleri, kullanıcının ne yapmak istediğini ifade etme eğilimindedir:

Kullanıcı hikayesi
Banka sorumlusu olarak,
müşteri bilgilerini değiştirebilmek ve
böylece bilgileri güncel tutabilmek istiyorum.

İkisi arasında gerçekten bir hiyerarşi olduğunu düşünmüyorum, ancak istersen veya nasıl çalıştığına uygunsa birini alabilirsin. Bir kullanıcı hikayesi, bir özellik için belirli bir gerekçe ya da bunu yapmanın belirli bir yolu olabilir. Ya da tam tersi olabilir. Bir özellik, bir kullanıcı hikayesini gerçekleştirmenin bir yolu olabilir. Veya aynı şeyi gösterebilirler. Her ikisini de kullanabilirsiniz: Yazılımın kısıtlamasını tanımlamak için işletme değerini ve özelliğini getiren özelliği tanımlayan kullanıcı hikayeleri.

Kullanıcı hikayesi : Bir müşteri olarak, en popüler kredi kartlarıyla ödeme yapmak istiyorum
Özelliği hükümetin GOV-TAX-02 XML API'sini destekliyor.

Ayrıca bir Özellik / Kullanıcı hikayesinin yürütülmesinin bir yolu olan senaryo sorusu da vardır. Genellikle belirli bir kabul testine temiz bir şekilde eşlenirler. Örneğin

Senaryo : Para çekme
Banka hesabımda 2000 $ olduğu için
100 $ çekildiğimde 100 $
nakit alırım
Ve bakiyem 1900 $

Yani, biz bu terimleri anladığım bu işe . Bu tanımlar matematiksel bir tanımdan veya standart bir terimden uzaktır. Bir sağ kanat politikacı ya da bir sol kanat politikacı arasındaki fark gibidir. Nerede yaşadığına bağlı. Kanada'da, sağ kanat olarak kabul edilenler Birleşik Devletlerde sol kanat olarak kabul edilebilir. Çok değişken.

Cidden, bunun için fazla endişelenmem. Önemli olan, ekipteki herkesin bir tanım üzerinde hemfikir olmanızdır. Scrum gibi bazı yöntemler onları daha resmi olarak tanımlama eğilimindedir, ancak sizin için neyin işe yaradığını seçin ve gerisini bırakın. Sonuçta, yaklaşık çevik değildir süreçleri ve araçları üzerinde Bireyler ve etkileşimler ve kapsamlı belgeler üzerinde çalışma yazılımı ?

Epic : Sonunda daha küçük hikayelere bölünmüş olan çok büyük bir kullanıcı hikayesi.

Kullanıcı hikayesi: Geliştiricilerin uygulama çabasını makul bir şekilde tahmin edebilmeleri için yeterli bilgi içeren çok yüksek düzeyde bir gereksinim tanımı.

http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx

Özellik : Bir yazılım uygulamasının veya kütüphanenin ayırt edici bir özelliği veya kabiliyeti (örneğin, performans, taşınabilirlik veya işlevsellik).

http://en.wikipedia.org/wiki/Software_feature

Bu şartlara çok katı bir hiyerarşi uygulaması konusunda sizi uyarıyorum. Bunu önceki işimde yapmaya çalıştık. İki defa. Her iki girişim de farklıydı ve her iki seferde de kendimizi gereksiz yere sınırladığımızı tespit ettik. Tek sabit Kullanıcı Hikayesinin tanımıydı . Planlama açısından bakıldığında, hikaye bir projenin temel yapı taşıdır. Daha büyük terimler (epik, özellik vb.) Etkili bir şekilde sadece etiketlerdir . Etiketler, aynı anda birden fazla Epik ve birden fazla Özelliğin parçası olarak bir hikayenin varolmasına izin vermenin kolay bir yoludur. Bundan daha katı olması zihinsel çabaya değmez.

Etiketler Stack Exchange için çalışır ve sizin için de çalışabilirler.

Destanlar, Hikayeler ve Özellikler ile çalışma şeklimiz aşağıdaki gibidir

Proje döngüsünün başında Epics ile karşılaştık . Bunlar çok yüksek seviyeli, neredeyse pazarlama merkezli, işlevselliğin kurşun noktasıdır. Örneğin, yönetici özeti olarak kullanabileceğiniz bir şey,

Yeni web sitemiz müşterilerin ürünlere göz atmalarına, müsaitlik ve fiyatlandırmalarını görüntülemelerine, sipariş vermelerine ve geçmiş sipariş geçmişlerini görmelerine izin verecek

Bu gibi Epics yol açar

• Ürün Kataloğuna Göz Atın
• Uygunluğu Görüntüle
• Fiyatlandırmayı Görüntüle
• Sipariş Vermek
• Sipariş Geçmişini Görüntüle

Bunlar kullanıcı hikayeleri olarak yazılmıştır (örneğin, bir müşteri olarak, ürün kataloğuna göz atmak istiyorum, böylece bilinçli bir satın alma kararı verebilirim), ancak gerçekte geliştirilip piyasaya sürülecekler için yalnızca on kişilik bir başlangıç ​​olarak hizmet vermektedir.

Bu Destanlar daha sonra Kullanıcı Hikayelerine bölünür . Bunlar gerçek uçtan uca kullanıcı seyahatleridir, kapsamları çok sınırlıdır ve bağımsız olarak tahmin edilebilecek ve planlanabilecek ve bir sürüm döngüsünde geliştirilebilecek , test edilip serbest bırakılabilecek şekilde tanımlanır .

Kullanıcı Hikayesi, teslimat birimidir. Tamamlanmış veya tamamlanmamış, canlı yayına girmeyen veya yayılmayan kullanıcı hikayesidir.

Bir Epic, çok sayıda kullanıcı hikayesine neden olabilir, hepsi aynı anda geliştirilmez veya yayınlanmaz.

Örnek olarak, Ürün Kataloğuna Göz At epik bölünebilir

• Kategori Hiyerarşisinde Gezin
• Anahtar Kelime İle Ara
• Ürün Özelliklerine Göre Filtrele (örn. Fiyat aralığı, marka, renk, boyut vb.)

Yine, bunların her biri, örneğin bir müşteri olarak, kategori hiyerarşisinde dolaşmak istiyorum, böylece ürünlere göz atabilir ve ihtiyaçlarım için en uygun ürünü inceleyebilirim.

Genel olarak, projelerimizin çoğu için onlarca Epik ve yüzlerce öykümüz var.

Şimdi, hikaye yaşam döngüsünden geçerken, bu hikayeleri Feature s ile etiketliyoruz . Örneğin, tüm göz at ve arama ve stok ve fiyatlandırma hikayeleri 'ürün kataloğu' ile etiketlenecek. Kredi Kartı ile ödemeyle ilgili Sipariş Verme hikayeleri bir 'kredi kartı' etiketi ile etiketlenebilir ve PayPal ile ödeme yapacak olanlar bir 'paypal' etiketi ile etiketlenir.

Bu etiketler, aynı faaliyeti gerçekleştiren farklı türler oldukları (örneğin tüm yer sırası öyküleri) olduğu için değil, birlikte serbest bırakılmaları gerektiği için birbirine ait öyküleri bir arada gruplandırmaya yarar.

Örneğin, "kredi kartıyla ödeme talimatı vermek" hikayesi "PayPal ile ödeme talimatı vermek" hikayesiyle aynı destansı altındadır, ancak birlikte serbest bırakılmaları gerekmez.

Oysa, "kredi kartıyla ödeme yapan bir sipariş vermek" hikayesi, "kredi kartına geri ödeme iadesi işleme" hikayesi ve "müşterilerin kaydedilmiş kredi kartlarını hesaplarında yönetmelerine izin verme" hikayesi birbirine benziyor . Hepsi 'kredi kartı' özellik etiketi ile etiketlenmiş olurdu. yani hepsi "Kredi Kartı" özelliğine aittir. PayPal'a iade iadesi yapmak mümkün değilse veya hesabınızdaki kayıtlı Kredi Kartlarınızı yönetmek mümkün değilse, Kredi Kartı ile ödeme yapma emri verme kabiliyetini serbest bırakmak çok yararlı değildir.

Not : Genel bir kural olarak, bu. Bu, sonuçta, bir iş kararıdır. Pazara çıkma zamanı önemliyse, bunlardan biriyle değil, biriyle yaşamaya meşru bir sebep olabilir.

Böylece, Epics, bağımsız olarak geliştirilebilecek (ilişkili, ancak ayrı) hikayeleri parçalamaya hizmet ederken, Özellikler birlikte yayınlanması gereken hikayeleri birlikte gruplamaya yarar.

Epics’in Kullanıcı Hikayeleri’nde parçalandığını ve Kullanıcı Hikayeleri’nin Özellikler’de oluştuğunu söyleyebilirsiniz. Bir özelliğe ait hikayeler genellikle Destanlar arasındadır. Bu nedenle, Destanlar ve Özellikler katı bir hiyerarşide değil, ortogonaldir.

Bizim çalışma biçimimizde, Destanlar hikayelere bölündükten sonra, amaçlarını kaybederler. Destanları tahmin etmiyor veya planlamıyoruz. Epics'teki ilerlemeyi takip etmiyoruz. Epics'i serbest bırakmayız. Kullanıcı Hikayelerini tahmin ediyoruz, planlıyor ve takip ediyoruz. Ve biz Özellikler serbest bırakıyoruz.

Doğru cevapların bulunmadığına dair pek çok yanıt gibi aynı fikirdeyim, çünkü bunlar sadece sizin hangi Çevik kampa dayandığınıza bağlı olarak değiştirilebilecek terimlerdir ve dış paydaşlar dahil ekibinizdeki herkes sürece kesinlikle kendi kampınızı oluşturabilirsiniz. ne anlama geldiklerini anlayın. Bu sadece ihtiyacınızı organize etmenin bir yoludur.

Sevdiğim cevap Mike Cohn'un kampından ve oldukça basit.

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

• Epik sadece büyük bir hikaye (hiyerarşik)
• Tema sadece bir grup Hikaye (hemen hemen etiketi gibi)

Aslında “Özellik” teriminden kaçınıyor. Bunun geleneksel şelale dünyasında ortak bir terim olduğu için olduğunu varsayıyorum. Birçok Çevik kamp, ​​farklılıkları vurgulamak için farklı terimler kullanma eğilimindedir.

Öyleyse, Başbakanınızın tanımında, Özellik Epic-Story hiyerarşisinin ortasında bir yerdedir.

İşte benim InfoQ makalemden bu tanımın bilgi grafiğim http://www.infoq.com/articles/visualize-big-picture-agile ;-)

Özellikler ve Destanlar aynı şey değil.

• Özellik bir Kullanıcı Hikayesi değildir.
• Bir Destan, bir Kullanıcı Hikayesidir.
• Bir Kullanıcı Hikayesi bir Destan olabilir.
• Bir Kullanıcı Hikayesi birçok Özellik içerebilir.
• Bir Özellik 1 ila Birçok Kullanıcı Hikayesi gerçekleştirebilir.

Planlama aşamalarında, tartışmalar neden Düşünceler typicaly olarak tanımlanır Destanları onları birkaç gün içinde başarmak için çok büyük için çaba çözümleri uygulamak için çünkü. Ürün Özellikleri bu aşamada tanımlanır. Ama bu sadece tartışmanın bir yan ürünü. Özellikler daha sonra ayrı bir tartışma olan bir ürün yol haritasını planlamak için kullanılır.

Epics alınmış ve sonuçlanan daha geniş ele alınmıştır Düşünceler her Epic. Özellikler ve Destanlar tartışmaları sürmek için kullanılan Backlog Sadeleştirme ve Sprint Planlama oturumları. O zaman bu tartışmalardan çıkan Kullanıcı Öyküleri inceliklendirilir , önceliklendirilir ve Sprint Planlama'da uygulama için sprint olarak kabul edilir.

Sadece sorun ayrıştırma. Onlar farklı boyutlar dışında sadece hikayeler.

Ben şahsen bedenlerini etiketlememeyi tercih ederim, ama bunu yaparsanız iyi. PM'ye, çalışma alanınızdaki tanımın ne olduğunu sorun.

Kuruluşumuzda 2.000'in üzerinde geliştirici var. Bu sorunun cevabı ortak ürünümüz üzerinde birlikte çalıştığımız yüzlerce Çevik ekip arasındaki akıcı ve net iletişim için önemlidir. Çok küçük bir organizasyon için, hiyerarşik olması gerekmeyen (başkalarının cevapladığı gibi) çok basit bir yapıya sahip olabilirsiniz. Bununla birlikte, büyük organizasyonlar için, bazı organize, ölçeklendirilmiş, tutarlı bir hiyerarşi için kesinlikle bir ihtiyaç vardır - ve burada kesinlikle hiyerarşik olmayan bir şeyden hiyerarşi yapma çabasında sorun vardır.

Bu arada, bu farklı seviyelerin her birine "iş kalemleri" diyoruz. Bazı kuruluşlar (yukarıdaki yanıtlayanların bazıları da dahil) farklı seviyelere Hikayeler veya Kullanıcı Hikayeleri olarak atıfta bulunur (ve biz de geçmişte kaldı), ancak bunu çok belirsiz bulduk, bu yüzden şimdi onlara genel olarak İş Öğeleri adını veriyoruz.

Şimdiye kadar "resmi olarak" yaptığımız en iyi şey, Dean Leffingwell'in SAFe Yatırım Temaları ve İş Destanları'nın yapısını, hiyerarşinin tepesinde (ve en başından ikinci), sonra bunun altındaki Özellikler ve son olarak da Özellikler altındaki Hikayeler olarak takip etmektir. Çevik'e göre, Görevler her zaman Hikayeler altındadır, bu yüzden daha yüksek bir terimi tekrar kullanmamaya özen gösteriyoruz. Tüm ekiplerimizde en azından SOME tutarlılığına sahip olmak için SAFe'yi izlemeyi seçtik.

Ancak bu ihtiyaçlarımız için hala yetersiz. Bir Özelliği, yazılım ürünümüzün bir tüketicisi için açık bir şekilde değerli bir teslim edilebilir değer olarak tanımlıyoruz (yani, bu Özellikleri yaklaşmakta olan Bültenlerimizin duyurularında listeleriz). Ve bir Hikayeyi, tek bir Çevik ekip tarafından tek bir Sprint'te teslim edilebilecek daha küçük bir kapsam ve çalışma olarak tanımlarız. Ayrıca artık SAFe Yatırım Teması ve İş Destanı tanımını Portföy düzeyinde (bu seviyenin altında değil) takip etmeye başlıyoruz. Ve biz "Tema" ve "Epic" ESKİ tanımlarımızı kullanmaya BAŞLATMAKTAYIZ.

Şimdi yavaş yavaş bu yönde evrimleşiyoruz, ancak ilerlemenin tekerlekleri yavaşça taşlıyor. Çalışmayı ısırık büyüklüğüne ayırma konusunda hala mücadele ediyoruz, böylece işi tanımlayabiliyoruz ve birden fazla ekip tarafından sorunsuzca halledebiliyoruz. Bunu yapmak için, bir Özellikten daha küçük fakat bir Hikayeden daha büyük olan bir "Alt Özelliğe" ihtiyaç duyulduğunu görüyoruz. Alt Özellikler, EACH BİREYSEL ekip tarafından bir Özellik üzerinde yapılan çalışma parçaları veya farklı zamanlarda (farklı Sprint'ler ve hatta farklı Sürümlerde) bir SINGLE ekibi tarafından yapılan çalışma parçaları için kullanılabilir.

Ayrıca, Feature ve Business Epic arasında birden fazla hiyerarşik seviyeye ihtiyacımız var, ancak bunları henüz “Temalar” olarak adlandırmak dışında çözemedik - ki bu, doğru bir terim olmadığını biliyoruz, çünkü SAFe Yatırım Temaları ile kolayca karıştı. Bazı büyük projeler (sürümler) için her biri işi daha küçük ve daha küçük parçalara bölen 5-8 farklı hiyerarşik seviyeye sahibiz. Bu Temaları “Özellik Grupları” olarak düşünebilirsiniz, ancak bu da mutlaka doğru terim değildir.

Belirsizlikten ziyade netlik sunan terimleri kullanmaya çalışmanın önemli olduğunu düşünüyorum. Öyleyse, bir Hikayeye başvuran herkes, tek bir Sprint'te yapılabilecek en küçük çalışma birimi anlamına gelir (Öykü altındaki Görevler hariç) ve Alt Özellik, bir Özellik tarafından yapılan bir Özellik üzerinde en küçük çalışma birimi anlamına gelir. takım. Aynı şekilde, bir Özellik Grubu, Özelliğin üstündeki bir hiyerarşik seviyedir. Bunun üzerinde biraz bulanıklaşır, bu yüzden genellikle sadece Temalar olarak adlandırırız ve Temalara diğer Temaların ebeveynleri ve çocukları olarak izin veririz. Özellik, Alt Özellik ve Öykü düzeylerini her birini tek bir düzeyle sınırlamaya çalışıyoruz (Özellikler diğer Özelliklerin çocukları olmamalıdır), ancak bunu kısıtlama konusunda henüz% 100 başarılı olamadık.

Bunlardan bazılarını düzenlemek için "Etiketler" kullanabileceğimizi biliyorum, ancak etiketler bize çalışmaları tüm ekiplerimiz arasında kategorize etmemiz gereken örgütsel iş dağılımı yapısını vermiyor. Tanım olarak, etiketler belirsizdir (çoktan çoğa ilişkiler), ancak bir hiyerarşi kesinlikle bire çoktur.

Sonuç olarak, bu hala bizim için devam eden bir çalışmadır ve hala bununla mücadele ediyoruz. Fakat SAFe, Theme, Epic, Feature ve Story tanımlarına bağlı kalmak bizi doğru yönde hareket ettiriyor!

Ürün İş Listesi Hiyerarşisi, ürün boyutuna ve modülerliğine büyük ölçüde bağlıdır (tanımlanan ürün alanı sayısı).

Küçük Projeler için: Epic> Hikaye fazlasıyla yeterli; ve ya "özellik" diyorsun.
Büyük projeler şöyle olabilir: Roman> Tema> Epik> Özellik> Hikaye

En iyi örnek aşağıdaki olabilir:
Roman = MS Office
Teması = MS Word / MS Excel ...
Epic = Tablolar / Yazı Tipi Dizini ...
Özellikler = Temel Tablo / Tablo Renk Düzeni / Hücreli İşlemler ...
Hikayeler (için ' 'Tablolar' Destanındaki Temel Tablolar 'Özelliği) = Tablo Ekle / Tablo Çiz / Ham Ekle / Sütun Ekle ...

Biriktirme için kendi ölçeklemenizi tanımlarken akılda tutmanın faydalı olduğuna inandığım şey şudur:
1. Hikaye: a) bir sprint içinde her zaman uygulanabilir; b) son kullanıcılar için her zaman test edilemez
2. Epic / Feature: a) bir sprint süresine uymuyor ve ayrıştırılması gerekiyor; b) her zaman son kullanıcılar için test edilebilir olmalıdır; c) Her zaman gönderilebilir, para kazanmak için kullanılması - YG bunun için hesaplanan olsun
3. eklemek veya değil Destanını> değerlendirirken Özellik Öyküsü> bölümünü veya Destanı sopa: Ben Destanı ve Story sadece aradaki Özelliği eklemek için tavsiye ederim: Epik kokan t 1 Serbest bırakma bile olsa, 1 Serbest bırakma süresine uyacak sevk edilebilir öğeyi tanımlamanız gerekir .

Umarım bu yardımcı olur.

Kuruluşumuzda aşağıdakilere sahibiz:

Theme = Birlikte bir hikaye koleksiyonu gruplandırmak için kullanılır

Epic = Kullanıcı hikayelerine bölünmesi gereken büyük bir kullanıcı hikayesini (gerçekte bir gereklilik) açıklar

Özellikler = Teneke söylediklerini yapar, gereken ürünün bir özelliğini tanımlar.

Kullanıcı hikayesi = Bu, görevlerden elde edilen en düşük detay seviyesidir.