Archive for the 'Dalle trincee' Category

2014: ho chiuso un blog, ho aperto un blog.

Ho atteso fin troppo, era davvero arrivato il momento. Ho aperto il mio nuovo blog e non credo che scriverò ancora qui. Sì, forse in occasione di qualcosa di interessante per la comunità agile italiana, ma visti i ritmi con cui ormai ero arrivato a pubblicare mi sa che sarà davvero raro.

Perché ho aperto un nuovo blog? Per almeno due motivi:

  1. Non ha senso autovincolarsi al mercato italiano. Ammesso e non concesso che io abbia qualcosa di interessante da raccontare, perché raccontarlo solo agli italiani? Se ciò che racconto invece non fosse di molto interesse, tanto varrebbe allora massimizzare le chance di trovare qualche matto che mi dia retta, rendendomi comprensibile ad un pubblico più ampio. In ogni caso quindi, abbasso le barriere linguistiche!
  2. Da un po’ non mi occupo più esclusivamente di software e mal sopporto certi facili inquinamenti – mentre gradisco le contaminazioni, paradossi del linguaggio! Su questo blog si parlerebbe sempre meno di software e sempre più di modi di organizzare il lavoro, anche scrivendo software, ma non solo. Da qui la necessità di partire da capo.

Devo un sacco a questo blog e ancora di più a chi ne ha letto i deliri. Ringrazio me stesso per averlo pubblicato, i lettori per averlo commentato e ringrazio Internet per l’occasione che mi offre, ogni giorno, da una ventina d’anni di confrontarmi.

Ti becco di là?

January 06 2014 | Dalle trincee | 3 Comments »

Arrivederci Roma! (o come fare di un articolo una lean start-up)

OK, OK… sono qui che cerco uno spunto per iniziare questo post, ma mi vengono solo espressioni troppo di rito – se non addirittura retoriche – e proprio non saprei come… vabbè, nel solco tracciato dalle ultime tendenze startappare, proviamo a scrivere un MVB, un Minimum Viable Blogpost¹. :-)

A metà novembre inizierò a lavorare come coach per il team eBay Italia.

Bene. Il grosso è fatto. Abbiamo un messaggio chiaro, il nocciolo dell’articolo è risolto e se vuoi puoi abbandonare qui la lettura, altrimenti, per qualche considerazione in più, puoi proseguire.

A metà novembre inizierò a lavorare come coach per il team eBay Italia. Rimarrò nella compagine sociale di ideato nella veste di board advisor per le metodologie di lavoro, altrimenti detto amichetto.

Ecco, già questa release mi sembra più completa: offre il nocciolo della questione e spiega cosa resterà della mia (amatissima) attività precedente. Sì, perché verso ideato io ho un debito di gratitudine: solo con quelle persone ho potuto sviluppare la mia professionalità e al contempo rendere visibile il frutto del nostro lavoro insieme in una misura tale da garantirmi, ad oggi, le mie più grandi soddisfazioni.

Questo forse può essere un buon momento allora per introdurre le motivazioni che mi portano verso eBay ed il suo team. “Se ami così tanto ideato”, sento già inquisire, “perché non ci rimani?”. Va bene, ascoltiamo il mercato – questo articolo è pur sempre una lean start-up! – e cerchiamo di fornire le giuste feature:

A metà novembre inizierò a lavorare come coach per il team eBay Italia. Rimarrò nella compagine sociale di ideato nella veste di board advisor per le metodologie di lavoro, altrimenti detto amichetto.

