abstrakt
Libri është një algoritëm i rrëfyer për kryerjen e procesit të zhvillimit nga ideja në zbatim duke përdorur teknika të shkathëta. Procesi është paraqitur në hapa dhe në çdo hap tregohen metodat për hapin e procesit. Autori thekson se shumica e metodave nuk janë origjinale, pa pretenduar se janë origjinale. Por stili i mirë i të shkruarit dhe njëfarë integriteti i procesit e bëjnë librin shumë të dobishëm.
Një teknikë kyçe e hartës së historive të përdoruesve është strukturimi i ideve dhe performancave ndërsa përdoruesi lëviz nëpër proces.
Në të njëjtën kohë, procesi mund të përshkruhet në mënyra të ndryshme. Ju mund të ndërtoni hapa ndërsa arrini një vlerë kryesore, ose thjesht mund të merrni dhe imagjinoni ditën e punës së përdoruesve ndërsa kalon duke përdorur sistemin. Autori fokusohet në faktin se proceset duhet të përvijohen, të fliten në formën e një historie përdoruesi në një hartë procesi, gjë që na dha emrin harta e historisë së përdoruesit.
Kush ka nevojë për të
Për analistët e IT dhe menaxherët e projekteve. Një që duhet lexuar. Lehtë dhe e këndshme për t'u lexuar, libri është me përmasa mesatare.
risjell
Në formën e tij më të thjeshtë, kjo është se si funksionon.
Një vizitor vjen në një kafene, zgjedh pjata, bën një porosi, merr ushqim, ha dhe paguan.
Ne mund të shkruajmë kërkesat për atë që duam nga sistemi në çdo fazë.
Sistemi duhet të tregojë një listë të pjatave, çdo pjatë ka një përbërje, peshë dhe çmim dhe të jetë në gjendje të shtohet në karrocë. Pse jemi të sigurt në këto kërkesa? Kjo nuk përshkruhet në përshkrimin “standard” të kërkesave dhe kjo krijon rreziqe.
Interpretuesit që nuk e kuptojnë pse kjo është e nevojshme zakonisht bëjnë gjënë e gabuar. Interpretuesit që nuk janë të përfshirë në procesin e krijimit të një ideje nuk përfshihen në rezultat. Agile thotë, le të përqendrohemi kryesisht jo te sistemi, por te njerëzit, te konsumatorët, detyrat dhe qëllimet e tyre.
Ne krijojmë persona, u japim atyre detaje për ndjeshmëri dhe fillojmë të tregojmë histori nga ana e personazhit.
Punonjësi i zyrës Zakhar shkoi për drekë dhe dëshiron të hajë një rostiçeri të shpejtë. Çfarë ka nevojë ai? Ideja është që ai ndoshta dëshiron një drekë biznesi. Një tjetër ide është se ai dëshiron që sistemi të kujtojë preferencat e tij, sepse ai është në dietë. Një ide tjetër. Ai dëshiron që menjëherë t'i sjellë kafe, sepse është mësuar të pijë kafe para drekës.
Dhe ka gjithashtu një biznes (një karakter organizativ është një personazh që përfaqëson interesat e një organizate). Bizneset duan të rrisin kontrollin mesatar, të rrisin shpeshtësinë e blerjeve dhe të rrisin fitimet. Ideja është - le të ofrojmë pjata të pazakonta të ndonjë kuzhine. Një ide tjetër - le të prezantojmë mëngjesin.
Idetë mund dhe duhet të konkretizohen, transformohen dhe paraqiten në formën e një historie përdoruesi. Si punonjës i Qendrës së Biznesit Zakhar, dua që sistemi të më njohë në mënyrë që të marr një menu bazuar në preferencat e mia. Si kamarier dua që sistemi të më njoftojë se kur duhet t'i afrohem tavolinës në mënyrë që klienti të jetë i kënaqur me shërbimin e shpejtë. Dhe kështu me radhë.
Dhjetra histori. Tjetra është prioritizimi dhe prapambetja? Jeff vë në dukje problemet që lindin: ngecja në detaje të vogla dhe humbja e të kuptuarit konceptual, plus prioritizimi i funksionalitetit krijon një pamje të prishur për shkak të mospërputhjes me qëllimet.
Rruga e autorit: Ne i japim përparësi jo funksionalitetit, por rezultatit = çfarë merr përdoruesi në fund.
Një pikë e dukshme jo e dukshme: seanca e prioritizimit nuk kryhet nga i gjithë ekipi, sepse është joefektiv, por nga tre persona. E para është përgjegjëse për biznesin, e dyta për përvojën e përdoruesit dhe e treta për zbatimin.
Le të zgjedhim minimumin për zgjidhjen e problemit të një përdoruesi (zgjidhja minimale e zbatueshme).
Ne detajojmë idetë e prioritetit të parë duke përdorur historitë e përdoruesve, skicat e projektimit, kufizimet dhe rregullat e biznesit në hartën e historisë së përdoruesit duke treguar dhe diskutuar me ekipin se çfarë kanë nevojë njerëzit dhe palët e interesuara në çdo hap të procesit. I lëmë idetë e mbetura të pashqyrtuara në numrin e madh të mundësive.
Procesi shkruhet në karta nga e majta në të djathtë, me ide në kartat poshtë hapave të procesit. Është e domosdoshme që rruga e gjithë historisë të diskutohet së bashku me anëtarët e ekipit për të siguruar mirëkuptim të ndërsjellë.
Elaborimi në këtë mënyrë krijon integritet në përputhje me proceset.
Idetë e marra duhet të testohen. Një anëtar jo i ekipit i vendos personit kapelen dhe e jeton ditën e personit në kokën e tij, duke i zgjidhur problemin e tij. Ka mundësi që ai të mos shohë zhvillimet, duke krijuar sërish karta dhe skuadra të zbulojë alternativa për vete.
Pastaj ka detaje për vlerësim. Për këtë mjaftojnë tre persona. Përgjegjës për përvojën e përdoruesit, zhvillues, testues me një pyetje të preferuar: "Po sikur...".
Në çdo fazë, diskutimi ndjek një hartë procesi të historisë së përdoruesit, e cila lejon mbajtjen në mendje të detyrës së përdoruesit për të krijuar një kuptim koherent.
A është i nevojshëm dokumentacioni sipas mendimit të autorit? Po, kam nevojë për të. Por si shënime që ju lejojnë të mbani mend atë që keni rënë dakord. Përfshirja e një të huaji përsëri kërkon diskutim.
Autori nuk thellohet në temën e mjaftueshmërisë së dokumentacionit, duke u ndalur në nevojën e diskutimit. (Po, dokumentacioni duhet, pavarësisht se si e pretendojnë njerëzit që nuk e kuptojnë thellë të shkathët). Gjithashtu, përpunimi i vetëm një pjese të aftësive mund të çojë në nevojën për një ripërpunim të plotë të të gjithë sistemit. Autori vë në dukje rrezikun e shtjellimit të tepruar në rastin kur ideja është e gabuar.
Për të eliminuar rreziqet, është e nevojshme të merrni shpejt reagime për produktin që po krijohet për të minimizuar dëmin e krijimit të produktit "të gabuar". Ne bëmë një skicë të idesë - e vërtetuam atë me përdoruesin, skicuam prototipet e ndërfaqes - e vërtetuam atë me përdoruesin, etj. (Më vete, ka pak informacion se si të vërtetohen prototipet e programit). Qëllimet e krijimit të softuerit, veçanërisht në fazën fillestare, janë të mësuarit përmes marrjes së reagimeve të shpejta; në përputhje me rrethanat, produkti i parë i krijuar janë skicat që janë në gjendje të provojnë ose hedhin poshtë një hipotezë. (Autori mbështetet në veprën e Eric Ries "Startup duke përdorur metodologjinë Lean").
Një hartë historish ndihmon në përmirësimin e komunikimit kur zbatimi kryhet në ekipe të shumta. Çfarë duhet të jetë në hartë? Çfarë ju nevojitet për të vazhduar bisedën. Jo vetëm një histori përdoruesi (kush, çfarë, pse), por ide, fakte, skica të ndërfaqes, etj...
Duke i ndarë kartat në hartën e historisë në disa vija horizontale, mund ta ndani punën në lëshime - theksoni minimumin e thjeshtë, një shtresë funksionaliteti në rritje dhe harqe.
Ne tregojmë histori në hartën e procesit.
Një punonjës erdhi për drekë.
Çfarë dëshiron ai? Shpejtësitë e shërbimit. Kështu që dreka e tij tashmë e pret në tavolinë ose të paktën në një tabaka. Oops - një hap i humbur: punonjësi donte të hante. Ai u identifikua dhe zgjodhi opsionin e drekës së biznesit. Ai pa përmbajtjen e kalorive dhe përmbajtjen ushqyese për ta ndihmuar atë të mbajë dietë dhe të mos shtojë peshë. Ai pa foto të gjellës për të vendosur nëse do të hante në atë vend apo jo.
Më pas, a do të shkojë të marrë drekë dhe darkë? Apo ndoshta dreka do të dorëzohet në zyrën e tij? Pastaj hapi i procesit është zgjedhja e një vendi për të ngrënë. Ai dëshiron të shohë se kur do t'i dorëzohet dhe sa do t'i kushtojë, kështu që ai mund të zgjedhë se ku do të kalojë kohën dhe energjinë e tij - të zbresë në katin e poshtëm apo të shkojë në punë. Ai dëshiron të shohë se sa e zënë është kafeneja për të mos u përplasur në radhë.
Pastaj punonjësi erdhi në kafe. Ai dëshiron të shohë tabakanë e tij që të mund ta marrë dhe të shkojë direkt në darkë. Kafeneja dëshiron të pranojë para për të fituar para në shërbim. Punonjësi dëshiron të humbasë një minimum kohe në vendbanimet me kafenenë, në mënyrë që të mos humbasë kohën e çmuar kot. Si ta bëjmë atë? Paguani paraprakisht ose anasjelltas pas shërbimit nga distanca. Ose paguani në vend duke përdorur një kioskë. Cila është gjëja më e rëndësishme për këtë? Sa njerëz janë të gatshëm të paguajnë për drekën me një kartë bankare? Sa njerëz do t'i besonin kësaj mense për të ruajtur numrin e kartës së tyre për pagesa të përsëritura? Pa kërkime në terren është e paqartë, nevojitet testim.
Në çdo hap të procesit, ju duhet të siguroni disi funksionalitetin; për këtë ju duhet të merrni një person si bazë dhe të zgjidhni atë që është më e rëndësishme për të (të njëjtët tre përzgjedhës). Ndoqi historinë deri në fund = bëmë një zgjidhje të zbatueshme.
Më pas vjen detajimi. Klienti dëshiron të shohë se sa e zënë është kafeneja, në mënyrë që të mos përplaset në radhë. Çfarë saktësisht dëshiron ai?
Shikoni parashikimin se sa njerëz do të ketë në 15 minuta kur ai të arrijë atje
Shikoni kohën mesatare të shërbimit në një kafene dhe dinamikën e saj gjysmë ore përpara
Shihni situatën dhe dinamikën e zënies së tavolinës
Po sikur sistemi i parashikimit të japë një rezultat të paqartë ose të ndalojë së punuari?
Shikoni përmes video radhët në kafene, si dhe zënien e tavolinave. Hmm, pse të mos e bëni këtë fillimisht?!
Autori tregon një ushtrim të vogël për të praktikuar: përpiquni të imagjinoni se çfarë bëni në mëngjes pasi të zgjoheni. Një kartë = një veprim. Zmadhoni kartat (në vend që të bluani kafe, pini një pije gjallëruese) për të hequr detajet individuale, duke u fokusuar jo në metodën e zbatimit, por në qëllimin.
Për kë është ky libër: analistët e IT dhe menaxherët e projektit. Një që duhet lexuar.
Apps
Diskutimi dhe vendimmarrja janë efektive në grupe prej 3 deri në 5 persona.
Shkruani në kartën e parë atë që duhet të zhvillohet, në të dytën - korrigjoni atë që keni bërë në të parën, në të tretën - korrigjoni atë që është bërë në të parën dhe të dytën.
Përgatitni histori si ëmbëlsira - jo duke shkruar një recetë, por duke zbuluar se për kë, për çfarë rasti dhe për sa njerëz është torta. Nëse i zbërthejmë shitjet, atëherë nuk do të ishte në prodhimin e ëmbëlsirave, kremrave etj., por në prodhimin e ëmbëlsirave të vogla të gatshme.
Zhvillimi i softuerit është i ngjashëm me bërjen e një filmi, kur ju duhet të zhvilloni dhe lustroni me kujdes skenarin, të organizoni skenën, aktorët, etj. përpara se të filloni xhirimet.
Gjithmonë do të ketë mungesë burimesh.
20% e përpjekjeve prodhojnë rezultate të prekshme, 60% japin rezultate të pakuptueshme, 20% e përpjekjeve janë të dëmshme - prandaj është e rëndësishme të përqendroheni në të mësuarit dhe të mos dëshpëroheni në rast të një rezultati negativ.
Komunikoni drejtpërdrejt me përdoruesin, ndjeni veten në këpucët e tij. Përqendrohuni në disa probleme.
Detajimi dhe zhvillimi i historisë për vlerësim është pjesa më e zymtë e scrum, bëjini diskutimet të ngrihen në modalitetin e akuariumit (3-4 persona diskutojnë në tabelë, nëse dikush dëshiron të marrë pjesë, ai zëvendëson dikë).
Burimi: www.habr.com