Kullanıcı hikayeleri ve özellikleri arasındaki fark nedir?

25

Buzlanma ile oynarken , kullanıcı hikayeleri ve kullanıcı özellikleri arasındaki farkı anlamadığımı anladım.

Birisi farkı açıklayabilir mi?

agile scrum features

— BЈовић
kaynak

23

Bir özellik, işletmeye yetenekler sağlayabilen farklı bir işlevsellik öğesidir.

Bir hikaye, paydaşlarınızdan geri bildirim almak ve yanlış bir şey yapıp yapmadığınızı öğrenmek için kullanabileceğiniz bir özelliğin küçük bir yönüdür.

Örneğin, bir özellik "kullanıcıların makaleler hakkında yorum yapmasına izin ver" olabilir. Bu özellik ile ilişkili hikayeler daha sonra olabilir:

yorumları kaydet
kaba kelimeler için yorumları filtrele
yorumları 400 karakterle sınırla ve kullanıcılara geri gönder
site spam spam botları durdurmak için captchas ekleyin
kullanıcıların Google kimliği ile giriş yapmasına izin ver

vb.

Her aşamada, aldığımız yönün yararlı olup olmadığı konusunda geribildirim alabiliriz.

Bazı takımlar, özellikleri hikayelere bölmekle uğraşmaz. Bu iyi.

— Lunivore
kaynak

13

Bu ilişkili hikayeler aslında kullanıcı hikayesi görevleri değil mi? Öyle diyebilirim. Bir kullanıcı hikayesi şöyle olacaktır: Bir kullanıcı olarak, makaleler hakkında yorum yapmak istiyorum, böylece kullanıcılar makale içeriğini iyileştirebilir veya endişelerini dile getirebiliriz. Bu kullanıcı hikayesi, tarif ettiğiniz görevlere bölünür ...

— Robert Koritnik

4

Geri bildirim almak için yapılması gereken ancak tek başına geri bildirim alamadığınız - örneğin bir veritabanı tablosu oluşturmak gibi bir görev olarak görüyorum. Bu hikayelerden herhangi biri, birincisi dışında, nakliyede değer kalmasına rağmen potansiyel olarak kaldırılabilir. Görevlerim dünyamda genellikle yatay olarak dilimleniyor. Ancak, farklı tanımlarınız varsa, sorun değil. Taneciklik tamamen ayrık bir şey değildir, her hedef bir başkasının alt yapısıdır ve bence sizin için pragmatik olan her şeyi yapmalısınız. Bu dökümü yararlı buluyorum, ekiplerimin çoğunda olduğu gibi.

— Lunivore

16

Özellikler == Kullanıcı Hikayeleri.

Verbiage, verilen belirli Çevik metodoloji ile belirlenir .

Farklı metodolojiler özelliklere atıfta bulunmak için farklı terminoloji kullanır. Hangi metodolojinin veya terminolojinin kullanılacağına karar vermek ekibin görevidir. Extreme Programming (XP), özellikleri temsil etmek için Kullanıcı Hikayeleri veya Hikayeleri terimlerini kullanır; Scrum, bir özellik listesini tanımlamak için Ürün İş Listesi kullanıyor; Özellik Odaklı Geliştirme, Özellik kullanır; ve DSDM Gereksinimi kullanır. Benzer şekilde, Birleştirilmiş İşlemin veya Çevik YUKARI, artan şekilde teslim edilebilir işlevselliği tanımlamak için Gereksinim ve / veya Kullanım Durumu kullanan çeşitli hafif sürümleri vardır. Sonuçta, amaç aynıdır - işletme değerini düzenli olarak küçük artışlarla ve daha sonra değil, daha kısa sürede sunmak.

— Aaron McIver
kaynak

+1, bu iyi açıklar. İş değeri veya müşteri değeri hakkında konuşmanız haricinde mutlaka özellik == kullanıcı hikayesi demem. Diğer durumlarda, ilgili terimin bir anlamı olmayabilir.

