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

18

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?

użytkownik144171
źródło
6
Historie użytkowników są właśnie takie - wymagania na poziomie użytkownika. „Wymagania programowe” niższego poziomu (często ograniczenia uważa się za dopuszczalne) należy zawsze zbierać osobno i oddzielnie dokumentować z odpowiednim odniesieniem.
Gusdor,
7
Chodzi o to, że historie użytkowników są takie, że większość użytkowników Twojego programu nigdy nie będzie wiedzieć ani obchodzić się, jak to działa . Nie dbają o strukturę bazy danych, podział problemów, struktury klas itp .; dbają o stabilność, szybkość i łatwość użytkowania. Dlatego rejestrujesz ich historie, aby dowiedzieć się, do czego będą używać programu. Sposób, w jaki następnie go wdrażasz, to zupełnie odrębny poziom wymagań, użytkownicy na ogół nie będą w stanie lub nie będą chcieli poinformować o tym procesie.
jonrsharpe
2
komar: Właściwie nie. Zapytałem, ponieważ jestem naprawdę zainteresowany tym, jak można to zrobić poprawnie, ponieważ jestem pewien, że biorąc pod uwagę powszechne stosowanie SCRUM, musi to stanowić problem dla wielu zespołów.
user144171
4
@maple_shaft problem z elementami „rantish” polega na tym, że przyciągają one rantish odpowiedzi. Zgadzam się, że jest w tym sensowny rdzeń, zastanawiam się, czy można go edytować, aby po prostu zachować ten rdzeń i zetrzeć zaproszenie do nieprzyzwoitych odpowiedzi
gnat
2
Tu jest dobre pytanie, ale napisane jest to rantem. Podjąłem próbę edycji.
DA01

Odpowiedzi:

28

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.

MetaFight
źródło
3
Kryteria akceptacji +1 dodają więcej szczegółów
ułamkowe
3

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.

gbjbaanb
źródło
4
Czy mógłbyś sformułować to w mniej (tj. Nie) uwłaczający sposób? Zgadzam się z tobą na ten temat, ale ludzie mają różne opinie i nie ma to uzasadnienia dla utraty twoich manier w ten sposób.
Frank
W rzeczywistości nie wyobrażam sobie wymagań, które nie zostałyby napisane z góry - nawet w przypadku najprostszych rzeczy, takich jak pola numeryczne, musisz znać długość, typ danych, sprawdzanie poprawności. Według tych guru te rzeczy nie są konieczne, aby znaleźć się w historii. Ale kiedy piszesz kod, US na wysokim poziomie jest bezużyteczne, musisz znać ograniczenia, przepływy itp. Itp. Nigdy nie widziałem projektu z czystym, dwustaniowym USA, który byłby skuteczny w implementacji i testowaniu.
user144171,
3
Klient zgodził się na 8-bitową liczbę całkowitą, więc to nie moja wina.
JeffO
2
@gbjbaanb: Agile to tylko nowe wymyślne słowo określające „używanie zdrowego rozsądku”, tj. znalezienie właściwej równowagi między wstępną analizą / projektem a szybkim dostarczeniem częściowego rozwiązania w celu zebrania opinii. Uważam, że termin zwinny jest dość irytujący, ponieważ niewiele jest w tych pomysłach innych niż nazwa. Gorzej dzieje się, gdy dość elastyczna struktura, taka jak SCRUM, jest narzucana jako zwinna . IMO naprawdę zwinne oznaczałoby porzucenie słów zwinny i SCRUM i dostosowanie procesu do twoich potrzeb, jak zawsze robiliśmy przed rozpoczęciem zwinnej fali.
Giorgio
1
@Alex bardzo pyta w kontekście SCRUM i zwinnych procesów.
gbjbaanb
3

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.

