Abstract
Questo libro racconta l'algoritmo per gestire il processo di sviluppo, dall'idea fino all'implementazione, utilizzando tecniche agili. Il processo è suddiviso in passi, e per ciascun passo vengono indicati i metodi appropriati. L'autore sottolinea che gran parte dei metodi non è originale e non pretende di esserlo. Tuttavia, lo stile di scrittura efficace e una certa coerenza nel processo rendono il libro molto utile.
La chiave della tecnica delle mappe delle storie degli utenti è la strutturazione delle idee e degli obiettivi lungo l'esperienza dell'utente nel processo.
È possibile presentare il processo in vari modi. Si possono organizzare i passi in base al raggiungimento del valore chiave, oppure si può semplicemente descrivere una giornata lavorativa degli utenti, come si svolge utilizzando il sistema. L'autore si concentra sul fatto che i processi devono essere narrati, raccontati sotto forma di storia dell'utente sulla mappa del processo, da cui il nome "mappa delle storie degli utenti".
A chi può essere utile
Per analisti IT e project manager. Imperdibile. È facile e piacevole da leggere, il libro ha una dimensione media.
Revoke
Nella sua forma più semplice, così funziona.
Un visitatore entra in un caffè, sceglie i piatti, effettua un ordine, riceve il cibo, mangia, paga.
È possibile scrivere i requisiti su ciò che desideriamo dal sistema in ogni fase.
Il sistema deve mostrare un elenco di piatti, per ogni piatto gli ingredienti, il peso e il prezzo e deve avere la possibilità di aggiungere al carrello. Perché siamo sicuri di questi requisiti? Nella descrizione 'standard' dei requisiti non sono indicati e ciò genera rischi.
Gli esecutori, non comprendendo a cosa serva, di solito non fanno ciò che serve. Gli esecutori non coinvolti nel processo di creazione dell'idea non si sentono neanche responsabili del risultato. L'Agile dice: concentriamoci prima di tutto non sul sistema, ma sulle persone, sui consumatori, le loro esigenze e obiettivi.
Creiamo personaggi, per empatia aggiungiamo dettagli e dalle prospettive dei personaggi iniziamo a raccontare storie.
L'impiegato Zahar è andato a pranzo e desidera uno spuntino veloce. Di cosa ha bisogno? L'idea è che probabilmente voglia un pranzo d'affari. Un'altra idea è che desidera che il sistema ricordi le sue preferenze, poiché è a dieta. Ancora un'idea. Vuole che gli venga portato subito un caffè, perché è abituato a berlo prima di pranzo.
E c'è anche il business (org персонаж — un personaggio che rappresenta gli interessi di qualche organizzazione). L'azienda vuole aumentare il valore medio dell'assegno, incrementare la frequenza degli acquisti e aumentare il profitto. Un'idea — perché non offriamo piatti insoliti di qualche cucina. Un'altra idea — perché non introduciamo la colazione.
Le idee possono e devono essere specificate, trasformate e formalizzate in forma di user story. Come impiegato del business center Zahar, voglio che il sistema mi riconosca, così posso ricevere il menu in base alle mie preferenze. Come cameriere, voglio che il sistema mi avvisi quando è il momento di avvicinarmi al tavolo, in modo che il cliente sia soddisfatto del servizio rapido. E così via.
Decine di storie. E poi la prioritizzazione e il backlog? Jeff indica i problemi che sorgono: il rischio di rimanere impantanati nei dettagli e la perdita della comprensione concettuale, insieme alla priorizzazione delle funzionalità, creano un quadro frammentato a causa della non coerenza rispetto agli obiettivi.
Il percorso dell'autore: Priorizziamo non le funzionalità, ma il risultato = ciò che l'utente ottiene alla fine.
Un punto ovvio ma non così ovvio: la sessione di prioritizzazione non si svolge con l'intero team, perché non sarebbe efficace, ma con tre persone. Il primo si occupa dell'aspetto commerciale, il secondo dell'esperienza utente e il terzo dell'implementazione.
Definiamo il minimo per risolvere un compito dell'utente (soluzione vitale minima).
Dettagliamo le idee della prima priorità tramite user story, schizzi di design, vincoli e regole aziendali nella mappa delle user story, raccontando e discutendo con il team ciò che è necessario per i personaggi e gli stakeholder ad ogni passo del processo. Le altre idee rimangono non elaborate, nel backlog delle opportunità.
Il processo viene scritto sotto forma di schede da sinistra a destra, con le idee sulle schede sotto i passaggi del processo. È fondamentale discutere insieme ai membri del team l'intero percorso della storia per creare una comprensione reciproca.
Utilizzare questo metodo crea un'integrità in linea con i processi.
Le idee raccolte devono essere verificate. Un membro del team assume il ruolo della persona e immagina per un giorno la sua vita, cercando di risolvere il suo compito. C'è la possibilità che non veda i risultati già ottenuti, creando di nuovo le schede, mentre il team scopre alternative.
Successivamente avviene la dettagliazione per la valutazione. Per questo bastano tre persone: il responsabile dell'esperienza utente, un sviluppatore e un tester con la sua domanda preferita: “E se…”.
A ogni fase, la discussione si basa sulla mappa dei processi della storia dell'utente, il che consente di mantenere a mente l'obiettivo dell'utente e creare una comprensione uniforme.
È necessaria una documentazione secondo l'autore? Sì, è necessaria. Ma come note, per ricordare di cosa ci siamo accordati. Coinvolgere una persona esterna richiede nuovamente discussione.
L'autore non approfondisce il tema della sufficienza della documentazione, concentrandosi invece sulla necessità di discussioni. (Sì, la documentazione è necessaria, indipendentemente da quanto affermino le persone che non comprendono a fondo l'agile). Inoltre, sviluppare solo una parte delle funzionalità può portare alla necessità di rifare completamente l'intero sistema. L'autore indica il rischio di una sovra-analisi quando non si indovina l'idea.
Per ridurre i rischi, è fondamentale ricevere rapidamente feedback sul prodotto in fase di sviluppo per minimizzare il danno causato dalla creazione di un prodotto "sbagliato". Abbiamo creato una bozza dell'idea — validata con l'utente, una bozza dei prototipi dell'interfaccia — validata con l'utente, ecc. (Viene fornita una breve indicazione su come validare i prototipi software). Gli obiettivi della creazione di software, specialmente nella fase iniziale, sono l'apprendimento attraverso un rapido feedback, quindi il primo prodotto creato è una bozza in grado di provare o confutare un'ipotesi. (L'autore si basa sul lavoro di Eric Ries "The Lean Startup").
La mappa delle storie aiuta a facilitare la comunicazione quando l'implementazione è gestita da più team. Cosa dovrebbe esserci nella mappa? Tutto ciò che è necessario per sostenere la conversazione. Non solo le user story (chi, cosa, perché), ma anche idee, fatti, schizzi dell'interfaccia, e altro.
Dividendo le schede nella mappa delle storie in più linee orizzontali, è possibile suddividere il lavoro in rilasci — evidenziare il minimo indispensabile, il livello di ampliamento delle funzionalità e i dettagli finali.
Discutiamo le storie nella mappa del processo.
Un dipendente è andato a pranzo.
Cosa desidera? Velocità di servizio. Vorrebbe che il suo pranzo fosse già pronto sul tavolo o almeno su un vassoio. Oops — passo dimenticato: il dipendente ha voluto mangiare. È entrato nel sistema e ha scelto una opzione di business lunch. Ha visto le calorie e 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 un pranzo e a pranzare? O forse gli porteranno il pranzo in ufficio? In tal caso, il passo del processo è scegliere dove mangiare. Vuole vedere la scadenza per la consegna e quanto costerà, per decidere dove spendere tempo e risorse — per andare al piano di sotto o rimanere al lavoro. Vuole conoscere il livello di affollamento del caffè, per evitare di trovarsi in lunghe code.
Successivamente, il dipendente arriva al caffè. Vuole vedere il suo vassoio, per prenderlo e andare immediatamente a pranzare. Il caffè vuole incassare denaro, per guadagnare grazie al servizio. Il dipendente desidera perdere il minor tempo possibile nei pagamenti con il caffè, per non sprecare tempo prezioso inutilmente. Come può farlo? Pagando in anticipo o, al contrario, dopo il servizio in modalità remota. Oppure pagando direttamente al momento, utilizzando un chiosco. Quale di queste opzioni è più importante? Quante persone sono pronte a pagare il pranzo con una carta bancaria? Quante persone si fideranno di memorizzare il numero della carta per pagamenti futuri in questa mensa? Senza una ricerca sul campo, rimane incerto; è necessaria una fase di test.
In ogni fase del processo, è necessario garantire in qualche modo il funzionamento; per questo bisogna prendere come riferimento una persona e scegliere cosa è più importante per lei (quella famosa triade di selezione). Se abbiamo completato la storia, abbiamo creato una soluzione sostenibile.
Successivamente si passa ai dettagli. Il cliente vuole vedere l'occupazione del caffè per evitare di fare la fila. Cosa desidera esattamente?
Vedere la previsione di quante persone ci saranno tra 15 minuti, quando arriverà lì.
Controllare il tempo medio di servizio nel caffè e la sua evoluzione per i prossimi trenta minuti.
Osservare la situazione e la dinamica dell'occupazione dei tavoli.
E se il sistema di previsione fornisse un risultato incomprensibile o smettesse di funzionare?
Guardare attraverso le telecamere le file nel caffè, così come l'occupazione dei tavoli. Hmm, perché non farlo prima di tutto?!
L'autore propone un piccolo esercizio per praticare: prova a immaginare cosa fai al mattino dopo esserti svegliato. Una scheda = un'azione. Raggruppa le schede (invece di macinare il caffè, bere una bevanda energizzante) per rimuovere dettagli individuali, concentrandoti non sul modo in cui si realizza, ma sull'obiettivo.
Questa è una lettura imprescindibile per analisti IT e project manager.
Applicazioni
Le discussioni e le decisioni sono più efficaci in gruppi da 3 a 5 persone.
Scrivi sulla prima scheda cosa deve essere sviluppato, sulla seconda cosa correggere di quanto fatto nella prima, nella terza correggi quanto fatto nella prima e nella seconda.
Prepara le storie come torte: senza scrivere la ricetta, scopri per chi, per quale evento e per quante persone è la torta. Se devi dividere l'implementazione, fallo non sulla preparazione della base, della crema, ecc., ma su piccole torte già pronte.
Lo sviluppo software è simile alla creazione di un film, dove è necessario elaborare e perfezionare attentamente la sceneggiatura, organizzare la scena, gli attori e molto altro prima di iniziare le riprese.
Le risorse non saranno mai sufficienti.
Il 20% degli sforzi porta risultati tangibili, il 60% porta risultati incerti, il 20% degli sforzi è controproducente — ecco perché è importante concentrarsi sull'apprendimento e non scoraggiarsi di fronte a un risultato negativo.
Comunica direttamente con l'utente e metti te stesso nei suoi panni. Concentrati su alcuni problemi.
La dettagliata elaborazione della storia per la valutazione è la parte più gravosa dello scrum; rendete le discussioni statiche in modalità acquario (alla lavagna discutono 3-4 persone; se qualcuno desidera partecipare, sostituisce uno di loro).
Fonte: habr.com
