A felhasználói történetek egyszerűek, mégis rendkívül erős konstrukciók: a felhasználó szemszögéből leírják a funkcionalitás darabjait, szilárd, kompakt módon kifejezve. Ezek tükrözik a felhasználói igények egy adott osztályát és a megszerezendő értéket. A formátum nagyon egyszerű, könnyen használható. Számos változat létezik, többek között:
miért felhasználói történetek?
A felhasználói történetek kiváló módot nyújtanak a termék egyértelmű meghatározására., Egy sor jól definiált, prioritást élvező felhasználói történet segíthet megfogalmazni a termék funkcionalitását az “egyszerű angol” használatával-technikai részletek és megvalósítás nélkül.
a “felhasználói történet” megközelítés értelmes termékbeszélgetéseket tesz lehetővé mind a termékfejlesztő csoporton belül, mind a külső érdekeltekkel.
a megfelelően megírt felhasználói történetek szilárd alapot nyújtanak a kommunikációhoz és az együttműködéshez — arra összpontosítva, ami a legfontosabb a felhasználó számára., Összehasonlítva más azt jelenti, hogy a rögzítése, dokumentálása, valamint a felhasználói követelményeknek, valamint termékleírás, legalább a következő előnyök:
- Felhasználói történetek elősegíti a határokon csapat volt egyértelmű, hogy mit kell építeni, kinek, miért, mikor. Mivel könnyen meghatározhatók, megérthetők és felülvizsgálhatók, a termék műszaki és nem MŰSZAKI tagok általi kommunikációjának és összefoglalásának szokásos módjává válhatnak. Rendkívül hasznosak a termékkör megbeszéléseihez vagy a technikai mély merülések belépési pontjaihoz. Ezek az agilis tervezés kulcsfontosságú elemei.,
- A felhasználói történetek ösztönzik a nem technikai tagok részvételét. A modern szoftverprojektek jellemzően összetettek, számos technológiát, rövidítést és megvalósítási lehetőséget érintenek. A terminológiát vagy a technikai nyelvet sok esetben — akár egyetlen csapaton belül is — nem értik, így a projekt “zaját” és kockázatait is bevezetik. A felhasználói történetek eltávolítják ezt a technikai dimenziót, így a csapat bármely tagja hozzájárulhat, egyszerűen úgy, hogy “felhasználóként” gondolkodik., A csapat nem technikai nyelvet használhat, hatékonyan együttműködhet a felhasználói történetek meghatározásában, kihívásában vagy rangsorolásában. Az együttműködésre és a csapatdinamikára gyakorolt hatás jelentős lehet.
- segítenek a teljes termék meghatározásában-szilárd, bölcsen rangsorolt történetek halmazaként. A termékfejlesztő csapat nagyot tud gondolni, meghatározza a felhasználói történetek szuperkészletét, majd hozzárendel prioritásokat (amelyek tükrözik a felhasználó várható értékét, összetettségét, függőségeit és egyéb üzleti prioritásait). Nem kell kemény döntéseket hozni, és a “hatáskörön kívül” megjelölni a tételeket., Ehelyett alacsonyabb prioritást rendelhet az “őrült” ötletekhez, miközben felfelé mozgathatja a felhasználói történeteket, amelyek tükrözik a termék alapvető funkcionalitását. Az egyes iterációk, fázisok vagy verziók hatókörét meghatározó “vágott vonalak” meghatározása ezután a rendelkezésre álló erőforrások és a csapat sebessége kérdése.
nagyszerű felhasználói történetek írása
a formátum egyszerű, a történetek írása egyszerű. De a nagyok írása kissé trükkös lehet. Íme néhány iránymutatás, amelyet figyelembe kell venni:
felhasználói történetek ≠ feladatok
A felhasználói történetek nem feladatok., Valójában egy történetnek több száz egyedi feladatra lehet szüksége a sikeres kézbesítéshez. A feladatok a megvalósításról szólnak; a felhasználói történetek a meghatározásról szólnak.
a történetek összeállításakor összpontosítson arra, hogy tisztázza a termék jellemzőit — a mi, nem a Hogyan.
Stay high-level
magas szintűnek, de pontosnak és pontosnak is kell lennie. A történeteknek egyszerűnek és szilárdnak kell lenniük. Ez segít a csapat tagjainak és az érdekelt feleknek mélyen megérteni a felhasználói igényeket, és elkerülni, hogy időt töltsenek a kulcsszavak, terminológia és mozaikszavak tisztázására. Csak használjon egyszerű és pontos nyelvet.,
értsd meg a felhasználók
meg kell felfedezni, illetve tanulmányozza a valódi felhasználók a termék-elfog a profilok, nézőpontok, elvárások, valamint a kapcsolódó ” fájdalom pontokat.”A felhasználói kutatás és más technikák betekintést generálhatnak, hogy jobban megértsék a felhasználókat és azok igényeit.
a technikáktól függetlenül szükség van a kulcsfontosságú felhasználók készletére — ideális esetben personas formájában—, mielőtt elkezdi összeállítani a felhasználói történeteket.,
Think as a user
The <mint egy adott felhasználói osztály/ persona /szerep> A felhasználói történet egy része meghatározza a szöget, a perspektívát — hogyan érzékeli az adott felhasználó a történetben foglalt funkciókat.
Ez kritikus fontosságú — a termék tulajdonosának és az egész csapatnak a felhasználó szemszögéből kell gondolkodnia, és meg kell értenie a mögöttes igényeket és a várható értéket.,
Think big
amikor egy terméket felhasználói történetek hátralékaként ír le, nincs jó ok arra, hogy gondolkodását költségvetéssel, idővel, megvalósíthatósággal vagy költséggel korlátozza.
a jó gyakorlat az, hogy nagynak kell gondolkodni, és hagyni, hogy az “őrült” felhasználói történetek bekerüljenek a lemaradásba. A kiterjesztett termékhátralék fenntartásának adminisztratív költsége kicsi; az abból származó érték — a termék tisztasága, látása és lehetőségei szempontjából — hatalmas.,
használja epics
Epics is formájában magasabb szintű történetek, amelyek leírják a nagy darab funkcionalitás-ezek általában szükség jelentős mennyiségű munka, több Sprint. Az epikusok gondolkodásának másik módja a kapcsolódó, kisebb történetek csoportosítása/ konténerei, amelyek mindegyike közös célt szolgál. Az eposzok jók a történeteik rendezésére és a Nagykép megteremtésére.,
ne dobja el — rangsorolja helyett
mivel egy hatékony prioritási folyamat, ez jó gyakorlat, hogy folyamatosan gazdagítja a termék lemaradás új felhasználói történetek, leíró új felhasználói interakciós forgatókönyvek, “véletlen ötletek,” vagy a kimenet a termék innovációs tevékenységek.
a lehetséges zaj kezeléséhez megfelelően csoportosítania kell az új bejegyzéseket. Mindenesetre ne szűrje ki/dobja ki az elemeket a lemaradásból: a lefedett elemeket általában elfelejtik, míg a prioritást nem élvező elemek felfedezhetők, és a megfelelő feltételek mellett relevánsak lehetnek.,
a kontextustól függően a felhasználói történetek rangsorolása trükkös folyamat lehet. Meg kell becsülni az értékét minden történet, a felhasználó számára, valamint az üzleti. Meg kell méretezni a komplexitás, megbecsülni a megvalósíthatóság, valamint a költség/erőfeszítés szükséges építeni, majd engedje el a funkciót. Be kell, hogy azonosítsa a kereszt-függőségek a lemaradás-érvényesítése konkrét rendelés között bizonyos bejegyzéseket.
Setup for success-not just acceptance
a csapatok gyakran meghatározzák a felhasználói elfogadási teszteket és a kapcsolódó elfogadási kritériumokat. Az elfogadás azonban nem elég-be kell állítania a sikert., Termékmenedzserként több kell, mint annak megerősítése, hogy “úgy működik, ahogy kellene “vagy” a specifikációk szerint.’
olyan metrikákra van szükség, amelyek a közvetlen felhasználói visszajelzésekhez is kapcsolódnak, rögzítve, hogy mennyire boldogok és elkötelezettek a valódi felhasználók. Míg az elfogadás jó, hogy ellenőrizzék a fejlesztési életciklus a funkció, siker körülbelül közép – / hosszú távú hatása, értéke létre a valós felhasználók számára a termék. Meg kell határozni mind-a termék és / vagy epikus és / vagy történet szinten.
tag történetek, metaadatok hozzáadása
komplex termékek több száz felhasználói történetet igényelnek., A könnyebb navigáció és adminisztráció érdekében hatékonyan kell megnevezni, kategorizálni és címkézni a történeteit. A történet első néhány felülvizsgálata után kerülje el a leírás átnevezését vagy drasztikus megváltoztatását, mivel ez zavarokat és hiányosságokat okozhat a csapatban.
A történetek metaadatainak megfelelő kezelése-állapot, haladás, linkek, prioritások, erőforrások stb. – segít felfedezni, figyelemmel kíséri, és megérteni a lemaradás.
ne ragaszkodjon a ragadós jegyzetekhez!,
igen, a fal tele színes sticky notes néz ki, és segít a csapat tűnik elfoglalt és produktív 🙂 de szüksége van egy komoly rendszer és speciális eszközök segítségével megfelelően kezelni, gazdagítani, rangsorolni és megosztani történeteket.,
különleges esetekben, például egy brainstorming, vagy gondolatok ülésen, az rendben van, hogy elfog az első felhasználó történetek segítségével sticky notes—feltéve, hogy akkor dokumentum őket a megfelelő termék irányítási rendszer. Ha nem, és csak ragacsos jegyzeteken tartja a történeteit, akkor valószínű, hogy az egyértelműség, az innováció, a hatékonyság és az együttműködés szempontjából kihagyja a lehetőségeket.,
még mindig szüksége van specifikációkra
a jól definiált felhasználói történetek rangsorolt sorozata nagyszerű, de ez csak a kezdet. A csapatnak elemeznie kell a történeteket — technikai szempontból—, és meg kell teremtenie a szükséges technikai leleteket.
ideális esetben a történetek olyan speciális dokumentációhoz vannak leképezve, amely szoftvermérnöki szempontból biztosítja az összes szükséges technikai részletet. A részletes műszaki specifikációs dokumentumokhoz és egyéb részletes tárgyakhoz a belépési pontokat biztosítják.,
vizualizáció segít
egy mindig (digitális) vizualizáció a kiemelt felhasználói történetek kategória, téma, vagy epic rendkívül hasznos lehet az együttműködés és összehangolás között csapatok és az érdekeltek. A statisztikákkal, kérdésekkel, blokkolókkal és előrehaladási mutatókkal együtt a történettérkép interaktív képernyőkön is megjeleníthető az együttműködési térben.
felhasználói történetek egy nagyszerű módja annak, hogy gyorsan, pontosan leírja a funkcionalitás egy szoftver termék vagy rendszer., Nagyon hatékonyak a brainstorming ülések, a tervezési sprintek, a hackathonok és más innovációk által vezetett folyamatok kimeneteinek rögzítésében is, ahol az ötletek áramlását kompakt, strukturált módon kell rögzíteni.