Scrum - historie użytkowników
Jak zrozumiałeś, historie użytkowników są powszechnie używane do opisywania cech produktu i będą stanowić część artefaktów Scruma - Product Backlog i Sprint Backlog.
Historie użytkownika
W tworzeniu oprogramowania funkcje produktu odgrywają kluczową rolę. To cechy, które użytkownik ostatecznie lubi wykorzystać w produkcie końcowym. W terminologii ogólnej zwane są one wymaganiami. Sukces projektu rozwoju oprogramowania polega na dokładnym i odpowiednim zrozumieniu wymagań użytkownika, a następnie wdrożeniu ich w produkcie końcowym. Dlatego wymagania lub cechy produktu muszą być dokładnie znane zespołowi projektowemu.
W 1999 roku Kent Beck wymyślił termin „Historie użytkowników” określający cechy produktu. Opisał, że narracja użytkownika jest prowadzona z perspektywy użytkownika, a dotyczy tego, co chce mieć, a nie tego, co system może dla niego zrobić. W ten sposób całkowicie zmienił się widok z produktu na użytkownika, a historie użytkowników stały się de facto standardem dla wymagań we wszystkich frameworkach Agile.
W projektach Scrum Backlog Produktu to lista historii użytkowników. Te Historie Użytkowników są uszeregowane pod względem ważności i wprowadzane do Backlogu Sprintu podczas Spotkania Planowania Sprintu.
Szacowanie jest również oparte na historyjkach użytkowników, a rozmiar produktu jest szacowany w punktach historii użytkowników.
Struktura historii użytkownika
Struktura User Story jest następująca -
Jako <Typ użytkownika> ,
Chcę <Wykonać jakąś czynność> ,
Żeby <mogę osiągnąć jakiś cel / korzyść / wartość> .
Przyjrzyjmy się, jak wygląda historia użytkownika w scenariuszu, w którym klient banku pobiera gotówkę z bankomatu.
Historia użytkownika: Wypłata gotówki klienta
Jak Customer,
chcę withdraw cash from an ATM,
Po to aby I don't have to wait in line at the Bank
Kryteria akceptacji historii użytkownika
Każda historyjka użytkownika ma również zdefiniowane Kryterium akceptacji, więc poprawność implementacji historyjki użytkownika jest potwierdzana przez zdanie Testu akceptacji opartego na Kryterium akceptacji.
Poniżej przedstawiono przykładowe kryterium akceptacji na przykładzie Wypłaty gotówki przez klienta według historii użytkownika.
Acceptance Criterion 1:
Given że konto ma zdolność kredytową
- Karta jest ważna
- A dyspenser zawiera gotówkę,
When klient żąda gotówki
Then upewnić się, że konto zostało obciążone
- I upewnij się, że wydano gotówkę
- I upewnij się, że karta została zwrócona.
Acceptance Criterion 2:
Given że konto jest przekroczone
- Karta jest ważna
When klient żąda gotówki
Then upewnij się, że wyświetlany jest komunikat o odrzuceniu
- I upewnij się, że gotówka nie zostanie wydana
- I upewnij się, że karta została zwrócona.
Pisanie historii użytkowników
Właściciel Produktu jest odpowiedzialny za Rejestr Produktu, a tym samym za Historie użytkowników. Nie oznacza to jednak, że tylko właściciel produktu pisze historie użytkowników. Każdy w Zespole Scrumowym może pisać historyjki użytkownika, a aktywność może być rozłożona na cały projekt w miarę dopracowywania wymagań i dodawania nowych funkcji.
Wymagania niefunkcjonalne w historiach użytkowników
Możliwe jest włączenie wymagań niefunkcjonalnych również do historyjek użytkownika. W podanym przykładzie bankomatu, aby bankomat był dostępny dla użytkownika 24X7, 365 dni jest wymaganiem niefunkcjonalnym, który można opisać za pomocą przypadku użycia.
Zarządzanie historiami użytkowników
Historiami użytkowników zarządza się w Backlogu Produktu. Historie użytkowników są uporządkowane według priorytetów. Historie użytkowników o najwyższym priorytecie są doprecyzowywane do szczegółowego poziomu, podczas gdy historie użytkowników o najniższym priorytecie są utrzymywane na niższym poziomie szczegółowości. Podczas każdego sprintu do rejestru sprintu trafiają historie użytkowników o najwyższym priorytecie, a tym samym bardziej szczegółowe. Jeśli historyjka użytkownika ma zostać dodana do rejestru produktu, najpierw określany jest jej priorytet, a następnie umieszczany jest zgodnie z jego miejscem zgodnie z priorytetem. W każdej chwili można zmienić priorytety historyjek użytkowników. W razie potrzeby można również usunąć dowolne historyjki użytkownika.
Korzyści z historii użytkowników
Główną zaletą User Story jest sama definicja skoncentrowana na użytkowniku. Dzieje się tak, ponieważ ostatecznie to użytkownik będzie używał produktu w odpowiednich scenariuszach użytkownika. Łączy użytkowników końcowych z członkami zespołu.
Sama składnia User Story zapewnia uchwycenie celu, korzyści lub wartości, które użytkownik chce osiągnąć.
Ponieważ kryteria akceptacji stanowią część samej historyjki użytkownika, będzie to dodatkowa zaleta dla Zespołu Scrumowego.
W trakcie realizacji projektu można wprowadzać zmiany w historyjce użytkownika. Jeśli zakres historyjek użytkownika staje się duży, należy go podzielić na mniejsze historyjki użytkownika. Warunki w kryterium akceptacji również mogą ulec zmianie.
Gdy przyrosty działającego produktu są dostarczane do użytkowników na koniec każdego sprintu, zespół scrumowy może uzyskać informacje zwrotne od użytkowników podczas spotkania poświęconego przeglądowi sprintu. Umożliwia to ciągłe włączanie informacji zwrotnej do produktu.
Wniosek
Historie użytkowników Scruma przybliżają użytkowników do zespołu Scruma i zapobiegają niespodziankom w ostatniej chwili.