PĂ«rmbledhje
Libri është një alogaritëm i treguar për procesin e zhvillimit nga ideja deri në zbatim duke përdorur teknikat agile. Procesi ndahet në hapa dhe në secilin hap përmenden metodat për atë hap të procesit. Autori thekson se shumica e metodave nuk janë origjinale, pa pretenduar për origjinalitet. Megjithatë, stilin e mirë të paraqitjes dhe disa kohezion të procesit e bëjnë librin shumë të dobishëm.
Teknika kryesore e hartës së historive të përdoruesve është struktuarimi i ideve dhe formulimi i kërkesave gjatë kalimit të procesit nga përdoruesi.
Megjithatë, paraqitja e kalimit të procesit mund të bëhet në mënyra të ndryshme. Mund të rregullohen hapat sipas arritjes së vlerës kryesore, ose thjesht mund të paraqitet një ditë punë e përdoruesve, si kalon me sistemin. Autori fokusohet në faktin se proceset duhet të paraqiten, të rrëfehen si histori përdoruesi në hartën e procesit, që i dha emrin hartë e historive të përdoruesve.
KĂ« gjithashtu i nevojitet?
Për analistët IT dhe menaxherët e projekteve. E domosdoshme për t'u lexuar. Lexohet lehtë dhe me kënaqësi, libri ka një madhësi mesatare.
Rishikim
Në formën më të thjeshtë, si funksionon kjo.
Vizitori vjen në kafe, zgjedh ushqimet, bën porosi, merr ushqimin, ha, dhe paguan.
Mund të shkruhen kërkesat, për atë që duam nga sistemi në çdo hap.
Sistemi duhet të tregojë një listë të ushqimeve, për çdo ushqim përbërjen, peshën dhe çmimin dhe të ketë mundësinë për ta shtuar në shportë. Pse jemi të sigurt në këto kërkesa? Në përshkrimin 'standard' të kërkesave kjo nuk është përshkruar dhe kjo krijon rreziqe.
Pjesëmarrësit që nuk kuptojnë pse është e nevojshme për këtë, zakonisht bëjnë atë që nuk është e nevojshme. Ata që nuk janë të angazhuar në procesin e krijimit të ideve, nuk janë të angazhuar në rezultat. Agile thotë, le të përqendrohemi përpara gjithçkaje, jo në sistem, por te njerëzit, te konsumatorët, detyrat dhe objektivat e tyre.
Krijojmë persona, për empati u japim detaje dhe nga ana e personave fillojmë të tregojmë historitë.
PunonjĂ«si i zyrĂ«s, Zakhar, shkoi pĂ«r drekĂ« dhe dĂ«shiron tĂ« hajĂ« shpejt. ĂfarĂ« i nevojitet? Ideja - ndoshta dĂ«shiron njĂ« drekĂ« biznesi. NjĂ« tjetĂ«r ide - ai dĂ«shiron qĂ« sistemi tĂ« mbajĂ« mend preferencat e tij, sepse ai ndjek njĂ« dietĂ«. NjĂ« tjetĂ«r ide - ai dĂ«shiron qĂ« tĂ« sjellin menjĂ«herĂ« kafenĂ«, sepse ai ka zakon tĂ« pijĂ« kafe para drekĂ«s.
Ka edhe një biznes (personazh organizativ - një personazh që përfaqëson interesat e një organizate). Biznesi dëshiron të rrisë mesataren e shpenzimeve, të rrisë frekuencën e blerjeve, të rrisë fitimin. Ideja - le të ofrojmë pjata të pazakonta të një kuzhine të caktuar. Një tjetër ide - le të prezantojmë mëngjeset.
Idetë mund dhe duhet të konkretizohen, të transformohen dhe të formohen në formën e një historie përdoruesi. Si punonjës i qendrës së biznesit, Zakhar, dua që sistemi të më njohë, që të më japë një menu në përputhje me preferencat e mia. Si garson, unë dua që sistemi të më njoftojë kur të shkojë në tavolinë, që klienti të jetë i kënaqur me shërbimin e shpejtë. Dhe kështu me radhë.
Disa histori. Pastaj prioritizimi dhe backlog? Jeff përmend problemet që lindin: ngatërrimi në detajet e vogla dhe humbja e kuptimit konceptual plus prioritizimi i funksionaliteteve krijon një pamje të çarë për shkak të mosmiratimit të qëllimeve.
Rruga e autores: Prioritizojmë jo funksionalitetin, por rezultatet = atë që përdoruesi merr në fund.
Një pikë e dukshme jo e dukshme: sesioni i prioritizimit nuk kalon me tërë ekipin, sepse nuk është efikas, por me tre njerëz. 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.
Përzgjidhim minimumin për zgjidhjen e një detyre të përdoruesit (zgjidhja më minimale e vazhdueshme).
Detajojmë idetë e prioriteteve të para me ndihmën e historive të përdoruesve, skicave të dizajnit, kufizimeve dhe rregullave të biznesit në hartën e historive të përdoruesve duke rrëfyer dhe diskutuar me ekipin se çfarë u nevojitet personave dhe palëve të interesuara në çdo hap të procesit. Idetë e tjera i lëmë pa u shqyrtuar, në backlogun e mundësive.
Procesi shkruhet në formën e kartelave nga majtas në djathtas, ndërsa idetë në kartelat nën hapat e procesit. Patjetër, rruga e kalimit të gjithë historisë duhet të diskutohet së bashku me anëtarët e ekipit për të krijuar mirëkuptim.
Përpunimi në këtë mënyrë krijon një kohezion të përputhjes me proceset.
Idetë e marra duhet të verifikohen. Një anëtar i ekipit vë një kapelë personazhi dhe kalon një ditë në kokën e personazhit, duke zgjidhur detyrën e tij. Ka një mundësi, kur ai nuk sheh punën e bërë, duke krijuar kartela nga e para, ndërsa ekipi zbulon alternativa.
Pastaj ndodh detajizimi pĂ«r vlerĂ«sim. PĂ«r kĂ«tĂ« mjafton tĂ« pakta tre njerĂ«z. NjĂ« pĂ«rgjegjĂ«s pĂ«r pĂ«rvojĂ«n e pĂ«rdoruesit, njĂ« zhvillues, njĂ« testues me pyetjen e preferuar: âĂfarĂ« ndodh nĂ«se...?â.
Në çdo hap, diskutimi ndodhi në hartën e proceseve të historisë së përdoruesit, duke lejuar që të mbajmë mend detyrat e përdoruesit dhe të krijojmë një kuptim të plotë.
A nevojitet dokumentacion sipas mendimit të autorit? Po, nevojitet. Por si shënime, që lejojnë të kujtojmë se për çfarë kemi rënë dakord. Angazhimi i një personi nga jashtë kërkon përsëri diskutim.
Autori nuk thellohet në temën e mjaftueshmërisë së dokumentacionit, duke e përqendruar theksin në nevojën për diskutime. (Po, dokumentacioni është i nevojshëm, pavarësisht nga çfarë thonë ata që nuk e kuptojnë thellë agile). Po ashtu, përpunimi i vetëm një pjese të mundësive mund të çojë në nevojën për ristrukturimin e tërë sistemit. Autori vëren rrezikun e përpunimit të tepruar në rast se nuk kapet ideja saktë.
PĂ«r tĂ« eliminuar rreziqet, Ă«shtĂ« e nevojshme tĂ« marrim pĂ«rshtypje tĂ« shpejta pĂ«r produktin qĂ« po krijohet pĂ«r tĂ« minimizuar humbjen e krijimit tĂ« produktit "jo atĂ«". BĂ«mĂ« njĂ« skicĂ« ideje â e validuam me pĂ«rdoruesin, njĂ« skicĂ« tĂ« prototipĂ«ve tĂ« ndĂ«rfaqes â e validuam me pĂ«rdoruesin etj. (VeçanĂ«risht pak pĂ«rshkruhet se si tĂ« validohen prototipet e programeve). QĂ«llimi i krijimit tĂ« softuerit, veçanĂ«risht nĂ« fazĂ«n fillestare â Ă«shtĂ« mĂ«simi pĂ«rmes marrjes sĂ« feedback-ut tĂ« shpejtĂ«, pĂ«rkatĂ«sisht produkti i parĂ« i krijuar Ă«shtĂ« skica qĂ« Ă«shtĂ« nĂ« gjendje tĂ« dĂ«shmojĂ« ose tĂ« hedh poshtĂ« hipotezĂ«n. (Autori mbĂ«shtetet nĂ« punĂ«n e Eric Ries "Startup nga metodologjia Lean").
Harta e historive ndihmon nĂ« stabilizimin e komunikimeve, nĂ«se zbatimi sigurohet nga disa ekipe. ĂfarĂ« duhet tĂ« ketĂ« nĂ« hartĂ«? Ajo qĂ« Ă«shtĂ« e nevojshme pĂ«r tĂ« mbĂ«shtetur bisedĂ«n. Jo vetĂ«m historia e pĂ«rdoruesit (kush, çfarĂ«, pse), por ide, fakte, skica tĂ« ndĂ«rfaqeve etj.
Duke ndarĂ« kartat nĂ« hartĂ«n e historisĂ« nĂ« disa linja horizontale, mund tĂ« ndajmĂ« punĂ«t nĂ« rilizime â tĂ« veçojmĂ« minimumin, shtresĂ«n e shtimit tĂ« funksionaliteteve dhe decorĂ«t.
Diskutojmë historitë në hartën e procesit.
Punonjësi erdhi për drekë.
ĂfarĂ« dĂ«shiron ai? ShpejtĂ«sinĂ« e shĂ«rbimit. QĂ« drekĂ«n e tij ta kishte pritur nĂ« tavolinĂ« ose tĂ« paktĂ«n nĂ« tavolinĂ«. Opa â njĂ« hap i humbur: punonjĂ«si dĂ«shiron tĂ« hajĂ«. Ai hyri nĂ« sistem dhe zgjodhi variantin e drekĂ«s biznesi. Ai pa kaloritĂ« dhe pĂ«rputhjen e vlerĂ«s ushqyese, pĂ«r tĂ« mbajtur dietĂ«n dhe pĂ«r tĂ« mos u mbipeshĂ«. Ai pa imazhet e pjatave, pĂ«r tĂ« marrĂ« vendimin nĂ«se do tĂ« hante nĂ« kĂ«tĂ« vend apo jo.
MĂ« pas ai do tĂ« shkojĂ« tĂ« marrĂ« drekĂ«n dhe tĂ« hajĂ«? Apo ndoshta do t'i sjellin drekĂ«n nĂ« zyrĂ«? AtĂ«herĂ« hapi i procesit â zgjedhja e vendit tĂ« ngrĂ«nies. Ai dĂ«shiron tĂ« shohĂ« afatin se kur do t'i sjellin dhe sa do tĂ« kushtojĂ«, pĂ«r tĂ« vendosur se ku tĂ« shpenzojĂ« kohĂ«n dhe energjinĂ« â tĂ« zbresĂ« poshtĂ« apo nĂ« punĂ«. Ai dĂ«shiron tĂ« shohĂ« ngarkesĂ«n e kafesĂ«, pĂ«r tĂ« mos pritur nĂ« radhĂ«.
Më pas punonjësi erdhi në kafe. Ai dëshiron të shohë tavolinën e tij, për ta marrë dhe menjëherë të shkojë të hajë. Kafeneja dëshiron të marrë paratë, për të fituar nga shërbimi. Punonjësi dëshiron të humbasë sa më pak kohë në pagesa me kafene, për të mos e humbur kohën e vlefshme pa përdorim. Si mund ta bëjmë këtë? Duke paguar përpara ose përndryshe pas shërbimit në distancë. Ose duke paguar në moment me ndihmën e kiosku. Cila është më e rëndësishme? Sa shumë njerëz janë të gatshëm të paguajnë për drekë me kartë bankare? Sa shumë njerëz do t'i besojnë ruajtjes së numrit të kartës për pagesa të përsëritura në këtë kafene? Pa një hetim në terren nuk është e qartë, kërkohet testim.
Në çdo hap të procesit, duhet të sigurojmë ndonjëherë funksionalitet, për këtë duhet të merret si bazë një personazh dhe të zgjidhet çfarë është më e rëndësishme për të (ajo tri të zgjedhurve). Kur u kalua historia deri në fund = u krijua një zgjidhje e qëndrueshme.
MĂ« pas vjen detajizimi. Klienti dĂ«shiron tĂ« shohĂ« ngarkesĂ«n e kafesĂ«, pĂ«r tĂ« mos pritur nĂ« radhĂ«. ĂfarĂ« saktĂ«sisht dĂ«shiron ai?
Të shohë parashikimin e numrit të njerëzve pas 15 minutash, kur të shkojë atje.
Të shohë mesataren e kohës së shërbimit në kafene 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 i parashikimit jep një rezultat të paqartë ose ndalon së funksionuari?
Të shohë përmes videove radhët në kafe, si dhe zënien e tavolinave. Hmm, por pse të mos e bëjmë këtë në radhë të parë?!
Autori tregon njĂ« ushtrim tĂ« vogĂ«l pĂ«r tĂ« pĂ«rmirĂ«suar praktikĂ«n: provoni tĂ« imagjinoni çfarĂ« bĂ«ni nĂ« mĂ«ngjes pas zgjohet. NjĂ« kartĂ« = njĂ« veprim. Geni kartat (nĂ« vend tĂ« blerjes sĂ« kafes â pi njĂ« pije qĂ« zgjon), pĂ«r tĂ« hequr detajet individuale, duke e fokusuar jo nĂ« mĂ«nyrĂ«n e realizimit, por nĂ« qĂ«llimin.
PĂ«r kĂ« Ă«shtĂ« kjo libĂ«r â pĂ«r analistĂ«t IT dhe menaxherĂ«t e projekteve. E domosdoshme pĂ«r tĂ« lexuar.
Aplikacionet
Diskutimi dhe marrja e vendimeve janë efektive në grupe prej 3 deri në 5 personash.
Shkruani nĂ« kartĂ«n e parĂ« se çfarĂ« duhet tĂ« zhvillohet, nĂ« tĂ« dytĂ«n â korrigjoni atĂ« qĂ« bĂ«het nĂ« tĂ« parĂ«n, nĂ« tĂ« tretĂ«n â rregulloni atĂ« qĂ« Ă«shtĂ« bĂ«rĂ« nĂ« tĂ« parĂ«n dhe tĂ« dytĂ«n.
PĂ«rgatitni historitĂ« si torta â pa shkruar recetĂ«n e pĂ«rgatitjes, por duke mĂ«suar kush, pĂ«r çfarĂ« rast, dhe pĂ«r sa njerĂ«z Ă«shtĂ« torta. NĂ«se e ndan zbatimin, nuk e ndani nĂ« pĂ«rgatitjen e bazave, kremit etj., por nĂ« pĂ«rgatitjen e tortave tĂ« vogla tĂ« gatshme.
Zhvillimi i softuerit është si krijimi i një filmi, kur duhet të zhvillohet me kujdes dhe të përfundohet skenari, të organizohet skena, aktorët etj. para fillimit të xhirimeve.
Resurset 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 shkojnĂ« keq â kjo Ă«shtĂ« arsyeja pse Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« fokusohemi nĂ« mĂ«sim dhe tĂ« mos humbasim besimin nĂ« rastin e njĂ« rezultati negativ.
Komunikoni drejtpërdrejt me përdoruesin, ndihuni si ai. Fokusohemi në disa probleme.
Detajimi dhe zhvillimi i historisĂ« pĂ«r vlerĂ«sim â pjesa mĂ« e mundimshme e scrum-it, bĂ«ni diskutimet tĂ« qĂ«ndrojnĂ« nĂ« mĂ«nyrĂ« akvariumi (3-4 persona diskutojnĂ« pranĂ« bordit, nĂ«se dikush dĂ«shiron tĂ« marrĂ« pjesĂ«, ai zĂ«vendĂ«son dikĂ« tjetĂ«r).
Burimi: habr.com
