Jak zdefiniować złożone reguły biznesowe za pomocą historii użytkowników?

Szybka i nieprzyzwoita definicja User Story :

"As a <role>, I want <goal/desire> so that <benefit>"

W tej powszechnie przyjętej definicji niewiele jest miejsca na definiowanie reguł biznesowych, ograniczeń lub danych wejściowych użytkownika.

Trywialny przykład tylko dla zilustrowania:

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

W tym głupim przykładzie, gdzie należy zdefiniować pola potrzebne przy rejestracji książki? Czy należy to gdziekolwiek napisać? A może właściciel produktu powinien przekazać wymagane reguły biznesowe w formie ustnej?

Pola są częścią rozmowy, którą należy przeprowadzić. Można je spisać, jeśli jest to przydatne, ale jest to wezwanie do sądu. Utrzymanie aktualności dokumentacji może być trudne, podczas gdy działające oprogramowanie może być do pewnego stopnia postrzegane jako dokumentacja.

User Story - Obietnicą prowadzenia rozmowy byłby wpis na blogu na ten temat.

Twój trywialny przykład ma kilka punktów, których nie wiem, jak dobrze byś to zauważył. Co to znaczy „rejestrować nowe książki”? Co to jest „Znajdź ich dostępność online?” To tam zaczyna się rozmowa, a po zakończeniu historii mogą pojawić się nowe historie, ponieważ być może rejestracje te muszą być przechowywane w aktach lub raporty muszą być generowane okresowo.

Dotychczasowe odpowiedzi udzieli ważnych punktów, szczególnie w odniesieniu do historii użytkownika będącego przypomnieniem do rozmowy . Inne rzeczy do rozważenia:

1. Jeśli historia jest zbyt skomplikowana, to prawdopodobnie epicka . Możesz podzielić epopeje na mniejsze historie teraz lub po tym, jak zostaną potraktowane priorytetowo w zaległościach produktu

2. Szczegóły sugerujące przypadki testowe są oddzielone od samej historii. [ Mike Cohn ]

   Możesz dodać na odwrocie karty opowieści, zrobić małe notatki, jeśli są naprawdę ważne, lub umieścić je w dokumencie z testów akceptacyjnych .

W celu oceny, czy Twoje historie użytkowników są dobre, możesz zastosować się do sugestii Billa Wake'a :

• I ndependent (z innych opowiadań)
• Nie do zaakceptowania
• V aluable (dla użytkownika lub klienta)
• E stymulowalny (w dobrym przybliżeniu)
• Centrum handlowe S (wystarczające do oszacowania)
• T estable

Możesz przeczytać rozdział 2 „Pisanie historii” w książce User Stories Applied autorstwa Mike'a Cohna.

Zazwyczaj na obszernej, obejmującej wiele aspektów historii użytkownika staram się uzyskać najbardziej ogólny przykład tej historii, a następnie, dla konkretnych szczegółów, tworzę potomne historie użytkowników, które z niej dziedziczą. Wiele narzędzi do zarządzania projektami Agile, takich jak RallyDev, pozwala ci to zrobić łatwo i uważam, że ma to sens.

Rejestracja nowych książek jest szeroka, więc być może istnieje 10 innych dziecięcych opowieści o tym <role>, w jaki sposób książki powinny być rejestrowane.

Ekstremalne szczegóły tych rzeczy lub dziwne szczegóły na marginesie, które zwykle definiuję w jednym lub większej liczbie zadań w ramach tej historii użytkownika. Zadania pomagają zdefiniować prace rozwojowe i projektowe, które należy wykonać (na poziomie ogólnym), aby sprostać tej historii użytkownika (np. Napisz weryfikator, aby upewnić się, że dane w polu opisu mają mniej niż 50 znaków ...) EDYCJA: Chciałem tylko dodać że prawdopodobnie lepiej jest ukrywać skrajne szczegóły w historiach użytkowników, ponieważ prawdopodobnie nie jest to coś, na czym naprawdę zależy. Użytkownicy chcą objaśniać oprogramowanie ogólnie i są zależni od twórców oprogramowania, aby dowiedzieć się i ukryć przed nimi szczegóły.

Tak właśnie podchodzę do problemu, ale jestem pewien, że istnieje wiele różnych sposobów.

Odpowiedź jest prosta, włącz reguły biznesowe do kryteriów akceptacji.

Trywialny przykład tylko dla zilustrowania:

Jako bibliotekarz chcę rejestrować nowe książki, aby studenci mogli znaleźć ich dostępność online

Będę zadowolony, gdy: * Mogę zarejestrować następujące pola: - ISDN - Autor - Dewey Dziesiętny bla bla * Widzę potwierdzenie, że książka została zarejestrowana przez system * Mogę wyświetlić książkę w systemie

Jak zdefiniować złożone reguły biznesowe za pomocą historii użytkowników?

Nie po to są historie użytkowników. Nie są to wymagania dotyczące oprogramowania, które przechwytują wszystkie szczegóły lub reguły biznesowe potrzebne do napisania implementacji. Są tylko opisem tego, co aplikacja powinna zrobić z perspektywy użytkownika.

Pamiętaj, co jest ważne: budowanie odpowiedniego oprogramowania. Używasz wszystkiego, co jest potrzebne, aby to zrobić, a historie użytkowników są po to, aby upewnić się, że zebrałeś potrzebne funkcje, które powinna mieć aplikacja, abyś mógł o nich mówić, ustalać priorytety, oceniać je itp. Brakująca część od klasycznego użytkownika historia (jako ... chcę ... tak, że) dotyczy komunikacji między osobami zaangażowanymi w tworzenie oprogramowania.

Posiadanie szczegółów jako kryteriów akceptacji, pod-opowieści, zadań technicznych dołączonych do historii użytkownika, w dokumencie specyfikacji lub czymkolwiek, wykracza poza to, co pomaga historia użytkownika. Użytkownik stoy jest tylko „przedmiotem” rozmowy przy podejmowaniu decyzji o budowie oprogramowania.

W podanym przykładzie istnieje wiele szczegółów dotyczących rejestracji książek, o których programiści niewiele wiedzą, takich jak Dewey lub inne systemy klasyfikacji, numery ISBN, numery akwizycji, powielone kopie / tytuły / autorzy, inne wydania i tak dalej. W przypadku nowego systemu klient musi podać takie dane (a bibliotekarz, ze wszystkich osób, na pewno się nimi zajmie ).

Cytując Steve'a O'Connella: „Przerażające jest zastanawianie się, ile polityki biznesowej tworzą programiści, którym brakowało niezbędnych szczegółów w specyfikacjach, więc po prostu to nadrobili”.