W jaki sposób historie użytkowników mogą nie zawierać wymagań (zapisanych na karcie) i nadal być możliwe do wdrożenia

Powiedziano mi: „Historie użytkowników nie są wymaganiami, to tylko przypomnienie tego, czego chce klient, nie można stawiać wymagań w historii”. Ale weźmy na przykład, że klient chce innego przetwarzania dla różnych kart kredytowych. Istnieją ścisłe wymagania, które muszą zostać zaimplementowane i znane, aby można było napisać przypadki testowe. Gdzie powinny iść wymagania, jeśli nie w historii użytkownika?

Jak programiści mogą tworzyć scenariusze, jeśli nie ma niższych wymagań? Jak testerzy mogą pisać przypadki testowe (szczegółowe) na podstawie historii użytkownika? Gdzie wymagania, takie jak ograniczenia DB, sprawdzanie poprawności pól itp., Znajdują się poza historią użytkownika?

Ta odpowiedź skupi się na tym, jak pracować z Historiami użytkowników i wymaganiach niższego poziomu. Nie będę omawiać zalet, ani ich braku, Scruma lub Agile. Nie będę też mówił o guru.

Ta odpowiedź zakłada, że ​​jesteś na pokładzie Scruma, ale nie znalazłeś jeszcze sposobu, aby działał on dla Ciebie.

Jak wspomnieli inni, Historie użytkowników mają na celu opisanie, w jaki sposób Użytkownicy chcieliby oprogramowania. Ponieważ Użytkownicy nie dbają o elementy implementacyjne niskiego poziomu, takie jak tabele bazy danych, ograniczenia, wzorce architektoniczne itp., Nie znajdziesz takich szczegółów w Historii użytkownika.

Nie oznacza to jednak, że tych szczegółów nie należy nigdzie rejestrować.

Kiedy programiści wdrażają Historie użytkowników, muszą zdawać sobie sprawę z szczegółów niższego poziomu, których typowi Użytkownicy nie będą wiedzieć. Informacje te mogą pochodzić od małych i średnich przedsiębiorstw, licencjackich, właściciela produktu, architekta lub innego eksperta lub osoby o technicznych zainteresowaniach.

Czy to oznacza, że ​​szczegóły niskiego poziomu powinny być zapisywane w Historiach użytkowników? Nie i tak).

W pewnym momencie pomiędzy tworzeniem i wdrażaniem historii ktoś będzie musiał dowiedzieć się, jak ją wdrożyć. Zwykle przybiera to formę rozmów z osobami zaangażowanymi w Historię (użytkownik, architekt, programista itp.). Rozmowy te powinny skutkować jednoznacznymi kryteriami akceptacji, które jasno określają zakres wdrożenia User Story. Te szczegóły będą musiały być gdzieś zapisane i gdzie to naprawdę zależy od ciebie. Kluczem tutaj jest to, że te szczegóły są wywoływane po utworzeniu Historii użytkownika. Myślę, że to właśnie podkreśla wasz guru .

Jako programista jasne jest, że będziesz potrzebować sposobu na powiązanie bardziej szczegółowych wymagań z Twoją historią użytkownika. To, jak to zrobisz, zależy wyłącznie od Twojego zespołu.

Jeśli ludzie w Twoim zespole chcą ukryć te szczegóły w Historiach użytkowników, być może będziesz musiał to uszanować. Korzyści z utrzymywania historii użytkownika wysokiego poziomu wolnych od szczegółów implementacyjnych. Dzięki temu są szczupłe, a zaległości można odczytać jako historię tego, czego chcieli Twoi użytkownicy i właściciel produktu. Po prostu przekaż swoje potrzeby jako programista. Powinieneś być w stanie wypracować kompromis, w którym po prostu link do User Story zapewni wszystkim zadowolenie.

Tak, to BS. A Scrum nie jest zwinny.

Nienawidzę sztywności tak zwanych zwinnych praktykujących, którzy mówią ci, że istnieje jeden sposób na zwinne podejście i że musisz przestrzegać wszystkich zasad określonych w świętych pismach świętych dowolnej metody „zwinnej”, której używają. To wszystko BS.

Zwinność polega na byciu zwinnym.

