Anotacija
Knyga yra pasakojamas algoritmas, leidžiantis atlikti kūrimo procesą nuo idėjos iki įgyvendinimo, naudojant judrias technikas. Procesas yra išdėstytas etapais ir kiekviename žingsnyje nurodomi proceso etapo metodai. Autorius atkreipia dėmesį, kad dauguma metodų nėra originalūs, nepretenduojant į originalumą. Tačiau dėl gero rašymo stiliaus ir tam tikro proceso vientisumo knyga labai naudinga.
Pagrindinis vartotojo istorijos atvaizdavimo metodas yra idėjų ir pasirodymų struktūrizavimas, vartotojui judant per procesą.
Tuo pačiu metu procesą galima apibūdinti įvairiais būdais. Galite atlikti žingsnius, kai pasieksite pagrindinę vertę, arba galite tiesiog imti ir įsivaizduoti naudotojų darbo dieną, kai ji praeina naudojant sistemą. Autorius sutelkia dėmesį į tai, kad procesai turi būti nubrėžti, nusakyti vartotojo istorijos forma proceso žemėlapyje, todėl mums buvo suteiktas vartotojo istorijos žemėlapio pavadinimas.
Kam to reikia
IT analitikams ir projektų vadovams. Būtina perskaityti. Lengva ir malonu skaityti, knyga vidutinio dydžio.
Atsiliepimai
Paprasčiausia forma tai veikia taip.
Lankytojas ateina į kavinę, išsirenka patiekalus, pateikia užsakymą, gauna maistą, pavalgo ir sumoka.
Kiekviename etape galime parašyti reikalavimus, ko norime iš sistemos.
Sistema turi rodyti patiekalų sąrašą, kiekvienas patiekalas turi sudėtį, svorį ir kainą bei gali būti dedamas į krepšelį. Kodėl mes pasitikime šiais reikalavimais? Tai nėra aprašyta „standartiniame“ reikalavimų apraše ir tai kelia riziką.
Atlikėjai, kurie nesupranta, kodėl to reikia, dažniausiai elgiasi neteisingai. Atlikėjai, kurie nedalyvauja idėjos kūrimo procese, nedalyvauja rezultate. Agile sako, kad pirmiausia koncentruokimės ne į sistemą, o į žmones, į vartotojus, jų užduotis ir tikslus.
Kuriame asmenybes, suteikiame joms informaciją, kad įsijaustume, ir pradedame pasakoti istorijas iš asmens pusės.
Biuro darbuotojas Zacharas nuėjo pietauti ir nori greitai užkąsti. Ko jam reikia? Idėja tokia, kad jis tikriausiai nori verslo pietų. Kita idėja yra ta, kad jis nori, kad sistema atsimintų jo nuostatas, nes jis laikosi dietos. Kita idėja. Jis nori, kad jam iškart atneštų kavos, nes įpratęs kavą gerti prieš pietus.
Ir dar yra verslas (organizacinis pobūdis – tai organizacijos interesams atstovaujantis veikėjas). Įmonės nori padidinti vidutinį čekį, didinti pirkimo dažnumą ir padidinti pelną. Idėja tokia – pasiūlykime neįprastų kokios nors virtuvės patiekalų. Dar viena idėja – pristatykime pusryčius.
Idėjos gali ir turi būti konkretizuojamos, transformuojamos ir pateikiamos vartotojo istorijos forma. Kaip Zakhar verslo centro darbuotojas, noriu, kad sistema mane atpažintų, kad galėčiau gauti meniu pagal savo pageidavimus. Kaip padavėjas, noriu, kad sistema praneštų, kada reikia prieiti prie staliuko, kad klientas liktų patenkintas greitu aptarnavimu. Ir taip toliau.
Dešimtys istorijų. Kitas yra prioritetų nustatymas ir atsilikimas? Jeffas atkreipia dėmesį į iškylančias problemas: įstrigimas mažose detalėse ir konceptualaus supratimo praradimas bei funkcionalumo prioritetų suteikimas sukuria niūrų vaizdą dėl neatitikimo tikslams.
Autoriaus kelias: Pirmenybę teikiame ne funkcionalumui, o rezultatui = tai, ką vartotojas gauna galiausiai.
Akivaizdus neakivaizdus dalykas: prioritetų nustatymo seansą vykdo ne visa komanda, nes ji neefektyvi, o trys žmonės. Pirmasis yra atsakingas už verslą, antrasis – už vartotojo patirtį, o trečiasis – už įgyvendinimą.
Parinkime minimumą vienai vartotojo problemai išspręsti (minimalus perspektyvus sprendimas).
Mes išsamiai aprašome pirmąsias prioritetines idėjas, naudodami vartotojų istorijas, dizaino eskizus, apribojimus ir verslo taisykles naudotojo istorijos žemėlapyje, pasakodami ir aptardami su komanda, ko žmonėms ir suinteresuotosioms šalims reikia kiekviename proceso etape. Likusias idėjas paliekame neišnagrinėtas galimybių stotyje.
Procesas užrašytas ant kortelių iš kairės į dešinę, o idėjos kortelėse pateikiamos žemiau proceso etapų. Būtina, kad kelias per visą istoriją būtų aptartas kartu su komandos nariais, kad būtų užtikrintas abipusis supratimas.
Tokiu būdu sukuriamas vientisumas, atitinkantis procesus.
Gautas idėjas reikia išbandyti. Ne komandos narys užsideda žmogui kepurę ir gyvena to žmogaus dieną savo galvoje, spręsdamas jo problemą. Gali būti, kad jis nemato pokyčių, vėl kurdamas kortas, o komanda atranda sau alternatyvų.
Tada yra detalių įvertinimas. Tam pakanka trijų žmonių. Atsakingas už vartotojo patirtį, kūrėjas, bandytojas su mėgstamu klausimu: „O kas, jei...“.
Kiekviename etape diskusijos vyksta pagal vartotojo istorijos proceso žemėlapį, kuris leidžia nepamiršti vartotojo užduotys ir sukurti nuoseklų supratimą.
Ar, autoriaus nuomone, dokumentai reikalingi? Taip, man to reikia. Bet kaip užrašai, leidžiantys prisiminti, dėl ko susitarėte. Norint vėl įtraukti pašalinį asmenį, reikia diskutuoti.
Autorius nesigilina į dokumentacijos pakankamumo temą, daugiausia dėmesio skiria diskusijos būtinumui. (Taip, dokumentacija reikalinga, kad ir kaip tvirtintų žmonės, kurie neturi gilaus supratimo apie judrumą). Be to, ištobulinus tik dalį galimybių, gali prireikti visiškai pertvarkyti visą sistemą. Autorius atkreipia dėmesį į perdėto įmantrumo riziką tuo atveju, kai idėja klaidinga.
Norint pašalinti riziką, būtina greitai gauti grįžtamąjį ryšį apie kuriamą prekę, kad būtų kuo mažesnė žala sukuriant „neteisingą“ produktą. Padarėme idėjos eskizą – patvirtinome ją su vartotoju, eskizavome sąsajos prototipus – patvirtinome su vartotoju ir t.t. (Atskirai yra šiek tiek informacijos apie programų prototipų patvirtinimą). Programinės įrangos kūrimo tikslai, ypač pradiniame etape, yra mokymasis, atitinkamai gaunant greitą grįžtamąjį ryšį, pirmasis sukurtas produktas yra eskizai, galintys įrodyti arba paneigti hipotezę. (Autorius remiasi Erico Rieso darbu „Startup using Lean methodology“).
Istorijos žemėlapis padeda pagerinti komunikaciją, kai įgyvendinama keliose komandose. Kas turėtų būti žemėlapyje? Ko reikia, kad pokalbis tęstųsi. Ne tik vartotojo istorija (kas, kas, kodėl), bet idėjos, faktai, sąsajos eskizai ir t.t.
Istorijos žemėlapyje kortas suskirstę į kelias horizontalias eilutes, darbus galite suskirstyti į leidimus – paryškinkite minimumą, didėjančio funkcionalumo sluoksnį ir nusilenkimus.
Mes pasakojame istorijas proceso žemėlapyje.
Darbuotoja atėjo papietauti.
Ko jis nori? Aptarnavimo greitis. Kad jo pietūs jau lauktų ant stalo ar bent jau ant padėklo. Oi – praleistas žingsnis: darbuotojas norėjo valgyti. Jis prisijungė ir pasirinko verslo pietų variantą. Jis matė kalorijų ir maistinių medžiagų kiekį, kad padėtų jam laikytis dietos ir nepriaugti svorio. Jis pamatė patiekalo nuotraukas, kad nuspręstų, ar valgys toje vietoje, ar ne.
Tada jis eis pietų ir vakarienės? O gal pietūs bus pristatyti į jo biurą? Tada proceso žingsnis yra vietos valgymui pasirinkimas. Jis nori pamatyti, kada jis jam bus pristatytas ir kiek kainuos, todėl gali pasirinkti, kur leisti laiką ir energiją – nusileisti ar eiti į darbą. Jis nori pamatyti, kaip kavinė yra užimta, kad nesistumdytų eilėse.
Tada darbuotojas atėjo į kavinę. Jis nori pamatyti savo padėklą, kad galėtų jį paimti ir eiti tiesiai pietauti. Kavinė nori priimti pinigus, kad užsidirbtų pinigų iš aptarnavimo. Darbuotojas nori sugaišti minimalų laiką atsiskaitymams su kavine, kad nešvaistytų brangaus laiko be reikalo. Kaip tai padaryti? Mokėkite iš anksto arba atvirkščiai po aptarnavimo nuotoliniu būdu. Arba atsiskaitykite vietoje naudodami kioską. Kas čia yra svarbiausia? Kiek žmonių nori mokėti už pietus banko kortele? Kiek žmonių patikėtų šiai valgyklai išsaugoti savo kortelės numerį pakartotiniams mokėjimams? Be lauko tyrimų neaišku, bandymai reikalingi.
Kiekviename proceso etape reikia kažkaip suteikti funkcionalumą tam, kad būtų pagrindas, ir pasirinkti, kas jam svarbiau (tie patys trys parinkikliai). Sekė istoriją iki galo = padarė perspektyvų sprendimą.
Toliau seka detalės. Klientas nori pamatyti, kaip kavinė yra užimta, kad nesistumdytų eilėse. Ko tiksliai jis nori?
Pažiūrėkite prognozę, kiek žmonių bus po 15 minučių, kai jis ten atvyks
Vidutinį aptarnavimo laiką kavinėje ir jo dinamiką pasižiūrėkite prieš pusvalandį
Peržiūrėkite situaciją ir stalų užimtumo dinamiką
Ką daryti, jei prognozavimo sistema duoda neaiškų rezultatą arba nustoja veikti?
Per vaizdo įrašą žiūrėkite eiles kavinėje, taip pat staliukų užimtumą. Hmm, kodėl to nepadarius pirma?!
Autorius nurodo nedidelį pratimą, kurį reikia praktikuoti: pabandykite įsivaizduoti, ką darote ryte, pabudę. Viena korta = vienas veiksmas. Padidinkite korteles (užuot malę kavą, gerkite gaivinantį gėrimą), kad pašalintumėte atskiras detales, sutelkdami dėmesį ne į įgyvendinimo būdą, o į tikslą.
Kam skirta ši knyga: IT analitikams ir projektų vadovams. Būtina perskaityti.
Apps "
Diskusija ir sprendimų priėmimas yra veiksmingi grupėse nuo 3 iki 5 žmonių.
Pirmoje kortelėje parašykite, ką reikia tobulinti, antroje - pataisykite tai, ką padarėte pirmoje, trečioje - pataisykite, kas buvo padaryta pirmoje ir antroje.
Ruoškite istorijas kaip pyragus – ne išrašydami receptą, o išsiaiškindami, kam, kokiai progai ir kiek žmonių tortas skirtas. Jei išskaidytume pardavimus, tai būtų ne į tortų, grietinėlės ir pan., o į mažų gatavų tortų gamybą.
Programinės įrangos kūrimas yra panašus į filmo kūrimą, kai prieš pradedant filmavimą reikia kruopščiai išvystyti ir nušlifuoti scenarijų, organizuoti sceną, aktorius ir pan.
Išteklių visada trūks.
20% pastangų duoda apčiuopiamus rezultatus, 60% nesuprantamus rezultatus, 20% pastangų yra žalingos – štai kodėl svarbu susitelkti į mokymąsi ir nenusiminti esant neigiamam rezultatui.
Tiesiogiai bendraukite su vartotoju, jauskitės jo vietoje. Sutelkite dėmesį į kai kurias problemas.
Istorijos detalizavimas ir plėtojimas vertinimui yra pati niūriausia skraidinimo dalis, diskusijas paverskite akvariumo režimu (3-4 žmonės diskutuoja prie lentos, jei kas nori dalyvauti, jis ką nors pakeičia).
Šaltinis: www.habr.com