Annotazione
U libru hè un algoritmu narratu per realizà u prucessu di sviluppu da l'idea à l'implementazione utilizendu tecniche agili. U prucessu hè dispostu in passi è à ogni passu i metudi per u passu di prucessu sò indicati. L'autore signala chì a maiò parte di i metudi ùn sò micca originali, senza pretendenu esse uriginale. Ma u bonu stile di scrittura è una certa integrità di u prucessu facenu u libru assai utile.
Una tecnica chjave di a mappa di a storia di l'utilizatori hè di strutturà idee è prestazioni mentre l'utilizatore si move in u prucessu.
À u listessu tempu, u prucessu pò esse discrittu in modu differente. Pudete custruisce passi cum'è ottene un valore chjave, o pudete simpricimenti piglià è imagine u ghjornu di travagliu di l'utilizatori mentre passa cù u sistema. L'autore si cuncentra nantu à u fattu chì i prucessi anu da esse delineatu, parlatu in a forma di una storia d'utilizatore nantu à una mappa di prucessu, chì hè ciò chì ci hà datu u nome di a storia di l'utilizatori.
Quale hà bisognu
Per analisti IT è gestori di prughjettu. Un must read. Facile è piacevule à leghje, u libru hè di taglia media.
Feedback
In a so forma più simplice, questu hè cumu si travaglia.
Un visitatore vene in un caffè, sceglie i piatti, mette un ordine, riceve cibo, manghja è paga.
Pudemu scrive esigenze per ciò chì vulemu da u sistema in ogni stadiu.
U sistema deve mustrà una lista di piatti, ogni piattu hà una cumpusizioni, pesu è prezzu è puderà aghjunghje à u carrettu. Perchè simu cunfidenti in queste esigenze? Questu ùn hè micca descrittu in a descrizzione "standard" di esigenze è questu crea risichi.
Artisti chì ùn capiscenu micca perchè questu hè necessariu di solitu facenu a cosa sbagliata. I performers chì ùn sò micca implicati in u prucessu di creà una idea ùn sò micca implicati in u risultatu. Agile dice, concentremu principalmente micca nantu à u sistema, ma nantu à e persone, i cunsumatori, i so compiti è i so scopi.
Creemu persone, li detemu dettagli per l'empatia, è cuminciamu à cuntà storie da a parte di a persona.
L'impiegatu di l'uffiziu Zakhar hè andatu à pranzu è vole piglià una merenda rapida. Chì hà bisognu ? L'idea hè chì probabilmente vole un pranzu d'affari. Un'altra idea hè chì ellu vole chì u sistema ricurdà e so preferenze, perchè ellu hè in una dieta. Un'altra idea. Ci vole à purtà u caffè subitu perchè hè abituatu à beie caffè prima di pranzu.
È ci hè ancu un affari (un caratteru organizativu hè un caratteru chì rapprisenta l'interessi di una urganizazione). L'imprese volenu aumentà u cuntrollu mediu, aumentà a freccia di compra, è crescenu i prufitti. L'idea hè - offremu piatti insoliti di qualchi cucina. Un'altra idea - presentemu u colazione.
L'idee ponu è deve esse cuncretizzate, trasfurmate è presentate in forma di una storia d'utilizatore. Cum'è un impiigatu di u Zakhar Business Center, vogliu chì u sistema mi ricunnosce per pudè riceve un menu basatu nantu à e mo preferenze. Cum'è un servitore, vogliu chì u sistema mi notificà quandu si avvicina à a tavula per chì u cliente hè cuntentu di serviziu veloce. Eccetera.
Decine di storie. A seguita hè a priorità è u backlog? Jeff signala i prublemi chì sorgenu: impantanarsi in picculi dettagli è perde a cunniscenza conceptuale, più a priorità di funziunalità crea una stampa ragged per l'incoerenza cù i scopi.
A strada di l'autore: No priurità micca a funziunalità, ma u risultatu = ciò chì l'utilizatore riceve à a fine.
Un puntu evidenti micca evidenti: a sessione di priurità ùn hè micca realizatu da tutta a squadra, perchè ùn hè micca efficace, ma da trè persone. U primu hè rispunsevule per l'affari, u sicondu per l'esperienza di l'utilizatori è u terzu per l'implementazione.
Selezziemu u minimu per risolve un prublema d'utilizatore (soluzione minima viable).
Detagliamu l'idee di primura priorità utilizendu storie d'utilizatori, schizzi di cuncepimentu, limitazioni è regule cummerciale nantu à a mappa di a storia di l'utilizatori dicendu è discutendu cù a squadra ciò chì e persone è i stakeholder anu bisognu à ogni passu di u prucessu. Lasciamu l'idee rimanenti senza esaminazione in u backlog di opportunità.
U prucessu hè scrittu nantu à e carte da manca à diritta, cù idee nantu à e carte sottu à i passi di u prucessu. Hè imperativu chì u percorsu attraversu a storia sana sia discutitu cù i membri di a squadra per assicurà a cunniscenza mutuale.
Elaborazione in questu modu crea integrità in rispettu di i prucessi.
L'idee ricevute anu da esse pruvatu. Un membru chì ùn hè micca squadra si mette in u cappellu di a persona è vive u ghjornu di a persona in a so testa, risolve u so prublema. Hè pussibule chì ùn vede micca i sviluppi, creendu carte di novu, è a squadra scopre alternative per ellu stessu.
Dopu ci sò dettagli per a valutazione. Trè persone sò abbastanza per questu. Responsabile di l'esperienza d'utilizatore, sviluppatore, tester cù una dumanda preferita: "E se ...".
In ogni tappa, a discussione seguita una mappa di prucessu di a storia di l'utilizatore, chì permette di mantene in mente u compitu di l'utilizatore per creà una cunniscenza coherente.
La documentation est-elle nécessaire à l'avis de l'auteur ? Iè, aghju bisognu. Ma cum'è note chì permettenu di ricurdà ciò chì avete accunsentutu. A implicazione di un esterno di novu richiede discussione.
L'autore ùn sfondate micca in u tema di a sufficienza di a documentazione, cuncintrau nantu à a necessità di discussione. (Iè, a documentazione hè necessaria, ùn importa micca chì e persone chì ùn anu micca una cunniscenza prufonda di l'agile a reclamanu). Inoltre, l'elaborazione di solu una parte di e capacità pò purtà à a necessità di una ripresa cumpleta di tuttu u sistema. L'autore indica u risicu di l'elaborazione eccessiva in u casu quandu l'idea hè sbagliata.
Per eliminà i risichi, hè necessariu di riceve rapidamente feedback nantu à u pruduttu chì hè creatu per minimizzà i danni di creà u pruduttu "sbagliatu". Avemu fattu un sketch di l'idea - cunvalidatu cù l'utilizatore, sketched prototipi di l'interfaccia - validatu cù l'utilizatore, etc. (Separatamente, ci hè un pocu infurmazione nantu à cumu cunvalidà i prototipi di u prugramma). L'ugettivi di creazione di software, in particulare in u stadiu iniziale, sò l'apprendimentu per riceve un feedback rapidu in cunseguenza, u primu pruduttu creatu hè sketches chì sò capaci di pruvucà o dispruvà una ipotesi. (L'autore si basa nantu à u travagliu di Eric Ries "Startup using Lean methodology").
Una mappa di a storia aiuta à migliurà a cumunicazione quandu l'implementazione hè realizata in parechje squadre. Chì deve esse nantu à a mappa? Ciò chì avete bisognu per mantene a conversazione. Micca solu una storia d'utilizatore (chì, chì, perchè), ma idee, fatti, schizzi di l'interfaccia, etc...
Dividendu e carte nantu à a mappa di a storia in parechje linee horizontale, pudete sparte u travagliu in versioni - mette in risaltu u minimu minimu, una strata di funziunalità crescente è arcu.
Contemu storie nantu à a mappa di u prucessu.
Un impiigatu hè ghjuntu à pranzu.
Chì voli ? Velocità di serviziu. Cusì chì u so pranzu l'aspitta digià nantu à a tavula o almenu nantu à una tavola. Oops - un passu mancatu: l'impiigatu vulia manghjà. Hè logatu è hà sceltu l'opzione di pranzu d'affari. Hà vistu u cuntenutu di caloria è u cuntenutu nutrizionale per aiutà à a dieta è micca guadagnà pesu. Hà vistu ritratti di u piattu per decide s'ellu manghjava in quellu locu o micca.
Dopu, andarà à piglià u pranzu è a cena ? O forse u pranzu serà purtatu à u so uffiziu? Allora u passu di u prucessu hè di sceglie un locu per manghjà. Ellu voli vede quandu ellu serà consegnatu è quantu costarà, perchè ellu puderà sceglie induve passà u so tempu è l'energia - andendu à u pianu di sottu o andà à travaglià. Ci vole à vede quant’ellu hè occupatu u caffè per ùn sbattà in fila.
Allora l'impiigatu ghjunse à u caffè. Ci vole à vede u so vassellu per pudè piglià è andà direttamente à cena. U caffè vole accettà soldi per fà soldi nantu à u serviziu. L'impiigatu vole perde un minimu di tempu nantu à l'insediamenti cù u caffè, per ùn perde u tempu preziosu inutilmente. Cumu fà? Paga in anticipu o viceversa dopu u serviziu à distanza. O pagà in u locu cù un kiosk. Chì ghjè u più impurtante di questu? Quante persone sò disposti à pagà per u pranzu cù una carta bancaria? Quante persone avissiru fiducia in questa cantina per almacenà u so numeru di carta per i pagamenti ripetuti? Senza ricerca di u campu ùn hè micca chjaru, a prova hè necessaria.
À ogni passu di u prucessu, avete bisognu à furnisce funziunalità per questu avete bisognu à piglià una persona cum'è una basa è sceglie ciò chì hè più impurtante per ellu (i stessi trè selettori). Seguitu a storia finu à a fine = hà fattu una suluzione viable.
Dopu vene u dettagliu. U cliente vole vede quantu hè occupatu u caffè, per ùn sbattà in fila. Chì voli esattamente?
Vede a previsione di quante persone ci saranu in 15 minuti quandu ellu ghjunghje
Vede u tempu di serviziu mediu in un caffè è a so dinamica una meza ora in anticipu
Vede a situazione è a dinamica di occupazione di a tavula
E se u sistema di previsione dà un risultatu pocu chjaru o si ferma di travaglià?
Fighjate à traversu video e fila in u caffè, è ancu l'occupazione di tavule. Hmm, perchè ùn fate micca prima ?!
L'autore indica un picculu esercitu per praticà: pruvate d'imagine ciò chì fate a matina dopu à u svegliu. Una carta = una azione. Ingrandà e carte (invece di macinazione di cafè, beie una bevanda rinfrescante) per caccià i dettagli individuali, cuncentrazione micca in u metudu di implementazione, ma in u scopu.
Per quale hè stu libru: analisti IT è gestori di prughjettu. Una lettura necessaria.
Apps
A discussione è a decisione sò efficaci in gruppi di 3 à 5 persone.
Scrivite nantu à a prima carta ciò chì deve esse sviluppatu, nantu à u sicondu - currettu ciò chì avete fattu in u primu, in u terzu - currettu ciò chì hè statu fattu in u primu è u sicondu.
Preparate storie cum'è torte - micca scrivendu una ricetta, ma scoprendu quale, per quale occasione, è quante persone hè a torta. S'ellu si rompe a vendita, allora ùn saria micca in a produzzione di pasticci, crema, etc., ma in a pruduzzione di picculi pasticci pronti.
U sviluppu di u software hè simile à fà un filmu, quandu avete bisognu di sviluppà cù cura è pulisce u script, urganizà a scena, attori, etc. prima di a filmazione.
Ci sarà sempre una carenza di risorse.
U 20% di i sforzi pruducenu risultati tangibili, u 60% dà risultati incomprensibili, u 20% di i sforzi sò dannosi - per quessa hè impurtante di fucalizza nantu à l'apprendimentu è micca dispiratu in casu di un risultatu negativu.
Comunicate direttamente cù l'utilizatore, sentite in i so scarpi. Focus nantu à certi prublemi.
Detailing and developing the story for evaluation is the most drery part of scrum, make the discussions stand-up in aquarium mode (3-4 persone discute à u bordu, se qualchissia vole participà, rimpiazza à qualchissia).
Source: www.habr.com