ProHoster > Blogs > interneta ziņas > Patons Džefs. Lietotāju stāsti. Agile programmatūras izstrādes māksla

Patons Džefs. Lietotāju stāsti. Agile programmatūras izstrādes māksla

Anotācija

Grāmata ir izstāstÄ«ts algoritms izstrādes procesa veikÅ”anai no idejas lÄ«dz Ä«stenoÅ”anai, izmantojot veiklus paņēmienus. Process ir izklāstÄ«ts pa posmiem, un katrā solÄ« ir norādÄ«tas procesa posma metodes. Autore norāda, ka lielākā daļa metožu nav oriÄ£inālas, nepretendējot uz oriÄ£inālām. Taču labais rakstÄ«Å”anas stils un zināma procesa integritāte padara grāmatu ļoti noderÄ«gu.

Galvenais lietotāju stāstu kartÄ“Å”anas paņēmiens ir ideju un priekÅ”nesumu strukturÄ“Å”ana, lietotājam virzoties cauri procesam.

Tajā paŔā laikā procesu var aprakstÄ«t dažādos veidos. Varat izveidot soļus, kad sasniedzat galveno vērtÄ«bu, vai arÄ« varat vienkārÅ”i iztēloties un iztēloties lietotāju darba dienu, kas paiet, izmantojot sistēmu. Autore koncentrējas uz to, ka procesiem ir jābÅ«t ieskicētiem, izrunātiem lietotāja stāsta veidā procesu kartē, kas mums deva nosaukumu lietotāja stāstu karte.

Kam tas vajadzīgs

IT analītiķiem un projektu vadītājiem. Jālasa. Viegli un patīkami lasīt, grāmata ir vidēja izmēra.

Pārskatīt

VienkārŔākajā veidā tas darbojas Ŕādi.

Apmeklētājs ierodas kafejnīcā, izvēlas traukus, veic pasūtījumu, saņem ēdienu, ēd un maksā.

Mēs varam uzrakstīt prasības tam, ko mēs vēlamies no sistēmas katrā posmā.

Sistēmai jāparāda ēdienu saraksts, katram ēdienam ir sastāvs, svars un cena un jāspēj pievienot grozam. Kāpēc mēs esam pārliecināti par Ŕīm prasÄ«bām? Tas nav aprakstÄ«ts ā€œstandartaā€ prasÄ«bu aprakstā, un tas rada riskus.

IzpildÄ«tāji, kuri nesaprot, kāpēc tas ir nepiecieÅ”ams, parasti rÄ«kojas nepareizi. IzpildÄ«tāji, kuri nav iesaistÄ«ti idejas tapÅ”anas procesā, netiek iesaistÄ«ti rezultātā. Agile saka, koncentrēsimies galvenokārt nevis uz sistēmu, bet uz cilvēkiem, patērētājiem, viņu uzdevumiem un mērÄ·iem.

Mēs veidojam personības, sniedzam viņiem sīkāku informāciju empātijai un sākam stāstīt stāstus no personas puses.

Biroja darbinieks Zahars devās pusdienās un vēlas ātri uzkost. Kas viņam vajadzÄ«gs? Doma ir tāda, ka viņŔ droÅ”i vien vēlas biznesa pusdienas. Vēl viena ideja ir tāda, ka viņŔ vēlas, lai sistēma atcerētos viņa vēlmes, jo viņŔ ievēro diētu. Vēl viena ideja. ViņŔ vēlas, lai viņam tÅ«lÄ«t atnes kafiju, jo viņŔ ir pieradis dzert kafiju pirms pusdienām.

Un ir arÄ« bizness (organizācijas raksturs ir personāžs, kas pārstāv organizācijas intereses). Uzņēmumi vēlas palielināt vidējo čeku, palielināt pirkumu biežumu un palielināt peļņu. Ideja ir ā€“ piedāvāsim kādas virtuves neparastus ēdienus. Vēl viena ideja ā€“ ieviesÄ«sim brokastis.

