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 »

Sfuggente e di qualità

Ron Jeffries, nella mailing list extremeprogramming@yahoogroups.com, in queste ultime ore a chi scriveva

[Unified Process] has [a flow with all the steps] formally described. I know [extreme programming] have different philosophies but they are both methodologies and should them both have a formal process.

rispondeva così

Sorry. Agile processes are not formal.

Questa risposta sintetizza (perché chiaramente si tratta di sintesi affatto esaustiva) molti aspetti difficili dell’approccio al mondo agile. Tra i primi che mi vengono in mente ora, mentre devo scappare per tornare al mio lavoro, trovo:

  1. I metodi agili non possono essere spiegati top-down. Una spiegazione frontale può aiutare, può introdurre, ma poi basta: bisogna fare e capire. La mera inesistenza di una impalcatura formale scardina ogni tentativo di verbalizzarne una.
  2. I processi agili sono facilmente fraintendibili da chi non è disposto ad approfondire il tema perché è più facile fare di concetti dai contorni sfumati quello che si vuole per giustificare le proprie esigenze dirette o addirittura le proprie debolezze. Penso a quanti ritengono che l’agile si risolva nella formula iteratività+incrementalità facendosi sfuggire che anche Unified Process contempla un approccio iterativo e incrementale.
  3. I metodi agili sono adatti a fronteggiare la realtà perché ne riflettono la complessa vaghezza. Non esiste squadra di calcio che possa vincere una partita applicando schemi rigidi. Non esiste medico serio che si aspetti che un paziente sia un sistema che restituisce output lineari . Non esiste ecologo che pensi che si possa agire per step contemporanemanete deterministici e lineari per rimettere a posto un ecosistema. Esistono invece molti professionisti IT che credono che un sistema complesso – come un progetto – possa essere controllato da entità (più) semplici – una persona o addirittura un tool.

Quello che credo sia il nostro dovere tutti i giorni è crescere aumentando la nostra consapevolezza della complessità del contesto dei progetti IT e saper galleggiare su quelle onde ridefinendo ogni giorno il nostro equilibrio, senza affetto per quello trovato oggi, senza nostalgia per quello abbandonato ieri.

Trovi sia difficile? Lo è!

June 11 2010 | Base | 3 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 »

phpDay 2010: e quattro!

Ache quest’anno posso comunicarti la mia partecipazione al phpDay, la conferenza italiana annuale dedicata a PHP.

È il quarto anno di fila che partecipo a questo evento come speaker, l’anno scorso con Sue me sue you blues – Contratti e preventivi nei processi agili, quest’anno con Qualità totale. Diventa sempre più difficile di anno in anno rimanere all’altezza dei nomi di fama nazionale e internazionale previsti in programma. Di questo come al solito non :) ringrazierò il Gr.U.S.P., che organizza tutto come sempre in passato.

Anche questa volta sarò al phpDay in compagnia di Bonacivita, il mio lealissimo motociclo. Dopo un inverno di arresto forzato, coglierò l’occasione dell’evento e la sua insolita prossimità con Roma per inaugurare la mia nuova stagione di mototurismo.
Bonacivita a Patrasso #2

April 20 2010 | Uncategorized | 2 Comments »

Manager e coach: ruoli e metafore da bar

Un brevissimo post per segnalarne a mia volta uno piuttosto interessante di Jurgen Appelo, uno dei miei blogger preferiti, sul differente ruolo del coach e del manager.

Non resisto alla tentazione di integrare con una metafora sportiva: in una squadra di football ci sono i manager e c’è il coach. Non credo debba aggiungere altro, secondo me messa così rende bene l’idea.

April 13 2010 | Visione agile | 3 Comments »

Lean. Da generazioni.

Più volte si è reso necessario ribadire che molte delle soluzioni proposte dai metodi agili, sebbene spesso controintuitive, sono sempre derivate dall’esperienza e mai dalla mera speculazione. Una forma di saggezza insomma, ampiamente condivisa, distillata e raccolta nella letteratura di settore.

Oggi in Liguria mia nonna riguardo al mio imminente trasloco:

Devi tenere solo quello che ti serve, butterai quasi tutto. Tanto si usano sempre solo poche cose e sempre quelle.

Lo avresti detto? La saggezza popolare è lean. :-)

April 03 2010 | Humor | 2 Comments »

Inventato il martello (agile), tutto diventa un chiodo (waterfall)

Mi sono imbattuto poco fa in questo interessante post di Robert ‘Uncle Bob’ Martin a proposito dell’impoverimento del termine “agile” nell’industria del software. Meglio ancora, l’articolo parla della sovrageneralizzazione di termini il cui significato è invece limitato, per quanto profondo, per quanto vasto, e al tipico sfruttamento pubblicitario che ne consegue. È ovvio – considerato l’autore del post – che il nucleo di questa argomentazione sia posto sull’attributo agile, particolarmente discusso, celebrato o condannato in questi ultimi anni.

L’argomentazione di Martin parte da considerazioni sulla metafisica aristotelica per giungere a dichiarazioni concrete e molto chiare. I riferimenti alla storia della filosofia, devo ammettere, mi permettono di togliermi qualche soddisfazione: se anche luminari indiscussi del software internazionale come Martin li usano, allora io non devo aver fatto troppo male in passato! :) Scherzi a parte, il passaggio che mi è piaciuto di più è questo

The danger is clear. The word “agile” will become meaningless. It will be hijacked by loads of marketers and consultants to mean whatever they want it to mean. It will be used in company names, and product names, and project names, and any other name in order to lend credibility to that name. In the end it will mean as much as Structured, Modular, or Object.

