www.fabiobeta.it

« Stand Up Meeting: Definizione
YAGNI for Managers: sometime you have to stop yourself »

Programmare a Babele: 4 idee per finire la torre
1 Aprile 2007

Perchè sviluppando software con 5 persone sembra di parlare 5 lingue diverse?

In questi giorni mi è ri-capitata un'esperienza che ho già avuto altre volte nella mia carriera nel mondo dell'informatica... ma questa volte è stata particolarmente intensa. Sono arrivato su un progetto in corso (anzi, in chiusura...), e mi sembrava di essere a Babele: sviluppatori, manager, clienti, analisti, tutti parlavano una lingua loro, diversa dalle altre. Interi concetti avevano anche 3 nomi. E' come se parlando di costuire una casa, le porte fossero chiamate contemporaneamente "porte", "ingressi", "assi con la maniglia" e "AcM" (l'appassionato di acronimi c'è sempre).

Sciami di specifiche scendevano dall'alto attaccando un solo sviluppatore-preda alla volta, lasciando all'oscuro il resto del team. Il cliente sbraitava "Ma ve lo avevo già detto!" senza che si fosse in grado di capire cosa e a chi. I più fortunati, probabilmente dei sensitivi, fuggivano in viaggi di nozze che il manager del progetto scopriva il giorno della partenza, chiedendosi chi avesse portato i confetti.

Ora vorrei poter raccontare come sono arrivato sul progetto e ho salvato tutto... ma non è andata così. Il progetto sta andando avanti grazie alla professionalità di persone che non hanno ceduto.

Però, vorrei far tesoro di quanto ho visto per darmi degli obiettivi per il futuro. Vorrei che un team ben pensato ed organizzato per affrontare un progetto fosse:

• Fisicamente Coeso: troppe volte sottostimiamo i limiti architettonici. In queste settimane ho visto quanto dividere il team in due stanze diverse dello stesso edificio sia pericoloso. La comunicazione si spezza, e quando chi lavora nella stanza A ha bisogno di qualcosa sviluppato nella stanza B, l'astio si infiltra rapidamente nelle frasi. Specie se c'è già pressione nell'aria.

  I tempi di risoluzione delle incomprensioni si allungano:

  • i linguaggi delle due stanze evolvono diversamente,
  • le email non sono mai abbastanza chiare,
  • portare nella stessa stanza tutte le teste coinvolte da un problema diventa faticoso.

  Quindi, mettete tutti nella stessa zona o almeno pranzate insieme, che fa sempre bene al morale.

• Repulso dalle email: le adorate email sono uno dei punti di incomprensione più diffusi nella nostra epoca.

  Le mail lunghe non vengono lette fino in fondo, le mail di routine (per esempio un report giornaliero di bachi) sono cestinate in automatico da regole celebrali ed informatiche.

  Magari un collega percepisce un problema (i suoi sensi da sviluppatore glielo fanno fiutare), ma, incapace di esprimerlo, non lo mette nella mail in cui ti segnala i problemi che gli risultano.

  I sottointesi tipicamente non li mettiamo nelle email, perchè annoiare il lettore? Però il lettore potrebbe avere sottointesi diversi dai nostri!

  Quindi, porca pupazza, alzare il sederino e camminare tutte le volte che serve!

• Facilitato alla comunicazione: se ci sono soluzioni economiche per incentivare la diffusione di conoscienza, ben vengano.

  Per esempio penso a Stand Up Meeting, indirizzi email di gruppo, Bug Tracking, Big visible Charts.

  E' brutto scoprire che il bug che ti blocca un tuo collega lo aveva visto il mese prima... evitiamolo per quanto possibile.

• Concorde su una visione del progetto: tutti dovrebbero aver ben chiaro cosa il progetto sta sviluppando. Non mi interessa che tutti sappiano come si chiama la tabella degli utenti maleducati, ma che tutti sappiano cos'è il prodotto finale.

  Se c'è qualcuno dedicato al DataBase, ogni tanto dovrebbe farsi un giro del sito. Se c'è un novellino appena arrivato gli si racconta tutta la fiaba. Anche se deve solo sviluppare una paginetta con scritto "Benvenuto".

  Facendolo aggiungiamo menti pensanti al gruppo e riduciamo la probabilità di sgambetti involontari (quante volte un amministratore del DB vi ha tolto "sotto al codice" una colonna che vi serviva?)

  Se tutti sappiamo cos'è la funzionalità "cannone", magari siamo poi in grado di capire quando abbassare la testa perchè sta per sparare.

Sono molto interessato alle opinioni e alle idee del resto del mondo su questo argomento. Spiacente di non aver ancora implementato i commenti su questo blog, vi invito ad inviarmi feedback ed idee :)

send a feedback to fabio

« Stand Up Meeting: Definizione
YAGNI for Managers: sometime you have to stop yourself »