Patton Jeff. Mga kwento ng gumagamit. Ang Sining ng Agile Software Development

Abstract

Ang aklat ay isang narrated algorithm para sa pagsasagawa ng proseso ng pagbuo mula sa ideya hanggang sa pagpapatupad gamit ang maliksi na pamamaraan. Ang proseso ay inilatag sa mga hakbang at sa bawat hakbang ang mga pamamaraan para sa hakbang ng proseso ay ipinahiwatig. Itinuturo ng may-akda na ang karamihan sa mga pamamaraan ay hindi orihinal, nang hindi inaangkin na orihinal. Ngunit ang magandang istilo ng pagsulat at ilang integridad ng proseso ay ginagawang lubhang kapaki-pakinabang ang aklat.

Ang isang pangunahing pamamaraan ng pagmamapa ng kwento ng gumagamit ay ang pagbuo ng mga ideya at pagganap habang ang gumagamit ay gumagalaw sa proseso.

Kasabay nito, ang proseso ay maaaring ilarawan sa iba't ibang paraan. Maaari kang bumuo ng mga hakbang habang nakakamit mo ang isang mahalagang halaga, o maaari mo lamang gawin at isipin ang araw ng trabaho ng mga user habang ginagamit ang system. Nakatuon ang may-akda sa katotohanan na ang mga proseso ay kailangang ibalangkas, na binibigkas sa anyo ng isang kuwento ng user sa isang mapa ng proseso, na siyang nagbigay sa amin ng pangalang mapa ng kuwento ng gumagamit.

Sino ang nangangailangan nito

Para sa mga IT analyst at project manager. Isang dapat basahin. Madali at nakakatuwang basahin, katamtaman ang laki ng libro.

Feedback

Sa pinakasimpleng anyo nito, ganito ito gumagana.

Dumating ang isang bisita sa isang cafe, pumipili ng mga pagkain, nag-order, tumatanggap ng pagkain, kumakain, at nagbabayad.

Maaari kaming sumulat ng mga kinakailangan para sa kung ano ang gusto namin mula sa system sa bawat yugto.

Dapat magpakita ang system ng isang listahan ng mga pagkaing, bawat ulam ay may komposisyon, timbang at presyo at maaaring idagdag sa cart. Bakit tayo nagtitiwala sa mga kinakailangang ito? Hindi ito inilarawan sa "karaniwang" paglalarawan ng mga kinakailangan at lumilikha ito ng mga panganib.

Ang mga gumaganap na hindi nauunawaan kung bakit ito kinakailangan ay kadalasang gumagawa ng maling bagay. Ang mga performer na hindi kasali sa proseso ng paglikha ng ideya ay hindi kasali sa resulta. Sabi ni Agile, mag-focus muna tayo hindi sa system, kundi sa mga tao, sa mga consumer, sa kanilang mga gawain at layunin.

Gumagawa kami ng mga persona, binibigyan sila ng mga detalye para sa empatiya, at nagsimulang magkuwento mula sa panig ng persona.

Ang empleyado ng opisina na si Zakhar ay nagpunta sa tanghalian at gustong magkaroon ng mabilis na meryenda. Ano ang kailangan niya? Ang ideya ay malamang na gusto niya ng isang business lunch. Ang isa pang ideya ay nais niyang matandaan ng system ang kanyang mga kagustuhan, dahil siya ay nasa isang diyeta. Isa pang ideya. Gusto niyang dalhan agad ng kape dahil sanay na siyang umiinom ng kape bago magtanghalian.

At mayroon ding negosyo (an organizational character is a character representing the interests of an organization). Gusto ng mga negosyo na taasan ang average na tseke, dagdagan ang dalas ng mga pagbili, at pataasin ang kita. Ang ideya ay - mag-alok tayo ng mga hindi pangkaraniwang pagkain ng ilang lutuin. Isa pang ideya - ipakilala natin ang almusal.

Ang mga ideya ay maaari at dapat kongkreto, baguhin at ipakita sa anyo ng isang kuwento ng gumagamit. Bilang isang empleyado ng Zakhar Business Center, gusto kong makilala ako ng system para makatanggap ako ng menu batay sa aking mga kagustuhan. Bilang isang waiter, nais kong ipaalam sa akin ng system kung kailan lalapit sa mesa upang ang kliyente ay masiyahan sa mabilis na serbisyo. At iba pa.

Dose-dosenang mga kuwento. Susunod ay ang prioritization at backlog? Itinuro ni Jeff ang mga problemang lumalabas: nababalot sa maliliit na detalye at nawawalan ng pag-unawa sa konseptwal, at ang pag-prioritize ng functionality ay lumilikha ng isang gulanit na larawan dahil sa hindi pagkakatugma sa mga layunin.

Ang landas ng may-akda: Hindi namin inuuna ang pagpapagana, ngunit ang resulta = kung ano ang nakukuha ng user sa huli.

Isang malinaw na hindi halatang punto: ang sesyon ng prioritization ay hindi isinasagawa ng buong koponan, dahil ito ay hindi epektibo, ngunit sa pamamagitan ng tatlong tao. Ang una ay responsable para sa negosyo, ang pangalawa para sa karanasan ng gumagamit at ang pangatlo para sa pagpapatupad.

