Shënimi
Libri është një rrëfim i algoritmit të zhvillimit nga ideja deri në zbatim, duke përdorur teknika agile. Procesi ndahet në hapa dhe në çdo hap përshkruhen metodat e procesit. Autori thekson se shumica e metodave nuk janë origjinale dhe nuk pretendojnë të jenë të tilla. Por stili i mirë i përshkrimit dhe një konsistencë e caktuar e procesit e bëjnë librin shumë të dobishëm.
Teknika kyçe e hartës së historive të përdoruesve është strukturimi i ideve dhe formulimi i qëllimeve gjatë kalimit të procesit nga ana e përdoruesit.
Megjithatë, kalimi i procesit mund të përshkruhet në mënyra të ndryshme. Mund të organizoni hapat sipas arritjes së vlerës kyçe, ose mund ta paraqisni thjesht ditën e punës së përdoruesve, sa herë që ata përdorin sistemin. Autori përqendrohet në faktin se proceset duhet të përshkruhen, të tregohet si histori përdoruesi mbi hartën e procesit, që shërben si titulli "harta e historive të përdoruesve".
Kush e ka këtë nevojë
Për analistët IT dhe menaxherët e projekteve. E domosdoshme për t'u lexuar. Leximi është i lehtë dhe i këndshëm, libri është me përmasë mesatare.
Rishikimi
Në formën më të thjeshtë, si funksionon.
Vizitori vjen në kafene, zgjedh pjatat, bën porosinë, merr ushqimin, ha, dhe paguan.
Mund të shkruani kërkesat për atë që dëshirojmë nga sistemi në çdo hap.
Sistemi duhet të tregojë një listë pjatash, çdo pjatë duhet të ketë përbërësit, peshën dhe çmimin dhe mundësinë për t'u shtuar në karrocë. Pse jemi të sigurt për këto kërkesa? Në përshkrimin "standarde" të kërkesave kjo nuk përshkruhet dhe krijon rreziqe.
Kryesorët, të cilët nuk e kuptojnë pse është e nevojshme, zakonisht nuk bëjnë atë që është e nevojshme. Kryesorët që nuk janë të angazhuar në procesin e krijimit të ideve, nuk janë të angazhuar as në rezultat. Agile thotë, le t'u japim prioritet jo sistemit, por njerëzve, konsumatorëve, detyrave dhe qëllimeve të tyre.
Krijojmë persona, atyre u japim detaje për empati dhe nga këndvështrimi i personave fillojmë të përshkruajmë historitë.
PunonjĂ«si i zyrĂ«s, Zahari, doli pĂ«r drekĂ« dhe dĂ«shiron tĂ« hajĂ« shpejt. ĂfarĂ« i nevojitet? Ideja â ndoshta ai dĂ«shiron njĂ« drekĂ« biznesi. NjĂ« tjetĂ«r ide Ă«shtĂ« se ai dĂ«shiron qĂ« sistemi tĂ« mbajĂ« mend preferencat e tij, pasi ai Ă«shtĂ« nĂ« dietĂ«. NjĂ« ide tjetĂ«r. Ai dĂ«shiron qĂ« t'i sjellin kafenĂ« menjĂ«herĂ«, sepse ai ka zakon tĂ« pijĂ« kafe para drekĂ«s.
Ka ka është një biznes tjetër (karakteri - personazhi që përfaqëson interesat e një organizate). Biznesi dëshiron të rrisë biletën mesatare, të rrisë frekuencën e blerjeve, të rrisë fitimin. Ideja është - po, le të ofrojmë pjata të pazakonta nga ndonjë kuzhinë. Një ide tjetër - po, le të prezantojmë mëngjeset.
Idejat mund dhe duhet të konkretizohen, të transformohen dhe të paraqiten në formën e një histori përdoruesi. Si punonjës i qendrës së bizneseve, Zahari, dua që sistemi të më njohë, që të marr një menu në përputhje me preferencat e mia. Si kamarier, dua që sistemi të më njoftojë kur të afrohem te tavolina, për të siguruar që klienti të jetë i kënaqur me shërbimin e shpejtë. E kështu me radhë.
Dhjetëra histori. Më pas, përprioritizimi dhe backlog? Jeffi thekson problemet që dalin: përfshirja në detaje të vogla dhe humbja e kuptimit konceptual, plus përprioritizimi i funksioneve krijon një pamje të çarë për shkak të moskoordinimit me qëllimet.
Rruga e autorit: Ne përprioritojmë jo funksionalitetin, por rezultatin = atë që përdoruesi merr në fund.
Një pikë e qartë jo e qartë: sesioni i përprioritizimit nuk kalon nga të gjithë anëtarët e ekipit, sepse nuk është efektiv, por nga tre persona. I pari është përgjegjës për biznesin, i dyti për përvojën e përdoruesit dhe i treti për implementimin.
Të theksojmë minimumin për zgjidhjen e një problemi të përdoruesit (zgjidhja minimale e jetueshme).
Të detajojmë idetë e prioritetit të parë me ndihmën e një historie përdoruesi, skicave të dizajnit, kufizimeve dhe rregullave të biznesit në hartën e historive të përdoruesve duke treguar dhe diskutuar me ekipin se çfarë nevojitet për personat dhe palët e interesuara në çdo hap të procesit. Idetë e tjera i lëmë të paqarta në backlog të mundësive.
Procesi shkruhet nĂ« formĂ« kartelash nga majtas drejt djathtas, dhe idetĂ« nĂ« kartela nĂ«n hapat e procesit. ĂshtĂ« thelbĂ«sore qĂ« rruga e kalimit tĂ« gjithĂ« historisĂ« tĂ« diskutohet sĂ« bashku me anĂ«tarĂ«t e ekipit pĂ«r tĂ« krijuar njĂ« mirkuptim.
Përpunimi në këtë mënyrë krijon një plotësi në përputhje me proceset.
Idetë që janë marrë duhet të kontrollohen. Një anëtar i ekipit vesh kapelen e personazhit dhe jeton në mendjen e personazhit për një ditë, duke zgjidhur problemin e tij. Ka mundësi që ai të mos shohë materialet përkatëse, duke krijuar kartela nga e para, ndërkohë që ekipi zbulon alternativa.
Pas ndodh detajizimi pĂ«r vlerĂ«simin. PĂ«r kĂ«tĂ« mjafton tre persona. NjĂ« pĂ«rgjegjĂ«s pĂ«r pĂ«rvojĂ«n e pĂ«rdoruesit, zhvilluesi, dhe testi me pyetjen e tij tĂ« preferuar: âPo nĂ«seâŠâ.
Në çdo etapë, diskutimi zhvillohet mbi hartën e procesit të historisë së përdoruesit, e cila lejon, duke mbajtur në mendje detyrën e përdoruesit, të krijohet një kuptim i plotë.
A është e nevojshme dokumentacioni sipas autorit? Po, është e nevojshme. Por si shënime që lejojnë për të kujtuar për çfarë u ra dakord. Angazhimi i një personi nga jashtë përsëri kërkon diskutim.
Autori nuk thellohet në temën e mjaftueshmërisë së dokumentacionit, duke e përqëndruar theksin në nevojën për diskutime. (Po, dokumentacioni është i nevojshëm, pavarësisht se si e pretendonin ata që nuk kanë kuptim të thellë mbi agile). Po ashtu, trajtimi vetëm i pjesës së mundësive mund të çojë në nevojën për të riparuar të gjithë sistemin. Autori nënvizon rrezikun e përpunimit të tepruar në rast se nuk u godit me idenë.
PĂ«r tĂ« eleminuar rreziqet, Ă«shtĂ« e nevojshme tĂ« merrni shpejt feedback mbi produktin qĂ« po krijoni pĂ«r tĂ« minimizuar dĂ«mimin e krijimit tĂ« âproduktit tĂ« gabuarâ. BĂ«ni njĂ« skicĂ« tĂ« ideve â validoni me pĂ«rdoruesin, skicat e prototipeve tĂ« ndĂ«rfaqes â validoni me pĂ«rdoruesin dhe kĂ«shtu me radhĂ«. (PĂ«rveç kĂ«saj, do tĂ« pĂ«rmendet pak si tĂ« validoni prototipet e programeve). QĂ«llimet e krijimit tĂ« softuerit, veçanĂ«risht nĂ« fazĂ«n fillestare â janĂ« mĂ«simi pĂ«rmes marrjes sĂ« feedback-ut tĂ« shpejtĂ«, pĂ«rkatĂ«sisht produkti i parĂ« i krijuar Ă«shtĂ« skica qĂ« janĂ« nĂ« gjendje tĂ« provojnĂ« ose tĂ« hedhin poshtĂ« hipotezĂ«n. (Autori mbĂ«shtetet nĂ« punĂ«n e Erik Ries âStartup me metodologjinĂ« Leanâ).
Harta e historive ndihmon nĂ« krijimin e komunikimesh, nĂ«se realizimi sigurohet nga disa ekipe. ĂfarĂ« duhet tĂ« jetĂ« nĂ« hartĂ«? Ajo qĂ« Ă«shtĂ« e nevojshme pĂ«r tĂ« mbĂ«shtetur bisedĂ«n. Jo vetĂ«m histori pĂ«rdoruesi (kush, çfarĂ«, pse), por ide, fakte, skica tĂ« ndĂ«rfaqeve etj...
Duke ndarĂ« kartat nĂ« hartĂ«n e historisĂ« nĂ« disa vijĂ« horizontale, mund tĂ« ndahet puna nĂ« lĂ«shime â tĂ« veçojmĂ« minimumin, shtresĂ«n e rritjes sĂ« funksionalitetit dhe shiritat.
Diskutoni historitë në hartën e procesit.
Punonjësi erdhi për drekë.
ĂfarĂ« dĂ«shiron ai? ShpejtĂ«si shĂ«rbimi. QĂ« dreka e tij tĂ« prishej nĂ« tavolinĂ« ose tĂ« paktĂ«n nĂ« njĂ« tepsi. Oops - njĂ« hap i humbur: punonjĂ«si vendosi tĂ« hajĂ«. Ai hyri nĂ« sistem dhe zgjodhi opsionin e biznes-lunchit. Ai pa kaloritĂ« dhe pĂ«rputhshmĂ«rinĂ« me vlerat ushqyese, pĂ«r tĂ« respektuar dietĂ«n dhe pĂ«r tĂ« mos u bĂ«rĂ« i overgewicht. Ai pa imazhet e jashtme tĂ« pjatĂ«s, pĂ«r tĂ« marrĂ« njĂ« vendim nĂ«se do tĂ« hante nĂ« atĂ« vend apo jo.
Më pas ai do të shkojë të marrë drekën dhe të hajë? Apo ndoshta do t'ia dërgojnë drekën në zyrë? Atëherë hapi i procesit është zgjedhja e vendit ku do të hajë. Ai dëshiron të shohë se kur do t'ia dërgojnë dhe sa do të kushtojë, për të zgjedhur se ku do të shpenzojë kohë dhe energji - në zbritje ose në punë. Ai dëshiron të shohë ngarkesën e kafesë, për të mos u ngushtuar në radhë.
Pas kësaj, punonjësi erdhi në kafe. Ai dëshiron të shohë tepsinë e tij, për ta marrë atë dhe menjëherë të shkojë për të ngrënë. Kafeja dëshiron të pranojë para, për të fituar nga shërbimi. Punonjësi dëshiron të humbasë sa më pak kohë për të paguar në kafe, për të mos humbur kohë të çmuar pa arsye. Si ta bësh këtë? Të paguash paraprakisht ose përndryshe pas shërbimit në distancë. Ose të paguash në moment me ndihmën e një kioske. Cila nga këto është më e rëndësishme? Sa njerëz janë të gatshëm të paguajnë për drekën me kartë bankare? Sa njerëz do t'i besojnë ruajtjen e numrit të kartës për pagesat e përsëritura në këtë kafene? Pa hulumtim në terren nuk është e qartë, ka nevojë për testim.
Në çdo hap të procesit është e nevojshme të sigurohet ndonjë funksionalitet, për këtë duhet të merret si bazë një person dhe të zgjidhet se çfarë është më e rëndësishme për të (ajo trio zgjedhësish). Të kalosh historinë deri në fund = të bësh një zgjidhje të qëndrueshme.
MĂ« pas vijon detajimi. Klienti dĂ«shiron tĂ« shohĂ« ngarkesĂ«n e kafesĂ«, pĂ«r tĂ« mos u ngushtuar nĂ« radhĂ«. ĂfarĂ« konkretisht dĂ«shiron ai?
Të shohë parashikimin se sa njerëz do të jenë pas 15 minutash, kur ai të arrijë atje.
Të shohë kohën mesatare të shërbimit në kafe dhe dinamikën e saj për gjysmë ore përpara.
Të shohë situatën dhe dinamikën e zënies së tavolinave.
E çfarë nëse sistemi parashikues jep një rezultat të paqartë ose ndalon së funksionuari?
Të shohë përmes videos radhët në kafe, si dhe zënien e tavolinave. Hmm, pse të mos e bëjmë këtë në radhë të parë?!
Autori thekson njĂ« ushtrim tĂ« vogĂ«l pĂ«r tĂ« praktikuar: provoni tĂ« imaginoni se çfarĂ« bĂ«ni mĂ«ngjesin pas zgjohet. NjĂ« kartĂ« = njĂ« veprim. Grumbuloni kartat (nĂ« vend tĂ« bluarjes sĂ« kafesĂ«âpirja e njĂ« pije energjizuese), pĂ«r tĂ« hequr detajet individuale, duke e fokusuar jo te mĂ«nyra e realizimit, por te qĂ«llimi.
PĂ«r kĂ« Ă«shtĂ« kjo libĂ«r â pĂ«r analistĂ«t IT dhe menaxherĂ«t e projekteve. E domosdoshme pĂ«r t'u lexuar.
Aplikacionet
Diskutimi dhe marrja e vendimeve janë të efektshme në grupe prej 3 deri në 5 personash.
Shkruani nĂ« kartelĂ«n e parĂ« atĂ« qĂ« duhet tĂ« zhvillohet, nĂ« tĂ« dytĂ«n â tĂ« korrigjoni atĂ« qĂ« Ă«shtĂ« bĂ«rĂ« nĂ« tĂ« parĂ«n, nĂ« tĂ« tretĂ«n â tĂ« korrigjoni atĂ« qĂ« Ă«shtĂ« bĂ«rĂ« nĂ« tĂ« parĂ«n dhe tĂ« dytĂ«n.
PĂ«rgatitni historitĂ« si tortat â jo duke shkruar recetĂ«n pĂ«r pĂ«rgatitje, por duke zbuluar kujt, pĂ«r çfarĂ« pĂ«rmbledhje, pĂ«r sa njerĂ«z Ă«shtĂ« torta. NĂ«se ndaheni realizimin, mos e ndani nĂ« pĂ«rgatitjen e bazave, kremit etj., por nĂ« pĂ«rgatitjen e tortave tĂ« vogla tĂ« gatshme.
Zhvillimi i softuerit ngjan me krijimin e një filmi, kur duhet të zhvillohet dhe rafinohet me kujdes skenari, të organizohet skena, aktorët etj., përpara fillimit të xhirimeve.
Burimet gjithmonë do të jenë të pamjaftueshme.
20% e pĂ«rpjekjeve japin njĂ« rezultat tĂ« dukshĂ«m, 60% japin diçka tĂ« paqartĂ«, 20% e pĂ«rpjekjeve dĂ«mtojnĂ« â kjo Ă«shtĂ« arsyeja pse Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« pĂ«rqendroheni nĂ« mĂ«sim dhe tĂ« mos humbni shpresĂ«n nĂ« rastin e njĂ« rezultati negativ.
Komunikoni me përdoruesin drejtpërdrejt, ndihuni në lëkurën e tij. Përqendrohuni në disa probleme.
Detajimi dhe pĂ«rpunimi i historisĂ« pĂ«r vlerĂ«sim â pjesa mĂ« e mundimshme e scrum-it, bĂ«ni diskutimet qĂ«ndruese nĂ« mĂ«nyrĂ« akvariumi (pranĂ« bordit diskutojnĂ« 3-4 njerĂ«z, nĂ«se dikush dĂ«shiron tĂ« marrĂ« pjesĂ«, ai zĂ«vendĂ«son dikĂ«).
Burimi: habr.com
