Ha szoftverfejlesztéssel foglalkozik, biztosan hallott már a felhasználói történetekről. Talán még vezetőként is írja őket. Vagy talán Ön ügyfél, és a szoftverfejlesztője azt szeretné, hogy a funkcióigényeket felhasználói történetekként fogalmazza meg.

Ebben a bejegyzésben mindent megtalál, amit valaha is tudni akart a felhasználói történetekről.

Mi a felhasználói történet a szoftverfejlesztésben?

A felhasználói történet egy formátum a szoftverfunkciók és/vagy követelmények megfogalmazására. Ahogy a “felhasználó” rész is sugallja, a felhasználói történetek egyes szám első személyben íródnak, és úgy írnak le egy funkciót, ahogyan azt az alkalmazás felhasználója érzékeli.

Egy tipikus felhasználói történet a következő struktúrát követi (ha az agilis fejlesztési folyamatról beszélünk):

Mint ,
Mi azt akarom,
hogy .

Az első rész (mint egy…) a felhasználó szerepét adja meg az alkalmazásban, ami általában azzal függ össze, hogy mit szabad ott csinálni.

A második rész (a funkció) a funkciónak arra a darabjára mutat, amit ebben az esetben használunk.

A harmadik rész (a kívánt eredmény) az az érték, amit a felhasználó a funkciótól szeretne kapni. Íme néhány példa.

1. példa

Mint regisztrált felhasználó,
szeretnék értesítést kapni, ha egy barátom a közelben egy eseményre megy,
hogy reagálhassak a hírre, vagy csatlakozhassak hozzájuk az eseményen.

Példa 2

Fuvarozóként,
minden 10. utazás után 10% kedvezményt szeretnék kapni
Így jutalmaznak, ha következetesen pénzt költök a szolgáltatásra.

Ezeknek a struktúráknak jó okai vannak. Amikor a termék/projektmenedzserek olyan szoftverkövetelményekkel foglalkoznak, amelyek különböző forrásokból származnak, néha nehéz számukra az egységesség elérése. Az is előfordulhat, hogy nem világos, hogy a felhasználók mely kategóriáját fedi le a funkció, vagy hol rejlik az üzleti érték. A felhasználói történetek formátuma segít megragadni ezeket a kritikus részleteket.

A felhasználói történetek összeállításának megközelítései

A felhasználói történetek többféleképpen írhatók, attól függően, hogy ki fog velük dolgozni.

A gherkin-út

A gherkin egy egyszerű szöveges nyelv, amely a viselkedést írja le anélkül, hogy megadná annak megvalósítását. Íme egy egyszerű példa a Gherkin szintaxisára:

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

Amint azt talán észrevetted, a behúzás a Gherkinben struktúrát határoz meg. Az alapvető paraméterek a Given/When/Then, és ezeket szükség esetén több And-val lehet kiegészíteni. A szintaxis azonban túlmutat ezeken az alapparamétereken. Ha igazán elszánt vagy a Gherkin elsajátítására, itt egy szép bemutató.

Míg a Gherkin nem feltétlenül a legjobb választás a projekt kezdeti követelményeinek összegyűjtésekor, a felhasználói történetek továbbfejlesztésekor hasznos lehet (különösen a QA csapat számára). A Gherkinben írt felhasználói történetek könnyen átalakíthatók tesztesetekké.

Az agilis út

Néhány agilis projektmenedzsment-alkalmazás kínál funkciót a felhasználói történetek bevitelére. Mi például a Taiga alkalmazást használtuk néhány belső projektünkhöz. Segít megszervezni a munkát a felhasználói történetek köré, amelyek a backlogban különálló feladatokra bonthatók.

Forrás: Taiga.io felület

Ha jobban belegondolunk, tökéletesen logikus, hogy a felhasználói történetek backlog elemként szerepelnek, majd egy felhasználói történethez több feladatot is hozzáadhatunk. Hogy miért? Mert, mondjuk, van egy funkció (=felhasználói történet) és három ember dolgozik rajta; ezeknek az embereknek külön feladatokra lesz szükségük. Szüksége lesz egy tervezőre a felület megtervezéséhez, egy HTML/JavaScript programozóra a felület programozásához, és a DevOps-ra a felület gyártásba adásához.

A többi eszköz, például a Pivotal Tracker (amely bevezeti az “epik” fogalmát az összefüggő történetek csoportosítására) szintén lehetővé teszi, hogy különböző típusú történeteket hozzon létre: Jellemzők, feladatok, hibák vagy kiadások.

Forrás:

Source: PivotalTracker.com

A különböző cégek által használt különböző megközelítések mellett ne feledjük, hogy van egy egyszerű és egyértelmű módja a felhasználói történetek megfogalmazásának – erre a poszt elején láthattál példákat.

Ki írjon felhasználói történeteket?

Szóval, kinek a feladata a felhasználói történetek írása? Nos, ez attól függ. Ha a csapata megállapodott abban, hogy a funkciókat felhasználói történetek formájában rögzíti, akkor a legvalószínűbb, hogy azok a terméktulajdonoson keresztül a részvényesektől származnak. Tehát lehet, hogy a PO az, aki ténylegesen lejegyzi őket.

Ez lehet egy projektmenedzser vagy egy minőségbiztosító is, aki szintén együttműködhet az ügyféllel a funkciók és követelmények megvitatásában. Vagy esetleg egy 15 fős startup, és Ön a CEO, a CTO és a CMO? Ebben az esetben példát mutathatna, és elkezdhetne felhasználói történetekkel dokumentálni a funkciókat.

Az informatikában sokan beszélnek a “felhasználói történetek fejlesztéséről” is, ami azt jelenti, hogy először a magas szintű részleteket regisztráljuk (pl. a funkciók egyszerű listájával kezdjük), majd ezeket részletesebb történetekké fejlesztjük feladatok, forgatókönyvek stb. hozzáadásával.

Végeredményben

A nap végén a funkciók felhasználói történetek formájában történő megfogalmazása segít az üzleti célokra összpontosítani. Emellett segít a követelmények teljessé tételében is. És, ahogyan már említettük, a pontos sablon/mezők, amelyeket használ, a helyzettől függően eltérőek lehetnek.