Come naturale evoluzione della vita professionale, il passaggio a eBay mi attira per 5 motivi, qui sotto elencati in ordine sparso. Sono ipotesi, il mio intento è validarle.

  1. I dati. L’enorme quantità di dati a disposizione, sia sulla percezione del prodotto da parte dell’utenza, sia sul funzionamento del software scritto, e la sfida che quelli pongono nell’essere letti correttamente, sono da una parte una splendida occasione per migliorare me stesso in tecniche di analisi finora poco praticabili, dall’altra una splendida base per rimuovere il più possibile dalle conversazioni un atteggiamento speculativo, sostituendolo con del sano empirismo.
  2. Il team interno. Meno problemi di turn-over, di allocazione delle risorse, di attenuazione delle disfunzionalità sistemiche della consulenza, possibilità di pensare alle conseguenze a lungo termine delle scelte fatte oggi. Il coaching viene valorizzato dalla quotidianità, dalla continuità. Quella in cui approderò tra meno di un mese è un’azienda piccola nell’organico, in cui dopo pochi giorni si è già conosciuto tutti, senza le dispersioni del grande integratore.
  3. Il prodotto proprietario. Dopo anni di consulenza per lo sviluppo di prodotti di terzi – che mi ha portato anche a sperimentare con enorme gratificazione – tornare a contribuire allo sviluppo di un prodotto unico con una community di utenti enorme mi interessa, soprattutto su una scala mai affrontata prima.
  4. Product manager. La presenza di una persona che ha la responsabilità di capire e definire cosa vada fatto prima di stabilire come vada fatto. Un sogno. Questo è l’aspetto che credo mi formerà di più. La (mancata) product ownership del software è un problema gravissimo, talmente grave che credo sarà il nuovo tema topico nei prossimi mesi: qualsiasi metodo fallisce nel portare i suoi frutti se non sai cosa vuoi ottenere.
  5. Orientamento al ROI. I numeri attuali sono chiarissimi, comunicati al sottoscritto da subito, dalle prime ore. I numeri che si vogliono ottenere sono chiari. In mezzo ci sarà il nostro lavoro. No frills, ma sviluppo orientato alla generazione di ricavi. Non è sterile cinismo: dopo 13 anni di lavoro con i prodotti web, so quanto la serenità dei team passi per la concretezza dei requisiti. Nel mondo della consulenza con ideato pensiamo di aver detto la nostra negli ultimi anni, arrivando nel 2012 a proporre contratti innovativi. Ora per me è tempo di andare ad imparare che aria si respira quando il cliente non è più un alibi.

Beh, a rischio di essere stato un po’ prolisso, sicuramente ora le mie motivazioni sono chiare. Per ora il mio articolo può bastare. Aggiungiamo doverosi ringraziamenti!

[...]

Non mi rimane che ringraziare ideato, quindi, per tutto quello che sono potuto divenire con loro e grazie a loro negli ultimi 4-5 anni: Manuel, Antonio, Michele, Filippo, Paolo, Cirpo, Chiara, Andrea. Mille mila “grazie”!

C’è poi da rendere manifesto il debito di gratitudine verso le persone che, magari quando ideato ancora non esisteva, mi hanno letteralmente spinto fin qui:

  • Gabriele Lana, perché anche se è vero che probabilmente sarei arrivato alle metodologie agili per mille altre vie, la Storia è una sola e io, nella mia, devo ringraziare lui per avermi ispirato il fuoco per le metodologie agili (cit.) tanti anni fa. Una persona di generosità equiparabile solo alla sua competenza, dimostrata nei fatti anno dopo anno. Zero fumo, arrosto a pacchi, lui sì!
  • Francesco Ciccio Trucchia, concreto, concretissimo compagno d’avventure. Siamo citati insieme fin dai tempi del post di Gabriele. :-) I suoi consigli e la nostra complementarietà sono ancora oggi, dopo anni e anni, una fucina di valore tecnico ma soprattutto umano. Stima, stima, stima. Quando tu sarai davvero ricco, amico mio, io vorrò essere il tuo braccio destro!
  • Francesco Fullo Fullone, per avermi sempre messo in contatto con le persone giuste, per aver sempre, sempre, sempre impostato il suo lavoro verso lo sviluppo delle persone, per aver dimostrato e per dimostrare tutti i giorni all’Italia dell’informatica che le aziende sane esistono. E-si-sto-no.
  • Alberto Mucignat, perché lui non mi ascolta mai, ma io per fortuna lui lo ascolto sempre. Se un coach ha bisogno di un coach, il mio è Alberto. Parlo con lui e risolvo i miei stalli. Ti pare poco?
  • il team e-xtrategy, perché con loro ho imparato tutto quello che mille libri non potranno mai raccontarti. Una disposizione al cambiamento incredibile, una capacità pazzesca di darmi feedback sul mio stesso valore personale. Lorenzo, Mike, Miki, Marco, Adriano, Daniele, Alessandro, Giorgio, Ilaria, Silvia, Riccardo, Emanuele: grazie di cuore.
  • l’intera community italiana e internazionale con cui ho potuto interagire: GrUSP, PHP London, Extreme Programming Italia, PUG Roma, Better Software, Codemotion, XPUG Marche, WEBdeBS, ALE Network, Symfony, Indigeni Digitali, PUG Friuli. Siete stati tutti fonte, mezzo e vero obiettivo. L’ho detto per tutto il 2011 in giro per conferenze: nessun uomo, da solo, vale quello che può valere tra gli altri. Grazie!

