Senki sem szeret user story-t írni
Minden magára valamit is adó termékmenedzser ismeri a user story-kat. Ez az agilis módja annak, hogy átadjuk mérnök kollégáinknak az ügyfeleink problémáit és azt, hogy ezeket milyen új funkcióval szeretnénk orvosolni. Az eredetileg Kent Beck által kitalált user story-k arra szolgáltak, hogy kiváltsák a több tíz oldalas termékkövetelmény dokumentációkat.
A régi termékmenedzserek dolga volt, hogy a mérnököktől elzártan kidolgozzák ezeket a követelmény monstrumokat, amiket aztán átadtak és várták, hogy a funkció életre keljen. A probléma az volt, hogy az új fejlesztés hátterének a leírása, illetve a működésének minden részletre kiterjedő dokumentációja egy kisebb könyvet tett ki. Ennek ellenére nem mindig azt kapta a termékmenedzser és közvetve az ügyfél, amit szeretett volna. Ez visszavezethető arra, hogy:
Senki nem olvas el egy több tíz oldalas dokumentumot és jegyez meg minden részletet.
Az írott szöveg félreérthetősége miatt mást értett a termékmenedzser és a mérnök.
A szöveg hosszúsága miatt több hiba lehetett benne, ami miatt rossz irányba mehetett el a fejlesztés.
A user story, mint fogalom azért született, hogy a dokumentum helyett a történeten legyen a hangsúly. Vagyis azon, hogy mi az ügyfél problémája, mire keresünk megoldást. Ezért is lett user story a neve: egy történet, amit elmesélünk az ügyfeleinkről, felhasználóinkról. Ez a történetmesélés előtérbe helyezte a beszélgetést a mérnök és a termékmenedzser között. Funkciók helyett azon volt a hangsúly, hogy mindenki tudja, miért fejlesztünk és hogyan ellenőrizzük, hogy jó-e a fejlesztésünk. Erre utal a user story-k 3C-je:
Card. Vagyis az a kis alakú kártya, aminek az egyik oldalára kézzel felírták az ügyfél problémáját, kívánt funkcióját. A kis kártyák előnye volt, hogy nem fért rájuk sok szöveg, így nem lehetett minden részletre kiterjedő specifikációt írni.
Conversation. Vagyis a beszélgetés, amikor a termékmenedzser a kártyával odamegy a mérnökökhöz, hogy átbeszéljék, mit jelent az a kevés szöveg, ami rá van írva. A kártyák fizikai volta elősegítette a beszélgetést, hiszen nem lehetett elküldeni elektronikusan, oda kellett menni a többiekhez, meglobogtatni a kártyát és beszélni velük.
Confirmation. Vagyis az ellenőrzés. Ahelyett, hogy minden részletre kiterjedő specifikáció készülne, csak azt kellett tisztázni, hogy mik azok a kulcs tesztek, amiken át kell mennie a fejlesztésnek. Ezek tipikusan a kártya hátuljára kerültek, tehát itt is csínján kellett bánni a karakterekkel.
Hogy ezután mi történt, azt csak találgatni tudom. De az agilis fejlesztés és a SCRUM elterjedésével a user story-k csak nőttek és nőttek, amíg átalakultak rejtett termékkövetelmény dokumentumokká. Ezeket az új user story-kat a termékmenedzserek írják egy digitális eszközben, hogy aztán átadják a fejlesztőknek, akik megbecsülik és leszállítják. A több tíz oldal dokumentáció helyett több tíz “Jira ticket” lett. A kis kártyára írt szöveg helyett pedig - hogy egy átlagos álláshirdetést idézzek - “részletes, tesztelhető és mérhető user story írás” lett az elvárás. A sztorizást felváltotta a folyamatos user story gyártás, ami a legtöbb termékmenedzsernek szenvedés.
Ésszerűnek tűnik, hogy ha minden le van írva, az segít. A mondás is úgy szól: szó elszáll, írás megmarad. Mégis, három érvem van arra, hogy ne töltsünk annyi időt user story-k írásával:
Napjainkban a fejlesztési ciklusok nagyon rövidek. Ha egy funkció elejétől a végéig pár nap - pár hét alatt készen van, kisebb eséllyel felejtődik el a fejlesztés lényege. Régen hónapokon, sőt éveken át készültek a fejlesztések, szükség volt valamire, ami segített az emlékezésben.
A termékmenedzser ideje véges. Ha választani lehet, akkor a részletesebb user story helyett inkább válassza a csapatmunkát. Minden perc, amit a user story finomításával tölt, olyan idő, amit nem a csapattal ötletel vagy tesztel.
A legtöbb funkció sokat változik az ötlettől a kész termékig. Ha előre leírunk egy részletes tervet, sok időt fogunk tölteni az átírásával. Ehhez hozzáadódik, hogy ha egyszer leírunk valamit, kevésbé akarunk tőle eltérni, mint ha nem írtuk volna le. A le nem írt ötleteket, terveket könnyebb szívvel cseréljük le egy jobbra.
Én is töltöttem napokat azzal, hogy minden részletre kiterjedő user story-kat írjak, és ha őszinte akarok lenni, ez segít egy ideig. De időkihasználás szempontjából nem éreztem optimálisnak, plusz utáltam csinálni. Jelenleg kevés user story-t írok, mégis sokkal jobban át tudom adni, hogy mit is szeretnének az ügyfeleink. Ezt a következőképpen csinálom:
A gondolatoknak időt kell adni, hogy beérjenek. Szinte soha nem beszélünk olyan koncepciókról részletesen, amiről ne esett volna szó korábban. Minden ügyfélvisszajelzést, ügyfélinterjút megosztok a csapattal, függetlenül attól, hogy a közeljövőben akarok-e foglalkozni vele. Ez időt ad mindenkinek, hogy eméssze a hallottakat.
Amikor el akarok kezdeni egy új fejlesztést, egy pár perces videóban elmesélem a problémát és azt, hogy én milyen megoldást találtam ki. Ezt egy olyan fórumon osztom meg, ahol az egész cég látja, így bárki hozzá tud szólni.
Ezután összeülünk, hogy átbeszéljük a problémát és a megoldási lehetőségeket, és ezt a megbeszélést fel is vesszük. Fontos, hogy ne legyen rajtunk időnyomás. Ha nem találunk ki semmi jót, akkor befejezzük a megbeszélést és alszunk rá egyet. Néha többet is. Még ha nem is akadunk el, általában felmerülnek kérdések, feladatok, amiket kiosztunk. Ezek lehetnek a probléma pontosítása, adatgyűjtés, technikai kutatás, illetve első körös design elkészítése.
Ezeket a megbeszéléseket addig iteráljuk, amíg úgy nem érezzük, hogy nincs bennünk több kérdés. Mindenki tudja, hogy mit akarunk csinálni és legfőképpen, hogy miért. Eközben a design folyamatosan változik, és a scope is többször nő vagy csökken. Általában csökken, mert szeretünk minél kisebb funkciókat szállítani.
Ekkor kezdem megírni Epic szinten a ticket-et, ami egy gyors, egy-két mondatos problémadefinícióból és rövid, pontokba szedett követelményekből áll. Ezen kívül csatolom hozzá az összes megbeszélés felvételét, valamint a design és egyéb anyagokat. Ezek lehetnek dokumentumok, Slack beszélgetések hivatkozásai vagy bármi egyéb, ami kell a kontextus megértéséhez.
Az Epic-et a mérnökök bontják kisebb egységekre, ami segít nekik szétosztani a feladatot. Ebbe én már nem szólok bele, sőt abba sem nagyon, hogy pontosan mikor kezd el dolgozni rajta a csapat.
Ez valószínűleg nem sokkal költségesebb folyamat, mint a SCRUM-ból megszokott user story - három amigo - refinement/grooming. És ezzel a módszerrel ritkábban szembesülök azzal, hogy nem a megbeszélt funkció készül el a végén, ráadásul a munkámat is sokkal jobban élvezem.