JeffO
źródło
1
Ale tu jest problem, trochę Clain US jest wszystkim, czego potrzebujesz, ale mówię, że nie jest to możliwe, gdy historia opowiada o „co”, a nie o „jak”. Jeśli chcą mieć ekran logowania, jakie długości będzie mieć pole? Jakie postacie będą dozwolone? itd ... użytkownicy nie dbają o to, ale deweloperzy i testerzy to zrobią i stąd trzeba to gdzieś napisać.
user144171,
4
Zapisz to! W dodatkowej dokumentacji nie ma nic złego, jeśli to wystarczy, aby wykonać zadanie. Po prostu zrozum, że w wielu przypadkach nie można traktować tego jak umowy z klientem. Klient faktycznie użyje ekranu logowania, a następnie powie ci, że potrzebuje więcej znaków, niezależnie od tego, co mówi twoja dokumentacja. Teraz możesz zdecydować, czy chcesz zmienić kod, dokumentację czy jedno i drugie.
JeffO
A jeśli dostosowanie długości danych wejściowych jest ogromnym przedsięwzięciem, Twój kod i tak nie jest zbyt zwinny, więc niewielka lub żadna dokumentacja nie zrobi dużej różnicy.
JeffO,
2
@ user144171 Próba spisania WSZYSTKICH wymagań dotyczących projektu lub funkcji z góry i w najbardziej szczegółowy sposób, aż do ostatniego bitu, jest tak samo zła, jak brak jakichkolwiek wymagań. To samo dotyczy projektowania.
AK_
@AK_ Nie wydaje mi się, żeby twierdził, że wszystko to musi być zrobione z góry, ale na pewno musi być zrobione z góry przed sprintem, gdy istnieje spora zaległość.
wałek klonowy
2

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.

wałek klonowy
źródło
Nie jestem pewien, czy rozróżniasz wymagania użytkowników od wymagań funkcjonalnych. Wymagania użytkownika, podobnie jak w USA, powinny być wymaganiami funkcjonalnymi, a wymagania funkcjonalne są dość różne od wymagań systemowych.
Alex,
@Alex: historia użytkownika / wymaganie => chcesz wypłacić pieniądze z bankomatu, wymaganie funkcjonalne => całkowity czas na wystawienie rachunków nie może przekroczyć 30 sekund. Wymagania użytkownika nie obejmują wymagań funkcjonalnych.
jmoreno
@jmoreno Ta „historia użytkownika” w twoim przykładzie nie jest historią użytkownika, jest punktem wyjścia do historii użytkownika. A „wymóg funkcjonalny” dotyczący czasu wykonania znajduje się w szarej strefie, głównym wymogiem funkcjonalnym jest wystawianie rachunków, ograniczenie czasowe może mieć wiele źródeł.
Alex,
2
@jmoreno W rzeczywistości taki wskaźnik wydajności jest uważany za wymóg niefunkcjonalny a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. Same zachowania są funkcje o systemie . Historia użytkownika kontrastuje oba te elementy, definiując potrzebę użytkownika. Funkcją użytkownika jest natomiast to, co znamy jako Korzystanie sprawie , a nie wymóg funkcjonalnego.
wałek klonowy
@Alex Zobacz mój komentarz powyżej. Myślę, że oboje jesteście zdezorientowani co do wymagań funkcjonalnych.
wałek klonowy
1

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.

Alex
źródło
1

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.

Cort Ammon - Przywróć Monikę
źródło
1
Problem w tym sposobie myślenia polega na tym, że działa dobrze w kreatywnym projekcie, w którym potrzeby użytkownika są jasne, ale twarde specyfikacje są ograniczone. Kiedy zaczynamy mówić o skomplikowanych interakcjach systemowych, a zwłaszcza o ograniczeniach regulacyjnych i potrzebie biznesowej dotyczących ściśle określonych parametrów systemu, same historie użytkowników często nie są w stanie uchwycić ważnych szczegółów. Więc zaczynają rozmowę, ale kiedy mam 20 stron twardych, nieugiętych specyfikacji i zasad, to jest to zbyt wiele do wchłonięcia w „rozmowie”. Konieczne są również wymagania funkcjonalne.
wałek klonowy
1
Zgadzam się, że potrzebne są wymagania, myślę, że powinny pójść gdzie indziej. Nie mogę mówić za resztą świata, ale przekonałem się, że niezwykle łatwo jest uzurpować sobie przeznaczenie historii użytkowników i przekształcać je w broszury pełne wymagań. Jeśli tak się stanie, nie mam dokąd pójść. W idealnym świecie można umieścić obie historie użytkowników, ale programiści są ludźmi, a kultura zmienna. Jeśli zespół przyzwyczai się do wykorzystywania historii użytkowników w celu spełnienia wymagań, może być kulturowo niemożliwe powrót do tego, co uważam za ich główny cel.
Cort Ammon - Przywróć Monikę
1

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ć.

Piotr jest
źródło
1

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.

CodeGnome
źródło
0

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.

DA01
źródło