Valószínűleg veled is előfordult már, hogy túl hosszúra vagy nehézkesre sikeredtek a user sztorik. Részt vettünk a Protechtor Haladó User Sztori tréningjén, amiből szeretnénk kiemelni nektek a szerintünk leghasznosabb ötleteket, praktikákat, konkrét gyakorlati tippeket. Cikkünkkel szeretnénk segíteni neked abban, hogy csapatod hasznosabb sztorikat készíthessen.
Szintén a témához kapcsolódik a ,,Hogyan készüljön a Te user sztorid” tréningünk, amit érdemes meghallgatni.

Helyezzük kontextusba a témát: Agilitás =J.P.É

Készítsük elő a terepet. Agilitás = J.P.É, azaz ,,Józan paraszti ész”. Mit is értünk ez alatt? Ha dolgozunk valamin, és a zsigeri érzéseink azt mutatják a technikákról, lépésekről, hogy nem igazából hasznos és kezelhető, akkor valószínűleg nem tévedünk. Használjuk! A folyamatok és szabályok ne térítsenek el bennünket. A hasznosság azt jelenti, hogy minden sztori segít bennünket a becslésben, a tervezésben és a megvalósításban. Fontos figyelembe venni, hogy nem szabad mindig a nagykönyvhöz ragaszkodni, sőt általában érdemes is eltekinteni tőle attól függően, hogy az általunk használt technológiákhoz hogyan tudjuk azokat hangolni. Tudatosan kell használni, a megfelelő lazasággal/merevséggel. Mi is ezt fogjuk tenni a cikkben, személyes tapasztalatok alapján.

De milyen akkor a jó user sztori, és hogyan küszöböljük ki a problémákat?

A user sztori definíció alapján tulajdonképpen a termék képesség leírása. Ezt finomítsuk picit: a user sztori elérendő dolog, amihez célt tudunk párosítani. Asszociálni tudjuk valamilyen értékhez. Ezt nehéz elképzelni, sok módon felfogható: mekkora örömet okozunk a felhasználónak, melyik ad számára több értéket, mivel segíti őt. A megfelelő sztori jól kommunikálható, egyértelmű. Az érintett és a fejlesztő számára is kifejezi a cél és érték közös, kölcsönös megértését. Kellően rövid idő alatt megvalósítható ahhoz, hogy a felek visszacsatolást tudjanak adni egymásnak.

Vannak váratlan helyzetek, technikai problémák: gyakori reakció ilyenkor, hogy kevesebbet tesztelünk, kevesebbszer nézzük át egymás kódját, kevesebb dokumentációt állítunk elő, így esik a minőség. Ha ez bizonyos szint alá esik, akkor a termék és a projekt is bukik. Ezt a határt gyakran nem is látjuk, csak a visszajelzésekből vesszük észre. Hogyan bánjunk ezzel? A J.P.É szemlélet fog nekünk segíteni. A megfelelő technikai kompetenciára ugyan szükségünk van, ugyanakkor együtt kell dolgozni ahhoz, hogy a terméket le tudjuk szállítani. Azonban a sok együtt dolgozó ember nem feltétlen jelent együttműködést, mi több, akár ellen is tudnak dolgozni. Valódi csapatmunka úgy érhető el, és úgy lehet egymást erősíteni, ha van támogató szervezet. A csapat körül olyan kontextusnak kell kialakulnia, ami segíti őt: itt nem anyagi javakról, hanem inkább jó tanácsokról beszélünk. Ahhoz, hogy a következő 7 feltétel megszülessen, a mentális kapcsolókat kell átállítani.

  • A világot az érintettek nézőpontjából vizsgáljuk.
  • Az értéket teremtő képességek megvalósítása.
  • Érintettek visszajelzése: gyakran új változatokat szállítunk.
  • A minőség fenntartása ugyanolyan fontos mint a képességek leszállítása.
  • Egy fecske nem csinál nyarat: igazi érték a csapatmunka.
  • Kicsi, önszervező csapatot alkotunk: együtt sírunk, együtt nevetünk.
  • Főkapcsoló: igény és törekvés a folyamatos tanulásra. Nem félünk a hibák elkövetésétől, tanulunk azokból. Az viszont probléma, ha nem tanulunk a hibákból, és folyamatosan elkövetjük újra és újra azokat.

Meg kell küzdeni a kihívásokkal!

A létrehozásnál kihívásokkal is meg kell küzdenünk. Fontos feltenni magunknak a kérdést, hogy készen állunk-e már a sztori leírására. Ugyanis lehet, hogy vannak olyan kérdések, amiket nem tudunk még megválaszolni. Bizonyos kockázatokat tudunk-e kezelni, technológiai elemeket értjük-e? Legyen egy ,,sprint ready” fogalom rendszerünk, hogy tudjuk, mikor állunk készen a megvalósításra.

További kihívás annak eldöntése, hogy elkészültünk-e már a sztorival. Ami nehezíti a terepet, hogy folyamatosan változó exit kritériákkal állunk szemben, így olyan megoldást kell választani, aminek a segítségével a sztorit értelmes módon le tudjuk zárni. Ha ezt mégse tudjuk kijelenteni, akkor fontos, hogy pontosan meg tudjuk mondani, mi hiányzik még belőle. A jó csapatok energiát fordítanak arra, hogy meg tudják mutatni, hogy készen állnak a sztorival, befejezték.

