Remote / Rotácie na projektoch / Refferal bonus 2000€ / Work&Travel.
Získaj odhad platu

GET SALLARY ESTIMATION

Vieme, že ak si najlepší, môžeš pracovať pre kohokoľvek.

Preto ti ponúkame okrem skvelých BENEFITOV aj adekvátne platové ohodnotenie. Vyplň náš dotazník a my ti na základe tvojich skúseností vypracujeme odhad tvojej budúcej výplaty v CODERAMA.

Napíšte nám:

Späť
User story

User story

User story je v oblasti vývoja softvéru a product managementu neformálny popis jednej alebo viacerých funkcionalít softvérového produktu z pohľadu koncového užívateľa.

Ide o nástroj používaný pri agilnom vývoji softvéru. Popisuje funkcionalitu aplikácie jazykom, akému rozumie aj koncový užívateľ. Píše sa v nej o aký typ užívateľa ide, čo tento užívateľ chce a prečo. User story však nepopisuje všetky podrobnosti danej funcionality, slúži skôr ako základ pre diskusiu. Na základe tohto popisu a diskusie k nemu neskôr vznikne požiadavka na vývoj funkcionality, s ktorou ďalej pracuje vývojový tím.


User stories sú zaznamenávané v nástroji na riadenie projektu, ako napríklad Jira. V závislosti od projektu ich môžu vytvárať či už klienti, samotní užívatelia, manažéri alebo členovia vývojového tímu.


Koncept 3C


Dobré user stories zahŕňajú tri kritické aspekty (známe aj ako Koncept 3C):

  1. Card – stručný popis požiadavky v štandardizovanom formáte,
  2. Conversation – diskusia vedená počas plánovania iterácie medzi zákazníkom a vývojovým tímom,
  3. Confirmation – akceptačné kritériá slúžiace pre overenie korektného správania implementácie.


Ako písať user stories


Štandardizovaný formát popisu požiadavky v user story má tvar:

As a <Role>, I want to <Action>, so that <Benefit>.


  • Role – špecifikuje užívateľa ktorý požaduje danú funkcionalitu,
  • Action – popisuje samotnú funkcionalitu systému, písané vo forme akcie,
  • Benefit – čo chce užívateľ pomocou funkcionality dosiahnuť.


INVEST


Skratka INVEST slúži ako pomôcka na zapamätanie všeobecne akceptovaných kritérií, ktoré určujú kvalitu user story. Tieto kritériá sú:


  • Independent – malo by ísť o samostatnú funkcionalitu ktorá nezávisí na iných,
  • Negotiable – mala by popisovať len potrebu užívateľa, bez špecifík, a nechať tak priestor na konverzáciu,
  • Valuable – mala by užívateľovi priniesť nejakú hodnotu,
  • Estimable – malo by byť možné odhadnúť jej implementačnú náročnosť pre potreby zaradenia do sprintu,
  • Small – mala by vyžadovať malé množstvo práce,
  • Testable – musí obsahovať akceptačné kritériá pre overenie správnosti implementácie.