Abstrakta
La libro estas rakontita algoritmo por efektivigi la evoluprocezon de ideo ĝis efektivigo uzante lertajn teknikojn. La procezo estas aranĝita en ŝtupoj kaj ĉe ĉiu paŝo la metodoj por la proceza paŝo estas indikitaj. La aŭtoro atentigas, ke la plej multaj el la metodoj ne estas originalaj, sen pretendi esti originalaj. Sed la bona skribstilo kaj iom da integreco de la procezo faras la libron tre utila.
Esenca tekniko de uzantrakontmapado devas strukturi ideojn kaj prezentojn kiam la uzanto moviĝas tra la procezo.
Samtempe, la procezo povas esti priskribita en malsamaj manieroj. Vi povas konstrui paŝojn dum vi atingas ŝlosilan valoron, aŭ vi povas simple preni kaj imagi la labortagon de la uzantoj dum ĝi pasas uzante la sistemon. La aŭtoro fokusiĝas al tio, ke procezoj devas esti skizitaj, parolitaj en formo de uzantrakonto sur procezmapo, kio donis al ni la nomon uzantrakontomapo.
Kiu bezonas ĝin
Por IT-analizistoj kaj projektestroj. Nepre leginda. Facila kaj agrabla legebla, la libro estas mezgranda.
Retrosciigo
En ĝia plej simpla formo, jen kiel ĝi funkcias.
Vizitanto venas al kafejo, elektas pladojn, faras mendon, ricevas manĝaĵon, manĝas kaj pagas.
Ni povas skribi postulojn por tio, kion ni volas de la sistemo en ĉiu etapo.
La sistemo devus montri liston de pladoj, ĉiu plado havas komponadon, pezon kaj prezon kaj povi aldoni al ĉaro. Kial ni fidas pri ĉi tiuj postuloj? Ĉi tio ne estas priskribita en la "norma" priskribo de postuloj kaj ĉi tio kreas riskojn.
Prezentistoj, kiuj ne komprenas kial tio estas necesa, kutime faras la malĝustan aferon. Prezentistoj, kiuj ne estas implikitaj en la procezo de kreado de ideo, ne estas implikitaj en la rezulto. Agile diras, ni koncentriĝu ĉefe ne al la sistemo, sed al homoj, al konsumantoj, iliaj taskoj kaj celoj.
Ni kreas personojn, donas al ili detalojn por empatio, kaj komencas rakonti rakontojn de la flanko de la persono.
Oficeja dungito Zakhar iris tagmanĝi kaj volas manĝi rapidan manĝeton. Kion li bezonas? La ideo estas, ke li verŝajne volas komercan tagmanĝon. Alia ideo estas, ke li volas, ke la sistemo memoru siajn preferojn, ĉar li estas dieto. Alia ideo. Li volas tuj alporti kafon al li, ĉar li kutimas trinki kafon antaŭ la tagmanĝo.
Kaj ekzistas ankaŭ komerco (organiza karaktero estas karaktero reprezentanta la interesojn de organizo). Komercoj volas pliigi la averaĝan ĉekon, pliigi la oftecon de aĉetoj kaj pliigi profitojn. La ideo estas - ni proponu nekutimajn pladojn de iu kuirarto. Alia ideo - ni enkonduku matenmanĝon.
Ideoj povas kaj devas esti konkretigitaj, transformitaj kaj prezentitaj en formo de uzantrakonto. Kiel dungito de la Zakhar Komerca Centro, mi volas, ke la sistemo rekonu min, por ke mi povu ricevi menuon laŭ miaj preferoj. Kiel kelnero, mi volas, ke la sistemo sciigu min, kiam mi alproksimiĝu al la tablo, por ke la kliento estu kontenta pri rapida servo. Kaj tiel plu.
Dekoj da rakontoj. Sekva estas prioritato kaj restaro? Jeff substrekas la problemojn kiuj ekestas: enŝtopiĝi en malgrandaj detaloj kaj perdi koncipan komprenon, krome prioritati funkciecon kreas ĉifonan bildon pro malkongruo kun celoj.
La vojo de la aŭtoro: Ni prioritatas ne la funkciecon, sed la rezulton = kion la uzanto ricevas finfine.
Evidenta neevidenta punkto: la prioritatsesion ne estas farata de la tuta teamo, ĉar ĝi estas senefika, sed de tri homoj. La unua respondecas pri komerco, la dua pri sperto de uzanto kaj la tria pri efektivigo.
Ni elektu la minimumon por solvi unu uzantan problemon (minimuma realigebla solvo).
Ni detaligas la unuajn prioritatajn ideojn uzante uzantrakontojn, projektajn skizojn, limojn kaj komercajn regulojn sur la uzantrakontmapo rakontante kaj diskutante kun la teamo, kion homoj kaj koncernatoj bezonas ĉe ĉiu paŝo de la procezo. Ni lasas la ceterajn ideojn ne ekzamenitaj en la restado de ŝancoj.
La procezo estas skribita sur kartoj de maldekstre dekstren, kun ideoj sur kartoj sub la procezaj paŝoj. Nepras, ke la vojo tra la tuta rakonto estu diskutita kune kun la teamanoj por certigi reciprokan komprenon.
Ellaboro tiamaniere kreas integrecon konforme al procezoj.
La ideoj ricevitaj devas esti provitaj. Ne-teamano surmetas la ĉapelon de la persono kaj vivas la tagon de la persono en sia kapo, solvante sian problemon. Eblas, ke li ne vidas la evoluojn, kreante kartojn denove, kaj la teamo malkovras alternativojn por si mem.
Poste estas detaloj por taksado. Tri homoj sufiĉas por tio. Respondeca pri sperto de uzanto, programisto, testisto kun plej ŝatata demando: "Kio se...".
En ĉiu stadio, la diskuto sekvas procezmapon de la historio de la uzanto, kio permesas konservi la taskon de la uzanto en menso por krei koheran komprenon.
Ĉu dokumentado necesas laŭ la opinio de la aŭtoro? Jes, mi bezonas ĝin. Sed kiel notoj kiuj permesas vin memori pri kio vi konsentis. Engaĝi eksterulon denove postulas diskuton.
La aŭtoro ne enprofundiĝas en la temon de sufiĉo de dokumentado, enfokusigante la bezonon de diskuto. (Jes, dokumentado necesas, kiom ajn homoj, kiuj ne havas profundan komprenon pri lerta, asertas ĝin). Ankaŭ, ellaborado de nur parto de la kapabloj povas konduki al la bezono de kompleta reverkado de la tuta sistemo. La aŭtoro atentigas la riskon de troa ellaborado en la kazo kiam la ideo estas malĝusta.
Por forigi riskojn, necesas rapide ricevi reagojn pri la produkto kreita por minimumigi la damaĝon de kreado de la "malĝusta" produkto. Ni faris skizon de la ideo - validigis ĝin kun la uzanto, skizis interfacprototipojn - validigis ĝin kun la uzanto, ktp. (Aparte, estas iom da informoj pri kiel validigi programprototipojn). La celoj de kreado de programaro, precipe en la komenca etapo, estas lernado per ricevado de rapida sugesto; sekve, la unua produkto kreita estas skizoj kiuj povas pruvi aŭ kontraŭpruvi hipotezon. (La aŭtoro dependas de la laboro de Eric Ries "Startup using Lean methodology").
Rakonta mapo helpas plibonigi komunikadon kiam efektivigo estas farita tra pluraj teamoj. Kio devus esti sur la mapo? Kion vi bezonas por daŭrigi la konversacion. Ne nur uzantrakonto (kiu, kio, kial), sed ideoj, faktoj, interfacskizoj, ktp...
Dividante la kartojn sur la historia mapo en plurajn horizontalajn liniojn, vi povas dividi la laboron en eldonojn - reliefigi la nuran minimumon, tavolon de kreskanta funkcieco kaj arkoj.
Ni rakontas rakontojn sur la proceza mapo.
Venis oficisto por tagmanĝi.
Kion li volas? Servaj rapidoj. Por ke lia tagmanĝo jam atendas lin sur la tablo aŭ almenaŭ sur pleto. Ho - preterpasita paŝo: la dungito volis manĝi. Li ensalutis kaj elektis la komercan tagmanĝan opcion. Li vidis la kalorian enhavon kaj nutran enhavon por helpi lin dieti kaj ne plipeziĝi. Li vidis bildojn de la plado por decidi ĉu li manĝos ĉe tiu loko aŭ ne.
Poste, ĉu li iros tagmanĝi kaj vespermanĝi? Aŭ eble la tagmanĝo estos liverata al lia oficejo? Tiam la paŝo de la procezo estas elekti lokon por manĝi. Li volas vidi, kiam ĝi estos liverita al li kaj kiom ĝi kostos, do li povas elekti kie pasigi sian tempon kaj energion - malsupreniri aŭ labori. Li volas vidi, kiel okupata estas la kafejo por ne puŝiĝi en vicoj.
Tiam la dungito venis al la kafejo. Li volas vidi sian pleton, por ke li povu preni ĝin kaj iri rekte al vespermanĝo. La kafejo volas akcepti monon por gajni monon per servo. La oficisto volas perdi minimumon da tempo en kompromisoj kun la kafejo, por ne malŝpari valoran tempon senutile. Kiel fari ĝin? Pagu anticipe aŭ inverse post servo malproksime. Aŭ pagu surloke per kiosko. Kio estas la plej grava afero pri ĉi tio? Kiom da homoj pretas pagi tagmanĝon per bankkarto? Kiom da homoj fidus ĉi tiun kantinon por konservi sian kartan numeron por ripetaj pagoj? Sen kampa esploro estas neklara, testado necesas.
Je ĉiu paŝo de la procezo, vi devas iel provizi funkciojn; por tio vi devas preni iun personon kiel bazon kaj elekti tion, kio estas pli grava por li (la samaj tri elektiloj). Sekvis la rakonton ĝis la fino = faris fareblan solvon.
Poste venas la detalo. La kliento volas vidi kiom okupata estas la kafejo, por ne puŝiĝi en vicoj. Kion precize li volas?
Vidu la prognozon pri kiom da homoj estos post 15 minutoj kiam li alvenos tien
Rigardu la mezan servotempon en kafejo kaj ĝian dinamikon duonhoron antaŭe
Vidu la situacion kaj la dinamikon de okupado de tablo
Kio se la prognoza sistemo donas neklaran rezulton aŭ ĉesas funkcii?
Rigardu per video la vicojn en la kafejo, kaj ankaŭ la okupadon de tabloj. Hmm, kial ne fari tion unue?!
La aŭtoro montras etan ekzercon por ekzerci: provu imagi, kion vi faras matene post vekiĝo. Unu karto = unu ago. Pligrandigu la kartojn (anstataŭ mueli kafon, trinku vigligan trinkaĵon) por forigi individuajn detalojn, koncentriĝante ne al la metodo de efektivigo, sed al la celo.
Por kiu ĉi tiu libro estas: IT-analizistoj kaj projektestroj. Nepre leginda.
Приложения
Diskuto kaj decidiĝo estas efikaj en grupoj de 3 ĝis 5 homoj.
Skribu sur la unua karto tion, kion oni devas disvolvi, sur la dua - korektu tion, kion vi faris en la unua, sur la tria - korektu tion, kio estis farita en la unua kaj dua.
Preparu rakontojn kiel kukojn - ne skribante recepton, sed eksciante al kiu, por kiu okazo kaj al kiom da homoj estas la kuko. Se ni rompas la vendojn, tiam ĝi estus ne en la produktado de kukoj, kremo, ktp., sed en la produktado de malgrandaj pretaj kukoj.
Disvolviĝo de programaro similas al farado de filmo, kiam vi bezonas zorge disvolvi kaj poluri la skripton, organizi la scenon, aktorojn, ktp antaŭ ol la filmado komenciĝas.
Ĉiam mankos rimedoj.
20% de klopodoj produktas palpeblajn rezultojn, 60% donas nekompreneblajn rezultojn, 20% de klopodoj estas malutilaj - tial gravas koncentriĝi pri lernado kaj ne malesperi en kazo de negativa rezulto.
Komuniku rekte kun la uzanto, sentu vin en liaj ŝuoj. Fokuso sur iuj problemoj.
Detaligi kaj disvolvi la rakonton por taksado estas la plej malgaja parto de scrum, starigu la diskutojn en akvario-reĝimo (3-4 homoj diskutas ĉe la estraro, se iu volas partopreni, li anstataŭigas iun).
fonto: www.habr.com