Zwinność polega na wykonywaniu zadań przy minimalnym obciążeniu. Nie oznacza to „braku dokumentacji”, ponieważ zwykle kończy się to bardziej zwinną rolą, po prostu zajmujesz się dokumentacją bez konieczności planowania procesu wykonywania dokumentacji. Podobnie jest z kodowaniem, testowaniem i przechwytywaniem wymagań. Jedyne, co ma znaczenie w sprawnym procesie, to te, które pomagają ci szybko i wydajnie wykonać zadanie bez BS.

Więc w tym przypadku, jeśli umieszczenie wymagań użytkownika na kartach pomoże Ci napisać, przetestować, udokumentować i zademonstrować potrzebny kod ... umieść wymagania na karcie i powiedz guru, że zespół ma zawsze rację.

Co myśli reszta zespołu deweloperów? W prawdziwie zwinnej metodologii, jeśli wszyscy uważają, że wymagania powinny być napisane z góry bez żadnych „rozmów z użytkownikami”, to powinno być to, że robisz to, co zespół uważa za najlepsze, aby wykonywać swoją pracę. Jeśli zespół uważa, że ​​rozmowy z użytkownikami są dobrą rzeczą, posłuchaj ich i zrozum, dlaczego tak myślą, i włącz się w ich sposób pracy.

Tylko nie nazywaj tego Historią użytkownika, a wszyscy będą zadowoleni.

Myślę, że odpowiedź brzmi: możesz to zapisać gdziekolwiek chcesz.

Ogólnie rzecz biorąc, konkretne implementacje nie są zawarte w historii użytkownika z kilku powodów:

1. Wiesz, czego chce klient, ale nie wiesz, jak to będzie realizowane.
2. Klient jest świadomy, że wiążą się z tym bardziej szczegółowe wymagania, ale tak naprawdę ich nie obchodzi i / lub nie rozumie.
3. Wszyscy myślą, że są w tej chwili w pełni świadomi konkretnych implementacji, ale nikt nie chce ich spisywać, ponieważ z ich doświadczenia wszystko to i tak się zmieni i nikt nie będzie chciał go przepisać.

W razie potrzeby nie ma reguł, które pomijają dodatkowe dokumenty. Może klient potrzebuje do niego dostępu, a może nie. Jeśli masz nadzieję, że uda ci się wygenerować jakąś umowę między tobą a klientem w sprawie konkretnej implementacji, tak jakbyś mógł ją wykonać, a kiedy to nie zadziała, obwiniaj klienta za zgodę, to się mylisz. Jeśli klient rozumie szczegóły techniczne przetwarzania kart kredytowych, powinieneś udostępnić im te dokumenty i ewentualnie włączyć je do rozmowy.

Myślę, że jeśli Twoi konsultanci Scrum mówią ci, że Scrum nie wymaga wymagań, masz bardzo słabych konsultantów. Mylą się nawet, gdy mówią, że historia użytkownika wcale nie jest wymogiem, tylko jednym rodzajem wymagania.

Jakie są różne rodzaje wymagań dotyczących oprogramowania?

Wymagania biznesowe

Są to generalnie potrzeby biznesowe na wysokim poziomie, coś, co ogólnie byłoby równoznaczne z jakimś stwierdzeniem w stylu wykonawczym na temat systemu. Jest celowo wysoki i szeroki i sam w sobie nie może zostać wdrożony bez znacznie większej ilości szczegółów.

Wymagania użytkownika

Są to wymagania User Story, które znasz. Na ogół pasują do karteczek samoprzylepnych.

• Aktor - zazwyczaj użytkownik lub interesariusz.
• Potrzeba - jakiś element lub ogólna funkcjonalność, która jest potrzebna użytkownikowi
• Powód - powód lub kontekst, dla którego taka potrzeba istnieje
• Kryteria akceptacji - są to ramy dla testów akceptacji użytkownika i podczas Demonstracji Sprint, w jaki sposób Właściciel Produktu będzie mógł zdecydować, czy historia użytkownika zostanie zaakceptowana, czy nie.

Wymagania funkcjonalne lub systemowe

To chyba brakujący element układanki. Wymagania funkcjonalne, oparte na wymaganiach na poziomie użytkownika, definiują aktorów na poziomie systemu i właściwości systemu, a także zachowania i funkcje systemu. Można to również zrobić w formie historii i uwzględnić w zaległościach. Te elementy powinny być samodzielne i mogą być wdrażane niezależnie od jednego wymagania użytkownika.

