Jeśli zajmujesz się tworzeniem oprogramowania, na pewno słyszałeś o historyjkach użytkownika. Być może nawet piszesz je jako menedżer. A może jesteś klientem i Twój twórca oprogramowania chce, abyś formułował żądania funkcji jako historyjki użytkownika.

W tym wpisie znajdziesz wszystko, co kiedykolwiek chciałeś wiedzieć o historyjkach użytkownika.

Co to jest historyjka użytkownika w tworzeniu oprogramowania?

Historyjka użytkownika jest formatem formułowania cech i/lub wymagań oprogramowania. Jak sugeruje część „użytkownik”, historyjki użytkownika są pisane w pierwszej osobie liczby pojedynczej i opisują funkcję tak, jak jest ona postrzegana przez użytkownika aplikacji.

Typowa historyjka użytkownika ma następującą strukturę (jeśli mówimy o zwinnym procesie rozwoju):

Jako ,
Chcę ,
Żeby .

Pierwsza część (jako…) określa rolę użytkownika w aplikacji, która jest zwykle związana z tym, co można w niej robić.

Druga część (cecha) wskazuje na fragment funkcjonalności, który jest używany w tym przypadku.

Trzecia część (pożądany wynik) to wartość, jaką użytkownik chce uzyskać dzięki danej funkcji. Oto kilka przykładów.

Przykład 1

Jako zarejestrowany użytkownik,
chcę być powiadamiany, gdy znajomy wybiera się na wydarzenie w pobliżu
Aby móc zareagować na wiadomości lub dołączyć do nich w wydarzeniu.

Przykład 2

Jako jeździec,
chcę otrzymać 10% zniżki na każdą 10-tą podróż
Tak, abym został nagrodzony za konsekwentne wydawanie pieniędzy na usługę.

Istnieją rozsądne powody dla tego rodzaju struktury. Kiedy menedżerowie produktu/projektu mają do czynienia z wymaganiami dotyczącymi oprogramowania, które pochodzą z różnych źródeł, czasami trudno jest im osiągnąć jednolitość. Niejasne może być również to, jakiej kategorii użytkowników dotyczy dana funkcja lub gdzie leży jej wartość biznesowa. Format historyjki użytkownika pomaga uchwycić te krytyczne szczegóły.

Podejścia do tworzenia historyjek użytkownika

Historyjki użytkownika mogą być pisane na różne sposoby, w zależności od tego, kto będzie z nimi pracował.

Sposób Gherkin

Gherkin jest językiem tekstowym, który opisuje zachowanie bez określania jego implementacji. Oto prosty przykład składni języka Gherkin:

Feature: Guest contributor functionality
In order to contribute to blog XXY
As a guest author
I want to be able to publish articles on the website


Scenario: I edit my own article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am the author of this article
Then I can see the "edit" button
And I can click it
And I can use a popup interface for editing my article

Scenario: I edit somebody else's article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am NOT the author of this article
Then I CANNOT see the "edit" button

Jak zapewne zauważyłeś, tiret definiuje strukturę w języku Gherkin. Podstawowymi parametrami są Given/When/Then, które w razie potrzeby mogą być uzupełnione o wiele And’s. Składnia wykracza jednak poza te podstawowe parametry. Jeśli jesteś naprawdę zdeterminowany, aby opanować Gherkin, oto fajny tutorial.

Choć Gherkin może nie być najlepszym wyborem podczas zbierania wstępnych wymagań dla projektu, może być korzystny (szczególnie dla zespołu QA) podczas dalszego rozwijania historyjek użytkownika. Historyjki użytkownika napisane w Gherkin są łatwe do przekształcenia w przypadki testowe.

Sposób na Agile

Wiele aplikacji do zarządzania projektami Agile oferuje funkcjonalność wprowadzania historyjek użytkownika. Na przykład w niektórych naszych wewnętrznych projektach używaliśmy aplikacji Taiga. Pomaga ona organizować pracę wokół user stories, które można rozbić na poszczególne zadania w backlogu.

Źródło: Interfejs Taiga.io

Jeśli się nad tym zastanowić, to posiadanie historyjek użytkownika jako elementów backlogu, a następnie dodawanie wielu zadań do jednej historyjki użytkownika, ma doskonały sens. Dlaczego? Ponieważ, powiedzmy, masz jedną cechę (=user story) i trzy osoby pracujące nad nią; będziesz potrzebował oddzielnych zadań dla tych osób. Będziesz potrzebował projektanta do zaprojektowania interfejsu, programisty HTML/JavaScript do zaprogramowania interfejsu i DevOps do wypuszczenia interfejsu na produkcję.

Inne narzędzia, takie jak Pivotal Tracker (który wprowadza pojęcie „epiki” do grupowania powiązanych historii razem) również pozwalają na tworzenie historii, które mogą być różnych typów: Features, Chores, Bugs czy Releases.

Źródło: PivotalTracker.com

Oprócz różnych podejść stosowanych przez różne firmy, pamiętaj, że istnieje prosty i nieskomplikowany sposób na sformułowanie user stories – którego przykłady widziałeś na początku tego wpisu.

Who Should Write User Stories?

Więc, czyim obowiązkiem jest pisanie user stories? Cóż, to zależy. Jeśli twój zespół zgodził się na przechwytywanie cech w formie historyjek użytkownika, najprawdopodobniej będą one pochodzić od udziałowców za pośrednictwem Właściciela Produktu. Tak więc, może to być PO, który faktycznie je zapisuje.

Może to być również Kierownik Projektu lub QA, który może również pracować z klientem w celu omówienia cech i wymagań. A może jesteś 15-osobowym startupem i jesteś CEO, CTO i CMO? W takim przypadku możesz dać przykład i zacząć używać historyjek użytkownika do dokumentowania cech.

Wiele osób w IT mówi również o „rozwoju historyjek użytkownika”, co jest procesem rejestrowania najpierw szczegółów wysokiego poziomu (np. zaczynając od prostej listy cech), a następnie rozwijania ich w bardziej szczegółowe historyjki poprzez dodawanie zadań, scenariuszy itp.

W podsumowaniu

Na koniec dnia, formułowanie cech w postaci historyjek użytkownika pomaga skupić się na celach biznesowych. Pomaga to również uczynić wymagania kompletnymi. I, jak już zostało powiedziane, dokładny szablon/pola, których używasz, mogą być różne, w zależności od sytuacji.