Jaki jest cel klauzuli „tak, że” w definicji historii użytkownika?

10

Historię użytkownika można zdefiniować w zdaniu takim jak:

As a <type of user> I want <some goal> so that <some reason>

Tylko Google dla „formuły historii użytkownika” i pierwszych linków wszystkie proponują tę formułę.

Moje pytanie brzmi: jaki jest cel takiej klauzuli? Czy to jest dla menedżerów? Czy istnieje, aby kierownicy projektów i interesariusze mogli lepiej zrozumieć priorytet przedmiotu? Dlaczego tam jest

Uwaga: Pracowałem z as a <type of user> I want <some goal>formułą i działa ona dobrze. Nie zauważyłem żadnego problemu w mojej pracy, implementując ten krótszy format.

Saeed Neamati
źródło
6
Jako użytkownik SE chcę jednorożca.
Piskvor opuścił budynek

Odpowiedzi:

19

Celem jest uniknięcie niepotrzebnej pracy poprzez zmuszenie użytkownika / klienta do zapewnienia solidnej, wymiernej korzyści biznesowej jako powodu istnienia tej funkcji.

Nie jest niczym niezwykłym, że te funkcje są dodawane tylko dlatego, że ktoś uważał, że brzmiały fajnie, lub dlatego, że ma to inne oprogramowanie, więc nasze też muszą je mieć. Najczęściej są one co najmniej całkowicie niepotrzebne, jeśli nie są aktywnie szkodliwe.

Zazwyczaj jednak łatwo jest dostrzec te funkcje, ponieważ osoby, które je proponują, będą miały trudności z dostarczeniem przekonujących powodów biznesowych.

Istnieje technika o nazwie Popping The Why Stack , w której bierzesz część „tak, że” i pytasz „dlaczego?”, A następnie bierzesz tę odpowiedź i pytasz „dlaczego?”. znowu rekurencyjnie. Jeżeli po (powiedzmy) 04:57 „Dlaczego” s, nie dotarły albo „bo to zrobi nam pieniądze” lub „bo będzie to nam zaoszczędzić pieniądze” (najlepiej z dokładnym opisem dokładnie jak to ma się wydarzyć), wtedy funkcja nie jest warta wdrożenia.

Niektórzy uważają, że jest to tak ważne, że faktycznie umieścili to na pierwszym miejscu w szablonie historii:

W celu [...]

Jak [...]

Chcę [...]

Jest świetny przykład z przemówienia niektórych osób z Thoughtworks: jeden z ich klientów chciał wydrukować raporty sformatowane w bardzo szczególny sposób. Kiedy konsultant zapytał „Dlaczego”, powiedzieli, że w ten sposób łatwiej było pisać z powrotem. Zamiast więc wdrożyć funkcję formatowania raportów, po prostu przesłali raporty przez sieć. Bez klauzuli „tak, że” nadal drukowaliby te dokumenty w jednym dziale, wysyłali je do drugiego i wpisywali z powrotem.

Jörg W Mittag
źródło
To, co opisałeś, nazywa się Five Whys ( en.wikipedia.org/wiki/5_Whys ) i jest ogólnie przydatne w dziedzinach inżynierii (oprogramowania), od inżynierii wymagań do kontroli jakości do doskonalenia procesów. Jest to prawdopodobnie dobra umiejętność do rozwijania.
Thomas Owens
Uwielbiam historię ThoughtWorks. Przekonałem się, że „So that” jest bardzo przydatne w zapewnianiu kontekstu historii i pomaganiu deweloperom w lepszym rozwiązaniu. Analitycy / klienci często zbyt szybko zawężają rozwiązanie; udostępnienie programistom kontekstu pozwala im na przemyślenie i zaprojektowanie rozwiązania technicznego, którego analitycy mogli nie wziąć pod uwagę, lub też nie uznać za możliwy.
Mathias
7

„Tak, że” stanowi przyczynę celu.

Na przykład celem może być wyświetlenie wyników sprzedaży z ostatniego miesiąca. Możesz z tym pracować, ale jednym z powodów, dla których musisz wiedzieć, dlaczego chcesz je wyświetlić, aby uzyskać głębsze wymagania. Co chcą zrobić z danymi dotyczącymi sprzedaży lub perspektywami? Znajomość tych informacji zapewni lepszy wgląd w aplikację i większe szanse na zaprojektowanie interfejsu użytkownika, który umożliwi klientowi robienie tego, co chce.

Innym zastosowaniem tego powodu jest nadanie priorytetu historiom. Jeśli masz dwie historie:

Chcę wyświetlić dane dotyczące sprzedaży w ubiegłym miesiącu.
Chcę wyświetlić listę potencjalnych klientów.

ale masz tylko zasoby, by to zrobić - który z nich? Bez powodu po prostu zgadujesz i możesz nie dostarczyć tego na czas. Jest to mniej ważne, ponieważ klient powinien najpierw powiedzieć ci, co zrobić, ale czasami tak nie jest.

ChrisF
źródło
Nie sądzę, że chodzi o ustalanie priorytetów dla historii, ale raczej o głębsze wymagania. Historie powinny być traktowane priorytetowo przez klienta. Jednak „tak, że” może być użyte do wywołania dodatkowych wymagań (funkcjonalnych, niefunkcjonalnych i jakościowych), które zwiększą wartość dla użytkownika. Myślę, że koncepcja maksymalizacji wartości dodanej jest jedną z mocnych stron wielu zwinnych metod.
Thomas Owens
@Thomas - dobry punkt. Zamienię powody - myślę, że ustalanie priorytetów jest możliwe, ale nie tak ważne.
ChrisF
1

Oprócz tego, co zostało powiedziane, podanie uzasadnienia wymagań pozwala ocenić ważność wymagań. Użytkownik może chcieć rzeczy z niewłaściwego powodu. Wyjaśnienie przyczyny „tak, że” pozwala analitykowi potwierdzić, że żądanie jest najlepiej spełnione w ten sposób.

Przykład:

AI chce mieć możliwość wyboru pracowników z listy wszystkich pracowników firmy

BI chce mieć możliwość wyboru pracowników z listy wszystkich pracowników firmy, abym mógł usunąć tych, którzy opuścili firmę 5 lat temu.

(B) nie ma sensu nawet w średniej organizacji, ale możesz zweryfikować wymaganie użytkownika i zaproponować klientowi inny sposób spełnienia tego wymagania.

Bez szans
źródło
+1 - pomaga dotrzeć do źródła problemu; w przeciwnym razie masz po prostu potencjalne rozwiązanie.
JeffO