• Aktor - jakiś system lub element.
• Potrzeba - potrzeba, właściwość lub określenie zachowania systemu, który powinien istnieć.
• Powód - kontekst, dlaczego jest to potrzebne w systemie
• Kryteria akceptacji - scenariusze, zachowania, funkcje i przepływy, które są niezbędne do zakomunikowania, w jaki sposób należy przeprowadzić testy systemu i integracji. Po zdaniu tego rodzaju testów dla wymagań wiemy, że ten wymóg funkcjonalny został spełniony. Mogą one istnieć w zewnętrznej dokumentacji twoich historii użytkowników, ale należy je uzupełnić, zanim opowieści zostaną przypisane w sprincie.

Wymagania funkcjonalne określają twoje rozwiązanie, które brzmi jak to, co opisujesz jako lukę w procesie.

Wymienione typy wymagań, które należy wymienić, ale są nieistotne dla pytania: wymagania niefunkcjonalne, wymagania techniczne itp.

Historia użytkownika jest szczególnym rodzajem artefaktu, którego celem jest opisanie interfejsu, którego użytkownik oczekuje od systemu, i dlatego właśnie szczegóły niskiego poziomu po prostu tam nie należą. Jeśli je tam umieścisz, zmienisz zamiar artefaktu i nie będzie on już zgodny z definicją Stanów Zjednoczonych.

Użyj innych form specyfikacji, aby uchwycić wymagania niższego poziomu i decyzje projektowe. Właśnie te inne formy powinny być rozwiązane w organizacji i dostosowane do konkretnego środowiska.

Twoje pytanie brzmi bardzo podobnie do czegoś takiego

Mam ten CarFactory i muszę go również wytwarzać w rowerach , ale nasz „Guru” OOD mówi, że nie mogę tego robić. Co to jest BS!?!

Przestrzegaj rozdziału obaw i spójności swoich artefaktów, zarówno tych w twoim kodzie, jak i tych w twoich procesach.

Myślę, że celem tego podejścia nie jest ograniczenie historii użytkowników, ale zapobieganie złym wymaganiom.

Z mojego doświadczenia wynika, że ​​użytkownicy zasadniczo nie są w stanie pisać wymagań. Programiści zasadniczo nie są w stanie pisać wymagań. Cholera, przyznajmy od razu: wymagania są trudne do napisania!

Myślę, że poprawne byłoby, gdyby użytkownik napisał coś w języku lingo wymagań jako część historii użytkowania. Jednak nie powinno to automatycznie oznaczać, że jest to wymóg. Posiadanie dwóch sprzecznych historii użycia jest drobnym problemem; posiadanie dwóch sprzecznych wymagań to poważny problem zerwania umowy. Promowanie jednego przed drugim nie ma sensu.

Myślę, że drakoński punkt widzenia wywodzi się z uznania ludzkiej natury. Jeśli ludzie zaczną myśleć o historiach użytkowników jako miejscu stawiania wymagań, zaczną to robić. Prawdziwą przewagą używania historii nad innymi sposobami gromadzenia wymagań, takich jak informacje, jest to, że są one sformułowane w naturalnych sformułowaniach i notacjach użytkownika. To sprawia, że ​​bardziej prawdopodobne jest, że programiści myślą z perspektywy klienta. W idealnym świecie żargon na niskie wymagania również mógłby się tam znaleźć. W rzeczywistości takie słowa powodują, że programiści docierają do łatwych do zrozumienia wymagań i pomijają subtelne sformułowania, a niuanse, które zwinny programista chce odkryć, używając historii użycia.

Podejmuj własne decyzje

Odpowiedź na „Więc w jaki sposób programiści mogą opracować historię, jeśli nie ma niższych wymagań?” jest bardzo proste - szczegółowe wymagania, które są ortogonalne do potrzeb użytkownika końcowego (np. ograniczenia DB, sprawdzanie poprawności pól itp.) nie mają znaczenia dla użytkownika. Jeśli potrzeby użytkownika mogą zostać zaspokojone przez bardzo różne sprawdzanie poprawności pól, bardzo różne struktury DB, a może nawet brak tradycyjnej DB, wówczas przyniesienie takich informacji z myślą o konkretnej implementacji byłoby przeciwne do zamierzonego, co może być bardzo różni się od tego, jak ostatecznie system jest wdrażany.

