Az agilis módszertanok, egészen az extreem programingtól kezdve, a felhasználói történeteket (user story) használják a szoftver funkcionalitásának definiálásához.
A felhasználói történetek üzleti (és nem technikai) szempontból fogalmazzák meg, hogy mit is kellene a fejlesztőknek implementálni, milyen irányba kellene a fejlesztésnek mennie.
Kinek készül
A felhasználói történetek első részében el kell mondanunk a fejlesztőnek, hogy ki fogja az adott funkciót használni. Ez többek között azért fontos, mert így ki lehet alakítani olyan felületet ami az adott típusú felhasználó jobban ért, implicit benne van a jogosultsági rendszerben elfoglalt helye, stb.
Én mint a cég könyvelője…
Mi készül?
A második részben leírjuk, hogy mit is szeretne elérni a felhasználó. Fontos, hogy ezt mindig úgy fogalmazzuk meg, hogy ne legyen benne technikai megkötés. A felhasználó nem egy új gombot szeretne, hanem valamit megcsinálni a szoftverrel, például egy új jelentést kapni. Ennek az igénynek a kielégítését többféleképp is meg lehet valósítani (új gombbal elindítani egy új jelentés elkészítését, egy régi jelentéshez hozzáfűzni, e-mailben elküldeni, pdf-ben letölthetővé tenni, stb.). Ezek között az opciók között nem tiszte és sokszor nem is tud az dönteni aki a felhasználói történetet írja.
… szeretnék egy havi összesített készletmozgás jelentést …
Miért készül?
Ez a rész az egyik jelfontosabb, nem csak abból a szempontból, hogy segítsen a csapatnak lehető legjobb (legolcsóbb, legoptimálisabb) implementációs döntést hozni, hanem azért is, mert ez validálja a story üzleti hasznosságát.
Ha nem tudjuk egy fél mondatban megfogalmazni, hogy üzletileg miért jó ennek az új funkciónak a bevezetése, valószínűleg nem is az. Ezen felül sokat segít az adott történet priorizáslásában is.
… azért hogy össze tudjam vetni az általam számított készletértékkel és hiba esetén segítsen merre kell továbbmennem.
Pontosan mit kell megoldani?
Az eddig leírtak alapján (ami nem más mint a sztori címe) lehet a őket priorálni és első olvasásra mindenki képet kaphat arról, hogy mi is a feladat, most azonban le kell írnunk, hogy pontosan mit is várunk el, különben nem tudnánk a fejlesztőkön számonkérni a történet funkcionalitását. Úgyhogy következik az elfogadási feltétel (Acceptance Criteria), ami egy pontokba szedett lista arról, hogy a pontos elvárásunk. Ismét nagyon fontos, hogy ha lehet tartózkodjunk az implementációs részletektől.
- csak az adott cég könyvelője érheti el a jelentést
- a jelentésnek tartalmazni kell:
- …
- havi nyitó és záró készletérték
- a készletmozgások értéke készletmozgásonként havi összesítésben
- …
Ezek voltak a felhasználói történet legfontosabb és a legtöbb esetben kötelező részei. Sok esetben érdemes azonban ezen felül is hozzáfűzni dokumentumokat, amik segítik a fejlesztőket az implementálásban. Írhatunk rövid folyamatleírást vagy bizonyos esetekben csatolhatunk felület terveket is, ha ez nincs benne a csapat kompetenciájában ez már az adott szervezetben kialakult munkafolyamaton múlik.
