Historia użytkownika a wymaganie

User Story rejestruje to, co użytkownik chce zrobić z systemem na wysokim poziomie. Rozumiem, że historia użytkownika spowodowałaby szereg wymagań na niskim poziomie. Czy historia użytkownika jest tym samym, co wysoki poziom wymagań dla systemu?

Szczerze mówiąc, po prawie dwóch latach spędzonych na rozwoju Agile, nadal uważam, że „historia użytkownika” to tylko wymyślne określenie „wymagania funkcjonalne”.

Na poziomie powierzchownym jest różna , np. Zawsze przyjmuje pewną formę ( „jako X, chcę Y, aby Z ...” ), ale kluczowe elementy - identyfikacja interesariusza i uzasadnienie - są również nieodłączne od pisemne wymagania funkcjonalne. Pisanie złej historii użytkownika jest równie łatwe, jak pisanie złych wymagań ( „jak [nazwa naszej firmy], chcę [niejasna funkcja], abym mógł [zrobić coś, co jest oczywistą częścią mojej pracy, na przykład „sprzedaj więcej klientom”] ” ).

Z mojego doświadczenia historie użytkowników prawie nigdy nie wychwytują wymagań niefunkcjonalnych , takich jak wydajność i bezpieczeństwo. Tego rodzaju wymagania są bardzo trudne do prawidłowego napisania, a format historii użytkownika po prostu nie jest zbyt dobry do ich uchwycenia, ponieważ bardziej dotyczą ogólnej jakości produktu i łagodzenia (ale nie eliminowania) ryzyka, niż zaspokajania konkretnego użytkownika potrzeba.

Tak więc naprawdę myślę o historiach użytkowników jako podzbiorze wymagań o określonej formule i nadal używam tych terminów dość zamiennie.

Jedną z głównych zalet historii użytkowników w stosunku do wymagań jest to, że słowo „wymaganie” sugeruje, że funkcja jest wymagana tam, gdzie jest często pożądana . Historie użytkowników mogą teoretycznie zostać uszeregowane według priorytetów i przypisane do każdej wersji, podczas gdy wymagania wydają się być warunkiem wstępnym każdej wersji.

Oczywiście, aby wspomniane wyżej rozróżnienie miało znaczenie, Twoi klienci i / lub kierownictwo wyższego szczebla muszą je zaakceptować; nic ci to nie da, jeśli masz 30 historii użytkowników zgrupowanych w „projekt”, który musi być ukończony w tym samym czasie. W takim przypadku możesz równie dobrze nazwać je „wymaganiami”, ponieważ są one w rzeczywistości wymagane.