Jesteś profesjonalnym programistą, więc podejmuj najlepsze decyzje dotyczące szczegółów implementacji. Użytkownik, który chce stołu, może powiedzieć stolarzowi, jaki rodzaj drewna chcieliby, ale od stolarza zależy, jak duże powinny być nogi stołu, aby poradzić sobie z rozsądnymi obciążeniami. Jeśli brakuje Ci informacji, aby podjąć sensowną decyzję, należy to omówić z użytkownikiem, ale około 90% treści dokumentu zawierającego szczegółowe wymagania w rzeczywistości nie potrzebuje żadnych informacji oprócz niejasnych historii użytkowników, zdrowego rozsądku i najlepszych praktyk branżowych .

Wszystkie te szczegóły nie są arbitralne - istnieją złe wybory i lepsze wybory i należy je udokumentować, ponieważ wpływają one na inne części wdrożenia, ale ostatecznie są to szczegóły wdrożenia, o których może i powinien decydować zespół wdrażający zgodnie do potrzeb użytkowników i najlepszych praktyk.

Standardowa analogia samochodu - jeśli klient chce, aby samochód był pomalowany na czerwono, odpowiednim wyjaśnieniem dla historii użytkownika byłoby pytanie, który odcień czerwieni byłby lepszy, ale nie skład chemiczny farby; należy się jednak spodziewać, że nie zdecydowaliby się pomalować samochodu akwarelami, które zmyłyby się w deszczu, ponieważ najlepiej tego nie robić.

TL; DR

Historie użytkowników służą do dokumentowania, jaką wartość należy dodać do produktu i dlaczego. Szczegóły implementacji (np. Sposób dodawania, testowania, mierzenia lub walidacji wartości) są ograniczone historią, ale nie są w nich zawarte. Zostały celowo pozostawione jako osobne artefakty, aby zachować elastyczność i zwinność w ramach.

Specyfikacje i szczegóły implementacji są najczęściej przechwytywane w innych artefaktach, takich jak skrypty i scenariusze rozwoju opartego na testach akceptacyjnych (ATDD), rozwoju opartego na testach (TDD) oraz rozwoju opartego na zachowaniu (BDD). Te konkretne artefakty nie są wymagane przez środowisko Scrum, ale z pewnością dadzą ci dobry punkt wyjścia, jeśli nie masz jeszcze innych skutecznych kontroli procesu.

Historie użytkowników nie są specyfikacjami

Oryginalny plakat (OP) zadał następujące pytanie :

[A] klient chce innego przetwarzania dla różnych kart kredytowych, istnieją rygorystyczne wymagania, które muszą zostać wdrożone i znane, aby można było napisać przypadki testowe ... GDZIE POWINIENEM ZOSTAĆ, JEŚLI NIE W HISTORII?

Historia użytkownika to funkcja zapewniająca wartość , zapewniająca kontekst do prowadzenia rozmów na temat implementacji oraz punkt widzenia związany z konsumentem wartości, który skorzysta z wartości dostarczonej przez tę funkcję.

Cały sens historii użytkownika polega na tym, że szczegóły implementacji nie są nakazowe. Zespół może zaimplementować tę funkcję w dowolny sposób, który dostarczy zidentyfikowaną wartość konsumentowi wartości we właściwym kontekście.

Sprawdzony przykład

Przykładowa historia użytkownika

Łatwiej to wyjaśnić, jeśli zaczniesz od mniej dwuznacznego zestawu historii użytkowników. Ponieważ OP nie dostarczył użytecznej historii użytkownika, która jest zgodna z mnemonikiem INVEST , wymyślę ją dla przykładu. Rozważ następującą historię:

Jako użytkownik, który woli płacić kartą Discover,
chciałbym mieć możliwość dokonywania zakupów przy użyciu karty Discover,
aby nie ograniczać się do kart Visa, Mastercard lub American Express.

Zapewnia to konkretną funkcję, zapewnia kontekst, który może pomóc w podejmowaniu decyzji dotyczących wdrożenia, które zespół musi podjąć, i identyfikuje konsumenta wartości jako klienta będącego właścicielem karty Discover. To nie jest zestaw specyfikacji, ale to jest to, czego potrzebujesz, aby mieć właściwe rozmowy z klientem i zespołem o tym, jak najlepiej wdrożyć historię podczas iteracji rozwoju.

Analiza i wdrożenie

Rzeczywiste wdrożenie zależy od zespołu. Zespół będzie musiał przeprowadzić analizę w celu ustalenia:

