Főoldal » User story – user sztori – júzer sztori

User story – user sztori – júzer sztori

MEGOSZTÁS

Ha tetszett a cikk, akkor nyugodtan oszd meg ismerőseiddel, valószínű ők is örülni fognak neki.

A héten egy gyakorló projekten dolgoztam, hogy szokjam a későbbi feladatokat. Az első feladat egy user story írás volt, amelyet egy specifikáció követ (folyamatosan készül). Mielőtt belekezdtünk volna a gyakorlatba kaptunk egy kis áttekintést  az eddigi tapasztalatok és a képzések anyagainak kombinációjából.

A feladat maga nem volt bonyolult, de egész összetett végeredményt tudtunk produkálni, amelynek komplexitása megközelítette a valós feladatokat. Gyakoroltuk és szoktuk a munkamenetet. Amiről most beszélni akarok az az user story.

A fogalom pont annyit jelent, mint a neve: a felhasználók igényeinek történetbe foglalása. Két részre oszthatjuk a sztorikat: az egyik fiktív felhasználók várható igényeire épít, itt brainstorming segítségével tudjuk megalkotni a terméket és a hozzá kapcsolódó igényeket, míg a második esetben valós személy, valós igényeit fogalmazzuk meg úgy, hogy az átadható legyen a fejlesztő csapatnak – természetesen míg átadjuk a csapatnak a feladatot több feladatunk is van: követelmény specifikáció megírása, projekt backlogba felvinni a feladatokat és priorizálni őket stb.

A cikk címe User story – user sztori – júzer sztori  lett, mert egyszerűen elkerülhetetlen feladata minden PO-nak, hogy az ügyfelek igényeit valahogy megfogalmazza. Ezekre rengeteg megoldás van, rengeteg stratégia, trükk, praktika. Én egy egyszerű recept szerint dolgozok. 5-10 fontosabb részegységből összeállítunk egy üzleti elemzést, amely tartalmaz:

  1. Egy címet, amely röviden összefoglalja a “változást”
  2. Egy kivonatot, amely a Ki? Mit? Miért? kérdésekre ad választ
  3. Egy háttérsztorit, amely kontextusba helyezi a feladatot
  4. Egy érintettek és érdekek részt, amely meghatározza a szereplőket és azok céljait
  5. Egy triggert (ravaszt), amely meghatározza, hogy mi a folyamat mozgatórugója
  6. Egy mockupot, amely egy egyszerűsített képernyőterv
  7. Egy sikeres forgatókönyvet, amely felvázolja, hogy mikor vagyunk elégedettek
  8. Egy elfogadó kritérium (AC) listát, amely biztosítja azt, hogy a szolgáltatást/terméket olyan formába kapjuk meg, amelyet el tudunk fogadni.

Természetesen ez a lista nem garancia a jó user sztorira, de alapvetően egy jól körülhatárolt keretet ad neki. A saját tapasztalataim alapján ez a lista túl sok mindent követel meg és nem ad annyi értéke, hogy érdemes legyen vele annyi időt eltölteni, mint amennyit én töltöttem vele. Másfelől lehet a tapasztalatlanságom miatt érzem így, de lehet azért is, mert nekem másmilyen stratégia szerint kell létrehoznom a júzer sztorijaimat.

Azt sem szabad elfelejteni, hogy ez a 3. hetem, amelyet a cégnél és a Scrum igazi tanulmányozásával töltök. Ahogy a módszertan is diktálja, a tapasztalatoknál nincsen értékesebb. Nem véletlenül a retrospektív az egyik mozgatórugója egy sikeres Scrum vagy egyéb agilitást megkövetelő módszertannak.

Nem akarok közhelyes lenni, de ide nem a gyári közmondás illik: az okos ember más hibájából, a hülye a sajátjából tanul. A Scrum pont ennek az ellenkezőjét állítja, hiszen a saját hibáidból kell építkezned és nem máséból, mert mi a garancia arra, hogy a más hibája az, amellyel éppen te is szembekerültél?

MEGOSZTÁS

Ha tetszett a cikk, akkor nyugodtan oszd meg ismerőseiddel, valószínű ők is örülni fognak neki.