Milyen információkra támaszkodhatunk mindehhez?

Dokumentumokra (specifikációkra, tervekre, levélkígyókra) és élő prezentációra (workshopokra, értekezletekre vagy arra, ha leülünk kávézni valakivel). Utóbbira helyezzünk kiemelt hangsúlyt, hiszen az élő kommunikáció esetén azonnal vissza tudunk kérdezni, előbbinél elesünk ettől a lehetőségtől. Az offline forma nem tudja ugyanazt a hatékonyságot adni, mint az élő dialógus. Ha már tudjuk, hogyan kommunikáljunk, és megvannak az információ forrásaink, felmerül a kérdés, hogy kivel tegyük mindezt. Akik a legtöbb inputot adják, akiknek nagy az érintettségük: kulcsfigurák, érintettek. Akinek alacsony az érdekeltsége, őket tájékoztatni kell. Azonban gyakran kiderül az is, hogy az alacsony érdekeltségű személyeknek jelentősebb a befolyása vagy jobban érintettek, mint az elsőre gondoltuk, így sok értéket tudnak adni a user sztori elkészítésének folyamatához.

Hogyan kommunikáljunk?

Értsük meg a célokat és találjunk alternatívákat. Ez lehetőséget ad arra, hogy több megvalósítási tervet is átbeszéljünk. Ha nincs ilyen, akkor valamilyen megközelítési, elérési dolgot kell találnunk, aminek nyomán el tudunk indulni. Minden alternatíva egy hipotézis, ami alapján úgy gondoljuk, ha ezt a valamit valamilyen módon megvalósítjuk, akkor azok segítenek céljainkat elérni. Forint tízmilliókat lehet elkölteni olyan rossz alternatívára, ami kezdetben ígéretesnek látszott, de egy rövid gondolatmenettel rá lehetett volna jönni, hogy nem olyan tökéletes, mint annak tűnt.

Ha már megvannak az információk, kérdés, hogy ki készítse el a sztorikat. Számos tévhit, félreértés kapcsolódik ehhez. A PO lenne a felelős a megfelelő backlog elemekért, a sztorik tartalmáért? Nem feltétlenül. Tapasztalataink szerint a jó sztorik ott készülnek, ahol a csapat és valamilyen kulcsérintett is szerepet vállalnak, és az ő együttműködésükkel alakulnak ki azok. Ha egy csapat 4-5 órát beleöl a jó sztori tervezésébe, az többet ér, mint 4-5 óra eltöltése magával a megvalósítással. Miért? Azért, mert sokkal nagyobb műszaki adósságot fogok elkövetni a megvalósítás során megfelelő tervezés nélkül, ami csak később fogja felütni a fejét.

Milyen a jó backlog?

Ha van egy feladatlistánk, sokszor nehéz eldönteni, hogy adott tevékenységet már elvégeztük-e. Készen van? Erre való a backlog, ami rendkívül hasznos eszköz. A backlog olyan mint egy jéghegy. Csak a csúcsa látszik ki, de jelentős része valahol a felszín alatt van. A vízvonal alatti backlog jelentős része túl nagy, ezekkel még foglalkoznunk kell.
Az egészséges backlog esetében azok, amik kilátszanak a vízből, teljes egészében sztoriknak nevezhetők. Ezekkel tudunk elkezdeni dolgozni. Azonban itt figyelni kell arra, ha ez túl sok, akkor a csapat folyamatosan el lesz telítve azzal, hogy ezeket a sztorikat kezelje, ezért az egészséges sztori jéghegy csúcsán való része pici.
A vízvonal alatti részből kell információkat, vagyis sztorikat kinyernünk. Konkrét dolgokat kell elővenni, amivel el tudunk indulni. Erre szükségünk van a hasznos munkához. Ha nincs támpontunk, akkor kérdezzük meg az érintetteket, vagy a fejükkel gondolkodva találjuk ki, mi lehet számunkra értékes, mik a bizonytalan vagy kockázatos dolgok. Próbáljunk meg vízvonal feletti bejegyzéseket is készíteni.

Ezt még vidd haza magaddal!

A legjobb, ha a sztorik elkészítését minél hamarabb elkezdjük. Nem baj, ha hibákat követünk el, ebből lehet tanulni. Jó tanácsok:
Gyakori hiba, hogy a sztori formájára helyezzük a hangsúlyt, sablont próbálunk keresni rá. Ez azt mutatja, hogy a sztori szerepe nincs megfelelő helyen a szervezetben, hiszen nem ismertük fel az értékeit. A fókusz a sztori tartalmán, és nem a formáján kell, hogy legyen.
Rossz induló sztori jelölteket választunk. Túl nagy méretűeket. Ezt úgy értjük, hogy a csapat áttekintő képességéhez képest túl nagy sztorit választunk.
Sztorinak látszó dolgot választunk, aminek pici a felhasználó értéke.

A kezdő csapatokat úgy támogathatjuk, ha biztosítunk valakit, akitől a csapat tagjai tanulhatnak. Legyen a tanulás is a fókuszban az egyéb projekttevékenységek mellett. A sztori készítése nem a cél, hanem egy nagyszerű eszköz a kommunikációra. Ne azért gyárts sztorikat, mert kell, hanem mert segítik a csapat munkáját. Mert miért is akarnánk cél és érték nélküli dolgokkal foglalkozni ugyebár!