Kokkuvõte
Raamat on jutustatud algoritm arendusprotsessi läbiviimiseks ideest teostuseni, kasutades agiilseid võtteid. Protsess on esitatud etappidena ja igas etapis on näidatud protsessi etapi meetodid. Autor juhib tähelepanu sellele, et enamik meetodeid ei ole originaalsed, pretendeerimata originaalsusele. Kuid hea kirjutamisstiil ja protsessi mõningane terviklikkus muudavad raamatu väga kasulikuks.
Kasutaja lugude kaardistamise põhitehnika on ideede ja esituste struktureerimine, kui kasutaja protsessis liigub.
Samal ajal saab protsessi kirjeldada erinevalt. Saate koostada samme, kui saavutate võtmeväärtuse, või võite lihtsalt ette võtta ja ette kujutada kasutajate tööpäeva, kui see süsteemi kasutades möödub. Autor keskendub sellele, et protsessid vajavad väljajoonistamist, kõnelemist kasutajaloo vormis protsessikaardil, mis andis meile nime kasutajalugude kaart.
Kes seda vajab
IT-analüütikutele ja projektijuhtidele. Kohustuslik lugemine. Lihtne ja mõnus lugeda, raamat on keskmise suurusega.
Vaadata
Kõige lihtsamal kujul see toimib nii.
Külastaja tuleb kohvikusse, valib nõud, esitab tellimuse, võtab toidu vastu, sööb ja maksab.
Igas etapis saame kirjutada nõuded selle kohta, mida me süsteemilt tahame.
Süsteem peaks näitama roogade nimekirja, igal roal on koostis, kaal ja hind ning neid saab ostukorvi lisada. Miks me oleme nendes nõuetes kindlad? Seda ei ole kirjeldatud nõuete “standardses” kirjelduses ja see tekitab riske.
Esinejad, kes ei saa aru, miks seda vaja on, teevad tavaliselt valesti. Esinejad, kes ei osale idee loomise protsessis, ei ole tulemusega kaasatud. Agile ütleb, et keskendugem eelkõige mitte süsteemile, vaid inimestele, tarbijatele, nende ülesannetele ja eesmärkidele.
Loome isikuid, anname neile empaatiavõimeks üksikasju ja hakkame lugusid jutustama isiku poolelt.
Kontoritöötaja Zakhar läks lõunale ja tahab kiirelt näksida. Mida ta vajab? Mõte on selles, et ilmselt tahab ta ärilõunat. Teine mõte on see, et ta soovib, et süsteem mäletaks tema eelistusi, kuna ta on dieedil. Teine idee. Ta tahab, et talle kohe kohvi tuuaks, sest ta on harjunud enne lõunat kohvi jooma.
Ja on ka äri (organisatsiooni tegelane on tegelane, kes esindab organisatsiooni huve). Ettevõtted soovivad suurendada keskmist tšekki, suurendada ostude sagedust ja suurendada kasumit. Idee on – pakume mõne köögi ebatavalisi roogasid. Veel üks idee – tutvustame hommikusööki.
Ideid saab ja tulebki konkretiseerida, transformeerida ja kasutajaloo vormis esitada. Zakhari ärikeskuse töötajana tahan, et süsteem tunneks mind ära, et saaksin oma eelistustele vastava menüü. Kelnerina soovin, et süsteem annaks mulle märku, millal lauale läheneda, et klient jääks kiire teenindusega rahule. Ja nii edasi.
Kümned lood. Järgmine on prioriteetide seadmine ja mahajäämus? Jeff toob esile esilekerkivad probleemid: pisidetailidesse takerdumine ja kontseptuaalse arusaamise kaotamine ning funktsionaalsuse tähtsuse järjekorda seadmine loob ebakõla eesmärkidega pildi.
Autori tee: me ei sea esikohale mitte funktsionaalsust, vaid tulemust = see, mida kasutaja lõpuks saab.
Ilmselge mitteilmne punkt: prioriteetide seadmise seanssi ei vii läbi kogu meeskond, sest see on ebaefektiivne, vaid kolm inimest. Esimene vastutab äritegevuse, teine kasutajakogemuse ja kolmas juurutamise eest.
Valime ühe kasutajaprobleemi lahendamiseks miinimumi (minimaalne elujõuline lahendus).
Me kirjeldame esmatähtsaid ideid kasutajalugude, kujunduse visandite, piirangute ja ärireeglite abil kasutajalugude kaardil, rääkides ja arutades meeskonnaga, mida inimesed ja sidusrühmad protsessi igas etapis vajavad. Ülejäänud ideed jätame võimaluste mahajäämusse läbi vaatamata.
Protsess on kaartidele kirjutatud vasakult paremale, ideed kaartidel protsessi etappide all. Vastastikuse mõistmise tagamiseks tuleb koos meeskonnaliikmetega arutada läbi kogu loo läbiv tee.
Sel viisil läbitöötamine loob terviklikkuse kooskõlas protsessidega.
Saadud ideid tuleb testida. Mitte-meeskonnaliige paneb inimesele mütsi pähe ja elab inimese päeva peas, lahendades tema probleemi. Võimalik, et ta ei näe arenguid, luues taas kaarte ja meeskond avastab enda jaoks alternatiive.
Seejärel on hindamiseks vaja detaile. Selleks piisab kolmest inimesest. Vastutab kasutajakogemuse eest, arendaja, testija lemmikküsimusega: “Mis siis, kui...”.
Igas etapis järgitakse arutelu käigus kasutaja ajaloo protsessikaarti, mis võimaldab kasutaja ülesannet silmas pidades luua ühtne arusaam.
Kas dokumentatsioon on autori arvates vajalik? Jah, ma vajan seda. Aga kui märkmeid, mis võimaldavad meeles pidada, milles kokku lepiti. Jällegi kõrvalseisja kaasamine nõuab arutelu.
Dokumentatsiooni piisavuse teemasse autor ei süvene, keskendudes diskussioonivajadusele. (Jah, dokumentatsiooni on vaja, olenemata sellest, kuidas inimesed, kes agilist sügavat arusaama ei tunne, seda väidavad). Samuti võib ainult osa võimaluste väljatöötamine kaasa tuua vajaduse kogu süsteemi täielikult ümber töötada. Autor toob välja liigse läbitöötamise ohu juhul, kui idee on vale.
Riskide kõrvaldamiseks on vaja kiiresti saada loodava toote kohta tagasisidet, et minimeerida “vale” toote loomisest tulenevat kahju. Tegime ideest eskiisi - valideerisime koos kasutajaga, visandasime liidese prototüübid - valideerisime koos kasutajaga jne. (Eraldi on veidi teavet programmide prototüüpide valideerimise kohta). Tarkvara loomise eesmärkideks, eriti algstaadiumis, on õppimine läbi kiire tagasiside saamise, vastavalt sellele luuakse esimese tootena visandid, mis suudavad hüpoteesi tõestada või ümber lükata. (Autor tugineb Eric Riesi tööle “Startup using Lean methodology”).
Loo kaart aitab parandada suhtlust, kui rakendamine toimub mitmes meeskonnas. Mis peaks kaardil olema? Mida on vaja vestluse jätkamiseks. Mitte ainult kasutajalugu (kes, mis, miks), vaid ideid, fakte, liidese visandeid jne...
Jagades ajalookaardil olevad kaardid mitmeks horisontaalseks jooneks, saate jagada töö väljaanneteks - tuua esile miinimumi, suureneva funktsionaalsuse kiht ja kummardused.
Räägime lugusid protsessikaardil.
Töötaja tuli lõunale.
Mida ta tahab? Teeninduskiirused. Et tema lõunasöök teda juba laual või vähemalt kandikul ootaks. Oeh – vahelejäänud samm: töötaja tahtis süüa. Ta logis sisse ja valis ärilõuna valiku. Ta nägi kalorisisaldust ja toiteväärtust, et aidata tal dieeti pidada ja mitte kaalus juurde võtta. Ta nägi roa pilte, et otsustada, kas ta sööb selles kohas või mitte.
Kas ta läheb järgmiseks lõuna- ja õhtusöögile? Või äkki tuuakse lõunasöök tema kontorisse? Seejärel on protsessi etapiks söögikoha valimine. Ta tahab näha, millal see temani toimetatakse ja kui palju see maksma läheb, et saaks valida, kuhu oma aega ja energiat kulutada – kas trepist alla või tööle. Ta tahab näha, kui tihe on kohvik, et mitte järjekordades sagida.
Siis tuli töötaja kohvikusse. Ta tahab näha oma salve, et saaks selle võtta ja otse õhtusöögile minna. Kohvik soovib teenindusega raha teenimiseks raha vastu võtta. Töötaja soovib kohvikuga arveldades minimaalselt aega kaotada, et mitte raisata väärtuslikku aega asjatult. Kuidas seda teha? Makske ette või vastupidi pärast kaugteenindust. Või tasuda kohapeal kasutades kioski. Mis on selle juures kõige olulisem? Kui paljud on nõus lõunasöögi eest pangakaardiga maksma? Kui paljud inimesed usaldaksid seda sööklat oma kaardinumbri talletamist korduvate maksete jaoks? Ilma väliuuringuteta on ebaselge, testimine on vajalik.
Protsessi igas etapis peate kuidagi pakkuma funktsionaalsust, selleks peate võtma aluseks mõne inimese ja valima, mis on tema jaoks olulisem (sama kolm valijat). Jälgis lugu lõpuni = tegi elujõulise lahenduse.
Järgmisena tuleb detailid. Klient tahab näha, kui suure hõnguga kohvik on, et mitte järjekordades sagida. Mida ta täpselt tahab?
Vaata prognoosi, kui palju inimesi on 15 minuti pärast, kui ta kohale jõuab
Vaata kohviku keskmist teenindusaega ja selle dünaamikat pool tundi ette
Vaadake olukorda ja laudade täituvuse dünaamikat
Mis saab siis, kui prognoosisüsteem annab ebaselge tulemuse või lakkab töötamast?
Vaata video kaudu kohviku järjekordi, aga ka laudade täituvust. Hmm, miks mitte seda enne teha?!
Autor toob välja väikese harjutuse, mida harjutada: proovige ette kujutada, mida teete hommikul pärast ärkamist. Üks kaart = üks tegevus. Suurendage kaarte (kohvi jahvatamise asemel jooge kosutavat jooki), et eemaldada üksikud detailid, keskendudes mitte teostusmeetodile, vaid eesmärgile.
Kellele see raamat on mõeldud: IT-analüütikutele ja projektijuhtidele. Kohustuslik lugemine.
Apps
Arutelu ja otsuste tegemine on tõhusad 3–5-liikmelistes rühmades.
Esimesele kaardile kirjutage, mida on vaja arendada, teisele - parandage esimesel ja kolmandal - parandage esimesel ja teisel tehtut.
Valmistage lugusid nagu koogid – mitte retsepti välja kirjutades, vaid uurides, kellele, mis puhuks ja kui paljudele inimestele kook mõeldud on. Kui müük jaotada, siis see ei läheks kookide, kreemi jms tootmiseks, vaid väikeste valmiskookide tootmiseks.
Tarkvaraarendus sarnaneb filmi tegemisega, kui enne filmimise algust on vaja stsenaariumi hoolikalt arendada ja lihvida, organiseerida stseen, näitlejad jne.
Alati jääb ressurssidest puudus.
20% pingutustest annab käegakatsutavaid tulemusi, 60% annab arusaamatuid tulemusi, 20% pingutustest on kahjulikud – seepärast on oluline keskenduda õppimisele ja mitte heita meelt negatiivse tulemuse korral.
Suhtle kasutajaga otse, tunne end tema nahas. Keskenduge mõnele probleemile.
Jutu detaileerimine ja hindamiseks edasiarendamine on rüselus kõige kõvem osa, arutelud akvaariumirežiimis püsti seisma (tahvlil arutavad 3-4 inimest, kui keegi soovib osaleda, asendab kedagi).
Allikas: www.habr.com