Ron Jeffries pisał dawno temu o 3C historii użytkowników ( http://xprogramming.com/articles/expcardconversationconfirmation/ ) z naciskiem na kartę (krótki opis), rozmowę między klientem a zespołem dostarczającym raz historię użytkownika staje się możliwe do wykonania, a uzgodnione potwierdzenie historii po tej rozmowie.

zasadniczo, przed rozmową, historie użytkowników są po prostu planowanym zakresem - przybliżone pomysły na temat tego, co możemy zrobić. po rozmowie powinieneś mieć sposób na potwierdzenie, że historia jest kompletna. Tak więc w zależności od czasu, kiedy spojrzysz na historię na tej osi czasu, historia może być tylko szerokim pojęciem o zakresie lub szczegółowym wymaganiem.

w dzisiejszych czasach znaczenie „historii użytkownika” wydaje się zawężone do samej „karcianej” części 3C Jeffriesa. w takim przypadku historia użytkownika nie jest wymogiem, ale obietnicą przeprowadzenia rozmowy na temat wymagań.

Mnóstwo złotych samorodków mądrości na temat historii użytkowników można znaleźć na wiki wiki C2 ( http://xp.c2.com/UserStory.html )

Historie użytkowników i wymagania to bardzo różne bestie.

Wymagania

Wymagania zakładają, że projekt aplikacji jest wykonywany wcześniej, a rozwój jest implementacją tego projektu. Wymagania koncentrują się zatem na tym, jak zaimplementować funkcjonalność.

Przykład wymagania:

• Utwórz formularz kontaktowy użytkownika z następującymi polami: imię, nazwisko, adres e-mail, dowolny tekst i przycisk przesyłania. Po naciśnięciu przycisku wysyłania wiadomość e-mail jest wysyłana do naszego zespołu pomocy technicznej.

Historie użytkownika

Historie użytkowników koncentrują się na tym, co należy osiągnąć, i nalegają, aby projekt produktu został wykonany w ostatniej chwili i jest to współpraca między osobą odpowiedzialną za produkt a osobą opracowującą. Szczegóły są ustalane podczas wdrażania na podstawie możliwości.

Przykład historii:

• Jako użytkownik Jimmy chcę skontaktować się z zespołem pomocy technicznej, gdy nie mogę prawidłowo korzystać z witryny, aby mógł mi pomóc.

Jaka jest różnica?

Jak widać, z pewnością istnieje różnica w ilości dostarczanych szczegółów, ale jest też wiele informacji, które są dostępne tylko w opowieści, a mianowicie cel, jaki chcemy osiągnąć za pomocą tej funkcji.

Chociaż może się wydawać, że cel jest stosunkowo nieistotny, jest to błędne założenie w zwinnym rozwoju. Zazwyczaj są dwa przypadki, w których znajomość celu jest bardzo ważna: zmniejszenie kosztu możliwości i umożliwienie zwinności.

Koszt możliwości

Jeśli w wymaganiu są ukryte założenia, osiągnięcie tego może być bardzo trudne. Na przykład: czy jest dostępny serwer pocztowy? Jeśli nie, opracowanie wymogu może zająć znacznie więcej czasu. W niektórych innych przypadkach ze względu na projekt można pominąć prostszy sposób osiągnięcia tego samego celu.

Natomiast historia użytkownika dotyczy kontaktu użytkownika z naszym działem wsparcia. Jeśli wysłanie wiadomości e-mail jest niewykonalne lub zbyt drogie, możemy od razu opracować inne rozwiązanie: napisz na przykład do bazy danych lub skorzystaj z formularza za pośrednictwem dokumentów Google lub po prostu podaj adres e-mail zamiast formularza. Nie można tego łatwo zrobić z wymaganiem, ale można to łatwo zrobić z historią i obecną osobą produktu.

Zwinność

Z tego powodu, mając wymagania, zwykle myślimy wcześniej o tych ukrytych założeniach i upewniamy się, że nie ma żadnych problemów. Tak więc w tym przypadku może istnieć inne wymaganie, zaplanowane wcześniej, które upewni się, że serwer pocztowy jest obecny.

To prowadzi nas do kolejnej ogromnej różnicy między historiami a wymaganiami, którą jest hierarchia . Jak zilustrowałem powyżej, wymagania z natury muszą być uporządkowane w jakiejś naturalnej hierarchii, aby spełnić zależności. Z drugiej strony historie koncentrują się na celu i nie mają takich ograniczeń.

Jest to zgodne z projektem, ponieważ w przypadku zwinności zasadnicze znaczenie ma dodawanie, usuwanie, zmiana harmonogramu i modyfikowanie historii zgodnie z potrzebami podczas realizacji projektu. Wymagania można na ogół dodawać, czasem modyfikować lub usuwać, ale generalnie bardzo bolesne jest przenoszenie ich ze względu na wszystkie zależności. Po prostu nie jest to często wykonywane. Jeśli pracujesz z wymaganiami, Twoja zwinna implementacja ucierpi lub prawdopodobnie nie będzie bardzo zwinna, w sensie możliwości przyjęcia zmian.

Dla mnie kluczowym elementem Historii użytkownika jest to, że przechwytuje Dlaczego i jak użytkownik korzysta z systemu. Jest to szczególnie przydatne, ponieważ nie określa szczegółowo sposobu, w jaki system zapewnia wymaganą funkcjonalność. Gdy potrzebne są testy interfejsu użytkownika i użyteczności, historia użytkownika może być najważniejszym dokumentem.

Jasne, możesz poprosić selen o sprawdzenie, czy niektóre węzły są obecne w kodzie HTML, zrobienie zrzutów ekranu lub sprawdzenie, czy niektóre piksele są tam, gdzie masz nadzieję, że są. Ale jeśli pojawia się wprowadzający w błąd tekst lub nie jest oczywiste, w jaki sposób użytkownik powinien korzystać z systemu, lub trudno mu jest dowiedzieć się, jak osiągnąć swój cel, nagle nie ma już kompletnego systemu. Teraz wymagane jest szkolenie w celu korzystania z systemu. Sprawdzenie kompletnego systemu pod kątem scenariuszy użytkownika jest kluczowym elementem ręcznego testowania.

W opowieściach użytkowników / scenariuszach znajduje się sposób myślenia, który powinien wpływać na wiele szczegółowych decyzji projektowych dotyczących wdrożenia. O ile programiści nie rozmawiają bezpośrednio z użytkownikami lub nie obserwują, jak korzystają z systemu, scenariusz użytkownika może być jedynym łącznikiem umożliwiającym im zrozumienie potrzeb użytkowników.

Wreszcie, pozwalają przedsiębiorcom określić, czego potrzebują, bez sugerowania, jak należy to osiągnąć. O wiele łatwiej jest opisać rozwiązanie niż potrzebę, a scenariusze użytkownika zapewniają ramy do opisu potrzeb bez proponowania konkretnego rozwiązania. Najczęstszym wymaganiem biznesowym, jakie słyszałem, jest „chcę, żeby był taki jak Excel, ale w sieci”, który nigdy nie był tym, czego naprawdę potrzebował.

Powiedziałbym więc, że dobra historia nie powinna zawierać żadnych konkretnych szczegółów dotyczących sposobu wdrożenia systemu. Powinien on powiedzieć: „Raz w miesiącu system A musi być aktualizowany o nowe dane z systemu B. Dane te mogą wymagać poprawek. Klient ma historię wprowadzania nieprawidłowych danych i nierealizacji problemu przez tygodnie”. Nie powinno się mówić: „System musi zaakceptować plik CSV Latin1 co najmniej raz w miesiącu i zgłosić wyjątek NumberFormatException, jeśli kolumna 3 nie jest liczbą”. Czy widzisz różnicę? Scenariusz opisuje potrzebę, a nie konkretne rozwiązanie. Następnie podczas testów powracasz do scenariusza, aby upewnić się, że rozwiązanie odpowiada potrzebom. Wymagania mogą łączyć niektóre potrzeby z niektórymi rozwiązaniami, a nawet całkowicie koncentrować się na rozwiązaniach.

Natknąłem się na to podczas wyszukiwania w Google i pomyślałem, że wrzucę swoją opinię.

Tak naprawdę nie ma różnicy między wymaganiem a historią użytkownika. Oba określają pożądany wynik lub cel z perspektywy użytkownika.

Jedyną różnicą jest sposób, w jaki analityk biznesowy uchwycił ten cel lub wynik. W tym przypadku jest to sformułowanie.

Przykład:

Jako kierownik zespołu chcę sprawdzić, który z moich zespołów pracuje nad sprawami dotyczącymi hipotek, aby móc monitorować ich wyniki.

Rozwiązanie powinno wyświetlać członków zespołu pracujących nad sprawami hipotecznymi.

Oba powyższe można interpretować w ten sam sposób, ale oba mają również dużą dwuznaczność. Najważniejsza jest tutaj różnica w stylu. Myślę, że problemem, który najczęściej widzimy, jest to, jak daleko sięgamy do zdefiniowania rozwiązania, zanim wyszliśmy ze świata wymagań i wkraczamy w świat projektowania funkcjonalnego. Czy do analityka biznesowego należy stwierdzenie „lista zalogowanych użytkowników według imienia i nazwiska w głównym menu aplikacji”, czy to zbyt wiele informacji? Kiedy siedzimy i rozmawiamy z naszymi interesariuszami, a wszyscy znamy rozwiązanie i potrafimy zinterpretować jego wygląd, nawet prawdopodobny język kodu, na którym zostanie on zbudowany, i sposób jego wdrożenia, czy naprawdę musimy zagrać w purystyczną grę „ zdefiniujmy cele, a nie rozwiązania ”. To właśnie tam czuję zamieszanie.

Wymagania często zakładają, że nie wiemy nic o rozwiązaniu, tylko pożądane wyniki. Tak, to sprawia, że ​​wszystko jest agnostyczne, ale czy to naprawdę pomaga nam w cyklu rozwoju? Jeśli potrafimy precyzyjnie zdefiniować coś wcześnie, dlaczego tego nie zrobić?

Podsumowując, nie martwię się o historie użytkowników i różnice wymagań. Ostatecznie chcesz zdefiniować wystarczającą ilość informacji, aby ktoś mógł opracować rozwiązanie. Historia użytkownika, która ma zbyt wysoki poziom, zostanie po prostu odrzucona i poproszona o podzielenie na mniejsze historie użytkowników. To samo, co styl „system powinien”. Prawdopodobnie zostanie odrzucone jako zbyt dwuznaczne, jeśli nie ma wystarczającej ilości szczegółów.

Na koniec idź z tym, co lubią widzieć twoi programiści i interesariusze.

Myślę, że istnieje duża niespójność co do tego, co oznaczają słowa, nawet w klasycznych podręcznikach. Ta sama niespójność dotyczy historii użytkowników. Różne organizacje i podręczniki traktują te warunki inaczej. Na przykład, jak klasyczny podręcznik Rogera Pressmana inżynierii oprogramowania mówi o wymaganiach, jest zupełnie inny niż książka Agile Software Requirements Deana Leffingwella. Szanuję ich obu i mogą być ważne.

Wymagania mogą być tym, co kodujemy, i które mają niezwykłą specyfikę, a niewiele pozostawia wyobraźni. Z drugiej strony można argumentować, że wymagania powinny określać problem biznesowy, a nie określać rozwiązanie. Myślę, że jest bardziej szczegółowy, a odpowiedź leży gdzieś w spektrum, który jest unikalny dla każdej firmy i branży (nie całe oprogramowanie powstaje w IT).

Nauczono mnie, że wywoływanie wymagań prowadzi do analizy, która prowadzi do projektowania, która prowadzi do architektury, która prowadzi do opracowania wymagań lub specyfikacji, co prowadzi do czegoś, co można zakodować. Nie wierzę, że to zwinnie. Moment, w którym te rzeczy się zdarzają, zmienia się i to jest najważniejsza różnica. W modelu wodospadu pozyskiwanie i opracowywanie odbywa się wcześnie. W lean i scrum, pozyskiwanie i opracowywanie odbywa się na różnych etapach, a więcej opracowań odbywa się w miarę zbliżania się do implementacji w sprincie. Podobnie jak wschodzące prace projektowe.

W naszej organizacji opieramy się na modelu Epics, funkcji i historii Leffingwella, nie jako wymaganiach, ale jako podział pracy i ustalanie priorytetów. Wymagania to inna sprawa. Wymagania są zarządzane osobno, ponieważ jesteśmy do tego zobowiązani w przypadku agencji regulacyjnych. A jednak niektóre zespoły z pewnością opracowują wymagania dotyczące historii użytkowników podczas planowania programu i planowania sprintu.

Wymagania funkcjonalne są zwykle formalną specyfikacją, która pozwala dokładnie wiedzieć, czy oprogramowanie działa, czy nie. Historia użytkownika jest zwykle o wiele bardziej nieformalnym sposobem opisania potrzeby jednej historii użytkownika. Nie określa sztywnej specyfikacji w celu ustalenia, czy oprogramowanie jest „prawidłowe” czy „nieprawidłowe”. Chociaż możesz przetestować jego część, prawdziwym zakończeniem historii użytkownika (jeśli zrobisz to dobrze) jest to, że użytkownik mówi „tak, to rozwiązuje mój problem!”. Zapamiętaj zwinny manifest:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

W swojej książce „User Story Stosowanej”, Mike Cohn powiedzieć wyraźnie, że niektóre rzeczy nie mapować do historii użytkownika i nie trzeba używać tylko tego.

W moim własnym zespole stosujemy:

• Historia użytkownika : potrzeba biznesowa pewnego użytkownika. Nacisk kładziony jest tutaj na potrzebę i dlaczego on jej potrzebuje. Jak powiedzieli inni, ważne jest tutaj, aby nie określać, jak to się robi, i zagłębić się w rzeczywistą potrzebę użytkownika (np. Nie musi przeglądać danych w tabeli, musi zobaczyć dokładną wartość dane, i on jest w stanie to zrobić).
• Błąd : nieoczekiwane zachowanie oprogramowania, które zakłóca normalne użytkowanie. Zwykle mają „Ważność” (niezależnie od priorytetu rozwoju), która ocenia, jak bardzo wpływa na przepływ pracy użytkownika.
• Dług techniczny Coś, co nie przeszkadza w korzystaniu z oprogramowania, ale wpłynie na nas , programistów, w przyszłości. Przykład: niektóre klasy są trudne do odczytania, kompilacja jest powolna, niektóre kody nie są testowane jednostkowo, IDE pokazuje dziwne ostrzeżenia ...
• Ulepszenie : zmiana w oprogramowaniu, która nie pozwala na nowe scenariusze, ale zapewnia lepsze wrażenia. Przykład: zmiana czcionek, przeprojektowanie formularza, aby był bardziej przejrzysty, dodanie rozsądnych domyślnych ustawień aplikacji itp.

Wymagania funkcjonalne nie pozwoliłyby nam zorientować się, że zaimplementowana funkcja nie zaspokaja potrzeby użytkownika, mimo że nasz test ogórkowy przeszedł pomyślnie i zaimplementowaliśmy każde napisane słowo. Historia jest dyskusją i jest nieformalna. Chodzi o to, aby faceci od wdrażania zrozumieli, na czym polega problem. Nie są narzędziem kontraktowym. Jeśli robisz „scrum ale ... ”, a twoja historia jest po prostu zabawnym sposobem na napisanie wymagań oprogramowania, to tak, nie ma różnicy.

Nie chodzi o historię użytkownika, chodzi o ogromną zmianę paradygmatu w sposobie podejścia do pracy do wykonania. Nie podpisujesz umowy, pomagasz niektórym użytkownikom rozwiązać problem. Jeśli nie widzisz historii użytkowników jako narzędzia do dyskusji z prawdziwym użytkownikiem, oznacza to, że nie używasz historii użytkowników, używasz funky składni wymagań .

Reszta tutaj to moja opinia: historia użytkownika nigdy nie odniesie sukcesu w sposób jednostronny. Potrzebujesz klienta do pracy z nim. Upadek wody jest skazany na dziwny bałagan wymagający, ale nie wymagający. Jeśli masz stałą ofertę przetargową z określonymi wymaganiami, nie używaj iteracji i historii użytkownika, nie ma sensu . Skorzystaj z pozostałej części zwinnego zestawu narzędzi: zautomatyzowany test jednostkowy / funkcjonalny, przegląd kodu, ciągła integracja, refaktoryzacja itp. Upewnij się, że twoje oprogramowanie działa nieprzerwanie i że możesz je natychmiast wysłać. Udostępnij go w niedokończonej formie klientowi, aby mógł przekazać jak najwięcej informacji zwrotnych. Gdybyś to zrobił, przyjacielu, nawet gdybyś nie zrobił „Historii użytkownika” i „Scruma”, byłbyś bardziej zwinny niż wiele tak zwanych sklepów „Agile”.

Wierzę, że wszyscy będą wdrażać i oznaczać wszystko inaczej w zależności od wcześniejszych doświadczeń i nie warto kłócić się o to, jaki język działa dla tej firmy, która wykonuje pracę.

Jednak IMO, User Story jest zgodne z podejściem Agile, zgodnie z którym „klienci w budynku lub klient jest natychmiast dostępny”, gdzie dokumentacja niekoniecznie jest potrzebna, ponieważ szczegóły są w głowie klienta i są łatwo dostępne, więc formalne SRS może nie będzie wymagane. Teraz „Zadanie” „Historii użytkowników” polega na tym, jak deweloper zamierza budować historie użytkowników w sposób strawny.

Przykładową historią użytkownika może być:

Jako użytkownik administracyjny chcę przeglądać dane moich klientów wymienione w siatce

a „zadaniem” może być:

1. Utwórz siatkę, która wyświetla dane do wyświetlenia

2. Włącz sortowanie w siatce, która posortuje wybraną kolumnę

Teraz każde z zadań jest szacowane i wykonywane w odpowiednim sprincie.

Z „tradycyjnej” perspektywy, w której „trudno jest zdobyć klienta, musimy to zanotować, aby mógł potwierdzić, że mamy go tuż przed rozpoczęciem planowania / kodowania”, specyfikacja wymagań oprogramowania jest będą pomysły, które były w głowach klientów, które zostały opracowane, a następnie spisane i sformalizowane, a następnie opracowane i zarządzane.

W tym przypadku „wymaganie funkcjonalne” to drobiazgowy szczegół tego SRS i część większego pomysłu. Tak więc, moim zdaniem, historia użytkownika może być postrzegana jako (część) formalnego „wymagania”, a zadaniem tej historii użytkownika jest (lub jeden z wielu) wymóg funkcjonalny.

W przykładowej historii użytkownika formalne „wymaganie” byłoby długim dokumentem zawierającym schematy blokowe i zasadniczo koncentruje się na dokumentacji, w przeciwieństwie do bardziej „zwinnego” podejścia, które jest zorientowane na klienta.

Różnica polega na tym, że formalne „wymaganie” będzie zgodne z 10-stronicowym dokumentem przedstawiającym sekcję administracyjną aplikacji, która wskazuje, że niektóre listy będą potrzebne, pewne zabezpieczenia oparte na rolach itp., A następnie niektóre funkcje wymagania będą następujące: „siatki wykazów powinny umożliwiać sortowanie”, „informacje o użytkowniku powinny być wymienione w siatce” itp.

i wierzę, że w dzisiejszych czasach warunki są mieszane i mieszane ... co nie ma znaczenia