Ideális világban, felhasználói történetek készítésének alapjaként, vevői munkám van (kereslet, problémák/lehetőségek kutatása) munkakörök formájában. A felhasználói történetek a megoldás (ajánlat) meghatározása.
Az üzleti kérések kezelése felhasználói történet formájában az árok módszer húsa. Megtanulni jól megírni a felhasználói történeteket, ez egy kicsit fáj, de megéri, és célom az, hogy ebben a formában nyilvántartást vezessek, és nem korlátozódhat egyetlen speciális munkára sem (üzleti elemző vagy terméktulajdonos), hanem arra, hogy eszköz lehessek bennük mindenki (érintettek, felhasználók, fejlesztők) keze.
Hogyan lehet minőségi felhasználói történetet írni
Felhasználói történet
A felhasználói történetírás fő célja a kérdések megválaszolása:
1) akire a szükség vonatkozik
2) amire kifejezetten szüksége van
3) miért van rá szüksége
Ez az egyszerű jelölés hatékony módja annak, hogy információt közvetítsen arról, hogy milyen elvárásokkal rendelkezik (mire képes legyen a szoftver).
A projekt születésében betöltött szerepek és kapcsolatok azonosítása segít abban, hogy teljes értékű felhasználói történeteket tudjak írni, ez az alapkő, amely köré a felhasználói történet kerül. A szerepeket külön cikkben részleteztem.
Az egyik mnemonikus segédlet, amely segít a minőségi felhasználói sztori gyakorlati jelölésében, az INVEST rövidítés, amely egy sor attribútumot képvisel:
- Én - független
- N - alkuképes
- V - értékes
- E - becsülhető
- S - kicsi
- T - tesztelhető
A felhasználói történet olyan konstrukció, amelynek teljesítése lehet (szórakoztató) (N). A szállítás során megpróbálom minimalizálni az egyéb függőségeket (I), üzleti értéket hozok az ügyfél számára (V), előnyös, ha a kérdéses funkcionalitás a lehető legkisebb (S), hogy a lehető legpontosabban becsülhető legyen (E) és tesztelhető legyen (T).
Valószínűleg eredményes, kevésbé gyümölcsöző, de forró vitákat folytathatunk erről a mozaikszóról. Egyébként jó eszköz arra emlékezni. Általában úgy működik, hogy először elkészíti a felhasználói történet durva változatát, és elküldi az INVEST-nek.
Elfogadási feltételek
Az elfogadási kritériumok részletezik a specifikációt, és eltávolítják a kétértelműséget, amely a felhasználói történet megírásának egyszerűségéből fakadhat. Az elfogadási kritériumok hasznos listaként szolgálnak annak ellenőrzésére, hogy teljesülnek-e a követelmény elvárásai.
Ha az elfogadási kritérium túlságosan bonyolult büdös, akkor meg kell vizsgálni, hogy az általa szolgáltatott érték nem vonható-e be külön felhasználói történetbe (felosztás, I, V és S alkalmazás az INVEST rövidítésből).
Az elfogadási kritériumok részletesebben meghatározzák, hogy a felhasználói történetnek mi legyen a feltétele. Semmi sem akadályozza azonban, hogy mit ne tegyen a felhasználói történet az elfogadási kritériumok között (ez sokszor irányíthatja a programozó törekvését, hogy belefúrjon a nyúllyukba).
Az interneten nagyon sok elmélet található az INVEST-ről, a felhasználói történet alapszerkezetéről, szerepekről (emberekről) vagy elfogadási kritériumokról. Hozzáadnék néhány bevált ajánlásomat, amelyeket megszoktam hozzáadni a felhasználói történethez. 🙂
Status quo
A jelenlegi helyzet, probléma, kihívás leírása. Kontextualizálás a lehető legjobban. Az aktuális megoldás leírása erre az igényre, ha létezik megoldás (általában igen). Ez az egész szósz megadja a megoldónak a problémát, amellyel szembesül. Mivel szakterületünk a megoldás, a programozónak a zöld táblából kell a legjobban megközelítenie az ügyfél elvárásait, amelyeket így formalizálnak (írja le).
Itt már szalmát csépelek, de ha segíteni akarok az ügyfélnek az átalakulásban (valahol van, és máshol akar lenni, jobb helyen, mint most), akkor tudnom kell, honnan tart.
Étvágy/időzítő
Vágyam ennek a követelménynek vagy időmérőnek a megoldására segít megmutatni, hogy mennyire hajlandó vagyok elfogadni a megkerülő megoldásokat (vagyis jelenleg nem szeretnék tökéletes megoldást, ez ideiglenes megoldás).
Referenciaanyagok
Valamilyen vad specifikus képlet leírása, amely szerint elvárom, hogy az alkalmazás értékelje az üzleti szabályt (pl. A tárolási napok számának kiszámítása, vagy az értékcsökkenés várható összege a naptári időszak végéig), hatékonyabban szemlélteti: kiegészítő Excel kritériumok).
Nyitott kérdések
A jövőbeli megoldás dokumentációjának születésekor gyakran megválaszolatlan kérdések merülnek fel, amelyeket tanácsos konzultálni a szakterület szakembereivel vagy az automatizálni kívánt folyamatok tulajdonosával. Miután néhány kétértelműség villant fel a fejünkön, nem célszerű azokat leírni és helyet találni a válaszra. Ezeknek a kérdéseknek a megválaszolása után is jó megtartani őket a válaszokkal referenciaként (ismét segítenek a felhasználói történetet tágabb kontextusba helyezni).
Ha ismerem az ügyfél hipotéziseit, sejtéseit és igazoltan ellenőrzött számokat, és van lehetőségem (korábbi adatok), akkor ezt érdemes megtenni. Ez segíthet feltárni az ügyfél által jelzett súlyosságot (fájdalmat). Előfordul, hogy a probléma súlyosságát nem erősítik meg, vagy az adatok megfelelőbbek a megoldás irányításához.
Drótkeret
Egy kép jobb, mint ezer szó. Az ajánlás az, hogy a drótváz csak azt foglalja keretbe, amire gondolok. Tudatosan minimalizálnunk kell a részletekre való törekvést. A megoldás részleteit a tervezőre/UX személyre kell bíznom (ha ilyen formális vagy informális megoldásaim vannak).
A felhasználói történet hatékony módszer az üzleti követelmények dokumentálására. A felhasználói történetek listája (felhasználói történetek indexe) hatékonyan válaszolhat a kérdésekre még akkor is, ha a szoftver már kiszolgálja a felhasználókat - ez praktikus dokumentációvá válik.
Ivan Krištof
segít a szoftverprojekt menedzsereknek megfelelni az üzleti elvárásoknak
Diéta lemaradás
Hogyan lehet megszelídíteni a digitális szörnyeket, és hol várnak ránk? Egy kis történet…
A szoftver elfogadása nem ingyenes
A szoftver elfogadása nem ingyenes, a jelentõs szellemi energiába kerül, aki feliratkozik arra, hogy amit nekik (sokszor sok pénzért) eljuttattak, az elvárt módon mûködik.