Rozwój agilny to metoda skupiająca się na iteracyjnym i stopniowym rozwoju produktów oprogramowania. Podkreśla współpracę między zespołami wieloosobowymi, ciągłe feedback i elastyczność wobec zmiany wymagań w trakcie całego procesu rozwoju. Dwie popularne techniki stosowane w rozwoju agilnym to historie użytkownika i przypadki użytkownika. W tym kompletnym przewodniku omówimy obie techniki i argumentujemy, że obie są odpowiednie do rozwoju agilnego, jeśli są stosowane odpowiednio.
Historie użytkownika
Historie użytkownika to krótkie, proste opisy funkcji przedstawione z perspektywy użytkownika końcowego.
Zazwyczaj podlegają określonym wzorcom:
„Jako [rodzaj użytkownika], chcę [jakieś cel] aby [jakąś przyczynę].”
Historie użytkownika to potężny narzędzie w rozwoju agilnym, ponieważ pomagają zespołom skupić się na potrzebach użytkownika końcowego i wspierają komunikację oraz współpracę między stakeholderami.
Przykład: Załóżmy, że nasz zespół tworzy nową platformę e-commerce.
Historia użytkownika może wyglądać następująco:
„Jako kupujący, chcę możliwość filtrowania wyników wyszukiwania według zakresu cenowego aby móc znaleźć produkty w moim budżecie.”
Dlaczego jest to dobre rozwiązanie dla rozwoju agilnego?
Historie użytkownika to doskonały wybór dla rozwoju agilnego, ponieważ są lekkie, łatwe do zapisania i zapewniają wspólną wiedzę o tym, co należy stworzyć. Są również elastyczne i mogą być łatwo modyfikowane w trakcie całego procesu rozwoju. To czyni je idealnym rozwiązaniem dla zespołów agilnych, które cenią współpracę, ciągłe feedback i elastyczność.
Przypadki użytkownika
Przypadki użytkownika to szczegółowe opisy zachowania systemu z perspektywy aktora (zazwyczaj użytkownika lub innego systemu). Zazwyczaj składają się z serii kroków, które użytkownik wykonuje, aby osiągnąć określony cel, oraz opisują interakcje między użytkownikiem a systemem. Przypadki użytkownika to istotne narzędzie w rozwoju agilnym, ponieważ pomagają zespołom zrozumieć zachowanie systemu i wczesnie wykrywać potencjalne problemy w trakcie procesu rozwoju.
Przykład: Kontynuujmy przykład naszej platformy e-commerce.
Przypadek użytkownika może wyglądać następująco:
„Kupujący wyszukuje produkt na platformie. Stosuje filtr cenowy i sortuje wyniki według ocen klientów. Dodaje produkt do koszyka i przechodzi do kasy. Po sprawdzeniu szczegółów zamówienia przesyła dane płatności i kończy zakup.”
Dlaczego jest to dobre rozwiązanie dla rozwoju agilnego?
Kasusy użytkownika są również doskonałym wyborem dla rozwoju agilnego, ponieważ zapewniają szczegółowe zrozumienie, jak system powinien się zachowywać. Pomagają zespołom w wykrywaniu potencjalnych problemów na wczesnym etapie procesu rozwoju oraz zapewnieniu, że system spełnia potrzeby użytkownika końcowego. Są również przydatne w testowaniu i weryfikacji, co jest istotnym aspektem rozwoju agilnego.
Porównanie historii użytkownika i przypadków użytkownika
Choć zarówno historie użytkownika, jak i przypadki użytkownika są odpowiednie dla rozwoju agilnego, różnią się na kilka sposobów. Historie użytkownika są lekkie i skupiają się na potrzebach użytkownika końcowego, podczas gdy przypadki użytkownika są bardziej szczegółowe i opisują zachowanie systemu. Historie użytkownika są zazwyczaj używane do zapisania wymagań najwyższego poziomu, podczas gdy przypadki użytkownika służą do opisania konkretnych interakcji między użytkownikiem a systemem.
Na końcu wybór między historiami użytkownika a przypadkami użytkownika zależy od konkretnych potrzeb projektu. Historie użytkownika są bardziej odpowiednie dla projektów, w których wymagania są niejasne lub podatne na zmiany, podczas gdy przypadki użytkownika są bardziej odpowiednie dla projektów, w których wymagania są dokładnie zdefiniowane i szczegółowe. W praktyce wiele zespołów używa obu technik, aby upewnić się, że mają kompletną wiedzę o zachowaniu systemu i potrzebach użytkownika końcowego.
Przykład – sklep internetowy z produktami spożywczymi
Przykład historii użytkownika: „Jako zajęta mama, chcę móc tworzyć listę zakupów w aplikacji, aby łatwo śledzić produkty, które muszę kupić. Chcę również móc dodawać i usuwać produkty z listy oraz oznaczać produkty jako kupione, gdy skończę zakupy.”
W tej historii użytkownika opisaliśmy konkretną funkcję, która spełnia potrzeby użytkownika końcowego (zajętych matek) i przynosi im korzyść (łatwe śledzenie listy zakupów). Historia użytkownika została napisana z perspektywy użytkownika końcowego i wykorzystuje określony szablon, aby zapewnić jasność i spójność.
Przykład przypadku użytkownika: użytkownik chce utworzyć nową listę zakupów w aplikacji. Otwiera aplikację i przechodzi do funkcji listy zakupów. Klikają przycisk „Utwórz nową listę” i wpisuje nazwę listy. Następnie zaczyna dodawać elementy do listy, klikając przycisk „Dodaj element” i wpisując nazwę produktu. Może również określić ilość lub dodać dodatkowe uwagi. Gdy użytkownik doda wszystkie potrzebne elementy, może zapisać listę i później do niej powrócić. Może również oznaczać elementy jako kupione, gdy zostały zakupione.
W tym przypadku użytkownika opisaliśmy konkretny scenariusz, w którym użytkownik interakcjonuje z funkcją listy zakupów aplikacji. Opisaliśmy kroki, które użytkownik wykonuje, aby osiągnąć swój cel, oraz interakcje między użytkownikiem a systemem. Przypadek użytkownika jest bardziej szczegółowy niż historia użytkownika i zapewnia kompletną wiedzę o tym, jak funkcja powinna się zachowywać.
Oba podejścia – historia użytkownika i przypadek użytkownika – są przydatne w rozwoju agilnym. Historia użytkownika zapewnia przegląd najwyższego poziomu funkcji i skupia się na potrzebach użytkownika końcowego, podczas gdy przypadek użytkownika oferuje bardziej szczegółowe opisanie zachowania funkcji. Użycie obu podejść gwarantuje, że zespół rozwojowy ma kompletną wiedzę o funkcji i potrzebach użytkownika końcowego, co jest kluczowe dla sukcesu rozwoju agilnego.
Szczegółowe opisanie historii użytkownika za pomocą 3C
oto możliwy podział 3C na przykład historii użytkownika:
- Karta: „Jako zajęta mama, chcę móc tworzyć listę zakupów w aplikacji, aby łatwo śledzić produkty, które muszę kupić. Chcę również móc dodawać i usuwać produkty z listy oraz oznaczać produkty jako kupione, gdy skończę zakupy.”
- Rozmowa:
- Właściciel produktu: „Czy możesz powiedzieć mi więcej o tym, dlaczego musisz śledzić swoją listę zakupów?”
- Zajęta mama: „Oczywiście, jako mama z zajętym harmonogramem, muszę się upewnić, że niczego nie zapomnę, gdy idę do sklepu. Byłoby naprawdę pomocne, gdybym mógł łatwo tworzyć listę zakupów na moim telefonie i dodawać lub usuwać elementy, gdyby to było potrzebne.”
- Właściciel produktu: „Rozumiem. Jak ważne jest dla Ciebie oznaczanie produktów jako kupione?”
- Zajęta mama: „To ważne, bo wtedy mogę szybko zobaczyć, co już kupiłam, a co jeszcze muszę dostać.”
- Potwierdzenie: „Jako zajęta mama, mogę tworzyć listę zakupów w aplikacji, dodawać i usuwać elementy z listy oraz oznaczać produkty jako kupione, gdy skończę zakupy.”
Szczegółowe opisanie przypadku użytkownika za pomocą opisu przypadku
o to przykład opisu przypadku użytkownika oparty na opisie problemu i historii użytkownika:
Nazwa przypadku użytkownika: Utwórz i zarządzaj listą zakupów
Uczestnicy:
- Użytkownik: osoba, która chce utworzyć i zarządzać listą zakupów w aplikacji.
Wstępne warunki:
- Użytkownik pobrał i zainstalował aplikację na swoim urządzeniu mobilnym.
- Użytkownik ma stabilne połączenie internetowe.
Warunki końcowe:
- Użytkownik pomyślnie utworzył i zarządza listą zakupów w aplikacji.
Przebieg zdarzeń:
- Użytkownik otwiera aplikację i przechodzi do funkcji listy zakupów.
- Aplikacja wyświetla listę istniejących list zakupów lub prosi użytkownika o utworzenie nowej listy.
- Użytkownik klikuje przycisk „Utwórz nową listę”.
- Aplikacja prosi użytkownika o wpisanie nazwy nowej listy.
- Użytkownik wpisuje nazwę nowej listy i klikает „Zapisz”.
- Aplikacja wyświetla pustą listę zakupów z nazwą podaną przez użytkownika.
- Użytkownik klikuje przycisk „Dodaj przedmiot”.
- Aplikacja prosi użytkownika o wpisanie nazwy przedmiotu, który chce dodać do listy.
- Użytkownik wpisuje nazwę przedmiotu i klikает „Dodaj”.
- Aplikacja wyświetla nowy przedmiot na liście zakupów.
- Użytkownik powtarza kroki 7–10, aż dodadzie wszystkie potrzebne przedmioty do listy.
- Użytkownik może usunąć przedmiot z listy, klikając przycisk „Usuń przedmiot” obok przedmiotu.
- Użytkownik może oznaczyć przedmiot jako kupiony, klikając przycisk „Oznacz jako kupiony” obok przedmiotu.
- Aplikacja aktualizuje listę zakupów, aby odzwierciedlić wszelkie zmiany dokonane przez użytkownika.
- Użytkownik może w każdej chwili wyświetlić listę zakupów, powracając do funkcji listy zakupów w aplikacji.
Alternatywne przebiegi:
- Jeśli użytkownik anuluje tworzenie nowej listy w kroku 5, aplikacja powraca do listy istniejących list zakupów lub prosi użytkownika o ponowne utworzenie nowej listy.
- Jeśli użytkownik anuluje dodawanie nowego przedmiotu w kroku 9, aplikacja powraca do listy zakupów bez dodawania przedmiotu.
Różnice między historiami użytkownika a przypadkami użycia
Tabela zawiera podsumowanie różnic między historiami użytkownika a przypadkami użycia. Historie użytkownika to krótkie, proste opisy skupione na celach i potrzebach użytkownika, podczas gdy przypadki użycia zawierają szczegółowe, krok po kroku opisy zachowania systemu i jego funkcjonalności.
| Historie użytkownika | Przypadki użycia |
|---|---|
| Krótkie, proste opisy funkcji z perspektywy użytkownika. | Szczegółowe, krok po kroku opisy sposobu, w jaki użytkownik oddziałuje na system. |
| Skupione na celach i potrzebach użytkownika. | Skupia się na zachowaniu systemu i jego funkcjonalności. |
| Podkreślają rozmowę i współpracę między stakeholderami. | Podkreślaj bardziej zformalizowany, strukturalny podejście. |
| Często pisane w bardziej nieformalnym, rozmownym stylu. | Często pisane w bardziej zformalizowanym, technicznym stylu. |
| Zwykle używane do zapisywania wymagań i cech najwyższego poziomu. | Zwykle używane do zapisywania szczegółowych wymagań funkcyjnych. |
| Zwykle łatwiejsze i szybsze do napisania i przejrzenia. | Zwykle bardziej czasochłonne do napisania i przejrzenia. |
Podsumowanie
Artykuł bada zastosowanie historii użytkownika i przypadków użycia w rozwoju agilnym, argumentując, że oba podejścia są odpowiednie, gdy są stosowane odpowiednio. Historie użytkownika to krótkie, proste opisy funkcji z perspektywy użytkownika, podczas gdy przypadki użycia zapewniają szczegółowy, krok po kroku opis interakcji użytkownika z systemem.
Do ilustracji sposobu stosowania obu podejść wykorzystano przykład problemu tworzenia i zarządzania listą zakupów. Artykuł podkreśla znaczenie zasad 3Cs (Karta, Rozmowa, Potwierdzenie) przy tworzeniu skutecznych historii użytkownika oraz znaczenie aktorów, warunków wstępnych i warunków końcowych przy tworzeniu skutecznych przypadków użycia. Ogólnie rzecz biorąc, artykuł stanowi kompleksowy przewodnik dla programistów o tym, jak skutecznie stosować historie użytkownika i przypadki użycia w rozwoju agilnym.
Wniosek: historie użytkownika i przypadki użycia są oba cennymi narzędziami w rozwoju agilnym, gdy są stosowane odpowiednio. Historie użytkownika są lekkie, łatwe do napisania i elastyczne, co czyni je idealnymi dla projektów z ewoluującymi wymaganiami. Przypadki użycia są szczegółowe i zapewniają kompletną wiedzę o zachowaniu systemu, co czyni je idealnymi dla projektów z dobrze zdefiniowanymi wymaganiami. Stosując oba podejścia, zespoły agilne mogą zapewnić sobie kompletną wiedzę o zachowaniu systemu i jego celach.