Piliin natin ang pinakamababa para sa paglutas ng isang problema ng user (pinakamababang solusyon na mabubuhay).

Idinedetalye namin ang mga unang priyoridad na ideya gamit ang mga kwento ng user, mga sketch ng disenyo, mga hadlang at mga panuntunan sa negosyo sa mapa ng kwento ng user sa pamamagitan ng pagsasabi at pagtalakay sa team kung ano ang kailangan ng mga tao at stakeholder sa bawat hakbang ng proseso. Iniiwan namin ang natitirang mga ideya na hindi napag-aralan sa backlog ng mga pagkakataon.

Ang proseso ay nakasulat sa mga card mula kaliwa hanggang kanan, na may mga ideya sa mga card sa ibaba ng mga hakbang sa proseso. Kinakailangan na ang landas sa buong kuwento ay talakayin kasama ng mga miyembro ng pangkat upang matiyak ang pagkakaunawaan sa isa't isa.

Ang elaborasyon sa ganitong paraan ay lumilikha ng integridad sa pagsunod sa mga proseso.

Ang mga ideyang natanggap ay kailangang masuri. Ang isang hindi miyembro ng koponan ay nagsusuot ng sumbrero ng tao at nabubuhay ang araw ng tao sa kanyang ulo, na nilulutas ang kanyang problema. Posible na hindi niya makita ang mga pag-unlad, lumikha muli ng mga card, at ang koponan ay nakatuklas ng mga alternatibo para sa sarili nito.

Pagkatapos ay mayroong detalye para sa pagsusuri. Sapat na ang tatlong tao para dito. Responsable para sa karanasan ng user, developer, tester na may paboritong tanong: β€œPaano kung...”.

Sa bawat yugto, ang talakayan ay sumusunod sa isang mapa ng proseso ng kasaysayan ng user, na nagbibigay-daan sa pagpapanatiling nasa isip ng gawain ng user upang lumikha ng magkakaugnay na pag-unawa.

Kailangan ba ang dokumentasyon sa opinyon ng may-akda? Oo, kailangan ko ito. Ngunit bilang mga tala na nagpapahintulot sa iyo na matandaan kung ano ang iyong napagkasunduan. Ang pagsali muli ng isang tagalabas ay nangangailangan ng talakayan.

Ang may-akda ay hindi sumasali sa paksa ng kasapatan ng dokumentasyon, na nakatuon sa pangangailangan para sa talakayan. (Oo, kailangan ang dokumentasyon, gaano man ito inaangkin ng mga taong walang malalim na pang-unawa sa maliksi). Gayundin, ang pagpapaliwanag ng bahagi lamang ng mga kakayahan ay maaaring humantong sa pangangailangan para sa isang kumpletong rework ng buong system. Itinuturo ng may-akda ang panganib ng labis na pagpapaliwanag sa kaso kapag mali ang ideya.

Upang maalis ang mga panganib, kinakailangan na mabilis na makatanggap ng feedback sa produktong nilikha upang mabawasan ang pinsala ng paglikha ng "maling" produkto. Gumawa kami ng sketch ng ideya - napatunayan ito sa user, naka-sketch na mga prototype ng interface - napatunayan ito sa user, atbp. (Hiwalay, mayroong kaunting impormasyon kung paano i-validate ang mga prototype ng programa). Ang mga layunin ng paglikha ng software, lalo na sa paunang yugto, ay natututo sa pamamagitan ng pagtanggap ng mabilis na feedback; ayon dito, ang unang produktong nilikha ay mga sketch na maaaring patunayan o pabulaanan ang isang hypothesis. (Ang may-akda ay umaasa sa gawa ni Eric Ries na "Startup using Lean methodology").

Nakakatulong ang isang mapa ng kwento na mapabuti ang komunikasyon kapag isinasagawa ang pagpapatupad sa maraming koponan. Ano ang dapat na nasa mapa? Ano ang kailangan mo upang magpatuloy ang pag-uusap. Hindi lang isang kwento ng gumagamit (sino, ano, bakit), ngunit mga ideya, katotohanan, sketch ng interface, atbp...

Sa pamamagitan ng paghahati sa mga card sa mapa ng kasaysayan sa ilang pahalang na linya, maaari mong hatiin ang trabaho sa mga release - i-highlight ang pinakamababa, isang layer ng pagtaas ng functionality at bows.

Nagkukuwento kami sa mapa ng proseso.

Dumating ang isang empleyado para sa tanghalian.

Ano ang gusto niya? Mga bilis ng serbisyo. Para ang tanghalian niya ay naghihintay na sa kanya sa mesa o hindi bababa sa isang tray. Oops - isang napalampas na hakbang: gustong kumain ng empleyado. Nag-log in siya at pinili ang business lunch option. Nakita niya ang calorie content at nutritional content para matulungan siyang magdiet at hindi tumaba. Nakita niya ang mga larawan ng ulam para magpasya kung kakain siya sa lugar na iyon o hindi.

