az Egyik legnagyobb kihívás a szoftver fejlesztés, a szinte lehetetlen feladat összejövetel egyértelmű követelményeket aztán, hogy azok a követelmények, változatlan marad során kód fejlesztés. A vízesés megközelítése szoftver fejlesztés—annak ellenére, hogy erőfeszítéseket kell meghatározni, dokumentum, valamint jóváhagyja minden lehetséges készenléti előtt fejlesztési kezdődik,—a szállított termék ritkán, amit az ügyfél akar.
az agilis alternatíva? Felhasználói történet létrehozása.,
a szoftverfejlesztés agilis megközelítésének egyik legnagyobb előnye, hogy a követelmények nem kőbe vannak rendezve, hanem várhatóan megváltoznak, az érdekelt felek és az üzlet folyamatos visszajelzésével. Agilis módszerek, például a Scrum, valamint az extrém programozás (XP) helyettesíti a hagyományos, hosszú követelmények dokumentumok egy kiemelt termék backlog készült tömör felhasználói történetek, amelyek részletei jelennek közelebb, amikor a történet végrehajtható.,
bár a felhasználói történet létrehozása inkább művészet, mint tudomány, Ez a bemutató megadja azokat az információkat, példákat és lépéseket, amelyekre kiváló minőségű felhasználói történeteket kell létrehoznia.
A felhasználói történetek története
XP először 1998-ban vezette be a felhasználói történetek fogalmát, összehasonlítva azokat a használati esetekkel. Az objektumorientált szoftverfejlesztésben: a használat Esetvezérelt megközelítésben Ivar Jacobson bevezette a felhasználási eseteket a követelmények dokumentálásának módjaként egy szerep (a rendszert használó személy) és maga a rendszer közötti kölcsönhatások meghatározásával, hogy elérje a célt az egységes modellezési nyelv (UML) segítségével.,
Ez a megközelítés népszerű volt az objektumorientált fejlesztésben, és továbbra is kulcsfontosságú folyamatként használják a szoftverfejlesztési keretrendszerekben, mint például az Unified Process (UP), az IBM Rational Unified Process (RUP), valamint az Oracle Unified Method (OUM). A használati esetek használata a felhasználói történetek helyett iteratív és inkrementális fejlesztést tesz lehetővé, és a követelmények meghatározásának agilis megközelítése.,
a sokkal rövidebb felhasználói történetek bevezetésével, valamint az XP és Scrum népszerűségével a felhasználói történetekből álló termékhátralék lett az agilis követelmények meghatározásának általánosan ismert megközelítése. Sok gyakorló még mindig úgy gondolja, hogy a felhasználói történetek az egyetlen elfogadható agilis megközelítés. Alistair Cockburn, az agilis Manifesto egyik aláírója azonban inkább a használati eseteket részesíti előnyben a felhasználói történetekkel szemben.
bár rengeteg erős vélemény van az “agilis” jelentéséről, mind a használati esetek, mind a felhasználói történetek kompatibilisek ezzel a megközelítéssel., Egyesek szerint a felhasználói történetek végül hasonlóak lesznek a használati esetekhez, miután a csapat egyetért a végrehajtás részleteivel. A korai szakaszban, a felhasználói történet egyszerűen egy rövid mondat,de ez nem teljes, amíg a részletek és elfogadási kritériumok meghatározása.
felhasználói történetek létrehozása
különböző vélemények vannak a felhasználói történet meghatározásáról, valamint arról, hogyan lehet a legjobban létrehozni egyet., Néhány iránymutatást egy jó felhasználói történet a következők:
- legyen írta valaki, hogy ki képviseli az üzleti felhasználók (általában a termék tulajdonosa)
- Ez kezdetben kell tartalmaznia rövid leírása a “ki, mit, miért,”de nem a “hogyan”
- Ez kell készítenie egy függőleges szelet működő kódot
- legyen elég kicsi ahhoz, hogy be lehet kódolni a gyakorlatban egy iterációs (rendszerint egy-négy héten belül)
a Különböző sablonok, technikák, valamint a rövidítések használata segít a termék tulajdonosok írni felhasználó történetek., A három leggyakoribb módszer a szerep-funkció-ok sablon, A három C (kártya, beszélgetés, megerősítés), és INVEST (független, forgatható, értékes, becsülhető, kicsi, tesztelhető).
példák
azt mondják, hogy olyan alkalmazást fejleszt ki, amely lehetővé tenné az oktatók számára, hogy feltöltsék a tanfolyamokat, és vonzzák az osztály iránt érdeklődő hallgatókat. Itt van, hogyan alkalmazná a felhasználói történet technikákat.,
szerep-funkció-ok
ahogy Mike Cohn a Mountain Goat Software magyarázza, a szerep-funkció-ok sablon, vagy RGB (szerep, cél, haszon), úgy néz ki, mint ez:
“mint egy Azt akarom, hogy .”
bár vannak variációk, ez a rövid mondatszerkezet a who-ra, mi-re és miért összpontosít. Ez megakadályozza, hogy a termék tulajdonosa túl sok információt adjon a Fejlesztőcsapatnak arról, hogyan kell megoldást megvalósítaniuk. Azzal, hogy a fejlesztőcsapat arra koncentrál, hogy ki, mit és miért, felhatalmazást kap arra, hogy megtalálja a legjobb technikai megoldást.,
1. példa: adjon meg egy edzőt azzal a képességgel, hogy edzőként adjon hozzá egy kurzust
, Szeretnék új kurzust hozzáadni, hogy lehetőségem legyen új hallgatók vonzására.
2. példa: adjon meg egy hallgatónak azt a képességet, hogy diákként keressen egy kurzust
, szeretnék keresni a tanfolyam kínálatát, hogy megtalálhassak egy olyan ajánlatot, amely a leginkább érdekel.
a szerep (who)
a szerep leírja, hogy ki részesül ebből a funkcióból. Figyeljük meg, hogy a szerep nem egyszerűen “a felhasználó.,”Különböző típusú felhasználók vannak, ezért azt akarjuk, hogy a szerep pontosabb legyen, mint a “felhasználó”, de írja le a felhasználó típusát, amely előnyös lesz a történetből. A terméktulajdonosok gyakran feladata, hogy a felhasználók elméjébe kerüljenek annak érdekében, hogy megértsék, mi lenne a legértékesebb számukra.
példa 1 Role = trainer
példa 2 Role = student
a funkció (mi)
Ez a lépés nagyon röviden leírja, hogy mit akar a felhasználó. Ez leginkább azt a követelményt képviseli, amelyet a hagyományos szoftverfejlesztésben ír le., Ugyanakkor óvatosnak kell lennie, hogy ne legyen túl konkrét, vagy írja le, hogyan kell írni a kódot. Ez végül meg lesz határozva, de nem akkor, amikor először létrehozza a felhasználói történetet. A felhasználói történetet annak a Felhasználónak a szemszögéből kell írni, aki részesül a funkcióban, nem pedig a fejlesztő szemszögéből, aki kódolja.
1. Példa Feature = új irányt
2. Példa Feature = keresés a tanfolyam ajánlatok
Az ok (miért)
Végre, azt akarjuk, hogy az állam miért a felhasználó akarja ezt a funkciót. Milyen értéket kap a felhasználó?, Ez segít a termék tulajdonosának értékelni, hogyan kell rangsorolni a felhasználói történetet a lemaradásban. Ha az értéket vagy hasznot nem lehet csuklós, lehet, hogy valami, ami nem szükséges. Az érték megértése gyakran segít a Fejlesztőcsapatnak innovatív módszereket találni a kód végrehajtására annak érdekében, hogy megoldja azokat a objektív módszereket, amelyek eltérhetnek attól, amit a termék tulajdonosa szem előtt tart.,
1. példa ok = új diákok vonzása
2. példa ok = keressen egy olyan ajánlatot, amely leginkább érdekel engem
A három C: kártya, beszélgetés, megerősítés
A Ron Jeffries által kifejlesztett három C képlet segít megállapodásra jutni az üzleti és a technikai csapat között a felhasználói történet jelentéséről. A három C végigvezeti őket a progresszív kidolgozása egy történet, egy rövid nyilatkozatot, hogy egy teljesen fejlett felhasználói történet.,
Card
a felhasználói történet szándékosan rövid, egy egyszerű kijelentéssel kezdődik, amely belefér egy 3×5 indexkártyába, általában az általam lefedett szerep-funkció-haszon formátumot követve. Például:
edzőként Szeretnék új kurzust hozzáadni, hogy lehetőségem legyen új hallgatók vonzására.
beszélgetés
bár a felhasználói történet egyszerű kijelentésként kezdődik, a részleteknek meg kell jelenniük, mielőtt a csapat elkezdi dolgozni a történetet., Ahelyett, hogy leírná, mi szükséges a dokumentációban, a csapat magában foglalja 1) képviselet az üzleti (általában a termék tulajdonosa), és 2) maga a fejlesztő csapat, beleértve a fejlesztők, tesztelők, üzleti elemzők, vagy bárki más a csapat.
Ez a beszélgetés lehetővé teszi a fejlesztő csapat számára, hogy kérdéseket tegyen fel annak érdekében, hogy világos képet kapjanak arról, hogy mit kérnek és milyen értéket biztosítanak. Például:
Fejlesztő: az edzőnek fel kell töltenie a tanfolyamot egy webhelyre?,
Terméktulajdonos: nem, a tréner csak információkat ad hozzá a felkínált kurzusról, és a szolgáltatásnak tartalmaznia kell egy módot arra, hogy a hallgató bekerüljön az érdeklődési listára. Ez a történet lehetővé teszi az edző számára, hogy hirdessen egy tanfolyamot.
Fejlesztő: milyen mezőket kell tartalmaznia?
Terméktulajdonos: tanfolyam címe, absztrakt, dátumok és idők, hely.
Fejlesztő: ez csak a személyes osztályok reklámozására szolgál?
termék tulajdonosa: Igen., Lehet, hogy később hozzáadunk egy virtuális osztály opciót, de ez a történet csak a személyes osztály-ajánlatok tanfolyam-információinak hozzáadására terjed ki.
Fejlesztő: milyen információkat kell összegyűjteni, amikor egy potenciális hallgató kéri, hogy kerüljön egy érdeklődési listára?
termék tulajdonosa: név, telefonszám és e-mail cím.
a csapat frissíti a felhasználói történetet a beszélgetésből összegyűjtött információkkal, és megvitatják a végrehajtást—vagy a “Hogyan”—t, amely gyakran konkrét feladatokat hoz létre, amelyeket meg kell tenni a történet befejezéséhez., Bár a felhasználói történet a felhasználó szemszögéből íródott, a fejlesztőcsapat megírja a fejlesztőknek szánt feladatokat, és tartalmazza a technikai megvalósítás részleteit is.
megerősítés
a Fejlesztőcsapatnak tisztában kell lennie azzal, hogy a szolgáltatás hogyan fog működni különböző helyzetekben, beleértve a hibafeltételeket is. A termék tulajdonosának meg kell erősítenie az elfogadási kritériumokat. Ezek azok a kritériumok, amelyeket teljesíteni kell ahhoz, hogy a történetet megvalósítottnak és elfogadottnak lehessen tekinteni., Íme egy példa az elfogadási kritériumokra:
- egy oktató képes új kurzust hozzáadni a kurzus címének, absztraktnak, dátumoknak és Időknek, valamint a helynek az űrlaphoz való megadásával, majd nyomja meg a “tanfolyam hozzáadása” gombot.
- ha bármelyik mező hiányzik, vagy a dátumok vagy idők érvénytelenek, hibaüzenetek jelennek meg.
- miután a tanfolyamot megfelelően hozzáadták, nyilvánosan megjelenik a tanfolyam weboldalán, és lesz egy gomb, amellyel a hallgató kifejezheti érdeklődését.,
- a kamat gomb segítségével a felhasználó megadhatja a nevét, e-mail címét és telefonszámát, ezeket az adatokat pedig tárolja és társítja az új kurzushoz.
INVEST: a solid user story attribútumai
INVEST egy olyan mozaikszó, amely segít felmérni, hogy van-e kiváló minőségű felhasználói története. Itt van, hogy a rövidítés attribútumai hogyan vonatkoznak a történetre, amelyen dolgoztunk.
i = Independent – lehet ezt a történetet befejezni a csapat? Azt akarjuk, hogy a csapat képes legyen befejezni az egész történetet, ahelyett, hogy egy másik csapattól függne például a GUI elvégzéséhez.,
n = forgatható—a történet nem annyira részletes, hogy pontosan leírja, hogy a mezőknek mennyi ideig kell lenniük, vagy adjon részleteket a dátumformátumokról és hasonlókról. Valószínűleg lesznek olyan közös rutinok vagy könyvtárak, amelyek lehetővé teszik a fejlesztői csapat számára, hogy a számukra legmegfelelőbb módon hajtsák végre.
v = értékes-a termék tulajdonosa leírja, hogy a keresett érték az a képesség, hogy a tréner képes legyen hirdetni a közelgő osztályokat. Ez egyértelmű az eredeti nyilatkozat” miért ” című részében, amelyet a beszélgetés során újra hangsúlyoztak.,
E = becsülhető—a csapat elég kérdéseket tesz fel, és összegyűjti a részleteket, hogy magabiztosan tudják becsülni a történetet.
S = kicsi-a csapatnak biztosnak kell lennie abban, hogy Sprinten belül képes lesz befejezni a történetet. Ha nem teszik, akkor megoszthatják a történetet. Például a mi minta történet, úgy dönthetnek, hogy a képesség, hogy összegyűjtse a diák információkat egy másik történet, és egyszerűen megjelenítéséhez információkat az osztály ezt a történetet.
t = tesztelhető-egyértelmű elfogadási kritériumokkal mind a boldog út, mind a hibafeltételek tesztelhetők.,
egy látáshoz igazítva
lefedtem a felhasználói történet létrehozásának alapjait, de még mindig meg kell értenie a nagy képet, mielőtt saját felhasználói történeteket hozna létre. Sok munkát kell tennie elöl, magasabb szinten, annak meghatározásához, hogy mi a legmagasabb értékű szolgáltatás, amelyet az ügyfeleknek kell szállítani. Ezek végül felhasználói történetekké bomlanak.
fontos, hogy a csapat először megértse a magas szintű látást, és meggyőződjön arról, hogy a funkciók, végül a felhasználói történetek igazodnak ehhez a magas szintű látáshoz.,
általában a terméket csoportosításokra bontja, amelyek nevek, például “témák” vagy “jellemzők szerint mennek.”Bár a címke ezek a backlog tételeket eltérő lehet attól függően, hogy az agilis módszer eszközöket használ, hogy leírja őket, az ötlet az, hogy megbizonyosodjon arról, hogy igazítsa úgy, hogy a munka nyomon követhető, akár a látás, amely biztosítja, hogy a találkozó a céljait, értékeit a termék látás.
ismét ne indítsa el a projektet felhasználói történetek létrehozásával; kezdje egy látás létrehozásával., Példánkban egyszerűen bemutatok egy mintakép-nyilatkozatot, amely néhány mintafunkcióhoz vezet, amelyek tovább bonthatók felhasználói történetekké.
Vision
olyan kiváló minőségű honlapot biztosít, amely lehetővé teszi az oktatók számára, hogy reklámozzák a tanfolyamokat, és lehetővé teszik a hallgatók számára, hogy ezeket a tanfolyamokat vegyék igénybe.
jellemzők
- adjon meg egy kurzusajánló oldalt, amely lehetővé teszi a hallgatók számára, hogy feliratkozzanak a kurzusokra.
- adjon meg egy kezdőlapot,amely megmondja a felhasználóknak, hogy mi a webhelyünk.
- adjon meg egy regisztrációs folyamatot, amely lehetővé teszi a felhasználók számára, hogy bejelentkezzenek, létrehozzanak egy profilt, és nyomon követhessék osztályaikat.,
- adjon meg egy blogot, amely segít hirdetni kínálatunkat és népszerűsíteni weboldalunkat.
felhasználói történetek
- biztosítja a tréner számára a tanfolyam hozzáadását a kurzusajánló oldalon.
- a diákok számára lehetővé teszi, hogy keressen egy tanfolyamot.
a fenti példában láthatja, hogy a felhasználói történetek hogyan származtak. A felhasználói történetek egy olyan szolgáltatás részét képezték, amely “tanfolyamot kínál”, amely igazodik a magas szintű látáshoz.,
Impact mapping
bár a látáshoz való igazítás segít a kezdeti lemaradás feltöltésében, ez nem az egyetlen módja ennek. Számos olyan eszköz és technika létezik, amelyet a termékmenedzserek felhasználhatnak az új lemaradásban lévő és a látáshoz igazodó történetek létrehozásához.
az egyik stratégiai tervezési technikát használják, hogy segítsen megérteni a nagy kép, impact mapping, népszerűsítette Gojko Adzic, szerzője ötven gyors ötleteket, hogy javítsa a felhasználói történetek és hatás leképezés: így nagy hatással van a szoftver termékek és projektek., Impact mapping egy elme térkép, amely kezdődik a cél, amely foglalkoznia kell a kérdés, az érték, miért épít a termék.
a következő szint felsorolja a “szereplőket” vagy azokat az embereket, akik segítenek elérni a célt. Ezután a térkép felsorolja azokat a viselkedéseket, vagy “hatásokat”, amelyeket a színészek végeznek e cél elérése érdekében. A térkép végső szintje bemutatja a csapat által megvalósított” teljesítményeket”. Ezek lehetővé teszik és támogatják a szereplőket a kívánt hatások megteremtésében. Ezekből a szállítmányokból származik a szoftver jellemzői és történetei.,
- Cél: Hogy széles körben elérhető kurzusok, hogy a diákok akarom, hogy
- Szereplők: Oktatók, hallgatók
- Hatások: Oktatók nyújt minőségi osztályok érdeke, hogy a diákok; a diákok nyújt áttétel, valamint ajánlások
- Eredmények: minőségi osztályok elérhető, hogy a diákok
- a Lehetséges történetek:
- “, Mint egy edző, azt akarom reklámozni, osztályok, így lehet kapni a diákok.
- ” edzőként visszajelzést Szeretnék kapni a diákoktól, hogy folyamatosan javulhassak.,”
- ” edzőként szeretném megtudni, hogy mit akarnak a diákok, így hozzáadhatom a tantervemet.”
- ” diákként olyan osztályokat akarok találni, amelyek a leginkább érdekelnek.”
- ” diákként olyan osztályokat akarok találni, amelyeket online tudok venni, hogy ne kelljen utaznom.”
- ” diákként szeretnék olvasni másoktól származó véleményeket, hogy eldönthessem, mely osztályok felelnek meg a legjobban.”
A felhasználói történetek ilyen módon történő feltérképezése lehetővé teszi a nyomon követhetőséget annak a gondolkodási folyamatnak a során, hogy a történetek végül hogyan hoznak létre értéket, és hogyan használják őket a végső cél eléréséhez., Az ötlet nem mindent megvalósítani, hanem megtalálni a legrövidebb utat a térképen a cél elérése érdekében.
hasító történetek
az agilis csapatok egyik leggyakoribb problémája az, amikor a történetek túl nagyok, és nem fejezhetők be iterációban. Amikor a csapat létrehozza a történethez kapcsolódó feladatokat, rájönnek, hogy túl sok ismeretlen van, vagy hogy az érintett feladatok több időt vesznek igénybe,mint a csapat egyetlen iterációban. A csapatok ezt néha úgy oldják meg, hogy egy nagyobb történetet kisebb történetekre osztanak.,
ne feledje azonban, hogy azt szeretné, hogy egy felhasználói történet olyan működő szoftvert szállítson, amely értéket ad a felhasználó számára. Ahelyett, hogy olyan felhasználói történetet hozna létre, amely csak részben tölt be egy funkciót, ossza meg a történeteket “függőleges szeletekre”, amelyek végpontok közötti funkciókat biztosítanak.
forduljon a közösség mélyebb tanulás
részletes megoldásokat, hogyan lehet megoldani a legkeményebb problémák kapcsolatos követelmények, felhasználói történetek egyedi minden helyzetben. A sikeres agilis gyakorlók egyik közös vonása azonban az, hogy szívesen segítenek másoknak, és megosztják azt, amit tudnak.,
a Cohn userStories weboldala lehetővé teszi, hogy azok, akik termékhátrányokkal és felhasználói történetekkel dolgoznak, megosszák termékeiket, erőforrásaikat és tudásukat. A termékek oldal tartalmaz egy lenyűgöző eszközök listáját, sok ingyenesen elérhető, lehetőségekkel felhasználói vélemények, bemenet. Cohn megjegyzi az oldalon, hogy reméli, hogy bővítse a helyszínen, így a termék holtjáték lehet osztani.
soha nem lesz egyetlen méretű válasz a tökéletes felhasználói történetek írására., Az idő múlásával azonban, a tapasztalatok egészséges keverékével, a szakértők tanácsaival, valamint a javasolt eszközökkel és technikákkal végzett kísérletekkel, folyamatosan javulhat.