Il Better Software (2013 e non solo)

Le abbiamo fatte tutte.

Nel senso che con questa 5° edizione del Better Software , Vivido ha partecipato a tutte.

Quest’anno una grande novitĂ  è stato il passaggio di mano dell’organizzazione dalla fondatrice Develer ad un gruppo di persone/aziende.

La Conferenza è cresciuta di anno in anno, sia come fruibilitĂ  logistica delle varie sessioni, che nei contenuti che si sono fatti sempre piĂą “sofisticati”, passando dall’iniziale (prime due edizioni)  attenzione ai concetti ed agli strumenti che stanno alla base delle metodologie Agili, fino a passare (le ultime due edizioni ) da case study su come queste metodologie sono state implementate in vari contesti, fino ad arrivare a quest’anno dove il focus è stato orientato sui concetti di produzione ed gestione Lean sia dei progetti che piĂą in generale delle organizzazioni e dei sistemi complessi.

A parte le conferme sulla qualità degli speaker, mi è piaciuto il senso di continuità logica nei contenuti dei vari talk, il che significa che gli organizzatori hanno messo attenzione nella creazione del palinsesto.

Concludo affermando che ormai il Better Software è una realtà consolidata e che deve continuare ad esistere.

Mi rendo conto che  deve essere molto impegnativo organizzare un evento del genere, soprattutto per chi fa giĂ  altro lavoro e quindi è mosso principalmente dalla passione, perciò – la butto li- se per il futuro gli attuali organizzatori pensano ad un modello ancora piĂą “allargato” Vivido è disponibile a dare il proprio contributo .

Metodi Agili non solo nello sviluppo del software

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.

Sulla inevitabile utilitĂ  della programmazione Agile!

Ho appena preso in mano “e-Commerce” il libro fresco di stampa scritto da Daniele Vietri aka @marlenek e Giovanni Cappellotto aka @giocappellotto  e solo sfogliandolo credo che in Italia non esista qualcosa di piĂą completo sull’argomento in questione, ma mi riservo di parlarne appena avrĂ  finito di leggerlo.

Qui volevo evidenziare questa frase che è mi saltata agli occhi e che descrive bene l’importanza dell’utilizzo di un approccio Agile nello sviluppo del software.

L’autore di queste parole è Jacopo Romei aka @jacoporomei , Agile Coach di Ideato che ho avuto occasione di vedere all’ultima edizione del Better Software in un simpatico duetto :

Lo sviluppo agile è la risposta del mondo del software alla realtà dei mercati moderni: elevate probabilità che la partita da giocare veda le regole cambiate in corsa.

La rapiditĂ  di risposta agli eventi è una necessitĂ  emersa con forza anche nell’industria “pesante”, nel mondo del software il problema è accentuato.

E’ inutile fare piani lunghi mesi o anni, o perlomeno è sicuramente troppo dispendioso: il budget va usato solo dove serve e bisogna smetterla di anticipare le mosse nel vano tentativo di sentirsi piĂą sicuri.

Un piĂą rigoroso metodo di ‘inspect & adapt’ garantisce investimenti piĂą piccoli quando le informazioni sono poche.

Galileo Galilei ha inventato questo sistema.