Warto zauważyć, iż każda opowieść, którą przekazujemy, tworzona jest w konkretnym celu. Najczęściej po to, aby inni mogli ją zapamiętać lub wykorzystać. Już Arystoteles doszedł do wniosku, iż człowiek z natury swojej dąży do tego, aby wiedzieć więcej. W zasadzie nie chodzi tutaj tylko o informację - samej informacji nie jesteśmy jako ludzie w stanie zapamiętać, dopóki nie nadamy jej sensu. Według badań osoby, którym przekazano suche dane - dużo gorzej je zapamiętały od ludzi, którym opowiedziano historię, wplatając w nią te same dane. Wnioski nasuwają się same - odpowiednio opowiedziana historia może zdziałać cuda, jeżeli chodzi o motywację, zaangażowanie i realizację celu.
# Grupy specjalistów
Przez wieki wiedza, którą musiał posiadać jeden człowiek, dotykała wielu obszarów życia. Zakres tej wiedzy w ramach pojedynczego obszaru nie był wielki, więc nasi przodkowie świetnie sobie radzili. Z czasem jednak praktycznie każda dziedzina życia rozwinęła się do bardzo wysokiego poziomu. Ludzie zaczęli się specjalizować, kreując jednocześnie swój własny - domenowy język, którym posługiwali się w swoim towarzystwie.
Bardzo łatwo dostrzec to w grupach takich jak medycy, prawnicy, sprzedawcy, kapłani, architekci… a dziś również programiści. Każda grupa specjalistów wykształciła swój własny technolekt. Główną cechą języków fachowych jest tworzenie uproszczeń morfologicznych w celu optymalizacji przekazu, w taki sposób, aby stał się on bardziej efektywny.
Przykładowe zwroty i słowa z języka programistów to: ai, backend, bug, code review, devops, konwersja, klasa, merge, nerd, system kontroli wersji… i wiele innych. Dla osób spoza branży zrozumienie zdań, zawierających technolekt, jest bardzo trudne, a czasem wręcz niemożliwe.
# Narzędzia przekazu
Oprócz języka fachowego w komunikacji branżowej bardzo często wykorzystywane są specyficzne narzędzia, dzięki których formułowane są określone przekazy. Takim narzędziem byłby akt prawny dla prawników, karta medyczna dla lekarzy czy API (interfejs programistyczny aplikacji) dla programistów. API jest przede wszystkim specyfikacją wytycznych, która opisuje sposób komunikacji pomiędzy poszczególnymi częściami aplikacji i/lub zewnętrznymi serwisami. Zdecydowanie można pokusić się o stwierdzenie, iż API będzie zrozumiałe dla jednej grupy zawodowej.
Powyższe narzędzia mają swoją określoną strukturę treści, wykorzystują technolekt i pełne zrozumienie treści w nich zawartej wymaga bardzo określonej wiedzy. Innymi słowy - łatwo nie jest. Na szczęście w większości przypadków nie musimy korzystać bezpośrednio z tych narzędzi, jeżeli nie należymy do danej grupy specjalistów.
Zdarzają się jednak sytuacje, gdy światy fachowe się przenikają. W branży IT widać to dość często, ponieważ coraz więcej dziedzin naszego życia zaczyna łączyć się z programowaniem. Przede wszystkim dlatego, iż nasz świat się wirtualizuje i powstają aplikacje dla „zwykłych” ludzi, tworzone przez programistów na zlecenie osób spoza świata IT. Zleceniodawcy muszą przekazać swój pomysł, w taki sposób, aby zrozumiał to programista.
Mogą to zrobić dzięki narzędzia, które nazywa się User Story (US).
## Wiedza domenowa
W tym miejscu warto wspomnieć o wiedzy domenowej. Wiedza domenowa to nic innego jak znajomość dziedziny, w której powstaje dana aplikacja. Programistom, wyspecjalizowanym w jakimś obszarze biznesowym, dużo łatwiej zrozumieć wymagania klienta i dostarczyć odpowiedni produkt. Czasami choćby podpowiedzieć rozwiązanie lub nakierować klienta w odpowiednią stronę. Znajomość biznesu bardzo pomaga w tworzeniu systemu i komunikacji, a co za tym idzie w dostarczaniu optymalnych rozwiązań.
# Co to jest User Story?
User Story to narzędzie, które wykorzystywane jest do opisywania wymagań przy tworzeniu oprogramowania. Co do zasady User Story powinno stosować język, który będzie zrozumiały zarówno dla osób technicznych, jak i nietechnicznych.
Jaki to język? **Maksymalnie prosty**. Biorąc pod uwagę fakt, iż muszą go zrozumieć dwie różne grupy fachowców, raczej powinno się unikać technolektu.
## Perspektywa użytkownika
Innymi słowy, User Story to nieformalnie spisane wymagania objaśniające zachowanie programu napisane z perspektywy użytkownika. Ostatnia część tego zdania jest bardzo istotna. Wskazuje na to, iż to użytkownik jest odbiorcą i to dla niego ważne jest, jak zachowa się program. Programista, który będzie analizował takie User Story, będzie w stanie lepiej zrozumieć potrzeby i oczekiwane zachowanie danej funkcjonalności.
„Historyjka” powinna opisywać konkretną korzyść dla konkretnej osoby. Warto podkreślić, iż użytkownik, z którego perspektywy jest tworzona, to nie zawsze odbiorca końcowy. Czasami to inny członek zespołu programistów, czasami administrator systemu, a czasami klient.
## Agile
User Story jako narzędzie bardzo często wykorzystywane jest w zwinnych metodykach zarządzania projektami (agile). Co prawda nie jest to artykuł o Agile’u, ale warto wspomnieć, iż w zarządzaniu zwinnym chodzi przede wszystkim o elastyczność w dostarczaniu działających rozwiązań. W metodykach zwinnych US jest określane jako najmniejsza jednostka pracy. Podział pracy na małe „historyjki” pozwala zachować sporą elastyczność, poprzez odpowiednie wybieranie zadań do pracy na najbliższy czasu.
# Jak zbudowane jest User Story?
Jak każde dobre narzędzie User Story również ma swoje specyficzne cechy, które sprawiają, iż jest narzędziem skutecznym. Jedną cechę już wymieniłem - prosty język. Druga cecha to konstrukcja. Dobra „historyjka” dotyka trzech aspektów:
* określa użytkownika / odbiorcę
* określa potrzeby
* określa cel, który ma zostać zrealizowany w związku z daną potrzebą.
Przykład:
Jako chcę , aby .
Jako **administrator** chcę **edytować stronę artykułu**, aby **móc dokonywać korekty treści**.
User Story nie powinno być zbyt szczegółowe. Powinno skupiać się na celu, który ma zostać zrealizowany i określać motywację, która za tym celem stoi. Powyższy przykład zwykle wykorzystywany jest jako nagłówek dla całej „storyjki". Oprócz tej podstawowej części w US powinny być zdefiniowane Acceptance Criteria (czasami też nazywane Conditions of Satisfaction). Acceptance Criteria (AC) to nic innego jak spis wymagań, które muszą zostać spełnione, aby stwierdzić, iż US zostało zakończone. W praktyce AC są często określane terminem Definition of Done. Prawidłowe określenie DoD zapobiega dostarczaniu nieprzetestowanych lub niepełnych rozwiązań do klienta końcowego.
Często spotkać się można również z opinią, iż dobrze przygotowane User Story powinno mieć oszacowany rozmiar (nie może być za duże), zdefiniowaną wartość i określone miejsce na liście zadań do wykonania.
## Pięć W
W praktyce tworzenia User Story można spotkać się również z zasadą Pięciu W (z ang. Five Ws). Zasada wzięła swoją nazwę od pięciu słów: kto, co, kiedy, gdzie i dlaczego (ang. who, what, when, where i why). Często stosowana jest w dziennikarstwie do tworzenia informacji prasowych.
Stosowanie zasady Pięciu W w budowaniu „historyjki” wygląda następująco:
Jako , chcę , ponieważ ~
## Zapisywanie Acceptance Criteria
Wspomniałem już czym są Acceptance Criteria i jakie jest ich zadanie w ramach User Story. Pozostaje nam zatem jeszcze kwestia formy zapisu. adekwatnie możemy spotkać się z dwoma podejściami. Pierwsze polega na zapisywaniu w postaci prostych zdań lub równoważników zdań rzeczy, najczęściej w postaci listy, które powinny być zrealizowane.
Można spotkać się również z innym podejściem, wykorzystującym Behavior Driven Development, gdzie warunki akceptacji określane są jako scenariusze, składające się z nazwy, warunków, zdarzenia wyzwalającego i spodziewanego efektu. Przykładowo:
Scenariusz:
Given
And
When
Then
Takich scenariuszy będzie tyle, ile wymagań będzie miało dane US.
## Zasada INVEST
Dobrze przygotowane User Story pomoże ustalić priorytety projektu, co w ostateczności przełoży się na efektywność dostarczania prac. Pomimo niewielu zasad bardzo łatwo się zgubić i zapomnieć o ważnych aspektach tworzenia „historyjek”. Aby tego uniknąć, warto skorzystać z zasady INVEST podczas ich przygotowywania. INVEST to akronim od słów: Independent, Negotiable, Valuable, Estimable, Small, Testable. Przyjrzyjmy się kolejnym punktom:
## Independent
Wspominałem, iż US jest najmniejszą jednostką pracy w projektach agile’owych. Warto tutaj podkreślić, iż powinno być również niezależne od innych "storyjek”. Oznacza to, iż zespół, który będzie rozwiązywał dane US, może je wykonać w oderwaniu od reszty. Kolejność zadań powinna wynikać z potrzeby biznesowej, a nie z powiązań pomiędzy US.
Czasami może to być trudne, ale często nie jest to niemożliwe do wykonania.
### Negotiable
We wcześniejszych punktach wspominałem, jak bardzo istotne jest zrozumienie wymagań i tego, dla kogo będzie realizowana dana funkcjonalność. Ten punkt wskazuje na wartość, jaką niesie za sobą wspólne tworzenie User Story. Dobra „historyjka” to rezultat współpracy pomiędzy zespołem a klientem, gdzie w ramach dyskusji każda ze stron może dodawać własne uwagi, spostrzeżenia i pomysły.
### Valuable
Ten punkt jest poruszany chyba najczęściej ze wszystkich. US powinno nieść ze sobą
wartość dla użytkownika końcowego, powinno być ważne dla biznesu.
### Estimable
Każde zadanie, nad którym będzie pracował zespół, powinno być możliwie łatwe do oszacowania. jeżeli nie można określić pracochłonności danego User Story to trudno stwierdzić, na kiedy efekt zostanie dostarczony. Z perspektywy biznesowej taka sytuacja jest niemożliwa do zaakceptowania.
### Small
„Historyjka” powinna być możliwie mała, tak aby można było ją zamknąć w ramach czasowych. Przy mniejszych zadaniach nie ma tak dużego ryzyka, iż coś nie zostanie dostarczone czy też, iż pojawią się dodatkowe aspekty, o których nie pomyśleliśmy. Rzeczy niespodziewane to jeden z największych wrogów produktywności.
### Testable
Acceptance Criteria powinny być łatwe do przetestowania. Na ich podstawie testerzy powinni mieć możliwość zbudowania jasnych i konkretnych scenariuszy testowych, a programiści bezproblemowo wiedzieć, jak sprawdzić, czy ich rozwiązanie działa.
## Definition of Ready
Powyżej opisałem większość cech dobrego User Story. Niestety życie pokazuje różne scenariusze i zdarzają się sytuacje, gdy „historyjki” nie są kompletne, nie posiadają jasno określonych warunków akceptacji czy po prostu nie da się oszacować ich czasochłonności. Przy tworzeniu User Story możemy też spotkać się z zasadą Definition of Ready, która mówi nam, iż zadanie można zostać uznane za gotowe do realizacji, jeżeli zespół stwierdzi, iż rozumie wymagania i są one odpowiednio opisane. Coś, co nie zostało zatwierdzone przez zespół, nie może być uwzględniane w jego pracy. Dlatego tak ważne jest, aby wszyscy jego członkowie uczestniczyli w zbieraniu wymagań i konsultacjach. Takie podejście daje wszystkim zaangażowanym odpowiednio dużo wiedzy na temat zadania do wykonania.
# Podsumowanie
Komunikacja to podstawowa umiejętność w ramach każdego projektu. Bez otwartej komunikacji opartej na jasno określonych zasadach trudno zbudować coś wartościowego. Wracając do początku tego artykułu - warto zwrócić uwagę na fakt, iż im więcej wiemy o świecie, tym trudniej nam się komunikować pomiędzy różnymi specjalizacjami. Narzędzia
takie jak User Story wychodzą poza schemat komunikacji jednej specjalistycznej grupy, otwierając ją na innych fachowców, tworząc tym samym produkty dotykające wielu dziedzin. Oczywiście US nie jest doskonałe - bardzo trudno wykorzystać je do opisywania typowo systemowych problemów (jak analizy techniczne czy błędy w oprogramowaniu), problematyczne może być również przywiązywanie zbyt dużej wagi do rozwiązań biznesowych, pomijając optymalizacje czy utrata całościowej wizji projektu, z powodu dużej fragmentaryzacji zadań.
Pomimo to, User Story pozwala na zrozumienie tego, co powinno zostać wykonane przez każdą ze stron, określenie priorytetów i zwiększenie użyteczności tworzonych rozwiązań, pomijając tym samym prace nad rozwiązaniami, które mogłyby nie zostać nigdy zaimplementowane produkcyjnie.
# Źródła
1. Wiedza domenowa - Marek Zając
2. Słownik programisty – zwroty, które każdy Junior Developer powinien znać | Blog Future Collars
3. Słowniczek pojęć IT dla początkujących programistów i nie tylko!
4. Język fachowy – Wikipedia, wolna encyklopedia
5. User Stories and User Story Examples by Mike Cohn
6. User Story (opowieść użytkownika) - co powinieneś o niej wiedzieć
7. Historyjki użytkowników | Przykłady i szablon | Atlassian
8. User story - Wikipedia
9. Visual Storytelling - Monika Górska
10. Jak napisać informację prasową? - E-wolontariat.pl
11. Jak budować User Story? – „Scrum i nie tylko. Teoria i praktyka w metodach Agile / Programowanie / Artykuły / IT PWN - [IT.PWN.PL](IT.PWN.PL)
12. Definition of Ready - wady I zalety - #białko czyli Scrum I Agile
13. Co to jest historia użytkownika i kryteria akceptacji (przykłady) - Testowanie Zwinne 14. DONE Understanding Of The Definition Of „Done” | [Scrum.org](Scrum.org)
15. What is acceptance criteria? | Definition and Best Practices
16. Appchance - Jak i po co tworzyć User Stories.
