W metodykach zwinnych User Stories tworzone są w celu zapisania pomysłów dotyczących rozwoju aplikacji, tego, jak mają działać nowe funkcjonalności. Z założenia User Stories ma pomóc lepiej skomunikować dział techniczny z biznesem.
Jak powinno być napisane User Stories?
Za pomocą User Stories opisujemy wymagania, zwykle z punktu widzenia użytkownika końcowego. User Stories są pisane w sposób prosty i zwięzły, nie stosując zawiłego technicznego słownictwa tak, aby były zrozumiała dla każdego.
Przykład:
Schemat budowania User Story: jako „użytkownik” chcę „potrzeba” aby „cel do osiągnięcia”.
Jako „właściciel domu” chcę „otworzyć drzwi” aby „do niego wejść”.
Każda historyjka powinna mieć jasno zdefiniowane reguły, które określają jej zakończenie. Takie kryteria określane są jako Definition of Done i muszą zostać spełnione, aby zadanie można było zaprezentować podczas Sprint Review, a następnie zamknąć jako ukończone – jeżeli kryteria zostały spełnione.
User Stories są zazwyczaj tworzone przez Product Ownera, ale czasami na potrzebę zespołu zakłada je również Scrum Master.
Po utworzeniu User Stories zapisywane są w Product Backlogu. Product Backlog to lista zadań i pomysłów, jakie przewidywane są do realizacji w aplikacji. User Stories wybrane do realizacji na najbliższy Sprint są doprecyzowane, a następnie są przypisywane do Sprint Backlogu. Sprint Backlog to lista planowanych zadań do wykonania w najbliższym Sprincie.
User Stories tworzone są w aplikacji, której zespół używa do zarządzania projektem. Poniżej możesz zobaczyć przykładową User Story utworzoną w Jira.
Kiedy możemy tworzyć User Story?
W zasadzie każdy moment jest dobry! Ważne jest zdanie sobie sprawy, że taka historyjka trafia do Product Backlogu, czyli nie jest realizowana od ręki. Na podstawie określonego priorytetu, czyli jak ważne dla nas jest dane zadanie, trafia ono do realizacji w ramach Sprint Backlogu.
Testowanie User Stories
Jednym z problemów User Story jest jego elastyczność. Jako tester/programista jesteś przyzwyczajony do konkretów, natomiast sam Scrum, jak i jego elementy są mocno elastyczne. Założeniem User Story było przyspieszenie i uproszczenie komunikacji Biznesu z zespołem wytwarzającym oprogramowanie. Dlatego też często historyjki są doprecyzowane na bieżąco. Dzięki temu nie blokują prac developerskich. Wadą ich z punktu widzenia testera może być to, że w User Stories znajdziemy informację, co użytkownik chce, natomiast nie będzie konkretnej informacji, np. o tym jakie dane ma pole przyjmować.
Z tym user story to różnie jest. Sam przekonałem się, że ISTQB nie zawsze jest wszędzie stosowane, choć wiedza jest b przydatna z książki, bo właśnie przerabiam. U mnie w firmie user stories to głównie zmiany w requirements, czyli w dokumencie mapującym, który używam do pisania testów dla migracji danych (a głównie post-migration w środowisku testującym) – solution designer używa tego pojęcia jako w sumie template dla podkreślenia zmian w dokumencie np. 24565 userstories. Ogólnie dokument mapujący zawiera wszystkie naniesione zmiany, czyli właśnie user stories i każde user stories ma swój osobny kolor – dodatkowo wtedy robi się highlight tekstu w dokumencie mapującym na kolor, który został przypisany do user stories np 24565 kolor ciemnozielony. Test suit ma swoje ID i to ID odpowiada właśnie ID user stories, dzięki temu zachowane jest „linkowanie”. By the way fajny art. Dzięki!
Hej, cieszę się, że artykuł się spodobał 🙂
co do teorii i jak coś nazywamy/stosujemy to nie ma co się przejmować – generalnie branża jest jaka jest no i trzeba z tym żyć. Od jakiegoś czasu się śmieję, że jakby ktoś wszedł na „scenę” i powiedział coś totalnie głupiego, to reszcie publicznośći nie pozostałoby nic innego jak przytaknąć i współczuć 😀
Dzięki za podzielenie się historią jak to u Ciebie funkcjonuje, bo to pokazuje różnorodność tej branży 🙂
Pod obrazkiem na górze w podpisie w środku jest USer zamiast User. Zaczyna mi się podobać to testowanie 🙂
Spostrzegawcze oko! Super dziękuję bardzo za zwrócenie uwagi 🙂