Gidó Csaba írása.
Harmadik alkalommal gyűlt össze Budapest leg-leg-leg… üzleti elemzőibb közössége, 2022. március 30-án.
A BA-TALK csoportban meghirdetett eseményre jelentkezőkkel egy kisebb csarnok is megtelt volna, de a szervezőket továbbra is a Szimpla Kert VIP terme “insprl”-ta, így az első 40 szerencsés jelentkező tudott részt venni a tartalmas estén. Ráadásul az időben érkezőknek pogi és házi “hógolyó” is jutott, illetve meg is ismerkedhettünk egymással.
A korábbi alkalmakon betekintést kaphattunk, hogy milyen értéket képvisel egy BA az IT projektekben, majd az online térbe kényszerült második alkalommal részletesen megismerhettük a – nemzetközileg is – ismert és elismert minősítéséket, és a tanúsítvány megszerzéséhez vezető rögös utat. Mindkét alkalmat a témákban tapasztalt kollégák segítségével követhettük.
Ezen alkalommal sem hiányozhattak az új ismeretek. Az agilitásból indultunk ki, amellyel már talán mindannyian találkozhattunk. Ismerhetjük előnyeit, rugalmasságát, de sok esetben szembesülünk megvalósítási korlátaival is, leginkább a projektet keretező szerződés “jóvoltából”. Láthattuk, hogy létezik módszer, aminek segítségével megkönnyíthető a projekt komplexitásának felbontása, a prioritások meghatározása, illetve elősegíthető a közös megértés.
Aki pedig mindezt elhozta nekünk, nem más, mint Tamás Árpi, aki maga is sok évet lehúzott BA sapkában a legkülönfélébb hazai és nemzetközi projektekben. Jelenleg a StoriesOnBoard megálmodója és gazdája. Remek előadást hallhattunk a user story mapping-ről, és hogy annak segítségével hogyan kezelhető a projekt szkópja…hogyan ne ijedjünk meg a kevésbé ismert követelményektől…mit kezdjünk a story-kkal, az epic-ekkel, meg az acceptance tesztekkel. És még kérdezhettünk is.
Na de ne rohanjunk előre…
A vízesés modellel kezdtük, és rögtön beültünk a híres DeLorean-be, amely visszarepített minket a 90-es évekbe, amikor még állítólag az Amazon sem létezett. Az előadó eljátszott a gondolatainkkal, hogy az “internetkultúra” kialakulásának korai szakaszában kezdjünk el megtervezni egy informatikai rendszert, amelynek fő víziója, hogy rengeteg könyvet adjon el.
Követelmény specifikáció: megalkottuk a követelmény specifikáció első elemét, miszerint az “A rendszernek képesnek kell lennie arra, hogy adminisztrációs felületen hozzá lehessen adni új könyvet”. A sort lehetne folytatni hosszú sorokon, oldalakon keresztül…
Rendszerterv: a hosszú követelmény specifikáció alapján és a közben jött ötletekkel tovább gazdagodva képzeletben “megrajzoljuk” először logikai majd fizikai szinten a rendszertervet. Elejétől a végéig, és még egy kicsit tovább is. Ebben a követelményeket funkciókra és nem funkcionális követelményekre bontottuk, melyeket egyenként megterveztünk…mintha mindig is könyveket árultunk volna interneten.
Fejlesztési feladatokkal kezdtünk el játszani ezután. Keletkeztek feladatok a leendő alkalmazás minden rétegében…persze megint minden részletre kiterjedően.
Mai BA (IT-s) fejjel ezek nem hangzanak túl jól. Mégis van előnye is eme módszernek.
-
- A projektnek ebben a szakaszban mindenki egyetért abban, hogy a majdani rendszernek mit kell tudnia.
- “Pontos” becslés, és ez alapján ütemezett feladatlista és projektterv készíthető egészen az utolsó mérföldkő végéig.
- Pontosan tervezhető az emberi erőforrás a fejlesztési projekt teljes időszakára.
A hátrányait ma már mindenki ismeri: a végére mindenki mást szeretne látni, mint ami elkészült. A keretek viszont kimerültek…nem ebben az időszakban köttetnek a legjobb barátságok.
Rávágnánk, hogy egyszerű a megoldás, meg hogy agilitás, meg hogy scrum, sprintek és minden szép és jó. És valójában ezek a kulcsszavak, de nem minden közegben működik ez ilyen sterilen.
Árpi ekkor kimondta az este kulcs kifejezését: user story mapping.
Mi is ez? Egy olyan vizualizálása a scope-nak, amely lehetővé teszi a nagy kép alábontását, és folyamatos priorizálását.
A vízszintes tengelyen megjelennek a fő követelmények, illetve azok csoportjai. A függőleges tengelyen pedig ezek alábontásai. Horizontálisan a követelmény(csoportok) sorrendjét a felhasználó fejében is értelmezhető tevékenységek végrehajtási sorrendje határozza meg, első körben. Függőlegesen az alábontás (story-k) valamilyen fontosság szerinti megközelítésben jelenik meg. Ez egyben egy időtengely is.
És van egy szkópunk. Ami nem a szkóp, hanem egy szkóp. De hogy álljunk neki? Mivel kezdjük? Meddig csináljuk? Az első két hetes sprint semmire sem elég. De még a második sem. ?
Fogalmazzuk meg, hogy mi lesz az első release tartalma. Ennek keretében pont annyit csináljunk meg, amivel némi visszajelzést kapunk a felhasználóktól, hogy jól gondolkodunk-e.
Egy kis rövid példa arra, hogy hogyan gondolkodunk, ha story map-et építünk:
- K: Érdemes könyvet árulni interneten?
- V: Talán.
- K: Csináljunk egy netes áruházat?
- V: Igen.
- K: Lehessen rendelni?
- V: Meg fizetni, meg kiszállítatni!
- K: Meg regisztrálni is?
- V: Persze, és bankkártyát is fogadjunk el, és lehessen beleolvasni is, miután kulcsszavak alapján megkerestük a kedvencünket?
- K: A kedvencünket?
- V: Persze, amit elmentettünk előző héten.
- K: Uhh, ezt mind?
- V: Nem, ennél sokkal többet…
- K: És ha nem jön be?
- V: Ööö!
- K: Mi lenne, ha először csak megmutatnánk az érdeklődőknek a könyveinket
- V: A borítóképpel, meg a fülszöveggel?
- K: Igen. És a megfelelő kategória alatt listázódnak a könyvek.
- V: Jóóó. És ha megtetszik neki?
- K: Kiírhatjuk a telefonszámodat? ?
- V: De arra nem lehet utalni.
- K: Nem, de fel lehet hívni.
- V: Oké, oké, oké… És akkor elutalja, én meg viszem neki a könyvet.
- K: El is küldheted postán.
- V: Persze, persze; akkor elkérem a címét a telefonban!
- K: Megegyeztünk: az első verzióban megmutatjuk a könyveinket, csoportosítva, néhány képpel, és részlettel; valamint a telefonszámot, amin meg lehet rendelni.
- V: Jjjjó. De aztán lehet regisztrálni is?
- K: Aztán. Lehet. Lehet, hogy lehet.
- V: Jaj de jó. Akarok Google meg Facebook reget is.
És már el is készült az első story map-ünk:
A folytatásban pedig ugyanezeket a tevékenységeket iteráljuk. A story-k tovább bonthatók, bővíthetők, amint megkaptuk az első felhasználói illetve használati visszajelzéseket. Ez alapján már kisebb granularitású story-k is készíthetők. Új fő követelmények befogadása is kezelhető, a vízszintes dimenzió növelésével.
Fontos, hogy mindig megfogalmazzuk a következő elérendő célt, és ennek tudatában hozzuk létre, módosítsuk és priorizáljuk a story-kat. Árpi példájában: az áruház óriási siker lett. Viszont a rendszeresen foglalt telefon miatt sokan nem tudták leadni rendelésüket. Megfogalmazásra került a következő cél: legyen skálázható az üzleti modell!
A továbbiakban arról volt szó, hogy hogyan születnek meg a story-k.
Több lépcsőben. Először csak olyan mélységben, hogy mindenki értse, miről szól, és a fontossága, ütemezése meghatározható legyen. Részletes kifejtése, és dokumentálása akkor történik, amikor szükség van rá, és tudjuk, hogy le lesz fejlesztve a következő időszakban.
Mindannyiunkban felmerült, hogy egy story készítése során, mikor mondhatjuk azt, hogy kész vagyunk. Mikor mondhatjuk azt, hogy mindenre gondoltunk, de nem is bonyolodtunk bele feleslegesen a részletekbe? Az alábbi javaslatot kaptuk e nehéz kérdés megválaszolására:
-
-
- gondoljuk végig, hogyan mutatjuk be a storyt, illetve az az alapján elkészült funkciót
- gondoljuk végig, hogyan ellenőriznénk a story-t, ha nekünk kellene rámondanunk, hogy igen, ezt szerettük volna
-
Ezzel megalkottuk az elfogadási kritériumokat. Kicsit más nézőpontból megnézzük, hogy minek az elkészültét várjuk. És lehet, hogy egyes story-kra nincs-, vagy nem most van szükség. Ezzel is meggyorsítjuk a validálási folyamatot.
Árpi interpretációjában valahogy így nézett ez ki ? A lényeg, hogy vágjuk a szkópot.
Visszatérve a story map-re…az előadás utolsó szekciójában néhány gyakran felmerülő kérdést, és az arra hozott válaszokat hallgathattuk meg:
-
-
- Hol helyezkednek el az EPIC-ek a story map-en? A válasz, hogy nincs egyértelmű megfeleltetése. A map felső szintjei “sose készülnek el”, míg az Epic-ek jellemzően elkészülnek.
- Mi a helyes sorrendje a vízszintes tengelyre “felpakolt” story-knak, gyűjtő fogalmaknak? A válasz itt sem definit: a lényeg, hogy a story map segítségével megvalósuljon a közös megértés, és ennek megfelelően kell a folyamatos alakítását végezni.
- Hogyan ábrázolom a folyamat ágakat, opcionális lépéseket? A válasz, hogy sehogy, a story mapping nem erre való.
- Ki, illetve kik készítik a map-et? Tapasztalat alapján nem az irodalomban meghatározott “csapat” készíti, hanem a domain expert vagy Product Owner vagy BA összerakja és folyamatosan karbantartja.
- Kell mellé dokumentáció? A rendszer illetve a projekt határozza meg a dokumentáció mértékét és összetételét, a story map a priorizálásért, ütemezésért, a közös megértésért felel. A klasszikus ökölszabályok itt is igazak: az elfogadási kritériumok, és Definition of Done lista elkészítésén nem érdemes spórolni.
- Hol alkalmazható jól, és hol kevésbé? Azon rendszerek esetén jó, ahol valós felhasználók vannak, akik visszajelzései alapján a “térkép” élőn tartható. Azon projektek esetén is megfontolandó a story map használata, ahol a szerződés megköveteli a monolit tervezési szakaszt, vagyis vízesés módszertan szerint kerül végrehajtásra: érdemes egyes – felhasználói munkafolyamatokat támogató – funkciók esetén kipróbálni.
-
Minden rendes tudományos értekezés végén előkerül az irodalom. Árpi is hozott néhány javasatot:
-
-
- Jeff Patton: a User Story Mapping könyv szerzője, és számos cikk írója a témában
- Mike Cohn: agilis nagykövetként, egyik remek könyve a User Stories Applied, amely a story írás fortélyait mutatja be.
- Spec by Example: érdemes utána olvasni; ahogy a neve is mutatja gyakorlati példákat használ a storyk elkészítésére
-
Az előadás legvégén Árpi megmutatta, hogy mit rejt még a zsákja:
Az előadás sajnos véget ért, de a meetupon leleményes házigazdáink tartogattak még meglepetéseket.
Mielőtt Árpi szót kapott volna, kaptunk egy gyors kihívást, amely természetesen nem állt túlságosan távol a story mapping-től. Kisebb csoportokba szerveződve kellett egy ételkiszállítás termék scope-ját 5 dobozba rögzítenünk. Fontos szempont volt, hogy a cetlik tartalmát mindenki értse, legyenek megszámozva, és legfeljebb 3 szóból álljanak. A másodperceknek tűnő rendelkezésre álló idő leteltével házigazdáink összesítették, a leggyakoribbakat kiválogatták, rendszerezték, táblára rakták, és szereztek egy fotóst. Majd szerencsére a kép készítéséhez még modellt is álltak ? .
Ekkor még nem feltétlenül tudtuk, hogy közösen megalkottuk a legújabb ételfutár rendszerének story map-jét.
Ha egy előadás után nincsenek kérdések, az nem OK. De ez egy remek előadás volt. Kérdeztünk is:
Ott vannak-e a fejlesztők a Story Mapping létrehozásakor, kezelésekor?
-
-
- elvileg ott kellene legyenek, a gyakorlatban a csapat összetétele, illetve a domain expert felkészültéségétől függ.
-
Miért jó, ha több projekt szerepkör is jelen van ezen alkalmak során?
-
-
- mert annál pontosabb a becslés, és az eladhatóság, és a megvalósítás kockázata is jobban felmérhető.
-
Ügyfél látja a Story Map-et? Ő is jelen van?
-
-
- kisebb projektek esetén előfordul, de leginkább az ügyfél képviselője van jelen a Product Owner vagy BA személyében
-
Technikai story-k megjelennek-e a map-en?
-
-
- alapvetően megjelenhetnének, de amikor a Story Map használatának célja a közös megértés, akkor nincs szükség rájuk
-
A Story Map tartalmazza-e a task-okat?
-
-
- nem; a modell a story szintjén marad végig az életciklusa során
-
A Release-ek időben egyforma hosszúak a módszertan alapján?
-
-
- nem; a release tartalmát a megfelelően magasra priorizált story-k összessége adja; ezek – a csapat általi – megvalósításának becsült időigénye határozza meg a release tervezett hosszát
-
Ez egy interjúzást támogató eszköz?
-
-
- nem; a közös megértést segíti, illetve az ütemezést és a release képzését
- továbbá biztosítja, hogy az ötletek ne felejtődjenek el
-
Tudsz tool-okat ajánlani?
-
-
- Persze, a mienket. Szerintem az a legjobb.
-
Konklúzió
Először is kell itt néhány nagy nagy KÖSZÖNÖM: Marcsinak, Árpinak, Noéminek, hogy ismét egy világszínvonalú eseményt hoztak össze nekünk.
A story mapping hatékony választ ad jónéhány problémára, amivel egy fejlesztési projekt során szembesülünk elemzőként. Számos ötletet hallhattunk, hogyan vágjunk bele, hogyan használjuk nem tipikus esetekben, hogyan optimalizáljuk. Egyben remek tippeket kaptunk az agilis elemek gyakorlati használatára is. Kaptunk olvasnivalót, és végül, de nem utolsó sorban kedvezményt is az egyik világelső story mapping eszköz megvásárlására, és támogatásának igénybevételére.
Kulcsszavak – amelyek mentén az este témái tovább kutathatók
-
-
- user story mapping
- shared understanding
- acceptance criteria
- user stories applied
-
Hasznos linkek:
-
-
- Insprl – Ami fejlődésre inspirál: https://insprl.hu/;
- BA TALK közösség: https://www.facebook.com/groups/2903485626578317
- https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909
- Előadónk által épített app: https://storiesonboard.com/
-
Köszönjük Gidó Csabának, aki összefoglalta nekünk az este minden lényeges gondoltatát.
Meetupunkat a PMI Budapest támogatta, ezért a PMI minősítéssel rendelkezők 1,5 PDU pontot gyűjtöttek.
Ha nem szeretnél lemaradni a következő meetupról, iratkozz fel az Insprl hírlevelére, vagy mondok jobbat, már jelentkezhetsz a következő meetupra, amely az Enterprise architecture gondolkodásról fog szólni.
Ha ennél gyorsabb és instant tudásra van szükséged, akkor csatlakozz május 23-24-én a Business analyst MINDSET tréningre, ahol két nap alatt bekeretezem az üzleti elemzés szemléletét.
Már csak az a kérdés, hogy Te is ott leszel-e velem. ?
