Archive for October, 2012

Uno sguardo a quelli bravi – User eXperience a confronto

In tutti i libri e in tutte le guide lette sulla User eXperience, non ho mai trovato degli esempi reali sui quali venivano applicate tutte le regole lette per una buona esperienza utente, nè tantomeno un confronto.

Con l’intento di approfondire l’argomento in questione, assieme al mio collega Luca (con cui è nata l’idea per questo laboratorio) abbiamo deciso di vedere come gli “esperti” rendono le proprie applicazioni così valide :)

Abbiamo così scelto un’applicazione sulla quale è stato fatto un apposito studio per la UX: Foursquare !


Per rendere il nostro laboratorio ancora più interessante e approfondito, abbiamo scelto di effettuare il nostro studio su due piattaforme diverse: Android e Windows Phone 7.
I due sistemi operativi hanno già di per se una User Interface ed una personalità d’uso completamente differente l’un l’altro, quindi anche le applicazioni differiranno molto fra di loro.

Read the rest of this entry »

Post to Twitter Post to Diigo Post to Facebook Post to FriendFeed Post to Google Buzz Post to LinkedIn

Metodi Agili non solo nello sviluppo del software

Dal blog di Claudio Menzani un post su una interessante case study:

Partecipo al Better Software fin dalla prima edizione del maggio 2009 e quest’anno invece delle considerazioni sui singoli talk – comunque tutti sempre molto interessanti – , mi vorrei soffermare su uno in particolare tenuto da Michele Luconi di e-xstrategy una software house marchigiana il cui percorso nell’adozione dei metodi agili sul team di sviluppo si è successivamente ribaltata anche sulla parte contrattualistica commerciale.

In pratica fino a qualche anno fa il loro metodo di sviluppo era basato su quello che è il modello della stragrande maggioranza delle aziende che sviluppano software a progetto, proprio come la nostra, e cioè raccogliere i requisiti per lo sviluppo in uno o più incontri con il cliente, scrivere un documento di analisi che a sua volta determina tempi e costi, utilizzando i quali il commerciale produce l’offerta.

Entrambi i documenti vengono sottoposti al cliente, che dopo una o più sessioni di revisione, approva il progetto inviando l’ordine.

A questo punto inizia la fase di sviluppo, ma come tutti noi sappiamo sviluppare software non è come costruire ponti, la tipica metafora che spesso viene usata per evidenziare il fatto che nell’arte di sviluppare software i requisiti cambiano quasi sempre in corso d’opera e questo cambiamento lo si deve assumere come naturale, ma va anche gestito altrimenti si trasforma in un contenzioso continuo con il cliente a scapito della qualità del lavoro, della tenuta nervosa e non ultimo del conto economico.

Il metodo “tradizionale” di gestione dei progetti, ci porta a considerare questo continuo cambiamento di requisiti con estrema diffidenza, sia dalla parte chi sviluppa, sia da chi deve porsi il problema di come recuperare i costi dal cliente evitando di trasformare gli incontri con il cliente stesso in sessioni dal tenore del recupero crediti.

Quindi armonizzare anche la parte commerciale al concetto che sottointende ai metodi agili offrendo un metodo ed uno strumento contrattuale è una ricaduta quasi naturale e comunque necessaria.

Michele Luconi, ha mostrato il contratto scritto con Jacopo Romei (coach e conferenziere sui metodi Agili) rilasciato in modalità open source e reperibile in rete, che cambia radicalmente l’approccio nella gestione del progetto dal punto di vista del rapporto con in cliente.
In pratica si tratta di un documento di due pagine che introduce il concetto di iterazione.

Nella pratica si effettua la prima raccolta di requisiti dopodichè si procede con l’analisi del progetto stimando il numero di iterazioni che possono essere necessarie per raggiungere l’obbiettivo, questo numero viene condiviso con il cliente, ma non ìnserito nel contratto, quindi è puramente indicativo.

Ogni iterazione ha la durata di una settimana ed ha un costo medio stabilito, esempio € 2.000.
Al termine dell’iterazione il risultato viene condiviso con il cliente, il quale, per contratto, ha le seguenti possibilità:
1) Approva l’iterazione ed emettiamo fattura.
Si passa allo sviluppo dell’iterazione successiva

2) Non approva l’iterazione. Il cliente può scegliere di terminare lo sviluppo, oppure di ridefinire i requisiti e procede con un’ulteriore iterazione.
Questo significa che la software house ha, al massimo, perso una settimana di lavoro.

E via di seguito fino al Go-Live del progetto.

Il case study presentato ha trasmesso sicuri elementi di novità

Ovviamente immagino che non sia un percorso rose e fiori, che necessiterà senz’altro di continui aggiustamenti, ma l’ho trovato di assoluto interesse e soprattutto mi ha dato l’impressione che in qualche modo chiuda il cerchio fra il momento di sviluppo e quello di gestione del rapporto con il cliente, in un ambito così particolare come quello dello sviluppo di progetto software

Post to Twitter Post to Diigo Post to Facebook Post to FriendFeed Post to Google Buzz Post to LinkedIn

Better Software 2012 ecco i motivi per cui torneremo

Lo ammetto, non è stato facile aspettare il 26 Settembre per arrivare al Better Software 2012 ma devo dire che ne è valsa la pena.

Vivido partecipa a questo evento fin dal 2009,la sua prima edizione, e siamo del tutto intenzionati a riconfermare la nostra presenza per il 2013 per una serie di motivi che spero di riuscire trasmettere ai più curiosi che continueranno la lettura di questo post.

vivido al better software 2012

Read the rest of this entry »

Post to Twitter Post to Diigo Post to Facebook Post to FriendFeed Post to Google Buzz Post to LinkedIn