Ora che ho fatto in tempo anche a commuovermi – uno scrive articoli e mette su un blog per motivi autoterapeutici, cosa credi? :-) – faccio appello all’Extreme Programming User Group e al PHP User Group di Milano per l’accoglienza nei prossimi mesi! eBay Italia, per chi non lo sapesse, è un’azienda meneghina, arrivederci Roma!

October 21 2012 | Dalle trincee | 14 Comments »

Ho avvistato un contratto sano: esistono!

C’è voluto un intero anno di sperimentazione e raffinamento, per essere certi di non doverci smentire troppo facilmente, o che le correzioni apportate fossero più rilevanti dell’idea di partenza, ma oggi ho un racconto croccantissimo su un nuovo modello di pricing adottato da e-xtrategy, una internet company marchigiana per cui svolgo attività di coaching da qualche anno. Cercherò di essere breve per trasmetterti in poco tempo lo spirito di questo post.

Il problema da risolvere

I contratti che tipicamente regolano i rapporti nello sviluppo di software sono il vero dramma del nostro mercato. Ereditati da mercati con caratteristiche finanziarie, tecniche e sociali completamente diverse, i classici contratti a corpo ad oggi, secondo me, sono il principale motivo di fallimento dei progetti software. Senza dilungarmi troppo, mi basterà farti notare come

  1. mantengano il rischio completamente sbilanciato sul fornitore che, per definizione, non dovrebbe invece partecipare al rischio d’impresa neanche un po’
  2. richiedano di prendere le decisioni più cruciali – visto che si tratta di denaro – in modo definitivo nel momento di minima conoscenza riguardo al progetto stesso: l’inizio.

Purtroppo il contratto a corpo, sovrano indiscusso delle gare d’appalto, rimane lo standard di riferimento per i progetti software. Questo problema può essere mitigato dall’impiego di altre forme contrattuali tradizionali: il contratto tempo e materiali con tetto dei costi, per esempio, oggi è la vera spina dorsale di aziende come ideato, che si permettono di chiedere al cliente appena acquisito un briciolo di fiducia in più sulla base della grande fiducia accordata dai clienti già acquisiti.

Il problema dei contratti tempo e materiali è che scalano male. Cosa intendo?

Intendo dire che i contratti che definiscono un prezzo in modo accoppiato al tempo speso per fornire valore ad un cliente hanno alcuni grossi difetti:

  1. mantengono il rischio completamente sbilanciato a sfavore del cliente.
  2. non incentivano la creatività nel cercare soluzioni migliori di rilascio, fatturazione o pagamento, riducendo quindi il valore medio dell’offerta.
  3. non incentivano l’azienda fornitrice allo sviluppo tecnologico, anzi, disincentivando l’innovazione! Un’azienda che fattura il tempo speso a lavorare non ha molti incentivi finanziari a ridurre il tempo impiegato a risolvere un dato problema(*).

Questa insofferenza per i contratti tradizionali – perché di insofferenza nel mio caso si tratta – potrebbe sembrare un dettaglio, un vezzo pignolo da fanatico agilista, ma vorrei invece ti fosse chiaro come un contratto sbagliato possa distruggere ogni sforzo di adozione di un approccio iterativo e incrementale. Lo preciso perché fra questi approcci figura anche quello detto lean start-up – scrivo strizzando l’occhio ad un tema molto in voga in questi mesi.

Nel gennaio 2011, chiamati a sviluppare un’applicazione mobile per la domotica, i ragazzi di e-xtrategy hanno dovuto gestire da subito una grande incertezza: requisiti descritti poco e male, un cliente abituato alla programmazione di dispositivi automatici senza esperienza di design di interfacce utente e tecnologie relativamente nuove rispetto all’esperienza del team. Necessariamente si imponeva su entrambi i versanti cliente-fornitore una forma contrattuale più intelligente, che portasse l’esposizione al rischio di entrambe le parti a convergere.

La soluzione

Cosa abbiamo pensato con e-xtrategy un anno fa per contribuire alla sovversione di preconcetti causa di sprechi tipici? L’idea fondante il nuovo contratto è nota da sempre in altri mercati: soddisfatti o rimborsati. Vediamo un po’ di dettagli.

Il team vende il suo tempo a prescindere dalle specifiche di progetto come nel caso del contratto time & material, ma sulla base dell’intera iterazione, come una tariffa flat per intenderci. “Per un’iterazione di sviluppo del tuo team io ti pago tot” ed il team incassa la cifra pattuita per ogni iterazione lavorata alla consegna del deliverable più opportuno (tipicamente il codice, ma anche template grafici, wireframe, prototipi etc etc). Il fornitore può rifiutare arbitrariamente il prodotto dell’ultima iterazione, rinunciando ad ogni diritto su esso, senza pagare il conmpenso stabilito.

“Eh ma così rischio di lavorare gratis!” ti sento già argomentare. Vero, rischio di lavorare gratis per la durata di un’iterazione. Ma nel caso di team sufficientemente maturi un’iterazione dura 5 giorni, quindi il rischio con un contratto di questo tipo è di lavorare gratis 5 giorni. Davvero non conosci alcun team sopravvissuto a 5 giorni di lavoro oltre una deadline stabilita da un contratto a corpo classico? Permettimi di dubitarne.

Fissando iterazioni brevi con questo contratto il cliente gode

  1. del controllo del time to market, potendo rilasciare virtualmente ogni 5 giorni in produzione
  2. della possibilità di scaricare il team in ogni momento, impegando al massimo 5 giorni per scoprire l’inadeguatezza del team selezionato
  3. della possibilità di allocare budget gradualmente, posticipando gli investimenti il più possibile
  4. della possibilità di definire con la massima libertà i requisiti senza inutili rigidità upfront

Fissando iterazioni brevi con questo contratto il fornitore gode

  1. della sicurezza di lavorare senza garanzia al massimo 5 giornate, scenario preferibile a molti scenari effettivi e tipici dei contratti a corpo
  2. di flussi di cassa stabili e ben parcellizzati
  3. dell’incentivo interno a migliorare la rapidità di sviluppo senza andare a discapito della qualità: se impiego meno tempo a parità di funzionalità consegnata evidentemente avrò margini più ampi, ma se la qualità degrada il cliente finirà per non pagarmi l’iterazione.
  4. della possibilità di servire il miglior ritorno di investimento, recependo i requisiti all’ultimo momento utile e responsabile

La vera morale

Ovviamente questa è una forma contrattuale che si fonda sulla (quasi) certezza del fornitore di apportare fin dalla prima iterazione valore concreto e apprezzabile al business del cliente. Non è quindi un contratto adatto a tutti, bisogna saperlo sostenere fin dalle più remote retrovie, coinvolgendo management, commerciali, programmatori, designer, grafici. Ma e-xtrategy dopo un anno si ritrova con un cliente soddisfatto, iterazioni acquistate e pagate ben oltre l’accordo iniziale e un prodotto completo, di alta qualità e in grado di abilitare il cliente a recuperare l’investimento fin dalle prime battute.

Insomma il vero obiettivo del mio lavoro: sviluppo sostenibile di software. Eh… quante soddisfazioni! :-)

Soprattuto – sono serio – la chance per me di raccontarvi che un altro mercato dell’information technology è possibile e non in un fantomatico paese paradisiaco d’oltralpe. È possibile qui e ora e dipende da noi, tutti noi. Tu allora lo vuoi?

