L’agilità dal punto di vista della progettazione

  • il fatto che lo sviluppo agile nasce centrato sulla soddisfazione del cliente “interno” (rapporto a 2 attori) e non sul soddisfare tutti gli attori che sono coinvolti nei servizi verso l’utente finale (management, marketing, utenza)!
  • lo sviluppo è un’attività ingegneristica “esatta”, la progettazione è basata puramente su ipotesi!
  • presupponendo che sia la progettazione a definire le storie con tutti gli attori: quanto in ogni ciclo di sviluppo va orientato all’evoluzione del prodotto, quando al miglioramento e quanto all’esplorazione?
  • progettare è spesso comunicare, per comunicare dobbiamo descrivere in maniera formale e dunque documentare… ma qual’è la documentazione ponte? (come risposta si è parlato di storie e wireframes)
  • la prioritizzazione delle storie va dunque ora fatta secondo il punto di vista di più attori (management, marketing, utenza) ma chi è più rilevante in che campo? dobbiamo introdurre una fattorizzazione?
  • quanto la conduzione dello sviluppo di prodotto/servizio deve essere strategica (di lunga visione) e quanto tattica (a breve termine)?
  • come facciamo a fare diventare i test con utenti semplici quanto i test jUnit? (nel senso che li possiamo lanciare quando vogliamo)
  • i deliverables e gli strumenti progettuali che gli UX designer usano ogni giorno sono ottimi per sviluppare il progetto e pessimi per evolverlo, rifattorizzarlo, manutenerlo… dobbiamo pensare a nuovi strumenti?

So che ad ognuno di questi punti vi sono già risposte teoriche o parzialmente applicate (in contesti dove però spesso tempo e budget sono pressochè infiniti) che tentano di dargli risposta ma purtroppo se prendiamo con pragmatismo i vari problemi capiamo che dobbiamo esplorare ancora parecchio questa sinergia di discipline per arrivare ad una risposta sostenibile in maniera trasversale sul mercato.

Per questo motivo la conclusione del mio intervento si è concentrata in maniera molto pragmatica nel dire che nella pratica quotidiana ho già provato a sviluppare un processo che tenti di unire questi due mondi e da circa 3 mesi lo stiamo testando con clienti e partner diversi in sketchin ma che l’agile che stiamo provando oggi non si basa su metodologie di dettaglio ma su una definizione di principio di agilità (scritta in maniera un po’ “volgare” per un purista dell’agile ma molto concreta) che speriamo nei prossimi mesi ci permetta di rispondere con soluzioni concrete alle questioni ancora oggi aperte.

ps: voglio ringraziare ancora Jacopo ed il mio team per il supporto nell’organizzazione di questo piccolo ma fantastico barcamp :)

  1. Aaaahhhh! Troppa roba!

    Punto 1. (sviluppo agile centrato sul cliente)
    D’accordissimo!

    Punto 2. (lo sviluppo è un’attività ingegneristica “esatta”)
    Seeeeeeeeeeee! Capisco cosa intendi, ma non c’è tutta questa certezza nelle soluzioni software e nemmeno tutta questa assenza di creatività.

    Punto 3.
    Problema evidentisssssimo!

    Punto 4.
    Comunicare NON è formalizzare! Comunicare è c o mu n i c a r e. Formalmente se serve, ma solo SE serve. Le user story funzionano perché sono INformali.

    Punto 5. Punto 6.
    Problemi simil… analogo al punto 3, no?

    Punto 7.
    Qui secondo me si deve scendere a patti con un SANO empirismo ed accettare test più imprecisi ma che possano essere più frequenti.

    Punto 8.
    Questo generalizza il punto 7. Il vero Graal della nostra comune ricerca. Ti piace messa così? ;)

    Bella giornata, mi sono divertito molto. Ciao!

  2. Punto 2: lo so, ma almeno c’è una certa oggettività… io non posso assicurare che il design funzioni, neanche dopo i test ;)

    Punto 4: sono d’accordo con te, ma qui parliamo di comprendere il design e comunicare a più pubblici in tempi spesso diversi (es: il wireframe che va in mano all’agenzia esterna che farà la creatività)

    Punto 5,6: si

    Punto 7: il problema è che è dimostrato che anche il coinvolgimento dell’utente è fondamentale e quando abbiamo a che fare con gli utenti sorge un problema di organizzazione del tempo

    Punto 8: fantastica :) iniziamo a lavorarci sopra e vediamo dove andiamo a parare :)

  3. Pingback: Agile UXD: un nuovo processo agile | Luca Mascaro dot info