Felhasználói történetek fő részei

Felhasználói történetek fő részei

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.