O User Story opowiada product owner - Tomasz Muszczek - Pilska Szkoła Programowania

by Dariusz Kacban
10 miesięcy ago
824 Views

Historyjki użytkownika są wspaniałe. Oto dlaczego.

Historyjki użytkownika (czy też, jak są często określane po angielsku „user stories”) na przestrzeni lat stały się standardem, według którego formułuje się zadania dla programistów do wykonania, zwłaszcza w przypadku nowych funkcjonalności. I rzeczywiście – historyjki użytkownika to sposób, by w jasny i zwięzły sposób określić co należy wykonać, jaką to przyniesie wartość oraz komu. Przyjrzyjmy się jednemu z najpopularniejszych szablonów historyjki użytkownika na poniższym przykładzie:

Jako administrator forum,
Chcę mieć możliwość przenoszenia tematów oraz postów do odpowiednich kategorii tematycznych,
Aby na forum panował porządek i organizacja.

Czytając historyjkę użytkownika nie mamy wątpliwości dla kogo („Jako administrator forum”) budujemy jaką funkcjonalność („Chcę mieć możliwość przenoszenia tematów oraz postów…”), by osiągnąć jaki cel tudzież w jaki sposób zwiększyć wartość produktu („Aby na forum panował porządek i organizacja”). Dodatkową zaletą user stories jest niewątpliwie to, że są one zrozumiałe dla każdego, kto je czyta: zrozumie je programista, tester, właściciel produktu, czy klient, który na wytwarzaniu oprogramowania wcale nie musi się znać.

Osobiście jednak preferuję nieco inny szablon historyjki użytkownika – mówiąc kolokwialnie, lubię je „odwracać do góry nogami”.

Aby na forum panował porządek i organizacja,
Jako administrator forum,
Chcę mieć możliwość przenoszenia tematów oraz postów do odpowiednich kategorii tematycznych.

Ktoś może powiedzieć, że to tylko zabieg kosmetyczny. Kto inny może powiedzieć, że taki układ jest niewłaściwy, ponieważ nie stawia użytkownika na pierwszym miejscu. Ośmielę się jednak stwierdzić, że w całym procesie wytwarzania oprogramowania nie tyle chodzi o użytkownika, a o wartość jaką produkt użytkownikowi oferuje. To może i jest bardzo subtelna różnica, jednak też bardzo istotna.

Czytając drugi wariant szablonu user stories od razu wiadomo, co chcemy osiągnąć lub jaką wartość chcemy dodać do całokształtu produktu („Aby na forum panował porządek i organizacja”), czyli od razu na wstępie określamy powód, dla którego w ogóle chcemy stworzyć jakąś funkcjonalność. Jeśli natomiast nie jesteśmy w stanie podać takiego powodu, lub musimy nad nim myśleć bardzo długo… to cóż, najwyraźniej ta konkretna funkcjonalność nie jest w naszym produkcie potrzebna (a przynajmniej na tym etapie rozwoju), ponieważ nie przyniesie ona wartości naszym użytkownikom. A bez wartości, funkcjonalność nie ma prawa bytu.

I dlatego właśnie, historyjki użytkownika są wspaniałe.

Więcej informacji o historyjkach użytkownika poznacie na szkoleniach organizowanych przez Pilską Szkołę Programowania Dowiecie się m.in.:

  • w jaki sposób user stories mogą łączyć się ze sobą
  • jak z nimi pracować na codzień z perspektywy programisty
  • różnice między user story a ticketem, oraz jak te terminy funkcjonują w kontekście bug trackera…
  • …oraz oczywiście czym jest bug tracker i jak zespół projektowy się nim posługuje w swojej codziennej pracy

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *