Alberto Mucignat

Negli ultimi giorni sto lavorando a un progetto con Jacopo e stiamo applicando un processo di sviluppo totalmente agile. Abbiamo discusso parecchio su come pianificare le priorità delle cose da fare e abbiamo sostanzialmente evidenziato due modelli che voglio condividere.



In questo modello, vengono fatte per prime le funzionalità ad alto valore e basso effort. Successivamente le funzionalità ad alto valore ed alto effort e per ultime le funzionalità a basso valore e basso effort.

E' utile quando si vogliono rilasciare velocemente delle nuove funzionalità, ma ha il rischio che funzionalità particolarmente complicate (ad alto effort, quindi anche a maggior rischio) comportino problemi quando è troppo tardi per porvi rimedio.

In realtà è più sicuro avere il seguente approccio.



Facendo prima le funzionalità ad alto valore ed alto effort, si scoprono subito i problemi e si lasciano le funzionalità a basso effort per tutta la seconda parte della realizzazione. Come dire: le rogne prima le affronti, meglio è.

Da notare che in entrambi i casi le funzionalità a basso valore e alto effort non dovrebbero essere fatte: non sono essenziali e costano tanto. Un buon motivo che aiuta il cliente a scegliere cosa non fare.

Può sembrare un modello semplice, ma spesso è complicato stabilire le priorità di un progetto e fare una valutazione dell'effort per ogni singola funzionalità.

La mancanza di tempo è la scusa più comune, una giustificazione più che altro verso se stessi. Con le metodologie agili esiste una facile pratica chiamata planning game che aiuta molto.

In alternativa, si rischia di considerare che tutto sia importante e tutto sia facile, mentre non è mai così.

Comunque questo è solo il primo macro-livello del modello di pianificazione che stiamo costruendo, ma fornisce le basi per una discussione iniziale.

Tu cosa ne pensi? Hai mai pianificato il lavoro sulla base del valore e del costo delle feature? Che problemi/benefit hai avuto?

L'altra sera ho fatto una bella chiacchierata con Matteo. Tra le mille cose, abbiamo parlato anche di metodologie agili e di come lui non sia riuscito ad applicare GTD alla sua vita personale, come aveva già spiegato qualche tempo fa.

Nella mia vita, mi sono accorto invece di avere per le cose un'approccio agile, con particolare affinità a Scrum, per chi lo conosce.

Per esempio, ci sono i progetti personali come le vacanze, l'acquisto di una macchina, cambiare casa, ecc. Mi capita quindi spesso di fare dei daily scrum con Oli, in cui ci diciamo quello che abbiamo fatto ieri e quello che faremo oggi e in cui discutiamo dei problemi e di come risolverli. E il mio backlog di cose da fare è composto da numerosi post-it, appiccicati al case del pc, che riordino quotidianamente.

In generale, nella vita mi pongo continuamente degli obiettivi a medio termine, a cui mi avvicino a piccoli passi, visualizzando costantemente le cose fatte e quelle ancora da fare. Se non è metodologia agile questa!

Insomma, la mia vita è una beta, in continua evoluzione.

Bella presentazione in 7 minuti scarsi su come integrare la user experience con le metodologie agili. Avevo letto qualcosa di simile in un articolo di Luca di qualche tempo fa.

Oggi si possono sviluppare soluzioni veloci e poco costose, grazie ai framework e alle metodologie di sviluppo agili, a patto però di scendere a compromessi sulle feature: sono gli utenti e le loro esigenze a guidare il processo di selezione delle feature, di individuazione delle priorità, ecc.

Andando più a fondo, Agile non significa veloce, significa economizzare e sviluppare bene le cose più importanti. Significa anche scegliere quello che non si deve fare, semplicemente perchè non serve o perchè non è essenziale (per l'utente).

Mi vien da dire, citando il maestro: I want to know user's thoughts, the rest are details.

Vernerdì 16 dicembre, si terrà a Milano la prima giornata italiana dedicata ai metodi di sviluppo agili (via AGM). Peccato non sia in programma nessun talk di sviluppo agile orientato al web.

Assieme all'IASummit a Roma (febbraio 2006), questa è una conferenza importante, perchè per la prima volta in Italia si parla di alcune discipline utilizzate proficuamente in tutto il mondo. Come dire... un po' di innovazione, nonostante Stanca.