jednym z największych wyzwań w rozwoju oprogramowania jest prawie niemożliwe zadanie zebrania jasnych wymagań, a następnie uzyskanie tych wymagań, aby pozostały niezmienione podczas tworzenia kodu. W podejściu waterfall do rozwoju oprogramowania-pomimo wysiłków mających na celu zdefiniowanie, udokumentowanie i zatwierdzenie każdego możliwego przypadku przed rozpoczęciem rozwoju-dostarczony produkt rzadko jest tym, czego chce klient.
zwinna alternatywa? Tworzenie historii użytkownika.,
jedną z największych zalet stosowania zwinnego podejścia do tworzenia oprogramowania jest to, że wymagania nie są określone w kamieniu, ale zamiast tego oczekuje się, że ulegną zmianie, dzięki ciągłym opiniom interesariuszy i firmy. Zwinne metody, takie jak Scrum i extreme programming (XP), zastępują tradycyjne, długie dokumenty z wymaganiami priorytetowymi zaległościami produktowymi złożonymi ze zwięzłych historii użytkowników, których szczegóły pojawiają się bliżej momentu, w którym historia jest gotowa do wdrożenia.,
chociaż tworzenie historii użytkownika jest bardziej sztuką niż nauką, ten samouczek zawiera informacje, przykłady i kroki potrzebne do tworzenia wysokiej jakości historii użytkownika.
historia user stories
XP po raz pierwszy wprowadził pojęcie user stories w 1998 roku, porównując je do przypadków użycia. W Object-Oriented Software Engineering: A Use Case Driven Approach Ivar Jacobson wprowadził przypadki użycia jako sposób dokumentowania wymagań poprzez zdefiniowanie interakcji między rolą (osobą używającą systemu) a samym systemem w celu osiągnięcia celu za pomocą Unified Modeling Language (UML).,
to podejście było popularne w rozwoju obiektowym i nadal jest używane jako kluczowy proces w ramach tworzenia oprogramowania, takich jak Unified Process (UP), IBM Rational Unified Process (RUP) i Oracle Unified Method (OUM). Korzystanie z przypadków użycia, a nie user stories, pozwala na iteracyjny i Przyrostowy rozwój i jest uważane za zwinne podejście do definiowania wymagań.,
wraz z wprowadzeniem znacznie krótszych user stories I popularnością XP i Scrum, backlog produktów składający się z user stories stał się bardziej znanym podejściem do zwinnego definiowania wymagań. Wielu praktyków nadal uważa, że historie użytkowników są jedynym akceptowalnym podejściem zwinnym. Jednak Alistair Cockburn, jeden z sygnatariuszy manifestu Agile, woli przypadki użycia niż historie użytkowników.
Chociaż istnieje wiele mocnych opinii na temat znaczenia „zwinnego”, zarówno przypadki użycia, jak i historie użytkowników są zgodne z tym podejściem., Niektórzy twierdzą, że historie użytkowników w końcu stają się podobne do przypadków użycia, gdy zespół zgadza się na szczegóły implementacji. Na wczesnym etapie Historia użytkownika jest po prostu krótkim zdaniem, ale nie jest kompletna, dopóki nie zostaną określone szczegóły i kryteria akceptacji.
Tworzenie user stories
istnieją różne opinie na temat definicji user story i jak najlepiej go o tworzeniu., Niektóre wskazówki dotyczące dobrej historii użytkownika obejmują:
- powinna być napisana przez kogoś, kto reprezentuje użytkowników biznesowych (zazwyczaj Product owner)
- powinna początkowo zawierać krótkie opisy „kto, co i dlaczego”, ale nie „jak”
- powinna produkować pionowy kawałek kodu roboczego
- powinna być na tyle mała, że może być kodowana i testowana w jednej iteracji (zwykle okres od jednego do czterech tygodni)
różne szablony, techniki i akronimy są używane, aby pomóc właścicielom produktów pisać historie użytkowników., Trzy z najczęstszych technik to szablon role-feature-reason, trzy C (karta, rozmowa, potwierdzenie) i inwestować (niezależny, negocjowalny, wartościowy, szacowany, mały, testowalny).
przykłady
powiedz, że opracowujesz aplikację, która pozwoli trenerom wgrywać oprogramowanie courseware i przyciągnąć uczniów, którzy są zainteresowani wzięciem udziału w zajęciach. Oto jak można zastosować techniki user story.,
Role-Feature-Reason
jak wyjaśnia Mike Cohn Z Mountain Goat Software, szablon role-feature-reason lub RGB (rola, cel, korzyść) wygląda mniej więcej tak:
„jako I want so that .”
chociaż istnieją różnice, ta krótka struktura zdań skupia się na tym, kto, co i dlaczego. Uniemożliwia to product owner przekazanie zespołowi programistycznemu zbyt wielu informacji o tym, w jaki sposób powinien wdrożyć rozwiązanie. Skupiając się na tym, kto, co i dlaczego, zespół programistów jest uprawniony do znalezienia najlepszego rozwiązania technicznego.,
przykład 1: zapewnienie trenerowi możliwości dodania kursu
jako trener chciałbym móc dodać nowy kurs, aby mieć potencjał przyciągania nowych uczestników.
przykład 2: zapewnienie studentowi możliwości wyszukiwania kursu
jako student chciałbym móc przeszukiwać oferty kursów, aby móc znaleźć ofertę, która najbardziej mnie interesuje.
rola (who)
rola opisuje, kto skorzysta z tej funkcji. Zauważ, że rola nie jest po prostu ” użytkownik.,”Istnieją różne typy użytkowników, dlatego chcemy, aby rola była bardziej konkretna niż „użytkownik”, ale opisz typ użytkownika, który skorzysta z historii. Właściciele produktów często mają za zadanie wniknąć w umysł swoich użytkowników, aby zrozumieć, co byłoby dla nich najcenniejsze.
przykład 1 Rola = trener
przykład 2 rola = uczeń
funkcja (co)
ten krok bardzo krótko opisuje, czego chce użytkownik. To najbardziej odpowiada wymogowi opisanemu w tradycyjnym tworzeniu oprogramowania., Należy jednak uważać, aby nie być zbyt dokładnym lub opisać, jak napisać kod. Zostanie to ostatecznie ustalone, ale nie podczas tworzenia historii użytkownika. Historia użytkownika powinna być napisana z perspektywy użytkownika, który skorzysta z funkcji, a nie z perspektywy dewelopera, który będzie ją kodował.
przykład 1 funkcja = Dodaj nowy kurs
przykład 2 Funkcja = przeszukaj ofertę kursów
powód (dlaczego)
wreszcie chcemy podać, dlaczego użytkownik chce tę funkcję. Jaką wartość otrzyma od niego użytkownik?, Pomaga to product owner ocenić, w jaki sposób priorytetowo traktować historię użytkownika na zaległościach. Jeśli wartość lub korzyść nie może być wyrażona, może to być coś, co nie jest konieczne. Zrozumienie wartości często pomaga zespołowi programistów znaleźć innowacyjne sposoby wdrożenia kodu w celu rozwiązania celu-sposobów, które mogą różnić się od tego, co ma na myśli właściciel produktu.,
przykład 1 Reason = przyciągnij nowych uczniów
przykład 2 Reason = Znajdź ofertę, która najbardziej mnie interesuje
the Three C 's: Card, Conversation, Confirmation
formuła Three C' S, opracowana przez Rona Jeffriesa, pomaga osiągnąć porozumienie między biznesem a zespołem technicznym co do znaczenia historii użytkownika. Trzy C prowadzą ich przez stopniowe opracowywanie historii, od krótkiej wypowiedzi do w pełni rozwiniętej historii użytkownika.,
Karta
Historia użytkownika zaczyna się celowo krótko, z prostym stwierdzeniem, które może zmieścić się na karcie indeksowej 3×5, zazwyczaj zgodnie z formatem rola-funkcja-korzyść, który właśnie omówiłem. Na przykład:
jako trener chciałbym móc dodać nowy kurs, aby mieć potencjał do przyciągnięcia nowych uczestników.
rozmowa
chociaż historia użytkownika zaczyna się jako proste stwierdzenie, szczegóły muszą pojawić się, zanim zespół rozpocznie pracę nad historią., Zamiast opisywać, co jest potrzebne w dokumentacji, zespół będzie zawierał 1) reprezentację firmy (zwykle właściciela produktu) i 2) sam zespół programistów, w tym programistów, testerów, analityków biznesowych lub kogokolwiek innego w zespole.
ta rozmowa pozwala zespołowi programistów zadawać pytania, aby upewnić się, że mają jasne zrozumienie tego, o co prosi się i dostarczanej wartości. Na przykład:
twórca: czy trener będzie musiał przesłać oprogramowanie szkoleniowe na stronę internetową?,
Product owner: Nie, trener będzie tylko dodawał informacje o kursie, który będzie oferowany, a funkcja powinna zawierać sposób, w jaki uczeń znajdzie się na liście zainteresowań. Ta historia daje trenerowi możliwość zareklamowania kursu.
programista: jakie pola należy uwzględnić?
Product owner: tytuł kursu, streszczenie, daty i godziny, miejsce.
deweloper: czy to będzie tylko dla zajęć reklamowych twarzą w twarz?
Product owner: tak., Możemy dodać opcję wirtualnej klasy później, ale ta historia obejmie tylko dodawanie informacji o kursie do oferty zajęć twarzą w twarz.
programista: jakie informacje należy zebrać, gdy potencjalny student prosi o wpisanie się na listę zainteresowań?
Product owner: imię i nazwisko, numer telefonu i adres e-mail.
zespół zaktualizuje historię użytkownika informacjami zebranymi z rozmowy i omówi wdrożenie—lub „Jak”—które często tworzy konkretne zadania, które należy wykonać, aby ukończyć historię., Chociaż historia użytkownika jest napisana z perspektywy użytkownika, zespół programistów pisze zadania dla programistów i zawiera techniczne szczegóły implementacji.
potwierdzenie
zespół programistów musi mieć jasne zrozumienie, jak funkcja będzie działać w różnych sytuacjach, w tym w Warunkach błędów. Muszą uzyskać potwierdzenie dotyczące kryteriów akceptacji od właściciela produktu. Są to kryteria, które muszą być spełnione, aby historia została uznana za zrobioną i zaakceptowaną., Oto przykład kryteriów akceptacji:
- trener może dodać nowy kurs, wpisując tytuł kursu, streszczenie, daty i godziny oraz lokalizację w formularzu i naciskając przycisk „Dodaj kurs”.
- Jeśli brakuje jakichkolwiek pól lub daty lub godziny są nieprawidłowe, pojawią się komunikaty o błędach.
- Po poprawnym dodaniu kursu zostanie on publicznie wyświetlony na stronie kursu i pojawi się przycisk do wyrażenia zainteresowania przez kursanta.,
- przycisk odsetki pozwoli użytkownikowi wprowadzić imię i nazwisko, adres e-mail i numer telefonu, a dane te zostaną zapisane i powiązane z nowym kursem.
INVEST: atrybuty solid user story
INVEST jest akronimem, który pomaga ocenić, czy masz wysokiej jakości user story. Oto, jak atrybuty w akronimie odnoszą się do historii, nad którą pracowaliśmy.
I = Independent—czy ta historia może być uzupełniona przez zespół? Chcemy, aby zespół mógł ukończyć całą historię, a nie być zależnym od innego zespołu do tworzenia GUI, na przykład.,
N = 0—historia nie jest tak szczegółowa, aby dokładnie opisać, jak długie powinny być pola lub podać szczegóły dotyczące formatów dat itp. Najprawdopodobniej będą wspólne procedury lub biblioteki, które pozwolą Zespołowi Deweloperskiemu zaimplementować w sposób, który ma dla nich największy sens.
V = Valuable-product owner opisuje, że poszukiwaną wartością jest zdolność trenera do reklamowania nadchodzących zajęć. Jest to jasne w” dlaczego ” oryginalnego oświadczenia i ponownie podkreślone w rozmowie.,
E = Estimable-zespół zadaje wystarczająco dużo pytań i zbiera szczegóły, aby czuć się pewnie w ich zdolności do oszacowania historii.
S = Small-zespół musi mieć pewność, że będzie w stanie ukończyć historię w trakcie Sprintu. Jeśli nie, mogą podzielić historię. Na przykład w naszej przykładowej historii mogą zdecydować, aby Możliwość zbierania informacji o uczniu była inną historią i po prostu wyświetlać informacje o klasie dla tej historii.
t = Testable – dzięki jasnym kryteriom akceptacji można przetestować zarówno szczęśliwą ścieżkę, jak i warunki błędu.,
dostosowując się do wizji
omówiłem podstawy tworzenia historii użytkownika, ale nadal musisz zrozumieć szerszy obraz, zanim stworzysz własne historie użytkownika. Jest wiele pracy, którą musisz wykonać z góry, na wyższym poziomie, aby określić, jakie funkcje o najwyższej wartości powinny być dostarczane klientom. Te są ostatecznie rozłożone na historie użytkowników.
ważne jest, aby zespół najpierw zrozumiał wizję wysokiego poziomu i upewnił się, że funkcje, a ostatecznie historie użytkowników, są zgodne z tą wizją wysokiego poziomu.,
zazwyczaj dzieli się produkt na grupy według nazw, takich jak „motywy” lub „funkcje.”Chociaż etykietowanie tych zaległych elementów może się różnić w zależności od metody zwinnej i narzędzi, których używasz do ich opisania, chodzi o to, aby upewnić się, że są one wyrównane, tak aby praca mogła być śledzona zgodnie z Twoją wizją, co zapewni, że osiągniesz cele i wartości wizji produktu.
ponownie, nie rozpoczynaj projektu od tworzenia user stories; zacznij od tworzenia wizji., W naszym przykładzie po prostu pokazuję przykładową wizję, która prowadzi do niektórych przykładowych funkcji, które można dalej rozkładać na historie użytkowników.
Vision
To wysokiej jakości Strona internetowa, która pozwoli trenerom reklamować kursy i umożliwić im udział w tych kursach.
funkcje
- Udostępnij stronę oferującą kursy, która pozwoli uczestnikom zapisać się na kursy.
- Zapewnij stronę główną, która powie użytkownikom, o co chodzi w naszej witrynie.
- zapewniają proces rejestracji pozwalający użytkownikom na zalogowanie się, utworzenie profilu i śledzenie ich klas.,
- Prowadź bloga, który pomoże zareklamować naszą ofertę i zyskać rozgłos na naszej stronie.
User stories
- Zapewnij trenerowi możliwość dodania kursu na stronie oferującej kurs.
- zapewniają studentom możliwość wyszukiwania kursu.
w powyższym przykładzie możesz zobaczyć, jak powstały historie użytkowników. Historie użytkowników były częścią funkcji „zapewnienia strony oferującej kurs”, która dostosowuje się do wizji wysokiego poziomu.,
mapowanie wpływu
chociaż dostosowanie do wizji pomoże wypełnić początkowe zaległości, nie jest to jedyny sposób, aby to zrobić. Istnieje wiele narzędzi i technik, które menedżerowie produktów mogą wykorzystać do tworzenia historii, które przechodzą w nowe zaległości i które są zgodne z wizją.
jedna z technik planowania strategicznego, mapowanie wpływu, została spopularyzowana przez Gojko Adzica, autora pięćdziesięciu szybkich pomysłów na ulepszenie Historii użytkowników i mapowanie wpływu: wywarcie dużego wpływu na produkty i projekty programowe., Mapowanie wpływu to mapa myśli, która zaczyna się od celu, który powinien odpowiedzieć na pytanie o wartość i dlaczego budujesz produkt.
następny poziom zawiera listę „aktorów”, czyli osób, które pomogą osiągnąć cel. Następnie mapa zawiera listę zachowań lub „oddziaływań”, które aktorzy wykonają, aby pomóc w osiągnięciu tego celu. Ostatni poziom mapy przedstawia „rezultaty”, które zespół może wdrożyć. Umożliwiają one i wspierają podmioty w tworzeniu pożądanych skutków. To z tych rezultatów czerpie się funkcje oprogramowania i historie.,
- cel: udostępnienie powszechnie dostępnych kursów, które uczniowie będą chcieli wziąć
- aktorzy: trenerzy, studenci
- wpływ: trenerzy zapewnią wysokiej jakości zajęcia, które są interesujące dla studentów; studenci zapewnią skierowania i rekomendacje
- rezultaty: wysokiej jakości zajęcia, które są dostępne dla studentów
- potencjalne historie:
- „jako trener chcę reklamować zajęcia, aby móc pozyskać studentów.
- ” jako trener chcę otrzymywać informacje zwrotne od uczniów, aby móc stale się doskonalić.,”
- ” jako trener chcę dowiedzieć się, czego chcą uczniowie, więc Mogę dodać do mojego programu nauczania.”
- „jako student chcę znaleźć zajęcia, które najbardziej mnie interesują.”
- „jako student chcę znaleźć zajęcia, które będę mógł uczęszczać online, aby nie musieć podróżować.”
- „jako student chcę czytać recenzje od innych, aby móc zdecydować, które zajęcia będą dla mnie najbardziej odpowiednie.”
odwzorowanie historii użytkownika w ten sposób umożliwia śledzenie procesu myślenia o tym, w jaki sposób historie ostatecznie tworzą wartość i jak ich używasz, aby osiągnąć cel końcowy., Nie chodzi o to, aby zaimplementować wszystko, ale znaleźć najkrótszą drogę przez mapę, aby osiągnąć swój cel.
dzielenie historii
jednym z najczęstszych problemów zwinnych zespołów jest sytuacja, w której historie są zbyt duże i nie można ich ukończyć w iteracji. Kiedy zespół tworzy zadania związane z fabułą, uświadamia sobie, że jest zbyt wiele niewiadomych lub że zadania będą wymagały więcej czasu niż zespół ma do dyspozycji w jednej iteracji. Zespoły czasami rozwiązują ten problem, dzieląc większą historię na mniejsze historie.,
pamiętaj jednak, że chcesz, aby Historia użytkownika dostarczała działające oprogramowanie, które zwiększy wartość dla użytkownika. Zamiast tworzyć historię użytkownika, która tylko częściowo uzupełni funkcję, podziel historie na „pionowe plasterki”, które zapewnią kompleksową funkcjonalność.
zwróć się do społeczności w celu głębszego uczenia się
Szczegółowe rozwiązania, jak rozwiązać najtrudniejsze problemy związane z wymaganiami i historiami użytkowników, są unikalne dla każdej sytuacji. Jednak jedną z cech odnoszących sukcesy praktyków zwinności jest to, że chętnie pomagają innym i dzielą się tym, co wiedzą.,
witryna Cohn userStories umożliwia osobom pracującym z zaległościami produktowymi i historiami użytkowników dzielenie się produktami, zasobami i wiedzą. Strona produktów zawiera imponującą listę narzędzi, z których wiele jest dostępnych za darmo, z możliwością przeglądania opinii użytkowników i wprowadzania danych. Cohn zauważa na stronie, że ma nadzieję rozszerzyć witrynę, aby można było udostępniać zaległości produktowe.
nigdy nie będzie uniwersalnej odpowiedzi na to, jak pisać doskonałe historie użytkowników., Jednak z czasem, dzięki zdrowej mieszance doświadczeń, porad ekspertów i eksperymentów z sugerowanymi narzędziami i technikami, można stale ulepszać.