Inizio la serie di 3 post dedicati al CSMA10 con un doveroso e sentito ringraziamento a XPug Marche, che ha organizzato l’evento; a Jacopo, che ci ha dato tanto di tutto: metodi, conoscenze, cultura, strumenti, consigli, esperienza, comprensione; e alla Casa di Campagna, per l’ospitalità. E ringrazio i singoli partecipanti al Campo (Stefano Leli, Stefano Ottaviani, Roberto Sileoni, Giacomo D’Angelo, Alessandro Violini, Lorenzo Massacci, Riccardo Mancinelli, Roberto Lupi, Costantino Giuliodori e Paola di Tomasso), perché si sono dimostrati seri, appassionati e apertissimi al confronto.
È da circa un anno e mezzo che e-xtrategy mi ha messo di fronte a progetti impostati secondo metodologie agili. Per tutto questo tempo ho cercato di ricostruire i motivi per cui mi si chiedeva di lavorare così. Ho visto i vantaggi e mi sono scontrata con diversi problemi. Al CSMA sono finalmente partita da zero: teoria, metodi, scrittura delle storie, planning e planning game, iteration e release planning, suddivisione in task… E finalmente ho potuto riempire il vuoto “culturale” che avevo. Siamo partiti da un finto progetto, sulla base della traccia suggerita da Stefano Ottaviani: un sito di e-commerce per la vendita di ebook online, che per motivi di tempo abbiamo ridotto a una semplicissima applicazione collegata con Twitter. Atomizzando il finto progetto deciso al CSMA, ho potuto fare le mie domande e tirare le fila.
Prima lezione: una nuova visione sulle user stories.
Da quando cerco di lavorare con questo metodo, la scrittura delle user stories mi è sembrata la prima grande novità metodologica. Mi sono sembrate molto utili per definire un progetto nel dettaglio, discuterlo e condividerlo, oltre che metterlo in ordine di priorità. Tutto questo mi ha messo di fronte all’evidenza di dover definire meglio il mio ruolo come designer delle interfacce e all’esigenza di trovare un terreno di dialogo comune con gli sviluppatori.
Da quando scriviamo un progetto con le user stories, mi sono sentita come se fossimo un gruppo di persone dentro un appartamento vuoto da riempire. Ogni storia era come un mobile che ognuno portava e lasciava lì dentro, in ordine sparso. A me veniva richiesto di mettere in ordine le stanze e trovare un posto per ogni cosa, oltre che trovare i mobili mancanti. In questa situazione, avevo difficoltà a inquadrare il progetto nel suo insieme, mi occorreva tempo per fare ordine e quindi anche per discutere i punti critici. Questo creava problemi perché è importante che tutto il team abbia chiaro il progetto nel più breve tempo possibile. Al CSMA credo di aver trovato la chiave giusta: posso inserirmi nella scrittura delle storie facendo ordine fin dall’inizio. Ho capito che gli sviluppatori hanno bisogno di spezzettare un progetto in piccole parti, mentre noi designer abbiamo bisogno della visione d’insieme. Il metodo che potrei usare è proprio quello di guidare il processo di scrittura individuando gli scenari (e sottoscenari) in cui l’utente si trova (o, forse, dovrei dire “che proponiamo all’utente”). Tra l’altro, ho scoperto che questi scenari corrispondono all’incirca a un tipo di user story che in gergo viene chiamata “epic” (storie molto grandi che quindi andranno spezzettate).
Curioso perché credo che davvero che sia un uovo di Colombo. Non vedo l’ora di mettere in pratica questo sistema.
10 Commenti
la connessione scenari/user stories è fondamentale e sia chiaro che ne rivendico la paternità (chiedere al jakuza ;-) )
a parte le frivolezze, ti segnalo un post che ho scritto qualche tempo fa, perché riassume gran parte del mio pensiero a proposito: http://www.mucignat.com/blog/archives/1947-augmented-design-e-agile-ux.html
al momento continuo a pensare che le user stories devono arrivare dopo che sono stati definiti gli “scenari ucd” (quelli che definisci correttamente epic). il problema è che per definire questi scenari *senza inventare* (ovvero senza sbagliare), bisogna fare ricerca con gli utenti. e quando fai ricerca con gli utenti, il 90% delle user stories vengono fuori già pronte.
ad ogni modo, viene spesso ignorata la sottile linea di demarcazione tra (1) il punto di vista dell’utente e (2) il punto di vista del designer/sviluppatore che scrive le funzionalità mettendosi nei panni dell’utente. e questa demarcazione può portare a grandi successi come a clamorosi errori, in base alla fortuna diciamo. :-)
Non temere, Jacopo ti cita spesso come partner di lavoro ideale, grazie a questi sistemi che avete messo a punto.
A maggio hai scritto in un post una lezione di Design che era il collegamento che stavo cercando. Curiosamente lo avevo letto (ti leggo sempre) ma è proprio un peccato che il cervello non colleghi le possibilità finché non ci sbatte il naso… o meglio, finché le mani non si “sporcano”. Nonostante l’averti letto e nonostante un anno di scrittura di user stories, mi ci è voluto il campo scuola per accendere la lampadina e far attivare tutti quei famosi “Ah! allora era quello!”
Queste metodologie mi sono arrivate dagli sviluppatori, quindi dal loro punto di vista… e ora sto impiegando tante energie a capire come conciliare tutto questo con il mio. E come evolvermi, di conseguenza. Ora spero di avere un minimo di base culturale in più, tanto da riuscire a diventare più utile e propositiva. :)
Nel frattempo, vado a rileggermi la miriade di link che hai messo nel tuo post. :)
Quanto dici sugli utenti / designer è sicuramente vero, e sarà l’argomento del prossimo post (è pronto in bozza e lo pubblico a breve). Ricordo che ti avevo chiesto, proprio sul tuo blog, come si può fare per includerli in tutto il processo. Mi avevi risposto che anche questi test vanno inclusi nello sviluppo, quindi non deve emergere un costo a parte. Mi trovi e trovavi d’accordo al 1000%, solo che noi ci scontriamo quotidianamente con problemi di budget e opportunità. Quando un progetto deve essere fatto con poche (ma veramente poche) migliaia di euro, non so ancora come possano venire fuori l’analisi o i test con gli utentu… L’unico modo che mi viene in mente è quello di Krüg: se non ci sono i soldi, vanno bene anche test “caserecci”. Lo scrivo in tutta sincerità. … non so se esista un’idea migliore.
un giorno ho letto una frase tipo “even a test on your mom is better than anything”. io in mancanza di budget faccio sempre un test con la mia ragazza o con qualcuno preso di forza dall’ufficio attiguo ;-)
ad ogni modo, è il solito giochetto del budget. a me fa ridere però: spesso i cambiamenti successivi costano molto di più perché ci sono errori da correggere. quindi in realtà (ed è la mia esperienza), ricerca e test riducono molto le correzioni e modifiche future.
certo bisogna comunicarlo e farlo digerire ai clienti. oh yes, benvenuti nel mondo del biznezz ;-)
L’ultimo pomeriggio del Campo Scuola è stato dedicato proprio a questo. Far capire che anche l’analisi ha un costo. Veniamo da settori per cui questa cosa non è ovvia per niente, perché si viene sempre paragonati a qualcuno che può farlo a un prezzo inferiore.
Francamente mi spaventa sempre di meno l’eventualità di perdere un lavoro per non aver avuto il coraggio di far capire che tutto ha un costo.
Ti spaventa sempre meno perché aumenta la consapevolezza di ciò che è giusto, di quanto vali e, anche, di ciò che è ineluttabile. Se al cliente facesse risparmiare qualcosa proverebbe anche a negare il modello eliocentrico del sistema solare, nessuna esigenza di budget però ne farà mai un argomento valido.
Ribadendo le forti sovrapposizioni esistenti fra l’approccio mio e quello di Alberto – che appunto stia tranquillo che cito cito! :-) – occhio a non perdere di vista che l’obiettivo qui (tra me, te Ilaria e i tuoi colleghi) è proprio quello di portare il tutto un passetto in avanti, accontentandoci di farne anche solo uno piccolissimo.
Gli scenari da cui Alberto anche qui propone la derivazione delle user story in modalità “top-down”, sono per me – e spero di riconfermarmi in un ‘noi’ nel tempo – un artefatto di natura dialogica e quindi continuamente zompettanti tra la deduzione “top-down” e l’induzione ‘bottom-up’. Sono liquidi, discussi, fanno venire in mente idee e servono a cementare idee.
In parole povere, OK derivare le user story dagli scenari, (che equivale allo story “splitting” che abbiamo visto) ma trovo perfettamente legittimo e utile ed efficace accorpare user story emerse fino ad ottenere nuovi scenari.
La mente umana funziona così, *soprattutto* quella dei cosiddetti esperti: dedurre dall’astratto al particolare e *contemporaneamente* indurre dal particolare all’astratto.
Siccome ci interessa
* Gli individui e le interazioni più dei processi e degli strumenti
* Il software funzionante più che la documentazione esaustiva
* La collaborazione col cliente più che la negoziazione del contratto
* Rispondere al cambiamento più che seguire i piani
sappiamo di essere sulla strada giusta non appena ci apriamo a questo riflusso “verso l’alto” delle informazioni che otteniamo in qualsiasi modo sul nostro progetto, che la fonte sia un utente, un cliente o un maledettamente nerd sviluppatore. :)
Per proseguire la metafora, non dovrebbe spaventarci se l’arrivo di un nuovo mobile o una diversa disposizione dei mobili cambiasse il progetto della casa. Spero di arrivarci, un passo alla volta.
Qui nelle Marche si potrebbe commentare con un classico “Hai detto cotica!” :D
Il problema è che man mano che la casa è organizzata è *vero* che costa di più accettare un nuovo mobile e riorganizzare la casa. Qui quindi dobbiamo fare due considerazioni:
– la metafora del mobilio un po’ comincia a vacillare: la ristrutturazione di user story, scenari e codice se affidato in mani esperte può essere economica da affrontare, o perlomeno non aumentare esponenzialmente, come nel caso classico. (C’è chi sostiene che addirittura si possano avere sistemi IT la cui complessità diminuisce al crescere del sistema stesso…)
– posticipare il più *possibile* l’ossificazione cui portano le decisioni prese *deve* essere un imperativo: postporre postporre postporre!
pensavo all’idea di “analisi come costo”… di solito io la definisco un’investimento. e i test sono un’assicurazione sul futuro del progetto.
Informazioni e licenza
Questo blog utilizza Wordpress è basato sul tema Gutenberg, modificato da me con i preziosi consigli di Nicolò e il fondamentale supporto di Luca
Eccetto dove diversamente specificato, i contenuti del mio blog sono pubblicati con Licenza Creative Commons Attribuzione Non commerciale - Condividi allo stesso modo 3.0 (Italia License).