Annotazione
Il libro è un algoritmo narrato per la conduzione del processo di sviluppo dall'idea all'implementazione utilizzando tecniche agile. Il processo è scomposto in fasi e per ogni fase vengono indicati i metodi relativi. L'autore sottolinea che gran parte dei metodi non sono originali e non pretende originalità. Ma un buon stile espositivo e una certa coerenza del processo rendono il libro molto utile.
La tecnica chiave della mappa delle storie degli utenti consiste nella strutturazione delle idee e degli obiettivi durante il processo vissuto dall'utente.
Il percorso del processo può essere esposto in modi diversi. Si possono costruire le fasi man mano che si raggiunge un valore chiave, oppure si può semplicemente prendere e presentare una giornata lavorativa degli utenti, come si svolge utilizzando il sistema. L'autore si concentra sul fatto che i processi devono essere esposti, raccontati come una storia dell'utente sulla mappa del processo, che ha dato origine al nome mappa delle storie degli utenti.
A chi serve
Per analisti IT e project manager. Da leggere assolutamente. È facile e piacevole da leggere, il libro ha una dimensione media.
Revoca
Nella sua forma più semplice, come funziona.
Il visitatore arriva al caffè, sceglie i piatti, fa un ordine, riceve il cibo, mangia, paga.
Si possono scrivere i requisiti su cosa vogliamo dal sistema in ogni fase.
Il sistema deve visualizzare un elenco di piatti, con ingredienti, peso e prezzo per ciascun piatto e dare la possibilità di aggiungere al carrello. Perché siamo certi di questi requisiti? Nella descrizione "standard" dei requisiti questo non è specificato e ciò genera rischi.
Gli esecutori che non comprendono il perché sia necessario di solito fanno ciò che non serve. Gli esecutori che non sono coinvolti nel processo di creazione dell'idea non sono coinvolti nemmeno nel risultato. Agile dice, concentriamoci soprattutto non sul sistema, ma sulle persone, sui consumatori, sui loro compiti e obiettivi.
Creiamo le personas, per empatia diamo loro dettagli e dal punto di vista delle personas iniziamo a raccontare storie.
L'ufficio dipendente Zakhar è andato a pranzo e vuole uno spuntino veloce. Di cosa ha bisogno? L'idea è che probabilmente vuole un pranzo d'affari. Un'altra idea è che vuole che il sistema ricordi le sue preferenze, poiché è a dieta. Un'altra idea. Vuole che gli venga portato subito il caffè, perché è abituato a bere caffè prima di pranzo.
C'è anche un business (orgsonage — un personaggio che rappresenta gli interessi di un'organizzazione). Il business vuole aumentare il valore medio della spesa, aumentare la frequenza degli acquisti e aumentare il profitto. L'idea è: perché non proporre piatti insoliti di qualche cucina? Un'altra idea è: perché non introdurre le colazioni.
Le idee possono e devono essere concretizzate, trasformate e presentate come user story. Come dipendente del centro business, Zahkar, voglio che il sistema mi riconosca, in modo da ricevere un menù basato sulle mie preferenze. Come cameriere voglio che il sistema mi avvisi quando è il momento di avvicinarmi al tavolo, così che il cliente sia soddisfatto del servizio rapido. E così via.
Decine di storie. Successivamente, la priorizzazione e il backlog? Jeff sottolinea i problemi emergenti: il legame con i dettagli minuti e la perdita della comprensione concettuale, oltre alla priorizzazione delle funzionalità, creano un quadro frammentato a causa dell'incoerenza rispetto agli obiettivi.
Il percorso dell'autore: priorizziamo non le funzionalità, ma il risultato = ciò che l'utente ottiene alla fine.
Punto ovvio ma non ovvio: la sessione di priorizzazione non viene effettuata dall'intero team, perché inefficace, ma da tre persone. Il primo si occupa del business, il secondo dell'esperienza utente e il terzo dell'implementazione.
Definiamo il minimo per risolvere una singola esigenza dell'utente (soluzione minimamente vitale).
Dettagliamo le idee di priorità uno tramite user story, schizzi di design, vincoli e regole aziendali sulla mappa delle storie degli utenti, raccontando e discutendo con il team ciò di cui hanno bisogno i personaggi e gli stakeholder in ogni fase del processo. Le altre idee rimangono non elaborate, nel backlog delle opportunità.
Il processo viene scritto in forma di schede da sinistra a destra, e le idee sulle schede sotto i passaggi del processo. È fondamentale discutere il percorso dell'intera storia con i membri del team per portare alla reciproca comprensione.
L'elaborazione in questo modo crea integrità nel rispetto dei processi.
Le idee ottenute devono essere verificate. Un non membro del team indossa il cappello del personaggio e vive nella mente del personaggio per un giorno, risolvendo il suo compito. È possibile che non vede i risultati precedenti, creando le schede da zero, mentre il team scopre alternative.
Quindi avviene la dettagliatura per la valutazione. Per questo bastano tre persone: il responsabile dell'esperienza utente, lo sviluppatore e il tester con la domanda preferita: “E se…”.
In ogni fase, la discussione si basa sulla mappa dei processi della storia dell'utente, permettendo di tenere a mente il compito dell'utente per creare un'unità di comprensione.
È necessaria la documentazione secondo l'autore? Sì, è necessaria. Ma come appunti, per ricordare ciò su cui ci siamo accordati. Coinvolgere una persona esterna richiede di nuovo discussione.
L'autore non approfondisce il tema della sufficienza della documentazione, ponendo l'accento sulla necessità di discussioni. (Sì, la documentazione è necessaria, nonostante ciò che affermano le persone che non comprendono a fondo l'agile). Inoltre, lavorare solo su una parte delle possibilità può portare alla necessità di rifare completamente il sistema. L'autore sottolinea il rischio di eccesso di lavorazione nel caso in cui non si indovini l'idea.
Per ridurre i rischi è necessario ricevere rapidamente feedback sul prodotto in fase di creazione per minimizzare i danni dalla creazione di un prodotto “sbagliato”. Abbiamo abbozzato un'idea — l'abbiamo validata con l'utente, abbozzato prototipi dell'interfaccia — l'abbiamo validata con l'utente, e così via. (Viene esposto brevemente come validare i prototipi di software). Gli obiettivi della creazione di software, soprattutto nella fase iniziale, sono apprendere attraverso il ricevimento di feedback rapido, pertanto il primo prodotto creato è un abbozzo capace di dimostrare o confutare un'ipotesi. (L'autore si basa sul lavoro di Eric Ries “The Lean Startup”).
La mappa delle storie aiuta a stabilire comunicazioni se l'implementazione è gestita da più team. Cosa deve esserci sulla mappa? Ciò che è necessario per supportare la conversazione. Non solo user story (chi, cosa, perché), ma idee, fatti, bozzetti di interfacce, ecc.
Dividendo le schede sulla mappa delle storie in diverse linee orizzontali, è possibile separare i lavori per release — evidenziare il minimo necessario, uno strato di sviluppo delle funzionalità e i “fiocchi”.
Parliamo delle storie sulla mappa del processo.
Il dipendente è andato a pranzo.
Cosa vuole? Velocità di servizio. Vuole che il suo pranzo sia già pronto sul tavolo o almeno su un vassoio. Oops — passo mancante: l'impiegato ha voglia di mangiare. È entrato nel sistema e ha scelto un'opzione di pranzo d'affari. Ha visto le calorie e la corrispondenza con il valore nutrizionale per seguire la dieta e non ingrassare. Ha visto le immagini del piatto per decidere se mangiare in quel posto o meno.
Poi andrà a prendere il pranzo e a pranzare? O forse gli porteranno il pranzo in ufficio? Quindi il passo del processo è scegliere dove mangiare. Vuole vedere quando gli sarà consegnato e quanto costerà, per decidere dove spendere tempo e fatica — scendere o lavorare. Vuole vedere la disponibilità del bar, per non dover spingere in fila.
Dopo, l'impiegato è entrato nel caffè. Vuole vedere il suo vassoio, per prenderlo e andare subito a pranzare. Il caffè vuole incassare, per guadagnare dal servizio. L'impiegato vuole perdere il minimo tempo possibile nei pagamenti con il caffè, per non sprecare tempo prezioso. Come fare? Pagare in anticipo o, al contrario, dopo il servizio in remoto. Oppure pagare al momento tramite chiosco. Qual è la cosa più importante? Quante persone sono disposte a pagare il pranzo con carta di credito? Quante persone si fideranno di conservare il numero della carta per i pagamenti ripetuti in questo mensa? Senza ricerca sul campo non è chiaro, è necessario un test.
Ad ogni passo del processo è necessario fornire qualche funzionalità, per questo è necessario prendere come base qualche persona e scegliere cosa sia per lui più importante (quella famosa triade di selettori). Se abbiamo seguito la storia fino alla fine = abbiamo creato una soluzione sostenibile.
Poi c'è la dettagliatura. Il cliente vuole vedere la disponibilità del caffè, per non dover spingere in fila. Cosa vuole esattamente?
Guardare la previsione di quante persone ci saranno tra 15 minuti, quando arriverà lì.
Controllare il tempo medio di servizio nel caffè e la sua dinamica per i prossimi trenta minuti.
Osservare la situazione e la dinamica di occupazione dei tavoli.
E se il sistema di previsione fornisce un risultato incomprensibile o smette di funzionare?
Guardare tramite video le code nel caffè, così come l'occupazione dei tavoli. Hmm, perché non farlo prima di tutto?!
L'autore suggerisce un piccolo esercizio per esercitare la pratica: prova a immaginare cosa fai al mattino dopo esserti svegliato. Una scheda = un'azione. Accorpa le schede (invece di preparare il caffè — bevi una bevanda rinvigorente), per rimuovere i dettagli individuali, concentrandoti non sul modo di attuazione, ma sull'obiettivo.
Per chi è questo libro — per analisti IT e project manager. Da leggere assolutamente.
Applicazioni
La discussione e la presa di decisioni sono efficaci in gruppi da 3 a 5 persone.
Scrivi sulla prima scheda cosa deve essere sviluppato, sulla seconda — correggi ciò che è stato fatto nella prima, sulla terza — correggi ciò che è stato fatto nella prima e nella seconda.
Prepara le storie come se fossero torte — non scrivendo la ricetta di produzione, ma scoprendo per chi, per quale occasione, per quante persone è la torta. Se si devono scomporre le realizzazioni, non in produzione dei pan di spagna, della crema, ecc., ma in produzione di piccole tortine pronte.
Lo sviluppo software è simile alla creazione di un film, dove è necessario progettare e rifinire attentamente lo script, organizzare la scena, gli attori e altro ancora prima dell'inizio delle riprese.
Le risorse saranno sempre insufficienti.
Il 20% degli sforzi produce un risultato tangibile, il 60% produce risultati poco chiari, il 20% degli sforzi è dannoso — ecco perché è importante concentrarsi sull'apprendimento e non scoraggiarsi in caso di risultato negativo.
Comunica direttamente con l'utente, metti ti nei suoi panni. Concentrati su alcuni problemi.
La dettaglio e la lavorazione della storia per la valutazione è la parte più noiosa dello scrum, rendi le discussioni in piedi in modalità acquario (alla lavagna discutono 3-4 persone, se qualcuno vuole partecipare, sostituisce qualcuno).
Fonte: habr.com