Idejas var un vajag konkretizēt, pārveidot un pasniegt lietotāja stāsta veidā. Kā Zakhar Business Center darbinieks es vēlos, lai sistēma mani atpazÄ«st, lai es varētu saņemt ēdienkarti, pamatojoties uz savām vēlmēm. Es kā viesmÄ«lis vēlos, lai sistēma man paziņo, kad jāpieiet pie galdiņa, lai klients bÅ«tu apmierināts ar ātru apkalpoÅ”anu. Un tā tālāk.

Desmitiem stāstu. Nākamais ir prioritāŔu noteikÅ”ana un kavÄ“Å”anās? Džefs norāda uz problēmām, kas rodas: iestrēgÅ”ana sÄ«kās detaļās un konceptuālās izpratnes zaudÄ“Å”ana, kā arÄ« funkcionalitātes noteikÅ”ana par prioritāti rada nesaskaņotu priekÅ”statu par neatbilstÄ«bu mērÄ·iem.

Autora ceļŔ: Mēs izvirzām prioritāti nevis funkcionalitāti, bet gan rezultātu = to, ko lietotājs galu galā iegÅ«st.

AcÄ«mredzams, nepārprotams punkts: prioritāŔu noteikÅ”anas sesiju neveic visa komanda, jo tā ir neefektÄ«va, bet gan trÄ«s cilvēki. Pirmais ir atbildÄ«gs par uzņēmējdarbÄ«bu, otrais par lietotāja pieredzi un treÅ”ais par ievieÅ”anu.

Izvēlēsimies minimumu vienas lietotāja problēmas risināŔanai (minimālais dzÄ«votspējÄ«gais risinājums).

Mēs detalizēti aprakstām pirmās prioritārās idejas, izmantojot lietotāju stāstus, dizaina skices, ierobežojumus un biznesa noteikumus lietotāju stāstu kartē, pastāstot un pārrunājot ar komandu, kas cilvēkiem un ieinteresētajām personām ir nepiecieÅ”ams katrā procesa posmā. AtlikuŔās idejas atstājam neizskatÄ«tas iespēju uzkrājumos.

Process ir uzrakstÄ«ts uz kartÄ«tēm no kreisās uz labo pusi, un idejas uz kartÄ«tēm zem procesa soļiem. Lai nodroÅ”inātu savstarpēju sapratni, kopā ar komandas locekļiem ir obligāti jāpārrunā ceļŔ cauri visam stāstam.

Šādā veidā tiek veidota integritāte atbilstoŔi procesiem.

Saņemtās idejas ir jāpārbauda. Nekomandas dalÄ«bnieks uzliek cilvēka cepuri un izdzÄ«vo cilvēka dienu savā galvā, risinot viņa problēmu. Iespējams, ka viņŔ neredz notikumus, atkal veidojot kārtis, un komanda atklāj sev alternatÄ«vas.

Pēc tam ir detalizēta novērtÄ“Å”ana. Tam pietiek ar trim cilvēkiem. AtbildÄ«gs par lietotāja pieredzi, izstrādātājs, testētājs ar iecienÄ«tāko jautājumu: ā€œKo darÄ«t, ja...ā€.

Katrā posmā diskusija seko lietotāja vēstures procesa kartei, kas ļauj paturēt prātā lietotāja uzdevumu, lai radītu saskaņotu izpratni.

Vai pēc autora domām dokumentācija ir nepiecieÅ”ama? Jā, man to vajag. Bet kā piezÄ«mes, kas ļauj atcerēties, par ko vienojies. Atkal iesaistot nepiederoÅ”u personu, nepiecieÅ”ama diskusija.

Autore neiedziļinās dokumentācijas pietiekamÄ«bas tēmā, pievērÅ”oties diskusijas nepiecieÅ”amÄ«bai. (Jā, dokumentācija ir vajadzÄ«ga, lai kā to apgalvotu cilvēki, kuriem nav dziļas izpratnes par veiklÄ«bu). Turklāt, izstrādājot tikai daļu no iespējām, var rasties nepiecieÅ”amÄ«ba pilnÄ«bā pārstrādāt visu sistēmu. Autore norāda uz pārmērÄ«gas izstrādes risku gadÄ«jumā, ja doma ir nepareiza.