Io ho smesso di usare la parola agile da qualche tempo. I miei ultimi clienti – perfino quelli che mi contattano perché non vedono l’ora di entrare nel mondo dei metodi agili – non mi sentono più pronunciarla. Combatto una lotta linguistica quotidiana per formulare concetti e frasi che aggirino queste 5 lettere in successione: a, g, i, l, ed e. Sono talmente preso da questa decisione ellittica da nutrire ormai forti dubbi anche sul nome di questo blog.

Perché questa avversione? Perché così all’improvviso? Per diversi motivi.

  1. Una parola, usata depauperata del suo significato più denso, è come un magazzino pieno di componenti non usate, come un set di user story iniziate e non completate: è, in sostanza, una forma di waste. Trovo sia più importante per un team mettersi in marcia concretamente verso l’agilità che fregiarsi di tale caratteristica.
  2. Persone che in buona o cattiva fede per motivi più o meno legati al marketing si vendono come agilisti e attribuiscono (anche) a passate collaborazioni con me la loro agilità mi danneggiano. Questo danno è vero qualunque sia il grado di evangelizzazione io abbia volontariamente apportato, questo danno è vero quantunque io abbia potuto ritenermi anche solo in grado di evangelizzare. E questo mi porta diritto al terzo punto.
  3. Io sono agile? Io posso davvero ritenermi arrivato ad un punto degno di tale fatidico attributo? Domanda difficile da esaurire con una risposta netta e sai perché? Perché l’agilità non è un valore assoluto e con questo non intendo affatto abbandonarmi al più facile dei relativismi. Intendo invece stabilire una natura relativa a priori dell’attributo di agilità: come la sicurezza è definita solo in termini di “fare A è più sicuro che fare B” e non certo di “fare A è sicurissimo”, così l’agilità è definibile in termini di “fare X è più robusto rispetto al bisogno di produttività in un contesto mutevole rispetto a fare Y” ma non certo di “facciamo così, facciamo così tutti e facciamolo sempre perché funzionerà ovunque”!

Qualcuno diceva riguardo l’abuso di cose e concetti:

Inventato il martello, tutto diventa un chiodo

Ecco, io vorrei fare l’uso migliore del mio martello, ma solo sui chiodi.

I processi agili sono il mio mezzo, chiunque mai li chiamerà come vorrà. Cercare di essere produttivi nel mondo reale, questo è il mio unico obiettivo.

February 27 2010 | Base | 4 Comments »

Roma Extreme Programming User Group, il bilancio di un anno

Ieri l’XPUG Roma si è riunito per il primo incontro di questo 2010. È stato un incontro molto positivo per diversi fattori:

  1. Il tema dell’incontro stesso è stato di per sé molto interessante: abbiamo iniziato a seguire il corso sul Test Driven Development di Piergiuliano Bossi. Di questo devo ringraziare Giorgio Vespucci dell’XPUG Roma che ha avuto questa ottima idea e ThinkCode Labs che ci ha concesso una licenza forfettaria per la visione in gruppo di 10 persone.
  2. Con l’arrivo di nuove persone e una tanto attrattiva occasione abbiamo rischiato che la licenza per 10 non fosse sufficiente. Alla fine per fortuna (nostra) qualche influenza e qualche defezione dell’ultimo minuto hanno fatto il nostro gioco. Record di presenze comunque realizzato.
  3. Detto record è solo l’ultimo episodio di un trend molto positivo innescato lo scorso anno – 12 mesi fa esatti. Nei pochi incontri del 2009 la presenza dei membri e quel sottile sentimento di partecipazione che va oltre la presenza fisica sono aumentati costantemente. Ottimo segno: l’intervento di defibrillazione di un anno fa sta portando i suoi frutti, col contributo di tutti. Abbiamo ancora tanto da invidiare a XPUG italiani ben più blasonati, ma è sempre più importante la tendenza dello stato, no? :)
  4. Il penultimo incontro basato sui kata e quest’ultimo centrato sul corso TDD dimostrano che è possibile crescere se si portano contributi reali alla crescita culturale di tutti. L’introduzione di attività concrete è quanto basta a fare di un XPUG un XPUG sano. Detto questo, il limite è solo la fantasia. Nel frattempo, almeno per un po’, fra kata e corso TDD il programma degli incontri sembra essere già a posto ;)

Ringrazio tutti gli appassionati partecipanti a questa piccola, sobria ma onesta avventura.

February 20 2010 | Eventi | 2 Comments »

Astrologia ed extreme programming

Una vecchia amica mi invia il mio oroscopo odierno, che recita:

Bilancia (23 settembre – 22 ottobre) “Tutto quello che complica il lavoro”, scrive il poeta Jason Shinder, “fa parte del lavoro”. Se nei prossimi giorni incontrerai qualche ostacolo, tieni presente il suo consiglio. Se ti accorgi che stai pensando “Accidenti! Se non fosse per queste complicazioni farei molti più progressi”, prendi in considerazione la possibilità che le complicazioni non siano distrazioni, ma indizi essenziali. Che non siano affatto seccature insopportabili, ma stimoli utili che ti indicano dove stanno le vere opportunità.

Al di là dell’innegabile saggezza di Shinder riguardo cosa rientri nella definizione di lavoro, io trovo questo un consiglio validissimo per il mio lavoro di ogni giorno.

I problemi o sono indizi essenziali o sono opportunità. Certe volte giocano un ruolo doppio. In extreme programming due modi di catturare i problemi in una di queste modalità sono rispettivamente la retrospettiva ed il principio di opportunità.

La morale è sempre quella: meglio pianificare per il mondo vero in cui inevitabilmente accade quello che non vorremmo mai che assumere per ipotesi un mondo più controllabile di quanto persino la teoria ci autorizzi a sognare.

p.s. no, non mi piace l’astrologia ;)

February 18 2010 | Uncategorized | No Comments »

« Prev - Next »