Jaka jest różnica między historiami użytkowników a funkcjami?

Grając w icescrum , zdałem sobie sprawę, że nie rozumiem różnicy między historiami użytkowników a funkcjami użytkownika.

Czy ktoś może wyjaśnić różnicę?

Cecha jest wyraźnym elementem funkcjonalności, który może zapewnić możliwości dla biznesu.

Historia to niewielki aspekt funkcji, za pomocą której można uzyskać informacje zwrotne od interesariuszy i dowiedzieć się, czy robisz coś źle.

Na przykład funkcją może być „pozwalanie użytkownikom na komentowanie artykułów”. Historie związane z tą funkcją mogą być:

• zapisz komentarze
• filtruj komentarze pod kątem niegrzecznych słów
• ogranicz komentarze do 400 znaków i przekaż je użytkownikom
• dodaj captchas, aby bot nie spamował strony
• zezwalaj użytkownikom na logowanie się za pomocą identyfikatora Google

itp.

Na każdym etapie możemy uzyskać informację zwrotną, czy wskazany kierunek jest przydatny.

Niektóre zespoły nie zadają sobie trudu dzielenia funkcji na historie. W porządku.

Funkcje == Historie użytkowników.

Verbage jest podyktowane zastosowaną metodologią Agile .

Różne metodologie używają innej terminologii w odniesieniu do funkcji. Zespół decyduje, której metodologii lub terminologii użyć. Extreme Programming (XP) używa terminów Historie użytkownika lub Historie do reprezentowania funkcji; Scrum używa Backlogu Produktu do opisania listy funkcji; Programowanie oparte na cechach wykorzystuje funkcję; a DSDM używa wymagania. Podobnie istnieją różne lekkie wersje Unified Process lub Agile UP, które wykorzystują Wymaganie i / lub Przypadek użycia w celu zdefiniowania funkcji dostarczania przyrostowego. Ostatecznie cel jest ten sam - regularne dostarczanie wartości biznesowej w małych krokach, a raczej wcześniej niż później.

Story Użytkownik jest nieformalnym oświadczenie w języku klienta, który przechwytuje intencją coś, życzenia klienta do osiągnięcia. Historię użytkownika można traktować jako nieformalne oświadczenie o wymaganiach.

Funkcji oprogramowania jest odrębną cechą oprogramowania, które przyczynia się do ogólnego wzornictwa i funkcjonalności oprogramowania.

Kilka kluczowych uwag:

• Story może opisywać funkcji , ale funkcja nie opisuje historię .
• Story może nie bezpośrednio opisania funkcji .
• Story może oznaczać włączenie liczby mieście .
• Feature - pojedynczo lub jako członek kolekcji funkcje - mogą przechwytywać intencją a Story .

Mając to na uwadze, zwykle opowiadam Historie jako opisy. Zasadniczo nieformalne wymagania, które mówią mi, czego chce klient. Z drugiej strony cechy, które zwykle uważam za specyfikację, która mówi mi, jak system powinien działać, aby spełnić wymagania klientów.

Te dwa terminy są ściśle powiązane, ale istnieją pewne różnice.

Po pierwsze, pochodzą z różnych domen. Termin „funkcja” jest dość ogólnym terminem na pewną część funkcjonalności oprogramowania, podczas gdy „historia użytkownika” została wymyślona i jest używana tylko w kontekście zwinnego tworzenia oprogramowania.

W praktyce bardzo często się pokrywają, ponieważ jedna historia użytkownika polega na wdrożeniu pewnej funkcji.

Jednak w niektórych sytuacjach mogą się różnić:

• Często funkcja jest zbyt pracochłonna dla historii jednego użytkownika. Historie użytkowników nie powinny być zbyt duże (zazwyczaj nie więcej niż kilka dni, maksymalnie 1-2 tygodnie pracy). Oczywiście wiele funkcji jest znacznie większych. W takim przypadku funkcja zostanie wdrożona w wielu historiach użytkowników. Niektóre osoby używają „epików” do grupowania historii użytkowników, w takim przypadku można powiedzieć, że ta funkcja jest epicka.
• Wymagania niefunkcjonalne (wydajność, bezpieczeństwo, zgodność itp.) Mogą być również traktowane jako historie użytkowników (choć nie jest to powszechnie akceptowane). W takim przypadku wynik historii użytkownika zwykle nie byłby nazywany funkcją (chyba że nazwiesz „nasza aplikacja rzadko powoduje awarię” funkcji).