Lai novērstu riskus, nepiecieÅ”ams ātri saņemt atgriezenisko saiti par topoÅ”o produktu, lai pēc iespējas samazinātu ā€œnepareizāā€ produkta radÄ«Å”anas radÄ«tos zaudējumus. UztaisÄ«jām idejas skici - validējām ar lietotāju, skicējām interfeisa prototipus - validējām ar lietotāju utt. (AtseviŔķi ir nedaudz informācijas par programmu prototipu validÄ“Å”anu). ProgrammatÅ«ras izveides mērÄ·i, Ä«paÅ”i sākotnējā posmā, ir mācÄ«Å”anās, saņemot ātru atgriezenisko saiti, attiecÄ«gi pirmais radÄ«tais produkts ir skices, kas spēj pierādÄ«t vai atspēkot hipotēzi. (Autors paļaujas uz Ērika RÄ«sa darbu ā€œStartup using Lean methodologyā€).

Stāstu karte palÄ«dz uzlabot saziņu, ja ievieÅ”ana tiek veikta vairākās komandās. Kam jābÅ«t kartē? Kas jums nepiecieÅ”ams, lai saruna turpinātos. Ne tikai lietotāja stāsts (kas, kas, kāpēc), bet idejas, fakti, saskarnes skices utt...

Sadalot kartÄ«tes vēstures kartē vairākās horizontālās lÄ«nijās, darbu var sadalÄ«t izlaidumos ā€“ izcelt paÅ”u minimumu, pieaugoÅ”as funkcionalitātes slāni un lokus.

Mēs stāstām stāstus procesa kartē.

Darbinieks ieradās pusdienās.

Ko viņŔ grib? Servisa ātrumi. Lai viņa pusdienas viņu jau gaida uz galda vai vismaz uz paplātes. Ups - nokavēts solis: darbinieks gribēja ēst. ViņŔ pieteicās un izvēlējās biznesa pusdienu iespēju. ViņŔ redzēja kaloriju saturu un uzturvērtÄ«bu, lai palÄ«dzētu viņam ievērot diētu un nepieņemties svarā. ViņŔ redzēja ēdiena attēlus, lai izlemtu, vai viņŔ ēdÄ«s Å”ajā vietā vai ne.

Pēc tam viņŔ dosies paēst pusdienas un vakariņas? Vai varbÅ«t pusdienas tiks nogādātas viņa birojā? Tad procesa solis ir Ä“Å”anas vietas izvēle. ViņŔ vēlas redzēt, kad tas viņam tiks nogādāts un cik tas maksās, tāpēc viņŔ var izvēlēties, kur tērēt savu laiku un enerÄ£iju ā€“ nokāpt lejā vai doties uz darbu. ViņŔ vēlas redzēt, cik noslogots ir kafejnÄ«ca, lai nemestos rindās.

Tad darbiniece ieradās kafejnÄ«cā. ViņŔ vēlas redzēt savu paplāti, lai varētu to paņemt un doties tieÅ”i uz vakariņām. KafejnÄ«ca vēlas pieņemt naudu, lai nopelnÄ«tu ar apkalpoÅ”anu. Darbinieks vēlas zaudēt minimālu laiku norēķiniem ar kafejnÄ«cu, lai netērētu dārgo laiku bezjēdzÄ«gi. Kā to izdarÄ«t? Maksājiet avansā vai otrādi pēc apkalpoÅ”anas attālināti. Vai arÄ« maksājiet uz vietas, izmantojot kiosku. Kas Å”ajā ziņā ir vissvarÄ«gākais? Cik cilvēku ir gatavi maksāt par pusdienām ar bankas karti? Cik daudz cilvēku uzticētos Å”ai ēdnÄ«cai saglabāt savas kartes numuru atkārtotu maksājumu veikÅ”anai? Bez lauka pētÄ«jumiem nav skaidrs, ir nepiecieÅ”ama pārbaude.

