A user story a végfelhasználók (userek) szempontjából ír le valamilyen funkciót, ami az agilis csapatok által szétbontásra kerül jól definiált technikai feladatokra (subtask-okra).
Mi az a user story?
Az üzletileg legkisebb egység, ami az üzlet és a fejlesztők számára is még egyaránt értelmezhető. A szétbontást követően a subtask-ok már inkább technikai megközelítést tartalmaznak.
A user story-k legfontosabb szerepe, hogy a felhasználó igényeit jeleníti meg, amivel kiváltja a tradicionális követelményspecifikációt. Igaz, hogy a specifikáció több információt hordoz magában, mint például a rendszer működésével, compliance, szállítók és egyéb követelményekkel kapcsolatban, de ezeknek a történeteknek a fókusza az üzleti érték és a felhasználó központú gondolkodás. Ezáltal egy jobb megértést biztosit a fejlesztők felé, hogy mi a tényleges üzleti igény.
A story megfogalmazása és felépítése
A user story megfogalmazása: „Én, mint(user szerep) azt szeretném, hogy (cselekmény) azért, mert (üzleti érték).„
Példa egy story-ra: „Én, mint egy autó tulajdonos, azt szeretném, hogy az autó magától meghatározza a sebességhatárt és álljon be erre, azért, mert így nem kell figyelnem a sebességre és nem lesz gyorshajtásom.”
Példa egy user story felépítésére:
- Név (Name);
- Rövid leírás (Description);
- Elfogadási kritériumok (Acceptance criteria) – akár narratíva megadásával;
- Mi az, amit nem csinálunk most meg, de tudjuk, hogy később üzleti értékkel bírhat vagy kockázatot csökkenthet (Not list/Not now list);
- Tesztesetek, amit a csapat és a Product Owner is megírhat (Non trivial testcases);
- Honnan veszünk adatokat, azokat hová küldjük (Data move);
- Minden más hasznos információ: tag-ek, fényképek, megjegyzések, kérdések a PO felé, …
INVEST, a jó történet tulajdonságai
A sokat használt mozaikszó az INVEST, ami a történetek megírásánál jelent segítséget. Az összes story-nak az alábbi tulajdonságokkal kell rendelkeznie:
- Independent –függetlenek legyenek a story-k egymástól, mert a story-k közti függőség megnehezíti a tervezést, priorizálást, becslést.
- Negotiable – rugalmasan tárgyalható, nem egy szerződés szigorúságával tekintünk rájuk.
- Valuable – Valódi értékkel bír a megrendelő, felhasználó részére.
- Estimable – Jól becsülhetőek, kellően kicsi méretűek és tárgyalhatók.
- Small/Short – Kellően kicsik, ideális esetben beleférnek egy iterációba.
- Testable – Jól tesztelhetőek és azt is tudjuk, hogyan tudjuk kitesztelni.
A user story-k megfogalmazása az agilis fejlesztés alapja, ezért tartjuk fontosnak, hogy munkánk során személyre szabott mentorálást nyújtsunk belőle az agilis csapatok szereplői számára.
Szerző: Bazsi
