La sostenibilità dell’agile design

Sono appena arrivato a San Francisco e ho colto l’occasione del viaggio per riflettere un po’ su un intervento sull’agile design che ho seguito durante il Web 2.0 Expo di New York.

Seguire un design e uno sviluppo agile è il modello che ritengo in assoluto più affascinante per chi punta alla qualità. Un processo rapido e focalizzato al risultato che permette specialmente nel nostro settore di creare prodotti innovativi e funzionali in un modello crescente.

Insomma una vera e propria panacea per molti progetti dal punto di vista teorico ma che nasconde a mio vedere una serie di inconvenienti dal punto di vista della sostenibilità nel nostro mercato sud europeo.

Il punto è che i processi agili richiedono il coinvolgimento di figure di alto livello che collaborano tra di loro in periodi contigui di forte concentrazione.

Questo significa ottenere in tempi brevi prototipi o prime versioni funzionali del prodotto dalla qualità eccelsa e perfettamente in tempo per il mercato, ma, significa anche bloccare completamente interi team di progettazione e sviluppo per tempi medio-lunghi (si parla di avere prodotti pronti al lancio in 2 cicli / 4 settimane ma completi e di ottima qualità dopo qualche mese).

Non è da nascondere che nel nostro mercato non sempre si punta alla qualità e che i clienti chiedono spesso una chiusura del progetto in tempi brevi e con costi contenuti.

Questo cozza nella pratica di tutti i giorni con la pratica definita precedentemente e succede così che chi fa “agile” si trova strozzato in pochi cicli, in tempi impossibili o semplicemente deve affrontare più progetti “mediocramente” perchè non ha i fondi per affrontarne uno “seriamente”.

Alla fine il risultato è sempre lo stesso: il prodotto è incompleto o di scarsa qualità

La domanda che dunque mi pongo è bisogna cambiare la mentalità della clientela/mercato portandola a comprendere i vantaggi di questi processi oppure identificare nuove strade che intermedino il tutto?

  1. Se fossi in te porrei questa domanda allo storico gruppo di Agile/eXtreme Programming dove trovi un po’ di team leader, sviluppatori che fanno xp e project manager: http://it.groups.yahoo.com/group/extremeprogramming-it/

    Magari ne nasce una bella discussione ;-)

    La mia personale opinione (anche di lettore/contributor della lista) è che fare Agile e XP significa coinvolgere tutti i soggetti e il cliente ha un ruolo chiave. Tra l’altro è uno dei principi dell’Agile Manifesto – http://www.agilemanifesto.org/

    Qualunque surrogato di Agile design/programming tu voglia mettere in pratica credo che una delle parti più difficili sia capire come relazionarsi con il cliente.

    In lista negli anni sono usciti vari use case scenario e anche esperienze negative. Più che passare un millennio a leggerti gli archivi ti consiglierei di porre la tua domanda spiegando i retroscena. Poi tieni d’occhio il sito di http://www.agileday.it che è una conferenza nazionale che si tiene ogni anno in Italia (organizzata da Abis, uno di quelli che Agile e XP in Italia ce l’hanno portato sin dagli albori)

    Saluti!

  2. clà

    è la storia del design in sè che ha la risposta: si deve arrivare al punto che la tua autorevolezza fa sì che il cliente ti dia carta bianca. vedi il pessimo Toscani. lui si impone per via della sua discussa e discutibile fama.

  3. Tre riflessioni:
    1. il rischio che ho osservato nel voler adottare una o più delle metodologie agili, è quello poi di volerla applicare pedestremente ad ogni possibile progetto/cliente. Cominci a camminare in azienda e senti nei discorsi altrui la parola “meeting” sostituita con “morning scrum”, “buglist” con “backlog” e così via. Ovviamente, ciò non basta: come le metodologie tradizionali di gestione dei progetti richiedono non solo strumenti, a maggior ragione quelle agili sono in primis una questione di cultura aziendale.
    2. Sempre per esperienza, i clienti, una volta spiegata loro la faccenda, sono più che felici di essere coinvolti nel progetto, posto (probabilmente) che il progetto stia loro effettivamente a cuore e che non sia un pretesto per giustificare l’utilizzo del budget semestrale (in questo caso consiglio di riconsiderare il portfolio clienti).
    3. L’enorme vantaggio dell’approccio agile dal mio punto di vista non è tanto l’affrontare “seriamente” un progetto, ma proprio quello di focalizzare quei (pochi) cicli di sviluppo che si hanno a disposizione (saranno sempre troppo pochi, rassegnamoci) per costruire progressivamente il prodotto: questo da un lato impone al cliente di avere voce in capitolo e di valutare cosa è critico o meno ottenere _considerato il budget reale_, e dall’altro di evitare di costruire impalcature fantascientifiche che poi si rivelano castelli di carte.

  4. Concordo con Bru. Se c’e` una cosa in cui bisogna stare attenti nell’applicare una metodologia agile e` il volerla applicare tout-court dal giorno 0 e su tutti i progetti. Ricetta per fallimento e frustrazione. L’adozione della metodologia stessa e` un processo incrementale.

    Inoltre bisogna vedere il team di persone (sviluppatori, manager, designer, grafici, blah blah) con cui si lavora. L’agile e` soprattutto psicologico, prima ancora che metodologico e tecnico. Quindi se hai qualcuno che ti rema contro non so quanto al largo puoi andare.

    La cosa piu` bella poi e` vedere qualcosa di usabile sin da subito. Focalizza l’attenzione, permette ai partecipanti di vedere che si sta facendo qualcosa di pratico e non (magari come accade nell’industria a volte) progettoni con time frame enormi senza iterazioni nel mentre.

    E poi diciamolo, e` divertente se preso nel giusto modo!

  5. Sono abbastanza d’accordo con i vostri commenti specialmente sull’esigenza di intermediare la teoria con la pratica e sul fatto che l’agile porti uno spirito “migliore” nel team, resta però il punto che spesso i budget con cui ci si confronta non permettono neanche di avere 3-4 cicli.

    Quando il budget totale di una startup non supera le poche migliaia di euro per tutto è praticamente insostenibile mantenere per più di uno o due cicli un processo di creazione agile e si passa ad un waterfall “si fa quello che si può… come viene viene” e purtroppo questa è una realtà molto comune sul mercato indigeno

  6. La mia modesta opinione relativamente all’agile design è che richieda dei prerequisiti spesso troppo stringenti, ne elenco alcune:

    – indisponibilità dei key users
    – difficoltà di parallelizzare il lavoro
    – richieste che vanno oltre un perimetro spesso poco definito delle funzionali
    – rischio di poca ingegnerizzazione del lavoro fatto per il numero ridotto di cicli a disposizione
    – e molto altro…

    Non credo che il mercato italiano – relativamente alle mie esperienze – sia pronto, e non credo lo sarà mai… ma spero di sbagliarmi perchè mi diverto molto a sviluppare Agile…

  7. Sono d’accordo sul fatto che il nostro mercato richiede spesso scarsa qualità del prodotto a favore di un contenimento, talvolta eccessivo, dei tempi e soprattuto dei costi.

    Però credo anche che le metodologie di sviluppo agile consentano proprio di ridurre costi e tempi tagliando i processi inutili senza sacrificare (troppo) la qualità, e credo che questo sia un valore aggiunto assolutamente da non ignorare.

    Anzi, da evidenziare il più possibile.

  8. Stefano il tuo punto non è in dubbio, semmai il dubbio resta sull’applicabilità nel nostro territorio.

    Noi lo stiamo provando su un paio di progetti e sembra funzionare :)