Katrā procesa solÄ« ir kaut kā jānodroÅ”ina funkcionalitāte; Å”im nolÅ«kam par pamatu jāņem kāds cilvēks un jāizvēlas, kas viņam ir svarÄ«gāks (tie paÅ”i trÄ«s atlasÄ«tāji). Sekoja stāstam lÄ«dz galam = radÄ«ja dzÄ«votspējÄ«gu risinājumu.

Tālāk seko detalizācija. Klients vēlas redzēt, cik noslogots ir kafejnÄ«ca, lai nemētātos rindās. Ko tieÅ”i viņŔ vēlas?

Skatiet prognozi, cik cilvēku bÅ«s pēc 15 minÅ«tēm, kad viņŔ tur nokļūs

Apskati vidējo apkalpoÅ”anas laiku kafejnÄ«cā un tā dinamiku pusstundu iepriekÅ”

Skatiet situāciju un galdu noslogojuma dinamiku

Ko darÄ«t, ja prognozÄ“Å”anas sistēma dod neskaidru rezultātu vai pārstāj darboties?

Noskaties caur video kafejnīcas rindas, kā arī galdiņu noslogojumu. Hmm, kāpēc gan to neizdarīt vispirms?!

Autore norāda uz nelielu vingrinājumu, ko praktizēt: mēģiniet iedomāties, ko jÅ«s darāt no rÄ«ta pēc pamoÅ”anās. Viena karte = viena darbÄ«ba. Palieliniet kārtis (nevis maltu kafiju, dzeriet uzmundrinoÅ”u dzērienu), lai noņemtu atseviŔķas detaļas, koncentrējoties nevis uz Ä«stenoÅ”anas metodi, bet gan uz mērÄ·i.

Kam Ŕī grāmata ir paredzēta: IT analÄ«tiÄ·iem un projektu vadÄ«tājiem. Jālasa.

progr

Diskusijas un lēmumu pieņemÅ”ana ir efektÄ«vas grupās no 3 lÄ«dz 5 cilvēkiem.

Pirmajā kartÄ«tē ierakstiet, kas ir jāattÄ«sta, otrajā - labojiet pirmajā un treÅ”ajā - labojiet to, kas tika izdarÄ«ts pirmajā un otrajā.

Gatavojiet stāstus kā kÅ«kas ā€“ nevis izrakstot recepti, bet gan noskaidrojot, kam, kādam gadÄ«jumam un cik cilvēkiem kÅ«ka ir paredzēta. Ja mēs nojauktu pārdoÅ”anas apjomus, tad tas bÅ«tu nevis kÅ«ku, krējuma utt., bet gan mazu gatavu kÅ«ku ražoÅ”anā.

ProgrammatÅ«ras izstrāde ir lÄ«dzÄ«ga filmas veidoÅ”anai, kad pirms filmÄ“Å”anas ir rÅ«pÄ«gi jāizstrādā un jānoslÄ«pē scenārijs, jāsakārto aina, aktieri utt.

Resursu vienmēr pietrūks.

20% pūļu dod taustāmus rezultātus, 60% dod nesaprotamus rezultātus, 20% pÅ«liņu ir kaitÄ«gas - tāpēc ir svarÄ«gi koncentrēties uz mācÄ«Å”anos un nekrist izmisumā negatÄ«va rezultāta gadÄ«jumā.

Sazinieties tieÅ”i ar lietotāju, iejÅ«tieties viņa vietā. Koncentrējieties uz dažām problēmām.

Stāsta detalizÄ“Å”ana un attÄ«stÄ«Å”ana vērtÄ“Å”anai ir drÅ«mākā Ä·ibeles daļa, diskusijas jātaisa stāvus akvārija režīmā (3-4 cilvēki apspriežas pie dēļa, ja kāds vēlas piedalÄ«ties, viņŔ kādu aizvieto).

Avots: www.habr.com

Pievieno komentāru