Opomba
Knjiga je pripovedan algoritem za izvedbo razvojnega procesa od ideje do izvedbe z uporabo agilnih tehnik. Postopek je razporejen po korakih in v vsakem koraku so navedene metode za korak postopka. Avtor poudarja, da večina metod ni izvirnih, ne da bi trdil, da so izvirne. Toda zaradi dobrega sloga pisanja in določene celovitosti postopka je knjiga zelo uporabna.
Ključna tehnika preslikave uporabniške zgodbe je strukturiranje idej in predstav, ko se uporabnik premika skozi proces.
Hkrati lahko proces opišemo na različne načine. Ustvarite lahko korake, ko dosežete ključno vrednost, ali pa si preprosto predstavljate delovni dan uporabnikov, kako poteka skozi sistem. Avtor se osredotoča na dejstvo, da je treba procese začrtati, jih izgovoriti v obliki uporabniške zgodbe na procesnem zemljevidu, kar nam je dalo ime zemljevid uporabniških zgodb.
Kdo ga potrebuje
Za IT analitike in vodje projektov. Obvezno branje. Enostavno in prijetno branje, knjiga je srednje velikosti.
Povratne informacije
V najpreprostejši obliki deluje tako.
Obiskovalec pride v kavarno, izbere jedi, odda naročilo, prejme hrano, poje in plača.
Na vsaki stopnji lahko napišemo zahteve, kaj želimo od sistema.
Sistem mora prikazati seznam jedi, vsaka jed mora imeti sestavo, težo in ceno ter možnost dodajanja v košarico. Zakaj smo prepričani v te zahteve? To ni opisano v »standardnem« opisu zahtev in to ustvarja tveganja.
Izvajalci, ki ne razumejo, zakaj je to potrebno, običajno naredijo narobe. Izvajalci, ki niso vključeni v proces nastajanja ideje, niso vključeni v rezultat. Agile pravi, da se ne osredotočimo predvsem na sistem, ampak na ljudi, na potrošnike, njihove naloge in cilje.
Ustvarimo osebe, jim damo podrobnosti za empatijo in začnemo pripovedovati zgodbe s strani osebe.
Pisarniški uslužbenec Zakhar je šel na kosilo in želi na hitro prigrizniti. Kaj potrebuje? Ideja je, da si verjetno želi poslovno kosilo. Druga ideja je, da želi, da si sistem zapomni njegove želje, ker je na dieti. Še ena ideja. Želi, da mu takoj prinesejo kavo, ker je navajen piti kavo pred kosilom.
In obstaja tudi posel (organizacijski značaj je značaj, ki zastopa interese organizacije). Podjetja želijo povečati povprečni ček, povečati pogostost nakupov in povečati dobiček. Ideja je - ponudimo nenavadne jedi neke kuhinje. Še ena ideja – uvedimo zajtrk.
Ideje je mogoče in jih je treba konkretizirati, transformirati in predstaviti v obliki uporabniške zgodbe. Kot zaposlen v poslovnem centru Zakhar želim, da me sistem prepozna, da lahko prejmem jedilnik glede na svoje želje. Kot natakar želim, da me sistem obvesti, kdaj naj pristopim k mizi, da bo stranka s hitro postrežbo zadovoljna. In tako naprej.
Na desetine zgodb. Sledi določanje prioritet in zaostanki? Jeff opozarja na težave, ki se pojavljajo: zabredenje v majhne podrobnosti in izguba konceptualnega razumevanja, poleg tega dajanje prednosti funkcionalnosti ustvarja raztrgano sliko zaradi neskladja s cilji.
Pot avtorja: Ne dajemo prednost funkcionalnosti, temveč rezultatu = kaj uporabnik dobi na koncu.
Očitna neočitna točka: seje določanja prioritet ne izvaja cela ekipa, ker je neučinkovita, ampak tri osebe. Prvi skrbi za poslovanje, drugi za uporabniško izkušnjo in tretji za implementacijo.
Izberimo minimum za rešitev enega uporabniškega problema (minimum viable solution).
Ideje prve prioritete podrobno opišemo z uporabo uporabniških zgodb, oblikovalskih skic, omejitev in poslovnih pravil na zemljevidu uporabniške zgodbe, tako da povemo in razpravljamo z ekipo, kaj ljudje in deležniki potrebujejo na vsakem koraku procesa. Preostale ideje puščamo nepreverjene v zaostanku priložnosti.
Postopek je napisan na karticah od leve proti desni, z idejami na karticah pod koraki postopka. Nujno je, da se o poti skozi celotno zgodbo pogovorimo skupaj s člani tima, da zagotovimo medsebojno razumevanje.
Izdelava na ta način ustvarja celovitost v skladu s procesi.
Prejete ideje je treba preizkusiti. Nečlan ekipe si nadene klobuk osebe in živi dan osebe v svoji glavi ter rešuje njen problem. Možno je, da ne vidi razvoja, znova ustvarja kartice in ekipa zase odkrije alternative.
Potem je tu še detajliranje za oceno. Za to so dovolj tri osebe. Odgovoren za uporabniško izkušnjo, razvijalec, tester z najljubšim vprašanjem: “Kaj če...”.
Na vsaki stopnji razprava sledi zemljevidu procesa uporabnikove zgodovine, kar omogoča upoštevanje uporabnikove naloge za ustvarjanje skladnega razumevanja.
Ali je dokumentacija po mnenju avtorja potrebna? Da, potrebujem ga. Ampak kot opombe, ki vam omogočajo, da se spomnite, kaj ste se dogovorili. Ponovno vključevanje tujca zahteva razpravo.
Avtor se ne spušča v temo zadostnosti dokumentacije, osredotoča se na potrebo po razpravi. (Da, dokumentacija je potrebna, ne glede na to, kako trdijo ljudje, ki agilnosti ne razumejo globoko). Prav tako lahko izdelava le dela zmogljivosti povzroči potrebo po popolni predelavi celotnega sistema. Avtor opozarja na tveganje pretirane elaboracije v primeru, ko je ideja napačna.
Za odpravo tveganj je potrebno hitro prejeti povratne informacije o ustvarjenem izdelku, da zmanjšamo škodo zaradi ustvarjanja »napačnega« izdelka. Naredili smo skico ideje – jo validirali z uporabnikom, skicirali prototipe vmesnikov – validirali z uporabnikom itd. (Ločeno je nekaj informacij o tem, kako preveriti prototipe programov). Cilji ustvarjanja programske opreme, predvsem v začetni fazi, so učenje s prejemanjem hitre povratne informacije, zato so prvi ustvarjen izdelek skice, ki lahko dokažejo ali ovržejo hipotezo. (Avtor se opira na delo Erica Riesa »Startup using Lean methodology«).
Zemljevid zgodb pomaga izboljšati komunikacijo, ko se implementacija izvaja v več skupinah. Kaj naj bo na zemljevidu? Kaj potrebujete za nadaljevanje pogovora. Ne samo zgodba uporabnika (kdo, kaj, zakaj), ampak ideje, dejstva, skice vmesnikov itd.
Če kartice na zemljevidu zgodovine razdelite na več vodoravnih črt, lahko delo razdelite na izdaje - poudarite minimalno, plast povečane funkcionalnosti in loke.
Na zemljevidu procesa pripovedujemo zgodbe.
Na kosilo je prišel zaposleni.
Kaj hoče? Hitrosti storitev. Da ga kosilo že čaka na mizi ali vsaj na pladnju. Ups – zgrešen korak: zaposleni je hotel jesti. Prijavil se je in izbral možnost poslovnega kosila. Videl je vsebnost kalorij in hranilne vrednosti, ki mu pomagajo pri dieti in se ne zredijo. Videl je slike jedi, da se je odločil, ali bo jedel na tem mestu ali ne.
Nato bo šel na kosilo in večerjo? Ali pa mu bodo morda kosilo dostavili v pisarno? Nato je korak v procesu izbira kraja za jesti. Želi videti, kdaj mu ga bodo dostavili in koliko bo to stalo, da bo lahko izbral, kje bo porabil svoj čas in energijo – dol ali v službo. Želi videti, kako zasedena je kavarna, da se ne bi prerival v vrstah.
Nato je uslužbenec prišel v kavarno. Želi videti svoj pladenj, da ga lahko vzame in gre takoj na večerjo. Kavarna želi sprejeti denar, da bi zaslužila s storitvijo. Zaposleni želi izgubiti najmanj časa pri poravnavah s kavarno, da ne bi neuporabno izgubljal dragocenega časa. Kako narediti? Plačajte vnaprej ali obratno po storitvi na daljavo. Ali pa plačajte na kraju samem v kiosku. Kaj je pri tem najpomembnejše? Koliko ljudi je pripravljenih plačati kosilo z bančno kartico? Koliko ljudi bi tej menzi zaupalo shranjevanje številke njihove kartice za ponovna plačila? Brez terenskih raziskav je nejasno, potrebno je testiranje.
Na vsakem koraku procesa morate nekako zagotoviti funkcionalnost, za to morate vzeti neko osebo kot osnovo in izbrati, kaj je zanjo bolj pomembno (isti trije izbirniki). Sledil zgodbi do konca = naredil izvedljivo rešitev.
Sledi detajliranje. Stranka želi videti, kako zasedena je kavarna, da se ne preriva v čakalnih vrstah. Kaj točno hoče?
Poglejte napoved, koliko ljudi bo čez 15 minut, ko pride tja
Oglejte si povprečni čas storitve v kavarni in njegovo dinamiko pol ure vnaprej
Oglejte si stanje in dinamiko zasedenosti miz
Kaj pa, če sistem napovedovanja daje nejasen rezultat ali preneha delovati?
V videu si oglejte vrste v kavarni, pa tudi zasedenost miz. Hmm, zakaj ne bi najprej naredili tega?!
Avtor opozarja na majhno vajo za vadbo: poskusite si predstavljati, kaj počnete zjutraj, ko se zbudite. Ena karta = eno dejanje. Povečajte karte (namesto mletja kave popijte poživljajočo pijačo), da odstranite posamezne podrobnosti, pri čemer se ne osredotočite na način izvedbe, temveč na cilj.
Komu je ta knjiga namenjena: IT analitikom in vodjem projektov. Obvezno branje.
Apps
Razprava in odločanje sta učinkovita v skupinah od 3 do 5 ljudi.
Na prvo kartico napišite, kaj je treba razviti, na drugo - popravite, kar ste naredili v prvi, na tretjo - popravite, kar ste naredili v prvi in drugi.
Pripravite zgodbe kot torte – ne tako, da napišete recept, ampak tako, da ugotovite, komu, za katero priložnost in koliko ljudi je torta namenjena. Če prodajo razdelimo, potem ne bi šlo v proizvodnjo tort, krem itd., ampak v proizvodnjo drobnih konfekcijskih tort.
Razvoj programske opreme je podoben snemanju filma, ko je treba pred začetkom snemanja natančno razviti in izpiliti scenarij, organizirati sceno, igralce itd.
Virov bo vedno primanjkovalo.
20% prizadevanj daje oprijemljive rezultate, 60% daje nerazumljive rezultate, 20% prizadevanj je škodljivih - zato je pomembno, da se osredotočimo na učenje in ne obupamo v primeru negativnega rezultata.
Komunicirajte neposredno z uporabnikom, počutite se v njegovi koži. Osredotočite se na nekatere težave.
Podrobnosti in razvijanje zgodbe za ocenjevanje je najbolj mučen del scrum-a, naj bodo razprave stand-up v akvarijskem načinu (3-4 osebe razpravljajo na tabli, če kdo želi sodelovati, nekoga zamenja).
Vir: www.habr.com