Astratto
Il libro è un algoritmo narrato per svolgere il processo di sviluppo dall'idea alla realizzazione utilizzando tecniche agili. Il processo è strutturato in fasi e in ciascuna fase sono indicate le modalità per la fase del processo. L'autore sottolinea che la maggior parte dei metodi non sono originali, senza pretendere di esserlo. Ma il buon stile di scrittura e una certa integrità del processo rendono il libro molto utile.
Una tecnica chiave per la mappatura delle storie degli utenti è strutturare idee e prestazioni mentre l'utente si muove attraverso il processo.
Allo stesso tempo, il processo può essere descritto in diversi modi. Puoi creare dei passaggi man mano che raggiungi un valore chiave oppure puoi semplicemente immaginare la giornata lavorativa degli utenti mentre utilizza il sistema. L'autore si concentra sul fatto che i processi devono essere delineati, raccontati sotto forma di user story su una mappa dei processi, da qui il nome user story map.
Chi ne ha bisogno
Per analisti IT e project manager. Assolutamente da leggere. Di facile e piacevole lettura, il libro è di medie dimensioni.
richiamo
Nella sua forma più semplice, ecco come funziona.
Un visitatore viene in un bar, seleziona i piatti, fa un ordine, riceve il cibo, mangia e paga.
Possiamo scrivere i requisiti per ciò che vogliamo dal sistema in ogni fase.
Il sistema dovrebbe mostrare un elenco di piatti, ogni piatto ha una composizione, un peso e un prezzo ed essere in grado di aggiungerlo al carrello. Perché abbiamo fiducia in questi requisiti? Ciò non è descritto nella descrizione “standard” dei requisiti e ciò crea rischi.
Gli artisti che non capiscono perché ciò sia necessario di solito fanno la cosa sbagliata. Gli artisti che non sono coinvolti nel processo di creazione di un'idea non sono coinvolti nel risultato. Agile dice: concentriamoci principalmente non sul sistema, ma sulle persone, sui consumatori, sui loro compiti e obiettivi.
Creiamo personaggi, forniamo loro dettagli per l'empatia e iniziamo a raccontare storie dal punto di vista del personaggio.
L'impiegato Zachar è andato a pranzo e vuole fare uno spuntino veloce. Di cosa ha bisogno? L'idea è che probabilmente vuole un pranzo di lavoro. Un'altra idea è che vuole che il sistema ricordi le sue preferenze, perché è a dieta. Un'altra idea. Vuole che gli venga portato subito il caffè perché è abituato a berlo prima di pranzo.
E c'è anche un business (un personaggio organizzativo è un personaggio che rappresenta gli interessi di un'organizzazione). Le aziende vogliono aumentare l'assegno medio, aumentare la frequenza degli acquisti e aumentare i profitti. L'idea è: offriamo piatti insoliti di una certa cucina. Un'altra idea: introduciamo la colazione.
Le idee possono e devono essere concretizzate, trasformate e presentate sotto forma di user story. Come dipendente dello Zakhar Business Center, desidero che il sistema mi riconosca in modo da poter ricevere un menu basato sulle mie preferenze. Come cameriere, voglio che il sistema mi avvisi quando avvicinarmi al tavolo in modo che il cliente sia soddisfatto del servizio veloce. E così via.
Decine di storie. Il prossimo passo è la definizione delle priorità e l'arretrato? Jeff sottolinea i problemi che sorgono: impantanarsi nei piccoli dettagli e perdere la comprensione concettuale, oltre a dare priorità alla funzionalità, crea un quadro irregolare a causa dell'incoerenza con gli obiettivi.
Percorso dell'autore: non diamo priorità alla funzionalità, ma al risultato = ciò che l'utente ottiene alla fine.
Un punto ovvio non ovvio: la sessione di definizione delle priorità non viene effettuata da tutto il team, perché è inefficace, ma da tre persone. Il primo è responsabile del business, il secondo dell'esperienza dell'utente e il terzo dell'implementazione.
Selezioniamo il minimo per risolvere il problema di un utente (soluzione minima praticabile).
Descriviamo in dettaglio le idee prioritarie utilizzando storie degli utenti, schizzi di progettazione, vincoli e regole aziendali sulla mappa delle storie degli utenti raccontando e discutendo con il team di cosa hanno bisogno le persone e le parti interessate in ogni fase del processo. Lasciamo le idee rimanenti non esaminate nell'arretrato delle opportunità.
Il processo è scritto sulle carte da sinistra a destra, con le idee sulle carte sotto le fasi del processo. È fondamentale che il percorso attraverso l'intera storia venga discusso insieme ai membri del team per garantire la comprensione reciproca.
L'elaborazione in questo modo crea integrità nel rispetto dei processi.
Le idee ricevute devono essere testate. Un membro non del team indossa il cappello della persona e vive la giornata della persona nella sua testa, risolvendo il suo problema. È possibile che non veda gli sviluppi, crei di nuovo le carte e la squadra scopra delle alternative da sola.
Poi ci sono i dettagli per la valutazione. Per questo bastano tre persone. Responsabile dell'esperienza utente, sviluppatore, tester con una domanda preferita: “E se...”.
In ogni fase, la discussione segue una mappa del processo della storia dell'utente, che consente di tenere presente il compito dell'utente per creare una comprensione coerente.
La documentazione è necessaria secondo l'autore? Sì, ne ho bisogno. Ma come appunti che ti permettono di ricordare ciò su cui hai concordato. Coinvolgere nuovamente un esterno richiede una discussione.
L'autore non approfondisce il tema della sufficienza della documentazione, concentrandosi sulla necessità della discussione. (Sì, la documentazione è necessaria, non importa come la sostengono le persone che non hanno una profonda conoscenza dell'agile). Inoltre, l'elaborazione solo di una parte delle capacità può comportare la necessità di una rielaborazione completa dell'intero sistema. L'autore sottolinea il rischio di un'elaborazione eccessiva nel caso in cui l'idea sia sbagliata.
Per eliminare i rischi, è necessario ricevere rapidamente un feedback sul prodotto che si sta creando per ridurre al minimo il danno derivante dalla creazione del prodotto “sbagliato”. Abbiamo fatto uno schizzo dell'idea, l'abbiamo convalidata con l'utente, abbiamo abbozzato prototipi di interfaccia, l'abbiamo convalidata con l'utente, ecc. (Separatamente, ci sono alcune informazioni su come validare i prototipi dei programmi). Gli obiettivi della creazione di software, soprattutto nella fase iniziale, sono l'apprendimento attraverso la ricezione di feedback rapidi; di conseguenza, il primo prodotto creato sono schizzi in grado di dimostrare o smentire un'ipotesi. (L'autore si basa sul lavoro di Eric Ries “Startup utilizzando la metodologia Lean”).
Una story map aiuta a migliorare la comunicazione quando l'implementazione viene eseguita da più team. Cosa dovrebbe essere sulla mappa? Ciò di cui hai bisogno per mantenere viva la conversazione. Non solo una user story (chi, cosa, perché), ma idee, fatti, schizzi di interfaccia, ecc...
Dividendo le carte sulla mappa della storia in più linee orizzontali, puoi dividere il lavoro in versioni: evidenzia il minimo indispensabile, uno strato di funzionalità crescente e archi.
Raccontiamo storie sulla mappa dei processi.
Un dipendente è venuto a pranzo.
Cosa vuole? Velocità del servizio. Così che il suo pranzo lo aspetta già sulla tavola o almeno su un vassoio. Ops, un passaggio mancato: il dipendente voleva mangiare. Ha effettuato l'accesso e ha selezionato l'opzione pranzo di lavoro. Ha visto il contenuto calorico e il contenuto nutrizionale per aiutarlo a seguire una dieta e a non ingrassare. Ha visto le foto del piatto per decidere se avrebbe mangiato in quel posto oppure no.
Poi andrà a pranzo e a cena? O forse il pranzo gli verrà consegnato in ufficio? Quindi la fase del processo è scegliere un posto dove mangiare. Vuole vedere quando gli verrà consegnato e quanto costerà, così potrà scegliere dove trascorrere il suo tempo e le sue energie: scendere o andare al lavoro. Vuole vedere quanto è affollato il bar per non fare la fila.
Poi il dipendente è venuto al bar. Vuole vedere il suo vassoio per poterlo prendere e andare direttamente a cena. Il bar vuole accettare denaro per guadagnare sul servizio. Il dipendente vuole perdere un minimo di tempo negli accordi con il bar, per non perdere inutilmente tempo prezioso. Come farlo? Paga in anticipo o viceversa dopo il servizio da remoto. Oppure paga sul posto utilizzando un chiosco. Qual è la cosa più importante in questo? Quante persone sono disposte a pagare il pranzo con una carta bancaria? Quante persone si fiderebbero di questa mensa per memorizzare il numero della propria carta per pagamenti ripetuti? Senza la ricerca sul campo non è chiaro, sono necessari test.
In ogni fase del processo, è necessario fornire in qualche modo funzionalità, per questo è necessario prendere una persona come base e scegliere ciò che è più importante per lui (gli stessi tre selettori). Ho seguito la storia fino alla fine = ho trovato una soluzione praticabile.
Poi arrivano i dettagli. Il cliente vuole vedere quanto è affollato il bar, per non fare la fila. Cosa vuole esattamente?
Guarda le previsioni di quante persone ci saranno tra 15 minuti quando arriverà lì
Visualizza il tempo medio di servizio in un bar e le sue dinamiche con mezz'ora di anticipo
Vedi la situazione e la dinamica dell'occupazione dei tavoli
Cosa succede se il sistema di previsione dà un risultato poco chiaro o smette di funzionare?
Guarda attraverso il video le code al bar, così come l'occupazione dei tavoli. Hmm, perché non farlo prima?!
L'autore indica un piccolo esercizio da praticare: prova a immaginare cosa fai la mattina dopo esserti svegliato. Una carta = un'azione. Ingrandisci le carte (invece di macinare il caffè, bevi una bevanda corroborante) per eliminare i singoli dettagli, concentrandoti non sulla modalità di realizzazione, ma sull'obiettivo.
A chi è rivolto questo libro: analisti IT e project manager. Assolutamente da leggere.
Apps
La discussione e il processo decisionale sono efficaci in gruppi da 3 a 5 persone.
Scrivi sulla prima carta ciò che deve essere sviluppato, sulla seconda correggi ciò che hai fatto nella prima, sulla terza correggi ciò che è stato fatto nella prima e nella seconda.
Prepara storie come le torte, non scrivendo una ricetta, ma scoprendo a chi, per quale occasione e per quante persone è destinata la torta. Se suddividessimo le vendite, non si tratterebbe della produzione di torte, creme, ecc., ma della produzione di piccole torte già pronte.
Lo sviluppo del software è simile alla realizzazione di un film, quando è necessario sviluppare e perfezionare attentamente la sceneggiatura, organizzare la scena, gli attori, ecc. prima dell'inizio delle riprese.
Ci sarà sempre una carenza di risorse.
Il 20% degli sforzi produce risultati tangibili, il 60% dà risultati incomprensibili, il 20% degli sforzi è dannoso: ecco perché è importante concentrarsi sull'apprendimento e non disperare in caso di risultato negativo.
Comunica direttamente con l'utente, sentiti nei suoi panni. Concentrati su alcuni problemi.
Dettagliare e sviluppare la storia per la valutazione è la parte più noiosa della mischia, rendere le discussioni in piedi in modalità acquario (3-4 persone discutono alla lavagna, se qualcuno vuole partecipare, sostituisce qualcuno).
Fonte: habr.com