Susunod, pupunta ba siya ng tanghalian at hapunan? O baka naman ihahatid ang tanghalian sa opisina niya? Pagkatapos ang hakbang ng proseso ay ang pagpili ng lugar na kakainan. Gusto niyang makita kung kailan ito ihahatid sa kanya at kung magkano ang magagastos, para mapili niya kung saan niya gugugol ang kanyang oras at lakas - pagbaba o papasok sa trabaho. Gusto niyang makita kung gaano ka-busy ang cafe para hindi magsiksikan sa pila.

Pagkatapos ay dumating ang empleyado sa cafe. Gusto niyang makita ang tray niya para kunin niya at dumiretso sa hapunan. Nais ng cafe na tumanggap ng pera upang kumita ng pera sa serbisyo. Nais ng empleyado na mawalan ng isang minimum na oras sa mga pakikipag-ayos sa cafe, upang hindi mag-aksaya ng mahalagang oras nang walang silbi. Paano ito gagawin? Magbayad nang maaga o vice versa pagkatapos ng serbisyo nang malayuan. O magbayad on the spot gamit ang isang kiosk. Ano ang pinakamahalagang bagay tungkol dito? Ilang tao ang handang magbayad para sa tanghalian gamit ang bank card? Ilang tao ang magtitiwala sa canteen na ito na iimbak ang kanilang numero ng card para sa mga paulit-ulit na pagbabayad? Kung walang field research ay hindi malinaw, kailangan ang pagsubok.

Sa bawat hakbang ng proseso, kailangan mong magbigay ng pag-andar, para dito kailangan mong kumuha ng isang tao bilang batayan at piliin kung ano ang mas mahalaga sa kanya (ang parehong tatlong mga tagapili). Sinundan ang kwento hanggang sa wakas = gumawa ng isang mabubuhay na solusyon.

Susunod ay ang pagdedetalye. Gustong makita ng kliyente kung gaano ka-busy ang cafe, para hindi magsiksikan sa mga pila. Ano ba talaga ang gusto niya?

Tingnan ang forecast kung gaano karaming tao ang naroroon sa loob ng 15 minuto pagdating niya doon

Tingnan ang average na oras ng serbisyo sa isang cafe at ang dynamics nito kalahating oras nang maaga

Tingnan ang sitwasyon at dynamics ng occupancy ng talahanayan

Paano kung ang sistema ng pagtataya ay nagbibigay ng hindi malinaw na resulta o huminto sa paggana?

Panoorin sa pamamagitan ng video ang mga pila sa cafe, pati na rin ang occupancy ng mga mesa. Hmm, bakit hindi muna gawin?!

Itinuro ng may-akda ang isang maliit na ehersisyo upang magsanay: subukang isipin kung ano ang iyong ginagawa sa umaga pagkatapos gumising. Isang card = isang aksyon. Palakihin ang mga card (sa halip na paggiling ng kape, uminom ng nakapagpapalakas na inumin) upang alisin ang mga indibidwal na detalye, hindi tumutuon sa paraan ng pagpapatupad, ngunit sa layunin.

Para kanino ang aklat na ito: IT analyst at project manager. Isang dapat basahin.

apps

Ang talakayan at paggawa ng desisyon ay epektibo sa mga grupo ng 3 hanggang 5 tao.

Isulat sa unang card kung ano ang kailangang paunlarin, sa pangalawa - itama ang ginawa mo sa una, sa pangatlo - iwasto ang ginawa sa una at pangalawa.

Maghanda ng mga kuwento tulad ng mga cake - hindi sa pamamagitan ng pagsulat ng isang recipe, ngunit sa pamamagitan ng pag-alam kung kanino, para sa anong okasyon, at kung ilang tao ang cake. Kung sisirain natin ang mga benta, kung gayon ito ay hindi sa paggawa ng mga cake, cream, atbp., ngunit sa paggawa ng maliliit na handa na mga cake.

Ang pag-develop ng software ay katulad ng paggawa ng isang pelikula, kapag kailangan mong maingat na bumuo at magpakintab ng script, ayusin ang eksena, mga aktor, atbp. bago magsimula ang paggawa ng pelikula.

Palaging magkakaroon ng kakulangan sa mga mapagkukunan.

20% ng mga pagsisikap ay nagdudulot ng mga nasasalat na resulta, 60% ay nagbibigay ng hindi maintindihan na mga resulta, 20% ng mga pagsisikap ay nakakapinsala - kaya naman mahalagang tumuon sa pag-aaral at hindi mawalan ng pag-asa kung sakaling magkaroon ng negatibong resulta.

Direktang makipag-usap sa gumagamit, pakiramdam ang iyong sarili sa kanyang mga posisyon. Tumutok sa ilang mga problema.

Ang pagdedetalye at pagbuo ng kwento para sa pagsusuri ay ang pinaka nakakapagod na bahagi ng scrum, gawing stand-up ang mga talakayan sa aquarium mode (3-4 na tao ang nag-uusap sa board, kung may gustong lumahok, papalitan niya ang isang tao).

Pinagmulan: www.habr.com

Magdagdag ng komento