(*) ovviamente rimangono intatti gli incentivi strategici: impiegare poco tempo per servire un cliente mi permette di servirne di più, anche quando la somma delle ore spese – e il fatturato – non cambiano. Rimane quindi comunque valido il principio di un servizio tempestivo e più rapido possibile.

February 08 2012 | Dalle trincee | 18 Comments »

Siamo fatti così

Molto probabilmente ricorderai dai tempi della scuola il concetto di mitosi, quello per cui la cellula, raggiunto un certo stadio del suo ciclo di vita e un certo accrescimento, si divide in due cellule figlie duplicando perfettamente il proprio patrimonio genetico e assegnando ad entrambe grosso modo lo stesso numero di risorse.
Se non ricordi la lezione di scienze a scuola forse ricorderai il fatidico momento ricorrente nella serie animata Siamo fatti così in cui i globuli bianchi rispondevano ad un’infezione duplicando rapidamente l’organico di truppe disponibili. Nelle ultime retrospettive in ideato si è pensato di ricorrere allo stesso meccanismo per rispondere agli inconvenienti della crescita: comunicazione più complessa, gestione lenta della conoscenza e colli di bottiglia nel processo a monte del team di programmatori. E così ora ideato si ritrova con due team grandi la metà di quello originale. continue reading »

September 23 2011 | Dalle trincee | 8 Comments »

Il sorriso in viso

Certo, ideato è la realtà in cui da anni passo la maggior parte del mio tempo come coach agile, ma se hai letto anche solo saltuariamente questo blog saprai che e-xtrategy è un’altra azienda che da qualche anno mi regala grandi soddisfazioni. Pochi giorni fa Michele ‘Miki’ Focanti, da qualche mese responsabile delle priorità di user story e task, mi ha scritto in vista dei nostri prossimi incontri.

[...]

Ad occhio mi sembra che “ci siamo”; abbiamo fatto la retrospettiva di gennaio ed abbiamo identificato le cose da migliorare che verificheremo a fine febbraio.
In questi giorni sta cambiando tutto “in tempo reale” (entrano progetti che devono essere consegnati dopo 2 giorni) e, incredibilmente, le persone continuano ad avere il sorriso in viso!

Il cambiamento epocale è stato questo:

prima qualsiasi evento (il cliente è contento, il cliente rompe le palle, c’è una cosa da modificare, etc) era legata all’e-xer [membro del team e-xtrategy, n.d.r.] responsabile del progetto (neanche al team). oggi qualsiasi evento diventa una “cosa di e-xtrategy” a cui dare una priorità e tutti si sbatteranno per portarla avanti prendendosi oneri ed onori.

in passato la telefonata al cliente era una delle cose più critiche. oggi è diventato: “Non riesci a chiamare Tizio? ok, allora lo chiamo io per te!”.

A presto

Miki

Capisci che fare il coach agile e parlare di lean development con persone così coraggiose è il lavoro più bello del mondo?

Miki, ci vediamo presto! ;-)

February 23 2011 | Dalle trincee | 1 Comment »

Agile è… non dire mai “ci pensi tu”

Un committente crede che tu ed il resto del tuo team di sviluppo possiate semplificare per delega, grazie ai metodi agili, il suo lavoro. Lui crede che possiate prendere il suo canovaccio, espanderlo nei dettagli, metterlo in piedi e portarlo pronto in tavola. Molti credono – come lui – che i metodi agili siano uno stupendo scenario in cui sponsorship illuminate da un’idea fulgida possano premere il pulsante rosso di veloci e precisi missili fire-and-forget che andranno a colpire il bersaglio del successo senza ulteriore necessità di azione e pensiero, certe volte addirittura senza alcun rischio d’impresa, “tanto facciamo tutto agile, no?”

A questi diluitori di significato, ricordo che da queste parti si predilige la collaborazione col cliente piuttosto che stare lì ad aspettare che i contratti vengano impugnati inesorabilmente da una delle parti contro l’altra e che invece sarebbe bene giocare allo stesso tavolo dall’inizio alla fine del progetto senza stare lì a sostituire la voglia di lavorare con deleghe e regolette, perché la prima serve comunque, le seconde non funzionano e le terze nessuno le ha ancora trovate.

La forma mentis è la stessa di chi dice che l’agile tutto sommato è solo buon senso riorganizzato rivelando a chi ascolta solo una grave superficialità nel parlare di una mentalità che offre parecchi punti di vista a volte persino controintuitivi.

Ecco, il buon senso: farebbe bene a farne uso un committente del genere e nel frattempo cercarsi un altro team, un’altra metodologia. Di sicuro un altro coach.

December 21 2010 | Dalle trincee | 4 Comments »

Lean e-xtrategy

e-xers

Sono di ritorno da una splendida due giorni passata lavorando con i ragazzi di e-xtrategy pensata per svolgere una retrospettiva su un progetto appena concluso, che ho avuto modo di seguire sin dall’inizio. Inutile dire che l’esperienza è stata formativa per me almeno quanto lo è stata per loro, che mi offrono sempre grande fiducia e libertà di svolgere le nostre analisi, senza sovrastrutture inutili, senza pregiudizi e senza la pretesa di dover nascere imparati, né io né loro.

I topic emersi e sviscerati sono stati diversi e purtroppo qui in questa sede posso solo riassumere i maggiori: kanban, value stream map, automatizzazione dei test e agile ux.

Kanban

Il problema immediatamente emerso dalla retrospettiva è stato quello di gestire le attività dell’azienda che non producono valore diretto per il cliente ma che vanno in ogni caso raccolte, valutate, inserite in una coda di priorità. Per tutti questi task la necessità di un punto di gestione concorrente e la possibilità per lo staff di e-xtrategy di lavorare in uno spazio di aperto e condiviso (elegantissimo peraltro n.d.r.) ha fatto emergere in pochi brevi passaggi l’adozione del kanban. Il kanban, lo scrivo brevemente a beneficio dei neofiti, è sostanzialmente una lavagna dove viene tracciato secondo poche ma ben determinate regole lo stato dei diversi task, abilitando il team ad una modalità di lavoro

  1. concorrente, dove sono ridotti al minimo gli stati di attesa per svolgere il proprio lavoro
  2. pull, dove si annulla la necessità di una figura responsabile dell’erogazione del lavoro da svolgere
  3. trasparente, dove ognuno sa e può sapere cosa sta facendo l’azienda nel suo insieme in un dato momento.

Abbattimento della burocrazia, trasferimento del controllo verso il basso e tracciamento di tutte le attività sono il cuore di questa soluzione.

Kanban in salsa marchigiana

'Porta' può essere tradotto dal marchigiano in questo contesto come 'Done' :-)

Value stream map

Sempre nell’ottica di individuare con precisione le attività che producono valore diretto per il cliente e distinguerle dalle attività accessorie abbiamo fatto ricorso alla mappatura del flusso del valore, che permette di individuare quali punti del processo ostruiscano la consegna del valore stesso al cliente. Come attività complementare abbiamo stabilito un ranking delle attività interne all’azienda secondo l’importanza percepita dal cliente rispetto al valore consegnato. Questo ranking è stato utile per capire in maniera più oggettiva quali siano le attività su cui cercare di tagliare i costi.

Interessante a dir poco, in un’azienda che passa la gran parte del tempo a scrivere codice PHP per consegnare siti web più o meno complessi, l’attività di scrivere PHP risulta essere fra le meno rilevanti per il cliente finale, quindi fra le meno dense dal punto di vista del valore consegnato. In sostanza una prova a posteriori di quanto sostengo da un bel po’: il codice è un mezzo, mai l’obiettivo.

Automatizzazione dei test

Per stabilire un punto di incontro oggettivo che stabilisca l’impalcatura di lavoro per il maggior numero di persone possibile all’interno dell’azienda si è stabilito di far attecchire i test funzionali una volta per tutte, incarnati da Selenium – nelle sue nuance Selenium RC per PHP e Selenium IDE. Il workflow per ora ipotizzato – perché solo dopo qualche settimana o mese di riscontri se ne potrà stabilire la bontà assoluta e relativa ad e-xtrategy – vede lo specialista XHTML/CSS produrre test funzionali di alto livello basati sui prototipi scritti in XHTML (vedi sotto) usando Selenium IDE – che permette di scrivere i test semplicemente usando il browser -  e poi una serie successiva di raffinamenti nelle fasi di sviluppo in cui i programmatori PHP con Selenium RC possono integrare gli stessi test in PHPUnit.

Interaction design (più) agile

Ale inizia a scrivere l'html del wireframe
Le intraprendenti decisioni prese dal team e-xtrategy in quei due giorni sono state argomento di discussione anche al di fuori delle mura e-xtrategy con commenti dei soliti noti ad un post di Alberto – Ilaria Mauric compresa, interaction designer di e-xtrategy. L’obiettivo che condivido con il team e-xtrategy in questo frangente è quello di mitigare, se non risolvere, il problema posto dall’integrazione di un team UX con un team di sviluppo. Dopo i primi esperimenti negli anni scorsi, infatti, i principali interaction designer con cui ho collaborato hanno rivisto al ribasso il loro entusiasmo per i metodi agili e si sono arroccati dietro un “per la progettazione il waterfall è inevitabile”, nonostante i pochi esperimenti fatti avessero lasciato soddisfatti tutti i team coinvolti – intesi nel loro senso più eterogeneo. Ovviamente, poi ho capito, per le aziende specializzate in interaction design il discorso ha senso: perché impelagarsi ad integrare il mio metodo con quello di chi sviluppa se il mio business è esclusivamente basato sulla progettazione?

E-xtrategy però presenta una situazione diversa in cui la multidisciplinarietà del team interno è elevata e in cui quindi una metodologia agile integrata ritorna immediatamente di altissimo interesse. Interaction designer, visual designer, sviluppatore XHTML/CSS e sviluppatori PHP, poiché a stretto contatto, possono condividere molto spesso i loro semilavorati e perfino lavorarli in pair cross-funzionali!

Il succo insomma sta nel ridurre al minimo l’approccio fornitore-cliente che vuole – per fare un mero esempio – che l’interaction designer sviluppi un wireframe che poi venga traformato in prototipo che poi venga passato al visual designer che poi passi il template al programmatore XHTML/CSS che poi passerà il lavoro finale alla gente del PHP, in una lunga serie di piccoli waterfall. Con alcuni accorgimenti è possibile circoscrivere molto la necessità di una progettazione upfront: sviluppato un prototipo XHTML molto simile al wireframe, si comincia a scrivere test funzionali per garantire che quel wireframe-ormai-prototipo sia la base di tutto il lavoro successivo per tutto il team. Si fa in modo insomma che il wireframe venga sugellato dai test automatici come il codice eseguibile, con un immenso guadagno sia in termini di formalismi e oggettività – il wireframe esaltato dai test nel suo giusto ruolo di contratto – sia in termini di organizzazione del lavoro – gli sviluppatori e i grafici possono in questo modo lavorare in parallelo sin dalle prime fasi dello sviluppo.

Non mi rimane che ringraziare e-xtrategy per la rinnovata esperienza di coaching e promettere a te di riportare qui la cronaca dei prossimi sviluppi più rilevanti relativamente a tutti questi temi .

July 31 2010 | Dalle trincee | 8 Comments »

Il Manifesto Agile in italiano – Reloaded

In un ormai antico post forse avevi letto della mia traduzione del Manifesto Agile. Oggi torno qui, parecchio tempo dopo, all’indomani della pubblicazione della traduzione italiana ufficiale del Manifesto Agile per ringraziare le persone con cui ho collaborato. Con tutti i traduttori e revisori ho condiviso pochi ma ottimi momenti insieme, di collaborazione vera.

Un piccolo gioiello di lavoro concorrente reso possibile da una altissima condivisione di valori, che ha a sua volta permesso – una volta tanto – di dedicarsi fin dal primo secondo alla creazione di valore invece che all’individuazione di un processo per crearlo. Un foglio elettronico online e via, a concentrarsi sugli aspetti linguistici della traduzione, sul core.

Non è stato semplice. Tradurre un documento come il Manifesto Agile, in cui ogni parola ha un peso preciso ed enorme, ti pone continuamente di fronte al compromesso tra fedeltà all’originale e bellezza della forma tradotta. Collaborare con persone tutte di grande consapevolezza, ma culturalmente miste, ha permesso di discutere ogni singola parola problematica e raggiungere sempre un compromesso linguisticamente denso: quella che si dice conoscenza implicita.

Il bello è stato far scorrere questa conoscenza implicita avanti e indietro tra le teste di persone distanti tra loro anche migliaia di chilometri e saper mettere su un processo pragmatico, umilmente efficace. A queste teste lontane ma compatte va il mio grazie.

July 01 2010 | Dalle trincee | 10 Comments »

@jacoporomei

Dopo anni di resistenza affatto attiva, semmai dovuta al timore di un sovraccarico di linea per il mio limitato quantitativo di materia grigia, ho deciso di sfidare i miei neuroni più social cedendo alla seduzione di Twitter. Dedicherò i miei tweet agli stessi temi che tratto su questo blog, ovviamente cavalcandone la natura più real time. Vediamo un po’ cosa accadrà a @jacoporomei.

April 26 2010 | Dalle trincee | 2 Comments »

Design concorrente per team distribuiti con Google Drawing

Dai tempi della fine dello storico PowWow – esempio quintessenziale del fenomeno dot-com anni ‘90 – cioè dal 2000, attendevo il ritorno di uno strumento per disegnare cooperativamente online in tempo reale. C’erano sì stati alcuni strumenti alternativi anche su piattaforme molto diffuse come MSN o Skype, ma mai con i miei clienti ero riuscito a trovare un modo comodo e facilmente accessibile per disegnare al volo durante una conference call. Beh, finalmente oggi è possibile tornare ai vecchi fasti.

Nella suite Google Docs infatti è stata recentemente aggiunta Drawing, l’applicazione per creare e modificare diagrammi. Con la consueta grammatica di interazione gli utenti possono condividere i loro diagrammi con altri utenti e collaborare interattivamente sugli stessi diagrammi esattamente come Google Spreadsheet ci aveva già abituato a fare con i fogli elettronici. In pratica abbiamo tutti noi finalmente a disposizione una whiteboard (quasi) gratuita da condividere con chiunque, ovunque ed in qualsiasi momento.

Per me questo rappresenta l’abbattimento di una barriera molto scomoda, vincolante buona parte della mia attività lavorativa. Ogni volta che mi sono trovato costretto a fare una riunione in remoto o a fare pair programming via Skype, è sempre mancata la possibilità di disegnare. Non so tu, ma io quando condivido e discuto concetti al di sopra di una complessità minima ho bisogno di fare schizzi ed esempi grafici. Negli ultimi anni avevo fatto grandi sforzi per ovviare a questa vera e propria amputazione mediatica, sforzandomi di raffinare la capacità di rimuovere le ambiguità dai discorsi e di comunicare in modo più verbale e meno visuale. Lo strumento di Google rende finalmente questa traduzione non necessaria e, soprattutto, non richiede grandi iniziative da parte dei miei clienti: un account Google. Punto. Niente plug-in, niente applicazioni, perfino niente Flash Player!

La conseguenza più importante per tutti di questo lancio è la nuova abilitazione ad un processo di design concorrente, tipicamente desiderato nel contesto lean, poiché concorrenza significa feedback più immediati. D’ora in avanti quindi niente più ostacoli per tracciare un po’ di UML durante un pair programming in remoto, più nessun problema per tracciare semplici grafici durante una conference call e, arrivo a pensare, d’ora in avanti avremo anche aperta la possibilità per i nostri interaction designer di prototipare (parti di) interfacce anche con collaboratori e clienti lontani!

Certo, questo non dovrà mai significare la rinuncia ad ogni tentativo possibile di incontrarsi de visu, e non tanto per un mio inguaribile romanticismo neo-luddista, quanto invece per l’oggettiva qualità della comunicazione fra le persone… di persona! Poi si sa, difficilmente resisterai al fascino di una partita a tris in remoto! ;)

April 21 2010 | Dalle trincee | 4 Comments »

Next »