— murrekatt

2

İlişkili terimler olsalar bile aynı olduklarını söyleyebileceğinizi sanmıyorum. Birkaç kullanıcı hikayesini kapsayan özelliklerden ne haber?

— sleske,

@sleske Saf bir Scrum yaklaşımındaki bir kullanıcı hikayesi, kullanıcıya katma değer ve dolayısıyla bir özellik olmalıdır. Eğer özellikleri iyi olan Epik olarak kataloglayacağız, ancak sonuçta sonuç veren kullanıcı hikayeleridir.

— Aaron McIver

1

@AaronMcIver: Evet, bu doğru. Ancak, bazen kullanıcı için gerçekten yararlı olan minimum işlevsellik miktarı (= özellik) bir kullanıcı hikayesi için (hatta bir yineleme için) çok fazladır. Bu durumda, özelliği birkaç hikayeye ayırmanız gerekir.

— sleske

— Btw

7

Bir Kullanıcı Hikayesi , müşterinin ulaşmak istediği bir şeyin amacını yakalayan, müşterinin dilinde gayrı resmi bir ifadedir. Bir Kullanıcı Öyküsünü Gayrı resmi Gereksinim Beyanı olarak düşünebilirsiniz .

Bir Yazılım Özelliği , yazılımın genel tasarımına ve işlevselliğine katkıda bulunan yazılımın ayrı bir özelliğidir.

Birkaç önemli husus:

Bir Öykü bir Özelliği tanımlayabilir , ancak bir özellik asla Bir Öyküyü tanımlamaz .
Bir Öykü , bir Özelliği doğrudan tanımlamayabilir .
Bir Öykü , bir dizi Özelliğin dahil edilmesi anlamına gelebilir .
Bir Özellik - tek başına veya bir Özellikler koleksiyonunun bir üyesi olarak - Bir Hikayenin amacını ele geçirebilir .

Tüm bunları aklımda tutarak, Hikayeleri açıklama olarak düşünme eğilimindeyim. Temel olarak müşterinin ne istediğini bana söyleyen gayrı resmi gereksinimler. Öte yandan özellikler, müşterilerin gereksinimlerini karşılamak için bir sistemin nasıl çalışması gerektiğini söyleyen bir şartname olarak düşünmeye meyilliyim.

— S.Robins
kaynak

3

İki terim birbiriyle yakından ilişkili, ancak bazı farklılıklar var.

İlk önce, farklı alanlardan geliyorlar. "Özellik" terimi, bir yazılımın işlevselliğinin bir kısmı için oldukça genel bir terim iken, "kullanıcı öyküsü" icat edildi ve gerçekten sadece çevik yazılım geliştirme bağlamında kullanıldı.

Uygulamada, çoğu zaman çakışmaktadır, çünkü bir kullanıcı hikayesi belirli bir özelliği uygulamaktan ibarettir.

Ancak, bazı durumlarda farklı olabilir:

Genellikle, bir özellik, tek bir kullanıcı hikayesi için çok fazla iş gerektirir. Kullanıcı hikayeleri çok büyük olmamalıdır (genellikle birkaç günden fazla değil, en fazla 1-2 hafta çalışma). Açıkçası birçok özellik çok daha büyük. Bu durumda, birçok kullanıcı hikayesinde bir özellik uygulanacaktır. Bazı insanlar kullanıcı hikayelerini birlikte gruplamak için "destanları" kullanır, bu durumda özelliğin destan olduğunu söyleyebilirsiniz.
İşlevsel olmayan gereksinimler (performans, güvenlik, uyumluluk vb.) Kullanıcı hikayeleri olarak da ele alınabilir (bunun evrensel olarak kabul edilmemesine rağmen). Bu durumda, kullanıcı hikayesinin sonucuna normalde bir özellik denemez (“uygulamamız nadiren çöküyor” olarak adlandırmazsanız bir özellik).

— sleske
kaynak