Agilità nel creare prodotti e servizi software
organizzare il lavoro in piccoli cicli iterativi molto focalizzati dove persone “concentrate” e “competenti” cercano di risolvere problemi nel minor fattore di rischio possibile

Ieri durante l’Agilecamp ho discusso in più momenti (culminati nel mio intervento.. di seguito la presentazione) di come i principi e le metodologie agili si possono innestare anche nel mondo della progettazione. La discussione in maniera un po’ curiosa si è focalizzata diverse volte sulle criticità che questi due mondi vivono nell’interfacciarsi ed in particolare io vedo come questioni critiche:

• 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 :)