User stories: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
m (Dodanie TL;DR) |
m (cleanup bibliografii i rotten links) |
||
| (Nie pokazano 14 wersji utworzonych przez 2 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''Historyjka użytkownika''' (ang. ''User story'') jest sposobem zapisu wymagań klienta. [[Metoda]] ta została zaproponowana przez Kenta Becka i Martina Fowlera - twórców metodyki [[Metodyka Extreme Programming|Extreme Programming]]<ref>Chrapko M. (2015)., s. 151</ref>, i jest często stosowana do gromadzenia wymagań w metodykach zwinnych np. [[Metodyka SCRUM|Scrum]], [[Kanban]] czy właśnie Extreme Programming. | |||
==TL;DR== | ==TL;DR== | ||
User story jest sposobem zapisu wymagań klienta w metodykach zwinnych. Składa się z trzech elementów: karty, konwersacji i konfirmacji. Każda historyjka powinna być istniejąca samodzielnie, negocjowalna, wartościowa, estymowalna, mała i testowalna. W metodyce Scrum historyjki są przechowywane w backlogu produktu, a podczas planowania sprintu zespół deweloperski wybiera, które z nich zostaną zrealizowane. Historyjki są umową pomiędzy zespołem deweloperskim a Product ownerem. | User story jest sposobem zapisu wymagań klienta w metodykach zwinnych. Składa się z trzech elementów: karty, konwersacji i konfirmacji. Każda historyjka powinna być istniejąca samodzielnie, negocjowalna, wartościowa, estymowalna, mała i testowalna. W metodyce Scrum historyjki są przechowywane w backlogu produktu, a podczas planowania sprintu zespół deweloperski wybiera, które z nich zostaną zrealizowane. Historyjki są umową pomiędzy zespołem deweloperskim a Product ownerem. | ||
| Linia 23: | Linia 7: | ||
User story to krótki opis wybranej funkcjonalności, napisany z punktu widzenia docelowego użytkownika danego produktu. Opis taki, zwykle jednozdaniowy, zawiera jedynie [[informacje]] najważniejsze z punktu widzenia przyszłego użytkownika - jest on zasygnalizowaniem problemu oraz punktem wyjścia do dyskusji o sposobach jego rozwiązania. | User story to krótki opis wybranej funkcjonalności, napisany z punktu widzenia docelowego użytkownika danego produktu. Opis taki, zwykle jednozdaniowy, zawiera jedynie [[informacje]] najważniejsze z punktu widzenia przyszłego użytkownika - jest on zasygnalizowaniem problemu oraz punktem wyjścia do dyskusji o sposobach jego rozwiązania. | ||
Tradycyjnie, historyjki użytkownika zapisywane są na niewielkich kartkach papieru lub kartonikach | Tradycyjnie, historyjki użytkownika zapisywane są na niewielkich kartkach papieru lub kartonikach - dzięki temu możliwe jest ich fizyczne umieszczenie na Scrum board lub Kanban Board. Rozmiar kartek ma również wpływ na to, że historyjki użytkownika zapisane na nich powinny być możliwie krótkie i zwięzłe. | ||
Jeden z najprostszych, a także najpopularniejszy szablon zapisu historyjki użytkownika wygląda następująco<ref>Chrapko M. (2015). | Jeden z najprostszych, a także najpopularniejszy szablon zapisu historyjki użytkownika wygląda następująco<ref>Chrapko M. (2015). , s. 151</ref>: | ||
''Jako''<'''Kto?'''>''chcę wykonać''<'''Co?'''>''aby''<'''Dlaczego?'''>. | ''Jako''<'''Kto?'''>''chcę wykonać''<'''Co?'''>''aby''<'''Dlaczego?'''>. | ||
Kluczowe w tworzeniu historyjki jest odpowiedź na trzy pytania widoczne we wzorze: | Kluczowe w tworzeniu historyjki jest odpowiedź na trzy pytania widoczne we wzorze: | ||
# '''Kto?''' | # '''Kto?''' - [[informacja]] na temat użytkownika systemu, jego typu. | ||
# '''Co?''' | # '''Co?''' - informacja o zadaniu, jakie dany [[użytkownik]] ma wykonać. | ||
# '''Dlaczego?''' | # '''Dlaczego?''' - informacja o oczekiwanym wyniku wykonanego zadania. | ||
W języku angielskim te trzy pytania układają się w tzw. “Trzy | W języku angielskim te trzy pytania układają się w tzw. “Trzy W": Who-What-Why. | ||
Przykładowa historyjka użytkownika: | Przykładowa historyjka użytkownika: | ||
| Linia 41: | Linia 24: | ||
''Jako'' '''[[klient]] sklepu''' ''chcę'' '''dodać [[produkt]] do koszyka''' ''aby'' '''go później kupić'''. | ''Jako'' '''[[klient]] sklepu''' ''chcę'' '''dodać [[produkt]] do koszyka''' ''aby'' '''go później kupić'''. | ||
Powyższy szablon może być oczywiście podstawą do modyfikacji | Powyższy szablon może być oczywiście podstawą do modyfikacji - jeżeli realizowany [[projekt]] tego wymaga, może on zostać rozbudowany o dodatkowe informacje lub okrojony, jeśli dana informacja nie jest akurat w danym projekcie potrzebna. | ||
Podczas tworzenia historyjek użytkownika należy pamiętać, aby opisywały tylko takie funkcjonalności, które mają rzeczywistą [[wartość]] dla użytkownika | Podczas tworzenia historyjek użytkownika należy pamiętać, aby opisywały tylko takie funkcjonalności, które mają rzeczywistą [[wartość]] dla użytkownika - nie uwzględniamy w nich informacji takich jak sposób realizacji danego zadania ani szczegółów technicznych - np. używanego języka programowania<ref>Chrapko M. (2015), s. 154</ref>. | ||
==Elementy User story | |||
<google>n</google> | |||
Każda historyjka użytkownika jest złożona z trzech poniższych elementów<ref>Jeffries R. (2011). | |||
# '''Karta''' | ==Elementy User story - trzy "K"== | ||
# '''Konwersacja''' | Każda historyjka użytkownika jest złożona z trzech poniższych elementów<ref>Jeffries R. (2011)., 2011</ref>: | ||
# '''Konfirmacja''' | # '''Karta''' - historyjka zapisana jest na niewielkiej kartce papieru. Kratka sama w sobie nie jest wymaganiem (ma za mało miejsca, aby umieścić na niej wszystkie niezbędne informacje), ale jest fizyczną reprezentacją wymagania, ułatwiającą pracę z wymaganiami, np. [[planowanie]] pracy. | ||
# '''Konwersacja''' - historyjka użytkownika jest podstawą do rozmowy pomiędzy wszystkimi członkami zespołu projektowego, mającej na celu ustalenie wszystkich szczegółów koniecznych do prawidłowego zaimplementowania historyjki w produkcie. | |||
# '''Konfirmacja''' - [[implementacja]] historyjki powinna zostać potwierdzona poprzez odpowiednie testy akceptacyjne. Testy akceptacyjne zwykle są opisywane po drugiej stronie karteczek z historyjkami. Uznaje się, że jedna historyjka nie powinna mieć więcej niż dziesięć kryteriów akceptacji<ref>Chrapko M. (2015)., s. 156</ref>. | |||
Powyższy podział jest w języku angielskim nazywany "The three C`s" (trzy "C") - od angielskich słów "Card" (karta), "Conversation" (konwersacja) i "Confirmation" (konfirmacja). | Powyższy podział jest w języku angielskim nazywany "The three C`s" (trzy "C") - od angielskich słów "Card" (karta), "Conversation" (konwersacja) i "Confirmation" (konfirmacja). | ||
==Atrybuty User story== | ==Atrybuty User story== | ||
Zgodnie z techniką [[INVEST]], każda historyjka użytkownika powinna być<ref>Chrapko M. (2015). | Zgodnie z techniką [[INVEST]], każda historyjka użytkownika powinna być<ref>Chrapko M. (2015). , s. 158</ref>: | ||
* Istniejąca samodzielnie (ang. Independent). | * Istniejąca samodzielnie (ang. Independent). | ||
* Negocjowalna (ang. Negotiable). | * Negocjowalna (ang. Negotiable). | ||
| Linia 63: | Linia 48: | ||
==User stories w Scrum== | ==User stories w Scrum== | ||
W [[Metodyka SCRUM|metodyce Scrum]] format historyjki użytkownika jest zwykle stosowany do przechowywania wymagań klienta w [[backlog produktu]]. Osobą odpowiedzialną za tworzenie historyjek użytkownika jest [[Product owner]]<ref>Sachdeva S. (2016) | W [[Metodyka SCRUM|metodyce Scrum]] format historyjki użytkownika jest zwykle stosowany do przechowywania wymagań klienta w [[backlog produktu]]. Osobą odpowiedzialną za tworzenie historyjek użytkownika jest [[Product owner]]<ref>Sachdeva S. (2016), s. 16797</ref>. Jest on również odpowiedzialny za przygotowanie kryteriów akceptacji dla każdej historyjki<ref>Chrapko M. (2015)., s. 156</ref>. | ||
Podczas planowania sprintu [[zespół]] deweloperski wybiera, które historyjki zostaną zrealizowane w najbliższym Sprincie, a następnie dokonuje dekompozycji historyjek na zadania możliwe do wykonania przez jedną osobę. | Podczas planowania sprintu [[zespół]] deweloperski wybiera, które historyjki zostaną zrealizowane w najbliższym Sprincie, a następnie dokonuje dekompozycji historyjek na zadania możliwe do wykonania przez jedną osobę. | ||
| Linia 69: | Linia 54: | ||
Historyjka użytkownika w scrum jest pewnego rodzaju umową pomiędzy [[zespół deweloperski|zespołem deweloperskim]] a Product ownerem: | Historyjka użytkownika w scrum jest pewnego rodzaju umową pomiędzy [[zespół deweloperski|zespołem deweloperskim]] a Product ownerem: | ||
* zespół deklaruje, że pracę nad daną funkcjonalnością rozpocznie dopiero po jej dokładnym omówieniu, | * zespół deklaruje, że pracę nad daną funkcjonalnością rozpocznie dopiero po jej dokładnym omówieniu, | ||
* Product owner natomiast deklaruje, że będzie dostępny zawsze, gdy zespół będzie chciał z nim rozmawiać<ref> Cohn M. (2009). | * Product owner natomiast deklaruje, że będzie dostępny zawsze, gdy zespół będzie chciał z nim rozmawiać<ref> Cohn M. (2009)., s. 239</ref>. | ||
== | |||
{{infobox5|list1={{i5link|a=[[Backlog sprintu]]}} — {{i5link|a=[[Backlog produktu]]}} — {{i5link|a=[[Feature-Driven Development]]}} — {{i5link|a=[[Scrum of scrums]]}} — {{i5link|a=[[Getting Things Done]]}} — {{i5link|a=[[Technika MoSCoW]]}} — {{i5link|a=[[Webmaster]]}} — {{i5link|a=[[Testowanie w projekcie]]}} — {{i5link|a=[[Ganttproject]]}} }} | |||
==Przypisy== | ==Przypisy== | ||
<references /> | <references /> | ||
==Bibliografia== | |||
<noautolinks> | |||
* Chrapko M. (2015), ''Scrum: o zwinnym zarządzaniu projektami'', Wydawnictwo Helion, Gliwice | |||
* Leffingwell D., Behrens P. (2009), ''A User Story Primer'' | |||
* Sachdeva S. (2016), ''Scrum Methodology'', International Journal Of Engineering And Computer Science, nr 5 | |||
</noautolinks> | |||
{{a|Karolina Zasada}} | {{a|Karolina Zasada}} | ||
[[Kategoria:Techniki zwinne]] | |||
{{#metamaster:description|Zapoznaj się z user stories - sposobem zapisu wymagań klienta stosowanym w metodykach zwinnych, takich jak Scrum czy Kanban. Dowiedz się więcej.}} | |||
Aktualna wersja na dzień 19:31, 17 gru 2023
Historyjka użytkownika (ang. User story) jest sposobem zapisu wymagań klienta. Metoda ta została zaproponowana przez Kenta Becka i Martina Fowlera - twórców metodyki Extreme Programming[1], i jest często stosowana do gromadzenia wymagań w metodykach zwinnych np. Scrum, Kanban czy właśnie Extreme Programming.
TL;DR
User story jest sposobem zapisu wymagań klienta w metodykach zwinnych. Składa się z trzech elementów: karty, konwersacji i konfirmacji. Każda historyjka powinna być istniejąca samodzielnie, negocjowalna, wartościowa, estymowalna, mała i testowalna. W metodyce Scrum historyjki są przechowywane w backlogu produktu, a podczas planowania sprintu zespół deweloperski wybiera, które z nich zostaną zrealizowane. Historyjki są umową pomiędzy zespołem deweloperskim a Product ownerem.
Konstrukcja
User story to krótki opis wybranej funkcjonalności, napisany z punktu widzenia docelowego użytkownika danego produktu. Opis taki, zwykle jednozdaniowy, zawiera jedynie informacje najważniejsze z punktu widzenia przyszłego użytkownika - jest on zasygnalizowaniem problemu oraz punktem wyjścia do dyskusji o sposobach jego rozwiązania.
Tradycyjnie, historyjki użytkownika zapisywane są na niewielkich kartkach papieru lub kartonikach - dzięki temu możliwe jest ich fizyczne umieszczenie na Scrum board lub Kanban Board. Rozmiar kartek ma również wpływ na to, że historyjki użytkownika zapisane na nich powinny być możliwie krótkie i zwięzłe.
Jeden z najprostszych, a także najpopularniejszy szablon zapisu historyjki użytkownika wygląda następująco[2]:
Jako<Kto?>chcę wykonać<Co?>aby<Dlaczego?>.
Kluczowe w tworzeniu historyjki jest odpowiedź na trzy pytania widoczne we wzorze:
- Kto? - informacja na temat użytkownika systemu, jego typu.
- Co? - informacja o zadaniu, jakie dany użytkownik ma wykonać.
- Dlaczego? - informacja o oczekiwanym wyniku wykonanego zadania.
W języku angielskim te trzy pytania układają się w tzw. “Trzy W": Who-What-Why.
Przykładowa historyjka użytkownika:
Jako klient sklepu chcę dodać produkt do koszyka aby go później kupić.
Powyższy szablon może być oczywiście podstawą do modyfikacji - jeżeli realizowany projekt tego wymaga, może on zostać rozbudowany o dodatkowe informacje lub okrojony, jeśli dana informacja nie jest akurat w danym projekcie potrzebna.
Podczas tworzenia historyjek użytkownika należy pamiętać, aby opisywały tylko takie funkcjonalności, które mają rzeczywistą wartość dla użytkownika - nie uwzględniamy w nich informacji takich jak sposób realizacji danego zadania ani szczegółów technicznych - np. używanego języka programowania[3].
Elementy User story - trzy "K"
Każda historyjka użytkownika jest złożona z trzech poniższych elementów[4]:
- Karta - historyjka zapisana jest na niewielkiej kartce papieru. Kratka sama w sobie nie jest wymaganiem (ma za mało miejsca, aby umieścić na niej wszystkie niezbędne informacje), ale jest fizyczną reprezentacją wymagania, ułatwiającą pracę z wymaganiami, np. planowanie pracy.
- Konwersacja - historyjka użytkownika jest podstawą do rozmowy pomiędzy wszystkimi członkami zespołu projektowego, mającej na celu ustalenie wszystkich szczegółów koniecznych do prawidłowego zaimplementowania historyjki w produkcie.
- Konfirmacja - implementacja historyjki powinna zostać potwierdzona poprzez odpowiednie testy akceptacyjne. Testy akceptacyjne zwykle są opisywane po drugiej stronie karteczek z historyjkami. Uznaje się, że jedna historyjka nie powinna mieć więcej niż dziesięć kryteriów akceptacji[5].
Powyższy podział jest w języku angielskim nazywany "The three C`s" (trzy "C") - od angielskich słów "Card" (karta), "Conversation" (konwersacja) i "Confirmation" (konfirmacja).
Atrybuty User story
Zgodnie z techniką INVEST, każda historyjka użytkownika powinna być[6]:
- Istniejąca samodzielnie (ang. Independent).
- Negocjowalna (ang. Negotiable).
- Wartościowa (ang. Valuable).
- Estymowalna (ang. Estimable)
- Mała (ang. Small).
- Testowalna (ang. Testable).
User stories w Scrum
W metodyce Scrum format historyjki użytkownika jest zwykle stosowany do przechowywania wymagań klienta w backlog produktu. Osobą odpowiedzialną za tworzenie historyjek użytkownika jest Product owner[7]. Jest on również odpowiedzialny za przygotowanie kryteriów akceptacji dla każdej historyjki[8].
Podczas planowania sprintu zespół deweloperski wybiera, które historyjki zostaną zrealizowane w najbliższym Sprincie, a następnie dokonuje dekompozycji historyjek na zadania możliwe do wykonania przez jedną osobę.
Historyjka użytkownika w scrum jest pewnego rodzaju umową pomiędzy zespołem deweloperskim a Product ownerem:
- zespół deklaruje, że pracę nad daną funkcjonalnością rozpocznie dopiero po jej dokładnym omówieniu,
- Product owner natomiast deklaruje, że będzie dostępny zawsze, gdy zespół będzie chciał z nim rozmawiać[9].
| User stories — artykuły polecane |
| Backlog sprintu — Backlog produktu — Feature-Driven Development — Scrum of scrums — Getting Things Done — Technika MoSCoW — Webmaster — Testowanie w projekcie — Ganttproject |
Przypisy
Bibliografia
- Chrapko M. (2015), Scrum: o zwinnym zarządzaniu projektami, Wydawnictwo Helion, Gliwice
- Leffingwell D., Behrens P. (2009), A User Story Primer
- Sachdeva S. (2016), Scrum Methodology, International Journal Of Engineering And Computer Science, nr 5
Autor: Karolina Zasada