• Najłatwiejszy sposób na wdrożenie nowej funkcji.
• Którą z różnych opcji wdrażania najłatwiej będzie wesprzeć w przyszłości, bez narastania zadłużenia technicznego.
• W jaki sposób zastosować zasady otwartego zamknięcia i YAGNI, aby upewnić się, że nowa funkcja jest niezawodna bez nadmiernej inżynierii.

Jedną z podstawowych zasad Manifestu Agile jest współpraca z klientem. Oczekuje się, że wielofunkcyjny, samoorganizujący się zespół będzie w stanie współpracować z klientem w celu wypracowania szczegółów wdrożenia w ramach wytycznych dostarczonych przez historię użytkownika.

Jeśli twoje historie użytkowników nie są dobrze napisane lub jeśli zespół nie ma umiejętności lub dojrzałości procesowej, aby wykonać wystarczającą analizę wymaganą przez zwinną strukturę, to oczywiście będzie to o wiele trudniejsze niż to konieczne. Całe książki zostały napisane na temat tworzenia dobrych historii użytkowników na odpowiednio wysokim poziomie szczegółowości; nie ma niestety srebrnej kuli, ale jest to umiejętność do nauczenia się dla zwinnych drużyn.

Projektowanie oparte na testach i zachowaniach

Najlepszym sposobem na zapewnienie rzetelności analizy oraz prawidłowego i możliwego do wdrożenia wdrożenia jest zastosowanie praktyk TDD i BDD. Na przykład, biorąc pod uwagę powyższą historię, zespół powinien uchwycić planowaną implementację za pomocą artefaktów, takich jak:

• Funkcje ogórka z testowalnymi scenariuszami.

  Jest to najbardziej przydatne do napędzania rozwoju testów akceptacyjnych oraz do dokumentowania oczekiwań użytkowników dotyczących zachowania aplikacji. Na przykład historia użytkownika powinna mieć jedną lub więcej powiązanych funkcji Ogórek, które opisują, w jaki sposób użytkownik może sprawdzić kartę Discover i jak wygląda ten proces dla użytkownika.

• Testy RSpec, które sprawdzają zachowanie (nie wewnętrzne szczegóły implementacji) nowych funkcji kodu.

  Jest to najbardziej przydatne do dokumentowania i sprawdzania zamierzonego zachowania funkcji w aplikacji. Na przykład historia użytkownika będzie kierować tworzeniem testów jednostkowych i integracyjnych, które zapewnią, że użycie karty Discover wywołuje zachowanie właściwe dla karty, wymagane przez aplikację do autoryzacji sprzedaży za pośrednictwem bramki płatniczej.

Konkretne narzędzia nie mają znaczenia. Jeśli nie lubisz Cucumber lub RSpec, użyj narzędzi lub metod, które najlepiej pasują do Twojego zespołu. Chodzi jednak o to, że szczegóły implementacji są oparte na historii użytkownika , ale nie są przez nią przepisywane . Zamiast tego implementacja (lub specyfikacje, jeśli wolisz) to szczegóły, które należy opracować podczas opracowywania funkcji we współpracy.

Wiele dobrych odpowiedzi tutaj. Mam nadzieję, że mogę dodać trochę wartości innym ...

Myślę, że jedno zawieszenie, które może mieć Twój zespół, migruje z metodologii innej niż Agile.

Jest to zwykle pewna metoda z wodospadu i, w praktyce, zwykle wymaga to udokumentowania wszystkich wymagań technicznych przed napisaniem wiersza kodu.

Ale to nie zawsze działa. Często to nie działa. Powód? Ponieważ wymagania rzadko są zgodne z rzeczywistością. Rzeczy się zmieniają. Stąd ruch w kierunku Agile.

Dzięki Agile historia użytkownika jest wszystkim, na czym jej zależy. Chcą dostać się od punktu A do punktu B. Jak się tam dostać pod względem implementacji, zależy od ciebie. Jeśli czekasz, aż ktoś powie ci wymagania techniczne, to naprawdę nie jest zwinny. Jeśli masz pytania, zapytaj. Jeśli potrzebujesz dokumentacji, udokumentuj, ale nie chcesz, aby klient podejmował wszystkie te decyzje za Ciebie. Mogą mieć opinie, ale w środowisku zwinnym opinie te powinny być (jak sugeruje twój guru) dyskusja w rozmowie.

Może wydawać się, że jest to obciążenie dla twojego zespołu, ale uważaj to za luksus. Twój zespół ma teraz wiele do powiedzenia w kwestii rozwiązania - co niekoniecznie miało miejsce w modelu wodospadu.