Pokud se zabýváte vývojem softwaru, určitě jste už slyšeli o uživatelských příbězích. Možná je dokonce píšete jako manažer. Nebo jste možná klient a váš vývojář softwaru po vás chce, abyste požadavky na funkce formulovali jako uživatelské příběhy.

V tomto příspěvku najdete vše, co jste kdy chtěli vědět o uživatelských příbězích.

Co je to uživatelský příběh při vývoji softwaru?

Uživatelský příběh je formát pro formulování funkcí a/nebo požadavků na software. Jak naznačuje část „uživatel“, uživatelské příběhy se píší v první osobě jednotného čísla a popisují funkci tak, jak ji vnímá uživatel aplikace.

Typický uživatelský příběh má tuto strukturu (pokud mluvíme o agilním procesu vývoje):

Jako ,
Chci ,
Aby .

První část (jako….) určuje roli uživatele v aplikaci, která je obvykle spojena s tím, co tam člověk smí dělat.

Druhá část (funkce) ukazuje na část funkce, která je v tomto případě použita.

Třetí část (požadovaný výsledek) je hodnota, kterou chce uživatel z funkce získat. Zde je několik příkladů.

Příklad 1

Jako registrovaný uživatel,
chci být upozorněn, když se kamarád chystá na nějakou akci v okolí
, abych mohl reagovat na zprávy nebo se k němu na akci připojit.

Příklad 2

Jako cestující,
chci získat 10% slevu na každou desátou jízdu
, abych byl odměněn za to, že soustavně utrácím peníze za službu.

Pro tento druh struktury existují rozumné důvody. Když se produktoví/projektoví manažeři zabývají požadavky na software, které pocházejí z různých zdrojů, je pro ně někdy obtížné dosáhnout jednotnosti. Může být také nejasné, které kategorie uživatelů se daná funkce týká nebo v čem spočívá její obchodní hodnota. Formát uživatelských příběhů pomáhá tyto kritické detaily zachytit.

Přístupy k sestavování uživatelských příběhů

Uživatelské příběhy lze psát různými způsoby v závislosti na tom, kdo s nimi bude pracovat.

Způsob Gherkin

Gherkin je prostý textový jazyk, který popisuje chování bez specifikace jeho implementace. Zde je jednoduchý příklad syntaxe jazyka 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 jste si možná všimli, odsazení definuje v jazyce Gherkin strukturu. Základní parametry jsou Dáno/Když/Pokud, a ty mohou být v případě potřeby doplněny o více And. Syntaxe však jde nad rámec těchto základních parametrů. Pokud jste opravdu odhodláni zvládnout jazyk Gherkin, zde je pěkný návod.

Přestože jazyk Gherkin nemusí být nejlepší volbou při shromažďování počátečních požadavků na projekt, může být přínosný (zejména pro tým QA) při dalším vývoji uživatelských příběhů. Uživatelské příběhy napsané v jazyce Gherkin lze snadno převést na testovací případy.

Agile Way

Mnoho agilních aplikací pro řízení projektů nabízí funkci pro zadávání uživatelských příběhů. V některých našich interních projektech jsme například používali aplikaci Taiga. Pomáhá organizovat práci kolem uživatelských příběhů, které lze rozdělit na jednotlivé úkoly v backlogu.

Zdroj: Rozhraní Taiga.io

Pokud se nad tím zamyslíte, dává perfektní smysl mít uživatelské příběhy jako položky backlogu a pak k jednomu uživatelskému příběhu přidat více úkolů. Proč? Protože, řekněme, máte jednu funkci (=uživatelský příběh) a pracují na ní tři lidé; pro tyto lidi budete potřebovat samostatné úkoly. Budete potřebovat designéra, který navrhne rozhraní, programátora HTML/JavaScript, který rozhraní naprogramuje, a DevOps, který rozhraní uvolní do produkce.

Další nástroje, jako je Pivotal Tracker (který zavádí koncept „epics“ pro seskupování souvisejících příběhů), také umožňují vytvářet příběhy, které mohou být různých typů:

Zdroj: PivotalTracker.com

Kromě různých přístupů používaných různými společnostmi nezapomeňte, že existuje jednoduchý a přímočarý způsob formulování uživatelských příběhů – jeho příklady jste viděli na začátku tohoto příspěvku.

Kdo by měl psát uživatelské příběhy?

Kdo je tedy zodpovědný za psaní uživatelských příběhů? No, to záleží na tom. Pokud se váš tým dohodl na zachycení funkcí ve formě uživatelských příběhů, je velmi pravděpodobné, že budou pocházet od akcionářů prostřednictvím Product Ownera. Takže to může být právě PO, kdo je skutečně napíše.

Může to být také projektový manažer nebo QA, který může také spolupracovat se zákazníkem na projednávání funkcí a požadavků. Nebo jste třeba startup o 15 lidech a jste CEO, CTO a CMO? V takovém případě byste mohli jít příkladem a začít používat uživatelské příběhy k dokumentaci funkcí.

Mnozí v IT také hovoří o „vývoji uživatelských příběhů“, což je proces, kdy nejprve zaznamenáte detaily na vysoké úrovni (např. začínáte jednoduchým seznamem funkcí) a poté je rozpracujete do podrobnějších příběhů přidáním úkolů, scénářů atd.

Závěrem

V konečném důsledku vám formulace funkcí ve formě uživatelských příběhů pomůže udržet zaměření na obchodní cíle. Pomáhá vám také zajistit úplnost požadavků. A jak již bylo řečeno, přesná šablona/políčka, která použijete, se mohou lišit v závislosti na situaci.