Domyślam się, że funkcja może być czymś w rodzaju "autoryzacji kartą kredytową", a historia użytkownika może brzmieć "autoryzuj kartę kredytową dla systemu PayPal".Jaka jest różnica między historią użytkownika a funkcją w zwinnej terminologii?
A więc historia użytkownika to podzbiór funkcji?
Tak, coś jak podzbiór. Ten artykuł jest dobry odczyt:
Features vs Stories
Fragment:
Uświadomiłem sobie dzisiaj, że nie uczynił wyraźną różnicę w moim umyśle między funkcjami i historie i to ważnym różnica. Zasadniczo, funkcja to grupa opowiadań, które są powiązane z i dostarczają pakiet funkcji , które użytkownicy końcowi będą zwykle oczekują od razu. Na przykład zmiana rozmiaru tabeli wstawianej to funkcja (uwaga: jest to zdolność do przeciągania, aby zmienić rozmiar tabel, wierszy i kolumn - spróbuj w Word). W pierwszym przejściu z okresu najprawdopodobniej zostanie utworzona pojedyncza historia dla zmiany rozmiaru tabel , ale będzie ona zbyt duża dla oszacowania . Więc podzielisz go na trzy historie, zmienisz rozmiar kolumn, zmienisz rozmiar wierszy i zmienisz rozmiar samej tabeli.
Spójrz na "Diego's' post na tej stronie, odświeżająca perspektywa. –
Dzięki ... To dobry link, który już wysłałeś. Za każdym razem, gdy czytam doświadczenie kogoś, kto ponownie zastanawia się nad tym, co robi, sprawia, że myślę o tym na inny sposób. To jeden z powodów, dla których uważam, że ta strona jest niesamowita ... ciągle się uczysz –
Dokładne sentymenty tutaj :) –
Wcale ..
Opowieść użytkownik reprezentuje małe części wartości biznesowej. Tak naprawdę trudno jest powiedzieć, kiedy historia użytkownika jest podzbiorem danej funkcji lub funkcja jest podzbiorem historii użytkownika (należy również pamiętać, że historie użytkowników są zazwyczaj pisane przez interesariuszy, którzy nie wiedzą dokładnie, czego chcą ... :))
Tak więc, jeśli zastosujesz się do zalecenia zwinnego, aby zachować krótkie historie, wpadniesz w "najlepszy" scenariusz, który jest historią użytkownika będącą podzbiorem tej funkcji. Jeśli jednak Twój interesariusz napisze długie historie, każda historia będzie miała kilka cech (jeśli istnieje dobra komunikacja między zespołem i interesariuszami, nie stanie się tak, ponieważ zespół podzieli historie na małe)
Według Kent Beck and Martin Fowlerhistorie i cechy są synonimami:
opowieść użytkownik jest fragment funkcjonalności (niektórzy ludzie używają słowa funkcja), która ma wartość do klienta.
Co można nazwać funkcję jest zwykle określany jako tematu lub epickiej. Motywy i eposy są używane do grupowania historii użytkowników do większych zestawów funkcji, które mają sens same w sobie.
Z bardziej semantycznego punktu widzenia: funkcja jest częścią systemu, który próbujesz zbudować, historia użytkownika jest sposobem na opisanie tej części.
Korekta:
Pascal zauważył - I być może brakowało prawdziwego znaczenia „funkcji” w tym cytacie („Opcja” oczywiście odnosi się do funkcji) Oprócz tego, nadal uważam, że jeden może używać tych słów (historii funkcji i użytkownika) jako synonimów w wielu kontekstach ("Pracuję nad tą historią" vs. "Pracuję nad tą funkcją"), ponieważ, jak powiedział Pascal, historia użytkownika jest sposób na przechwycenie funkcji. Co oznacza, że istnieje relacja 1: 1 między tymi dwoma. I, jak widać z mojej uwagi na temat semantyki, tak naprawdę to rozumiem.
"To, co nazywasz funkcją, jest zwykle określane jako temat lub epos", podoba mi się ta analogia. :) –
Usunąłem mój komentarz przez przypadek, więc odkładam go dla większej przejrzystości: czy jesteś pewien, że niektórzy używają funkcji słowa nie dotyczy funkcjonalności? –
BTW, bardzo podoba mi się addendum, nawet jeśli mam inny punkt widzenia (osobiście widzę relację jako * user story => feature * bez ścisłej równoważności). –
Funkcje są tym, co robi system. Historie użytkowników to tylko jeden ze sposobów przechwytywania funkcji.
Moja uwaga, Pascal;) –
Właśnie natknąłem się na ten temat, gdy szukałem różnych pomysłów na temat "używania wielu ról dla podobnych wymagań".
Myślę, że funkcja jako pojemnik na powiązane historie pomaga w ustalaniu priorytetów wymagań, ponieważ interesariusze zazwyczaj mówią o swoich potrzebach jako zależne historie. W ostatnim projekcie, klient powiedział mi następująco
Członek może wysyłać wiadomości do administratora administrator może wysyłać wiadomości do wszystkich członków Użytkownicy mogą wysyłać wiadomości do siebie
Kiedy widzę te wymagania, i Wiemy, że powinniśmy wdrożyć system, który umożliwi ludziom wysyłanie wiadomości, a my powinniśmy dodać kontrole, aby pozwolić komu coś zrobić.
A także wiem, że wymagania te mogą mieć inne wymagania ukryte, takie jak czytanie wiadomości, że przyszedł ich aranżacji mogą być ustalone jako spam itp
więc staram się przeformułować te wymagania jak
Jako członek lub administrator mogę wysyłać wiadomości do innych osób. Jako członek lub administrator mogę czytać wiadomości, które zostały do mnie wysłane.
Jako kryteria akceptacji, oświadczam szczegółowo, kto może wysłać do kogo.
Następnie wszystkie te funkcje nazywam "prywatną wiadomością", więc w pewnym momencie później, jeśli klient zdecyduje, że jest to dodatkowy koszt, może powiedzieć "po prostu upuść prywatną wiadomość" i mogę usuń wszystkie z zaległości.
Zwinny sklep użytkownika musi być skoncentrowany na osobie. Na przykład: "Jako właściciel konta mogę autoryzować moją kartę kredytową do Paypal." Następnie będziesz chciał uzyskać szczegółowe kryteria sukcesu. – Jay
Istnieją modele UML do wyjaśniania związków między Historiami, zaległościami itp. W http://scalingsoftwareagility.files.wordpress.com/2007/03/a-lean-and-scalable-requirements-information-model-for-agile- enterprise-pdf.pdf – Fuhrmanator