Jakie historie użytkowników należy napisać na początkowych etapach projektu?

Po prostu rozpoczynając projekt, nie masz nic --- brak interfejsu użytkownika, brak warstwy danych, nic pomiędzy. Dlatego też jedna historia, taka jak „użytkownicy powinni mieć możliwość obejrzenia swoich zdjęć”, będzie wymagała dużo pracy. Gdy już znajdziesz tę historię, taka jak „użytkownicy powinni móc edytować swoje foos” jest bardziej realistyczna, ale ta pierwsza historia będzie wymagała skonfigurowania warstwy interfejsu użytkownika, warstwy logiki prezentacji, warstwy logiki domeny i warstwy dostępu do danych.

Nie pasuje to do mojej koncepcji „zadań”: dla mnie wolałbym mieć coś w rodzaju następujących „zadań”:

• Pokaż fikcyjne dane foos użytkownika w HTML, pochodzące z obiektów JavaScript.
• Skonfiguruj warstwę logiczną prezentacji i połącz z nią obiekty JavaScript.
• Skonfiguruj warstwę logiki domeny i połącz z nią warstwę logiki prezentacji.
• Skonfiguruj warstwę dostępu do danych i połącz z nią warstwę logiki domeny.

Czy wszystkie z nich należą do jednej „historii” powyżej? Jeśli tak, to uważam, że historie nie są zbyt użyteczną ramą na wczesnych etapach projektu. Jeśli tak, to w porządku --- chcę się tylko upewnić, że czegoś nie przegapię, ponieważ naprawdę staram się nauczyć tej zwinnej metodologii najlepiej jak potrafię.

To dobre pytanie i prawdopodobnie istnieje na nie kilka dobrych odpowiedzi. Moje zdanie jest takie:

Historia jest historią użytkownika, dlatego należy ją zdefiniować w terminach opisujących korzyści dla użytkownika.

Jeśli zwinne i opowiadania będą dla ciebie działać, powinny działać nawet na początkowych etapach. Pierwszy punkt jest pojedynczą historią użytkownika (choć trochę technicznie sformułowaną), ale pozostałe trzy to techniczne opisy zadań.

Na początkowych etapach projektu, gdy nie masz odpowiednich ram, aby programowanie CRUD ( C reate, R ead , U pdate, D elete) było szybkie i łatwe, Twoje historie muszą być znacznie mniejsze, przyrostowe sztuk.

Zamiast „Użytkownik powinien mieć możliwość zobaczenia swojego foo” , coś takiego:

1. Użytkownik powinien widzieć stronę z przykładowymi danymi
2. Użytkownik powinien widzieć stronę z interaktywnymi przykładowymi danymi
3. Użytkownik powinien widzieć stronę z interaktywnymi przykładowymi danymi na żywo

Pamiętaj, że większość historii użytkowników, które wydają się zbyt duże, aby rozwinąć się w jednym sprincie (odkryłem, że wszystko większe niż około 8 punktów historii lub dni rozwoju, było zbyt duże) można prawdopodobnie podzielić na kawałki, które wciąż mają znaczenie użytkownik.

Historia / funkcja nie musi być zbywalna, musi mieć jedynie znaczenie dla właściciela produktu. W powyższym przypadku możesz umieścić kilka szybkich elementów demonstracyjnych, aby pokazać, co się zmieniło i jak ta historia jest teraz wykonywana - na przykład dla nr 3 możesz wyświetlić stronę dla dwóch różnych użytkowników z danymi wstępnie wypełnionymi w bazie danych . Na etapie nr 2 wszyscy użytkownicy będą widzieć te same dane.

To, o co pytasz, jest niezbędne „jak myślisz o przestrzeni problemowej”, aby rozbić ją na rozsądne elementy, z których możesz wykonać projekt.

Niezależnie od tego, czy nazywasz to historią użytkownika, analizą, dekompostacją, specyfikacją lub zbieraniem wymagań ... ostatecznie sprowadza się to do kilku rzeczy, które normalnie będą miały pewną iterację.

Musisz uzyskać od użytkowników głowy, czego chcą. (Prawdopodobnie wiedzą, czego chcą i chcą rzeczy, które są niespójne, ale jeszcze tego nie widzą).

Musisz to uchwycić w jakiejś formie - naprawdę masz tylko 2 możliwości: słowa lub obrazy. Oba mają moc, użyj ich obu, jeśli możesz. Słowa są ostatecznie mocniejsze z punktu widzenia sporu umownego później.

Musisz przedstawić to z powrotem i szukać porozumienia.

Niektóre osoby robią wczesne prototypy wizualne, bez logiki biznesowej lub innej. Może to być potężna technika - do pewnego stopnia, ponieważ nadal wymaga pewnej ilości machania ręką.

Niektórzy będą tworzyć scenariusze, a następnie przedstawiać i wyjaśniać.

Niektórzy napiszą rygorystyczne i dokładnie przeanalizowane dokumenty.

Każda technika ma swoje zalety i wady.

O jedynej radzie, której udzieliłem, jest to, że zbyt wczesne wkroczenie do kodowania rozwiązania jest zwykle złym posunięciem. Zrozumienie CO robić, dla KTO i DLACZEGO, zanim to zrobisz, generalnie prowadzi do mniejszej liczby przeróbek i szybszego rozwoju.

Kiedy mówisz o „zadaniach”, wydaje mi się, że to jakiś podział pracy, ponieważ zorientowałem się, co, kto i dlaczego. Nie możesz dobrze określić zadań, dopóki historia użytkownika nie zostanie zrozumiana w dokumencie, zatwierdzonym przez klienta jako zakres pracy, którą zamierzasz wykonać. Wiedza o tym, co musisz osiągnąć (wynik), pozwala ci zorientować się, jakie zadania (kroki musisz osiągnąć).

Nie oszczędzaj na analizie i dokumentacji interfejsu użytkownika.

Myślę, że brakuje Ci opowieści użytkownika o tym, jak użytkownik spodziewa się korzystać z systemu. Jest to sposób na określenie wymagań biznesowych . Nie zostały one zaprojektowane tak, aby bezpośrednio powiedzieć ci, co robić technicznie, a tego właśnie chcesz.

Jest to prawdopodobnie jedna z najważniejszych części projektu. Jeśli nie spełnisz poprawnych wymagań biznesowych, system nie będzie przydatny dla użytkowników.