A User Story egy olyan eszköz, mely biztosítja azt, hogy egy fejlesztés során az agilis alapelvek érvényesülni tudjanak, áthelyezve a hangsúlyt a követelmények írásáról a róluk való beszélgetésre. Nyilván tele van az internet azzal, hogy mi is ez és hogyan kell jól alkalmazni, ezért én azt szeretném bemutatni, hogy konkrétan nálunk a Nitrowise Labs-nál hogyan is használjuk ezt az eszközt a fejlesztések során.
Mi is egyáltalán a User Story?
Ha erre a kérdésre egyértelműen tudod a választ, akkor nyugodtan ugord át ezt a részt, a neten tényleg sok ilyen leírás van, viszont annak, aki nem tudja pontosan, annak fontos, hogy tisztába tegyük.
A User Story egy rövid tömör leírása egy funkciónak, annak a személynek a perspektívájából, aki erre az új funkcióra vágyik. Úgy kell ezeket elképzelni, mint rövid történeteket, amiket a felhasználók / megrendelők el szeretnének érni a termék használata során.
Erre általában használunk egy formulát a következő módon:
azt szeretném, hogy < valamilyen elérendő cél >,
azért, hogy < indíték >.
Ahogy látszik, először bemutatjuk, hogy ki az a személy, akinek fontos a később megfogalmazott cél. Ehhez előre egyeztetett perszónákat használunk, így mindenki tudni fogja, hogy kire is gondoljon amikor az adott funkcióról egyeztetünk.
Második lépésben meghatározzuk, hogy mit is szeretne elérni ez a személy. Ez lényegében a kívánt funkcionalitás leírása.
Majd következik a miért is szeretné ezt elérni rész. Annak ellenére, hogy ez a része a formulának hivatalosan opcionális, mégis személyes tapasztalatom, hogy igen fontos eleme, hiszen ez lesz az a része a mondatnak, ami validálja a szükségességét a fejlesztésnek. Általában sokan sokféle funkciót el tudnak képzelni, viszont amikor válaszolni kell arra, hogy de mégis miért fontos / szükséges az adott funkció, akkor sok esetben kiderül, hogy nincs is igazán megfelelő indok / indíték a kért fejlesztésre. Akkor meg miért csináljuk meg, nem igaz?
Ezek a történetek általában ebből az egy összetett mondatból állnak, nagyon világosan leírják, hogy mit és miért szeretnénk elérni. Viszont nem mondja el, hogy pontosan hogyan szeretnénk elérni azt a célt.
Egy User Story-nak kicsinek kell lennie. Ez segíti a feladat méretének becslését, valamit segíti fókuszban tartani a fejlesztő csapatot és kellő rugalmasságot ad, ha változtatni kell a feleadaton. Minél nagyobb egy User Story (értsd: minél több tényleges fejlesztési feladatot foglal magában) annál nagyobb a kockázata annak, hogy a csapattagok elvesznek a részletekben, nem sikerül befejezni a feladatot egy adott iterációban, vagy félreértések történnek. A kérdés tehát az, hogy a kicsi mennyire kicsi? Egy jó ökölszabály, hogy egyetlen User Story-nak sem szabad tovább tartania, mint a Sprint időtartamának fele. Ez például egy 2 hetes Sprint alatt azt jelenti, hogy egyetlen User Story sem tarthat tovább 1 hétnél. És az, hogy kerülhet be a Sprintbe egy hetes feladat, az is kivétel és nem norma. Jellemzően egy User Story fél naptól 2 napig terjedő időkeretben fejleszthető le. Az, hogy ilyen kis egységekre tagoljuk a feladatokat növeli a Sprint-cél elérésének esélyét azáltal, hogy biztosítja, hogy a Story-k a Sprint során elkészüljenek, valamint átláthatóságot és folyamatos visszajelzést biztosít a csapat előrehaladásáról.
Ennek ellenére a User Story írás egyik előnye, hogy különböző részletességgel írhatók le a feladatok és senki nem tiltja azt, hogy elsőre egy nagyobb, több funkciót tömörítő feladatot írjunk le egy összetett mondattal, csak ebben az esetben ezt Epic-nek nevezzük és a fejlesztési projekt során folyamatosan tagoljuk egyre kisebb User Story-kra. A lényeg, hogy a Sprintek kezdetére már tényleg kicsik legyen a Story-k.
Törekedni kell arra, hogy ezek a storyk egymástól függetlenek legyenek, azaz bármikor önállóan fejlesztésbe adhatók a fejlesztőcsapat részére.
Minták User Story-kra:
Én, mint adminisztrátor, azt szeretném, hogy tudjam a rendszerben található felhasználókat inaktiválni, azért, hogy az előfizetésük megszűnését követően már ne férhessenek hozzá a nálunk tárolt adatokhoz.
Én, mint felhasználó, azt szeretném, hogy tudjak jelszót változtatni, azért mert, elfelejtettem a jelenlegi jelszavamat.
Természetesen a fejlesztők elé nem csak ezek az összetett mondatok kerülnek, hanem kiegészítésre kerülnek elfogadási kritériumokkal, nem funkcionális követelményekkel, vagy akár bármilyen egyéb kiegészítő információval a Sprint tervezés előtt.
Innen pedig következzen akkor, hogy milyen is a Nitrowise Labs módi, azaz hogyan használjuk a projektek során a User Story-kat.
Hogyan állnak elő a User Story-k?
Ez projektenként változó és eléggé függ az aktuális megrendelőtől. Most két példát mutatok be a mindennapjainkból megtörtént események alapján. ?
Amikor csak magunknak csináljuk…
Bizony van olyan, hogy nincs kivel érdemben egyeztetni és egy robosztus követelménydokumentációt fordít át a csapathoz rendelt Product Owner User Story-kra és alkot belőle Backlogot a fejlesztő csapatnak.
Látszólag ennek semmi értelme (de minimum az agilis megcsúfolásának tűnik), azonban az a tapasztalatunk, hogy a fejlesztő csapatok sokkal jobban (értsd: gyorsabban, jobb minőségben, pontosabban) valósítják meg a feladatokat, ha nem egy baromi hosszú, száraz, kimért szövegezésű dokumentum alapján fejlesztenek, hanem teszünk abba energiát, hogy lebontjuk a feladatokat (megírjuk a User Story-kat), rendszerezzük őket (Story Map-et, User Journey map-eket készítünk).
Végső soron ezekben az esetekben annyi történik, hogy egy meglévő dokumentációt alakítunk át egy olyan formátumra, amiből mi kényelmesebben tudunk dolgozni. Ha szerencsénk van akkor a megrendelő partner abban, hogy legalább az így előállt feladatlistát validálja, ha nincs akkor is megcsináljuk, mert nekünk könnyebb lesz az életünk. ?
Amikor egy megrendelő partner a közös munkában…
Szerencsére arra is egyre több példánk van, hogy a projekt során a megrendelővel közösen alkotjuk a User Story-kat és a megrendelő aktív partner abban, hogy User Storyk készüljenek, ne pedig egy hosszas követelmény dokumentáció.
Ilyen esetekben általában a részünkről dedikált Product Owner nagyon sokat beszélget a megrendelő munkatársaival (értsd: bárkivel, aki a termék fejlesztéséhez hozzá tud tenni) és ezek alapján a beszélgetések alapján készít folyamatábrákat, nagyvonalú képernyő terveket, amikkel validálja, hogy az elhangzottak alatt mindenki ugyanazt érti-e. Ha igen, akkor elkészíti a User Story-kat, amit aztán a megrendelővel validál, majd finomít, majd rendszerez, majd priorizál… majd újra beszélget, tovább finomít, ismét validál, újra rendszerez… egyszóval közösen alakítja a Product Backlogot az ügyféllel.
Szumma szummárum
Nálunk a csapathoz dedikált Product Owner felelőssége, hogy
- User Story-k legyenek (mindenki ugyanazt értse a feladaton),
- azok karban legyenek tartva (Product Backlog),
- megfelelő méretűek legyenek,
- és priorizálva legyenek.
Ha a megrendelő partner ebben, akkor vele közösen alakulnak ki User Story-k, ha nem, akkor mi önerőből oldjuk meg, azért, hogy a fejlesztőkhöz csak olyan feladat kerüljön, amit jó minőségben el is tudnak végezni.
Mikor állnak elő a User Story-k?
Alapvetően minden projekt indulásakor előáll egy User Story lista (Product Backlog), ami alapján képet kapunk arról, hogy mekkora is az a konkrét projekt.
Azonban a projekt elején még általában nem a végleges User Story-k készülnek el, hanem olyan részletességig megyünk el, amire már megfelelő nagyságrendi becslést tud tenni a csapat. Így képet kapunk arról, hogy mekkora lesz várhatóan a projekt, milyen összetételű (értsd: kompetenciájú) csapattal szükséges nekiindulni és várhatóan meddig is fog tartani. Sőt akár meg tudunk határozni előre mérföldköveket, releasenként elérendő célokat.
A projekt elején leírt User Story-k még nem minden esetben tartalmazzák az összes szükséges elfogadási követelményt és az is lehet, hogy még túl nagyok ahhoz, hogy az adott feladat fejlesztésre adható legyen. Ezek a pontosítások egy projekt során folyamatosan történnek, így, ha változás van a követelményekben nem dobunk ki jelentős mennyiségű munkát az ablakon (részletesen specifikált, de nem szükséges feladatok specifikációra szánt ideje).
Amikor egy User Story eléri a végleges állapotát az a Sprint indulásakor történő tervezés. Ilyenkor minden részlet a helyére kerül. Rögzítünk minden elfogadási követelményt, meghatározzuk mi az, amit az adott feladatba nem értendő bele és szükség esetén a nem funkcionális követelmények is rögzítésre kerülnek. Ezáltal minden fontos információ a rendelkezésre áll ahhoz, hogy a fejlesztők által adott becslés megfelelően pontos legyen és arra vállalást is tegyünk.
Hogyan helyettesítik a User Story-k a robosztus követelmény dokumentumokat?
Projekt elején
Az agilis projektek során (különösen a Scrum projektek esetén) egy Product Backlog-ot építünk, mely azon User Story-k priorizált listája, melyet a termékfejlesztés során kívánunk megvalósítani. Ez egy vízesés projekt során a logikai rendszertervnek (vagy követelmény specifikációnak) felel meg.
Ugyan az induláskor a Product Backlog még közel sem olyan részletességű, mint mondjuk egy logikai rendszerterv (ez tény), ellenben még nem találkoztam olyan projekttel, ahol pontról pontra az került leírásra a projekt elején, mint ami megvalósult (az ezzel kapcsolatos tapasztalatainkat itt foglaljuk össze https://hu.nitrowise.com/masokkal-tortenik-csak-ilyen-projekt/).
Azaz egy projekt indulásakor egy kellő mélységig definiált és vizuálisan szemléltetett (pl.: story map) terv ugyanolyan megfelelő, mint egy több száz oldalon keresztül leírt követelmény specifikáció, sőt nagyobb rugalmasságot biztosít a projekt során a változtatásra, egyáltalán a változtatásra való képességre, vagy a változtatásra fordított erőforrások mennyiségére. Változás márpedig a tapasztalataink alapján mindig lesz.
Projekt közben
Ahogy azt már korábban is írtuk, a projekt során a User Story-k folyamatosan „fejlődnek”, azaz egyre kisebbek, egyre pontosabbak lesznek. Azzal viszont, hogy nem előre, hanem mindig éppen „just in time” állnak össze a Story-k részletes elfogadási követelményei a Sprint indulására, azt nyerjük, hogy már az összes a projekt során összegyűjtött tapasztalatot tartalmazzák ezek a leírások, azaz tényleg az van leírva, ami meg is fog valósulni.
A csapat előtt pedig mindig célra tartóan egy rövid iteráció feladatai vannak, ami segíti a fókuszban tartást.
Projekt végén
Egy agilis projekt során ugyanúgy készülnek dokumentációk, mint egy klasszikus projekt során (adatbázis leírás, architektúra leírás, megvalósult fejlesztések funkcionális leírása, felhasználói kézikönyv, üzemeltetési kézikönyv).
Mi ezt általában úgy csináljuk, hogy a fejlesztés során folyamatosan (de legkésőbb egy adott Sprint végén) frissítjük a dokumentációt, így mindig rendelkezésre áll egy olyan leírás, ami a ténylegesen megvalósult fejlesztéseket pontosan tartalmazza.
A fejlesztés során előálló User Story-k és azok vizuális szemléltetése pedig megkönnyíti a projekt átvételét, vagy akár egy később becsatlakozónak a projekt megértését, hiszen garantáltan az van ezekben leírva, ami végül fejlesztésre került, nem pedig az, amit valaki hónapokkal előre megálmodott.
Összefoglalva
Csapataink most már 5 éves tapasztalattal rendelkeznek abban, hogy milyen az amikor a kacifántosan megfogalmazott követelmény dokumentációk helyett egyértelmű és megfelelően kidolgozott Product Backlogból dolgoznak a User Story-k segítségével. Az a tapasztalatunk, hogy a User Story írásba fektetett munka sokszorosan megtérül. Mióta így dolgozunk
- kevesebb a félreértés (a félreértett megértés),
- jobban nyomonkövethető egy projekt haladása
- motiváltabbak a fejlesztők (gyorsan lezárható kis feladatok, a sokáig tartó végtelen fejlesztések helyett)
- kevesebb az utólagos változtatás
- tényleg az készül el, amit a megrendelő szeretett volna.
Ha kérdésed merült fel, vagy csak szívesen beszélgetnél a fenti témáról, keress LinkedIn-en és írj!
Mindeközben én projekt menedzserből szépen lassan Product Ownerré váltam és a „sikeres” projekt zárás helyett a partnerek elégedettsége, az üzleti érték maximalizálása lett az, ami a mindennapjaimat vezérli.