User stories: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
m (Infobox update)
 
(LinkTitles.)
Linia 16: Linia 16:




'''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). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, 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.
'''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). ''[[Scrum]]. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, 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.
==Konstrukcja==
==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.
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.
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.
Linia 28: Linia 28:


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?''' – informacja na temat użytkownika systemu, jego typu.
# '''Kto?''' – [[informacja]] na temat użytkownika systemu, jego typu.
# '''Co?''' – informacja o zadaniu, jakie dany użytkownik ma wykonać.
# '''Co?''' – informacja o zadaniu, jakie dany [[użytkownik]] ma wykonać.
# '''Dlaczego?''' – informacja o oczekiwanym wyniku wykonanego zadania.
# '''Dlaczego?''' – informacja o oczekiwanym wyniku wykonanego zadania.


Linia 36: Linia 36:
Przykładowa historyjka użytkownika:
Przykładowa historyjka użytkownika:


''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 – 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.
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 sposob realizacji danego zadania ani szczegółów technicznych - np. używanego języka programowania<ref>Chrapko M. ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice 2015, s. 154</ref>.
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 sposob realizacji danego zadania ani szczegółów technicznych - np. używanego języka programowania<ref>Chrapko M. ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice 2015, s. 154</ref>.
==Elementy User story – trzy "K”==
==Elementy User story – trzy "K”==
{{#ev:youtube|ODsSlyYeQUI|480|right|Jak utworzyć backlog? (Sławomir Wawak)|frame}}
{{#ev:youtube|ODsSlyYeQUI|480|right|Jak utworzyć backlog? (Sławomir Wawak)|frame}}
Każda historyjka użytkownika jest złożona z trzech poniższych elementów<ref>Jeffries R. (2011). ''Essential XP: Card, Conversation and Confirmation'', "XP Magazine”, August 30, 2011</ref>:
Każda historyjka użytkownika jest złożona z trzech poniższych elementów<ref>Jeffries R. (2011). ''Essential XP: Card, Conversation and Confirmation'', "XP Magazine”, August 30, 2011</ref>:
# '''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.
# '''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.  
# '''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). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, s. 156</ref>.
# '''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). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, 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).
Linia 62: Linia 62:
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) ''[https://www.academia.edu/26010951/Scrum_Methodology Scrum Methodology]'', "International Journal Of Engineering And Computer Science", nr 5, s. 16797</ref>. Jest on również odpowiedzialny za przygotowanie kryteriów akceptacji dla każdej historyjki<ref>Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, s. 156</ref>.
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) ''[https://www.academia.edu/26010951/Scrum_Methodology Scrum Methodology]'', "International Journal Of Engineering And Computer Science", nr 5, s. 16797</ref>. Jest on również odpowiedzialny za przygotowanie kryteriów akceptacji dla każdej historyjki<ref>Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, 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ę.


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:

Wersja z 06:53, 22 maj 2020

User stories
Polecane artykuły


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.

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:

  1. Kto? – informacja na temat użytkownika systemu, jego typu.
  2. Co? – informacja o zadaniu, jakie dany użytkownik ma wykonać.
  3. Dlaczego? – informacja o oczekiwanym wyniku wykonanego zadania.

W języku angielskim te trzy pytania układają się w tzw. “Trzy W”: Who-What-Why[3].

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 sposob realizacji danego zadania ani szczegółów technicznych - np. używanego języka programowania[4].

Elementy User story – trzy "K”

{{#ev:youtube|ODsSlyYeQUI|480|right|Jak utworzyć backlog? (Sławomir Wawak)|frame}} Każda historyjka użytkownika jest złożona z trzech poniższych elementów[5]:

  1. 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.
  2. 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.
  3. 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[6].

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ć[7]:

  • 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[8]. Jest on również odpowiedzialny za przygotowanie kryteriów akceptacji dla każdej historyjki[9].

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ć[10].

Bibliografia

Przypisy

  1. ↑ Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice, s. 151
  2. ↑ Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice, s. 151
  3. ↑ Pfahl D. (2014). Lecture 11: Agile/Lean Methods, s. 2
  4. ↑ Chrapko M. Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice 2015, s. 154
  5. ↑ Jeffries R. (2011). Essential XP: Card, Conversation and Confirmation, "XP Magazine”, August 30, 2011
  6. ↑ Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice, s. 156
  7. ↑ Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice, s. 158
  8. ↑ Sachdeva S. (2016) Scrum Methodology, "International Journal Of Engineering And Computer Science", nr 5, s. 16797
  9. ↑ Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice, s. 156
  10. ↑ Cohn M. (2009). Succeeding with Agile: Software Development with Scrum, "Addison-Wesley", Reading 2009, s. 239

Autor: Karolina Zasada

Źródło: „https://mfiles.pl/pl/index.php?title=User_stories&oldid=118453”