mercoledì 29 luglio 2009

RDS Kata

RDS è l'acronimo di Radio Data System. Si tratta di uno standard europeo per l'invio di dati digitali attraverso le trasmissioni radio in FM. Tra le informazioni inviate esiste uno spazio riservato all'invio di un identificativo di 64 caratteri alfanumerici (RT) che può essere liberamente utilizzato dall'emittente. La quasi totalità delle stazioni radio utilizza questo spazio per inviare il nome della radio su cui si è sintonizzati. In alcuni casi però informazioni supplementari riguardo alle trasmissioni in corso, per esempio titolo e autore della canzone, vengono trasmesse al posto del nome. Sfortunatamente i ricevitori in grado di visualizzare tutti i 64 caratteri (per intero o grazie allo scrolling) non sono molte, la maggior parte hanno display a 8 caratteri. C'è chi allora si è ingegnato cercando di aggirare il problema. Vorrei prendere spunto da quest'idea per proporre il seguente kata.

Obbiettivo
Produrre un applicazione che prende in input autore, titolo e anno di un brano musicale e che sappia inviare a un ricevitore dotato di display a 8 caratteri il testo suddiviso in parti. Le emittenti che usano questa tecnica, lasciano il testo per alcuni secondi prima di passare al successivo. Ignoriamo il tempo che passa usando il metodo RadioStation.sendNextTextOn(RadioReceiver) che a ogni chiamata visualizza il testo successivo.

Requisiti

- quando non c'è un brano musicale viene inviato al display il nome della radio: "SIAgile "
- dopo aver inviato autore, brano e anno si invia di nuovo il nome della radio
- le parole più lunghe di 8 caratteri vengono inviate per intero (alcuni display possono avere più di 8 caratteri)
- se la somma di due parole consecutive più lo spazio è minore o uguale a 8 il testo viene inviato in un colpo solo, ad esempio "Il cielo" o "Io e te "
- la regola della somma delle parole vale separatamente per autore, titolo e anno. Non si vedrà mai "Io 2009 "
- il testo visualizzato è sempre centrato, ad esempio " Domani " o " Adesso "
. Per testi con numero di caratteri dispari ci sarà uno spazio in più a destra.

Nel prossimo post una mia soluzione in Java che utilizzerò come confronto per la Milestone One. Chi volesse partecipare e proporre soluzioni in qualunque linguaggio (anche Java) è il benvenuto.

sabato 25 luglio 2009

Milestone One

È ora di lasciarsi andare a qualcosa di più interessante che i miei fatti personali: i buoni propositi! Eh già, chi a fine anno non s'à mai detto "L'anno prossimo metto la testa a posto, lascio indietro le vecchie abitudini e cambio." E quale momento migliore della nascita del blog di SIAgile per fare progetti e porre degli obbiettivi da raggiungere poteva esserci? Devo ammettere di trovarmi un po' in imbarazzo: scrivere il mio primo blog e sentirmi esposto ai pubblici commenti è una sensazione mista tra vergogna e voglia di provarci, ma in poche parole ecco quello che mi piacerebbe fare.

Dopo anni di linguaggi a tipizzazione statica è arrivato il momento di portare nuova linfa vitale nel bagaglio delle mie esperienze. Vorrei approfittare di quest'argomento per fare la mia prima esperienza come blogger e raccontarvi il viaggio verso un mondo per me completamente nuovo: i linguaggi a tipizzazione dinamica. Nelle prossime settimane mi occuperò quindi di pubblicare un mio personale "diario di bordo" annotando i progressi. Dalla scelta del linguaggio, alle mie personali strategie di studio, passando attraverso frustrazioni e successi, per arrivare a ottenere una roadmap che possa essere seguita da chi come me vuole solo estendere la propria conoscenza.

In piena corrente agile, come primo obbiettivo userò un kata, considerandolo raggiunto solo al momento di riuscire a padroneggiare la sua esecuzione in maniera sicura senza continue pause e ripensamenti. Deciderò quale sarà il prossimo obbiettivo solo al completamento di questo.

Nel mio prossimo post la descrizione del kata di riferimento per la Milestone One: l'RDS kata.

giovedì 23 luglio 2009

Adattabilità al Contesto



Spesso mi chiedo quanto un programmatore debba addentrarsi ed approfondire la materia nel contesto del dominio applicativo del suo progetto e quanto invece ne debba rimanere fuori abbastanza da non lasciarsi condizionare nei futuri progetti. Mi spiego meglio.

Chissà a quanti di noi sarà capitato di trovarsi in un meeting con persone esperte di dominio, che discutevano a lungo su un problema senza giungerne a una. E quante volte, in quelle occasioni, è sorta la necessità di chiarire alcuni termini (perché per es. percepivamo la brutta sensazione che alcuni termini venivano usati impropriamente da alcuni e male interpretati da altri, o sinonimi che apparivano semanticamente diversi e così via)? E forse avremmo voluto porre delle domande banali, anzi triviali, talmente semplici..., e poi abbiamo avuto la tentazione di desistere per non fare la figura di un perfetto "incompetente"?

E invece...l'avete fatto! Temerari, incuranti del pericolo e assetati di comprensione. Avete posto delle domande semplici. Avete favorito la chiarezza tra i presenti e permesso che essi si intendessero nei termini e nei significati, portandoli sempre più verso la soluzione al loro problema. Ma avete rischiato grosso!

Chi programma sa quanto profondamente bisogna indagare la materia per produrre un software di qualità e soprattutto sa quanto velocemente bisogna essere in grado di estrarre dagli esperti l'essenziale, quello che serve al programma da realizzare ed infine quanto velocemente bisogna saper porre le domande giuste, quelle che portano a eliminare le contraddizioni o le incertezze (che ogni dominio applicativo presenta). Chi programma sa anche che bisogna saper dimenticare in fretta, per evitare di portasi dietro preconcetti e interpretazioni errate che devierebbero dalla soluzione ideale del prossimo cliente e quindi di procurargli un danno.

La conoscenza che raggiungiamo durante questa fase di apprendimento io la chiamerei : conoscenza orizzontale. Ossia ci appropriamo dei concetti fondamentali, che ci consentono in maniera analitica di organizzare le informazioni e forniscono quel minimo di autonomia necessaria. Successivamente quest'autonomia porta all'individuazione di tutti quei dettagli infinitesimali, di cui il programma ha vitale bisogno. Questo approfondimento non è più autosufficiente, ma avviene attraverso un processo di indagine e interrogazione continuo rivolto nei confronti del nostro esperto-interlocutore di dominio (diciamo customer on site?).

Ho avuto la fortuna in età adulta di fare lavori di sviluppo (programmi e apparecchiature) in diversi settori o domini applicativi: building automation, apparecchiature mediche, ospedaliero, bancario, assicurativo, e-learning e farmaceutico. Quello che ho imparato è che quanto più velocemente apprendo, tanto più dimentico. Anzi il contrario: più dimentico veloce il vecchio, tanto più apprendo rapidamente il nuovo.

L'atteggiamento critico e vigile nei confronti della conoscenza di un business specifico è un aspetto fondamentale della nostra professione. Se dovessimo diventare esperti noi stessi, appropriandoci di quella che io chiamerei la conoscenza verticale, al punto tale di poter fare a meno dell'esperto (condizione anche troppo frequente per coloro che lavorano per lungo tempo come programmatori presso lo stesso determinato tipo di organizzazione), porterebbe osmosi del ruoli, ossia alla totale autonomia del programmatore. (sebbene in alcuni contesti ci può anche stare).

Le conseguenze di questa "metamorfosi" sono diverse.
  • Innanzitutto l'esperto di business incomincia a delegare anche la definizione delle nuove funzionalità da svolgere.
E in seguito si avrà:
  • un eccessivo carico di lavoro intellettuale sul personale tecnico.
  • errori di interpretazione nel programma.
  • la perdita di interesse da parte del programmatore degli aspetti di design, leggibilità del codice, e semplicità della soluzione;
  • degrado del livello di sostenibilità del prodotto e che noi sappiamo essere, come il punto precedente, linfa vitale del software, nel genuino interesse economico del committente.
  • un inesorabile ridimensionamento dell'importanza della formazione tecnica e della sperimentazione di nuove idee, nuove tecnologie e nuove indagini e tecniche di sviluppo del software;
  • la compromissione dell'innovazione nell'azienda o della capacità evolutiva del prodotto in un contesto di mercato fortemente concorrenziale.
  • l'implicita promessa di carriera, nei confronti del programmatore, che si basa maggiormente sulla conoscenza verticale del dominio e non, come dovrebbe, sulla sua capacità di comunicazione, risposta al cambiamento, programmazione, disciplina e innovazione.
  • la perdita di assunzione delle responsabilità in maniera distinta tra coloro che definiscono cosa bisogna fare e con quale priorità, rispetto a coloro che devono definire come e in quanto tempo (si pensi al planning game).
  • il potere persuasivo esercitato dal personale tecnico che dimostrano di possedere conoscenza verticale, ossia padronanza profonda del dominio applicativo, sulla reputazione del programmatore all'interno dell'organizzazione. Fattore controproducente sulle performance nello sviluppo del software, perché svilisce la nostra difficile professione e degrada nel tempo le prestazioni di sviluppo e la qualità del prodotto del cliente.
  • infine dall'invito implicito al programmatore ad imparare un nuovo mestiere, nel caso in cui a egli interessasse guadagnare di più. (che spreco di know-how!)
Quante volte vediamo annunci di lavoro per tecnici specializzati in cui l'azienda cerca personale che abbia expertise nel dominio applicativo dell'azienda che lo pubblica?

Tutto questo spinge sempre più il programmatore a specializzarsi su un determinato business.

A mio avviso coloro che nel nostro lavoro si fanno sedurre dalla conoscenza orizzontale di dominio, rischiano di perdere flessibilità, di non essere in grado di cambiare colore come il camaleonte quando il contesto lo richiede, o la capacità di penetrare la materia rapidamente, facendo l'interesse del proprio cliente e dell'utente che si troverà confrontato 9 ore al giorno e per anni con il prodotto del suo lavoro di Programmatore.

Buon arcobaleno a tutti.

Responsabilità nello Sviluppo del Software

Accountability in software development è uno degli articoli più interessanti che parlano di etica nella produzione del software. Le parole di Kent Beck rappresentano molto bene anche le mie convinzioni su questa bella professione. Ho pensato che valesse la pena leggere questo lungo e piacevole testo in lingua italiana. Buona lettura.

"Una volta un contadino intervistò un ragazzo per un lavoro come bracciante in fattoria. Il ragazzo disse una cosa che lasciò particolarmente perplesso il contadino: 'io posso dormire quando soffia il vento'. Il contadino non sapeva cosa egli intendesse, ma il ragazzo sembrava competente ed quindi fu assunto.

Qualche mese dopo il contadino venne svegliato nel bel mezzo della notte da una tremenda bufera. Preso dal panico, corse verso la branda dove trovò il bracciante quasi addormentato. Scuotendolo brutalmente per svegliarlo, gli disse:

'Dobbiamo far rientrare gli animali!'.
'Sono già dentro.'

'Dobbiamo chiudere le finestre.'
'Sono già chiuse.'

'Dobbiamo ricoprire il fieno.'
'Già fatto.'

Dopo che i suoi timori fossero calati ed essere stato rassicurato che tutto era al suo posto, il contadino finalmente comprese il senso di quella misteriosa frase. Avendo cura di terminare ogni lavoro e lasciando la fattoria al sicuro ogni notte, il bracciante poteva dormire quando il vento soffiava.


Il contadino tornò a letto e disse alla moglie ciò che aveva appena appreso. Lei sorrise con un aria d'intesa e i due tornarono a dormire, cullati dal suono della burrasca."


Lo sviluppo del software va meglio se lavoro in modo che io possa "dormire quando soffia il vento". Sono più a mio agio con me stesso e il mio lavoro, i miei clienti sono più soddisfatti dai risultati che vedono, e i miei colleghi del team possono fidarsi di me. Comunque trovo difficile raggiungere questo livello di performance con la sola forza di volontà. Mi serve il supporto, l'incoraggiamento, e la responsabilità. Ho bisogno di essere un membro di una comunità per dare il massimo. Un elemento chiave per tutto ciò è la responsabilità: impegnarsi, lavorare in modo che io ne sia orgoglioso e rendere conto sulle mie attività in modo chiaro e diretto.


Quando iniziai a parlare di responsabilità, incontrai molta resistenza da parte dei programmatori che dicevano di odiare l'idea della responsabilità. Raccontavano storie del tipo "...e allora lui mi dice: 'ti considero responsabile per questa proroga sui tempi del progetto". Questo non è ciò di cui sto parlando. Questo è colpevolizzare, un tentativo per evitare o deflettere le conseguenze. Colpevolizzare è uno scarso presupposto a partire dal quale lavorare. Colpevolizzare necessita che tu spenda tempo e energia per proteggere te stesso. In un ambiente di biasimo non è opportuno dire quello che fai e quello che non sai. Colpevolizzare lascia ognuno preoccupato da coloro che sono lì fuori pronti ad incastrarlo. Tutta l'energia che spendono per nascondere potrebbe venir usata per interagire e aggiungere valore al progetto. Il lavoro perde in efficienza. La responsabilità è un potente presupposto a partire dal quale iniziare a lavorare. Lavorando bene e in modo trasparente si creano legami forti. Accettando responsabilità si prepara il terreno alla soddisfazione per un lavoro ben fatto. È un peccato che la parola 'Responsabilità' venga mal interpretata, perché ciò oscura un concetto utile.


La responsabilità può essere offerta, richiesta e persino demandata, ma non può esser forzata. 'Ti ritengo responsabile' non ha senso. 'Sei tu il colpevole' o 'spero che ne accetterai le conseguenze' possono aver senso, anche se sono indice di relazioni di lavoro che poggiano su fragili fondamenta. I manager possono richiedere e demandare responsabilità. Per esempio, un manager può domandare che il software sia pronto per il deploy alla fine della settimana, così che i progressi del team siano visibili. D'altro canto la responsabilità può essere offerta anche se non richiesta. "Vi posso mostrare un log di come ho speso il mio tempo la settimana scorsa' è un offerta di responsabilità.


Offro responsabilità per dimostrare la mia affidabilità e per incoraggiare me stesso a comportarmi al meglio. Per esempio, quando rendo conto alla mia sposa della questioni finanziarie, noi discutiamo su come spendere il denaro. Ci accordiamo sugli obiettivi e i principi delle nostre finanze. Io rendo conto a lei per come spendo veramente il denaro. Se perdessi dieci dollari per qualche cosa di inutile, direi solamente le cose così come stanno e attenderei la sua risposta. Avendo queste discussioni preliminari e sapendo che dovrò rendere conto, mi aiuta a spendere il mio denaro in maniera più saggia e a far crescere il nostro legame.


Nello stesso modo, quando programmo offro responsabilità, come un modo per dimostrare la mia affidabilità incoraggiando il mio miglior comportamento. Pair programming (la programmazione in coppia); test-first programming (programmazione scrivendo prima i test); integrazione continua; cicli quotidiani, settimanali e annuali resi visibili; rilassamento; e stime sono uno dei modi per prendermi degli impegni pubblici e rendere conto delle mie attività. Sapere di essere onesto e responsabile influenzerà il modo in cui svolgo il mio lavoro, così come sapere che sto nascondendo o occultando negativamente influisce sul modo in cui svolgo il mio lavoro. Assumere delle responsabilità per mia scelta e azione allontana la colpevolezza. Non c'è nessuna vergogna se tutto quello che faccio è sotto gli occhi di tutti.


Quando programmo con un collega, gli rendo visibile il mio pensiero e ascolto il suo. Se sono confuso, glielo dico. Se non mi piace il nostro design, glielo dico. Siamo liberi di chiedere una spiegazione o di ottenere delle idee dagli altri. Se non possiamo arrivare ad una soluzione migliore, allora andiamo avanti come meglio possiamo. Non c'è nulla da nascondere in questo processo, nessuna colpa, nessuna vergogna.


Test-first programming è una forma di responsabilità, specialmente quando praticata nella sua forma più pura dove nessun codice applicativo è stato scritto senza un test che fallisse prima. I test rappresentano un resoconto dei miei pensieri quando programmo. Essi registrano i problemi che considero. Se un problema non è rappresentato da un test, si presume che non l'abbia considerato quando stavo programmando.


Integrazione continua rende conto al team, circa ogni ora, di ciò che si sta facendo al sistema. Fermarmi nel lavoro per assicurarmi che tutti i test girano, aggiunge responsabilità, così come accertarmi che, nel caso io abbia creato un problema al sistema, ne ponga rimedio prima di procedere.


Avere i cicli di pianificazione visibili offre l'opportunità di rendere pubblici gli impegni e, alla fine del ciclo, di render conto di questi impegni. Non sono molto contento di perdere tempo, di non domandare aiuto quando serve, di evidenziare un'informazione incerta, quando so che dovrò renderne conto al termine della mia giornata o della mia settimana. 'Ho perso tre giorni per non aver fissato il difetto 142 perché avevo timore di chiedere aiuto' è più imbarazzante che chiedere aiuto.


Fare delle stime vuol dire anche prendersi degli impegni. Senza stime io non so quanto è necessario per fare una cosa. Senza qualche incertezza nei miei piani, in ogni caso, so anche che regolarmente non manterrò questi impegni. Prendere e mantenere impegni è una componente importante nel processo di creazione di legami forti durante lo sviluppo, legami che sosterranno il team nei momenti di difficoltà.


A volte nell'offrire responsabilità ho paura delle conseguenze ('se solo sapessero quando tempo ho impiegato a correggere quel difetto, penserebbero che sono un idiota'). Lavoro tanto meglio quanto più sono affidabile. Se sono un idiota, è meglio prenderne consapevolezza, piuttosto che fingere che non sia vero. Se ho fatto del mio meglio, non ho nulla da temere dal giudizio degli altri. Se stimo con sicurezza che un lavoro mi richiederà quattro mesi, allora se qualcuno mi dice che a loro piacerebbe averlo in due mesi, posso sincerarmi su cosa loro pensano veramente. Posso rispettare la loro posizione senza necessariamente condividerla. Posso ascoltare le loro necessità, non solo le parole o i suoni. Posso cercare dei modi che siano mutualmente benefici per rispondere a queste necessità. Se io sono sicuro delle mie stime e del mio lavoro, allora "posso dormire quando il vento soffia".


Quando vedo l'evoluzione del lavoro nel mondo IT, vedo un'evoluzione verso team e organizzazioni che offrono responsabilità. Il livello 5 del CMMi ha diversi pro e contro, ma quello che effettivamente offre è visibilità. Team a quel livello dicono ciò che hanno pianificato di fare e riporteranno ciò che fanno veramente. Dopodiché essi rifletteranno su questa esperienza per migliorarsi.


Responsabilità non è semplicemente una questione di riportare i fatti. Se so che ho creato dei difetti questa settimana e riporto ciò in modo accurato, allora sono onesto, non responsabile. Non ho completato il mio lavoro in modo da conviverci serenamente. Non sto agendo in modo da costruire dei legami, legami necessari al buon sviluppo del software. Extreme Programming è un modo di lavorare. I suoi principi e le sue pratiche contribuiscono alla mia abilità di essere responsabile quando sviluppo. La responsabilità mi incoraggia a fare il mio lavoro al meglio. Resisto alla tentazione di trovare delle scorciatoie o di lasciare del brutto codice quando so che altri lo vedranno e se ne prenderanno cura.


La responsabilità è importante a diversi livelli. Essere responsabile con me stesso, anche se è si tratta solo di fare e rivedere le to-do list quotidianamente, aiuta a focalizzare i miei sforzi e ottenere soddisfazione da ciò che porto a compimento. Dentro un team, la responsabilità incoraggia la formazione di fiducia, una fiducia che libera energia da usare per raggiungere gli obiettivi condivisi invece che per proteggere il proprio giardinetto. Team che offrono responsabilità ai loro clienti e alla loro organizzazione, generano anche fiducia. Quando un team responsabile dice "sei mesi", gli altri possono fidarsi di questa informazione e agire sulla base di quella informazione, certi che il team persegue un mutuo interesse. Qualche organizzazione di sviluppo si è spinta tanto oltre da rendere
accessibili pubblicamente le proprie metriche interne sulla qualità, offrendo responsabilità al mondo in generale per dimostrare la loro affidabilità, per comunicare quanto credono in ciò che fanno e per incoraggiarsi a dare il massimo.

La mia esperienza è quella che quanto più è alta la mia responsabilità, quanto più esprimo
i miei impegni apertamente e direttamente e riporto le mie attività, quanto più ascolto con empatia gli altri, tanto più vedo risultati migliori. Quanto più sono responsabile, tanto più sono creativo, tanto più è il lavoro che porto a termine, tanto più creo valore, tanto più apprendo velocemente, tanto più "posso dormire quando soffia il vento".
Kent Beck





mercoledì 22 luglio 2009

I Yam What I Yam

Nome: Rossano
Cognome: Bersagliere
Età: 36
Luogo d'origine: Canosa Sannita - Chieti
Residenza: Sementina - Canton Ticino
Stato civile: Celibe
Segni particolari: se ve li dicessi poi dovrei uccidervi ;-)


Nato nella fredda notte del 29 dicembre 1972, cresce e frequenta le scuole dell'obbligo nel ridente villaggio di Arbedo-Castione. Già in età preliceale manifesta la sua predisposizione per la tecnologia acquistando con i suoi sudati risparmi un Commodore 64. Dopo diverse peripezie scolastiche decide che lo studio non fa per lui e visto l'interesse per l'"informatica" decide di iscriversi alla scuola più breve possibile per programmatori: il Corso in Informatica di Gestione di Bellinzona. Dopo 1 anno di studio e 3 mesi di stage lavorativo presso il Credit Suisse trova lavoro presso la Banca della Svizzera Italiana. Si tratta di un contratto a termine: 9 mesi per la conversione di codice da Natural v1 a Natural v2. Nonostante la proposta della banca di rimanere con un contratto a tempo indeterminato si accorge che la scuola forse non era così male e decide di iscriversi alla Scuola Tecnica Superiore di Lugano nella sezione Informatica. Esce dopo 3 anni di studio e nel 1997 si trova a fare il consulente per AP Soft presso una grossa banca. Dopo 3 anni di consulenza ed esperienza nel settore titoli con linguaggio Natural di Software AG, decide che la sua carriera professionale ha bisogno di una svolta e si fa assumere da GM Technologies nel 2000.

Qui inizia il cammino verso le pratiche agili: attraverso lo sviluppo in java su piattaforme J2EE (Jboss e Weblogic) e servizi distribuiti fa esperienza insieme a un team dinamico che ha voglia di crescere e imparare. Si occupa anche dell'infrastruttura della ditta quali rete, sistemi operativi (linux per la maggior parte RedHat), database Oracle e MySql. Della gestione del ciclo di vita del sofware e dell'ambiente di sviluppo, iniziando con dei semplici script ant per cvs con integrazione manuale per arrivare ai più complessi maven con subversion e integrazione automatizzata su continuum.

Dinamico, alla continua ricerca di nuovi obbiettivi e stimoli, adora tutto quello che riguarda la buona cucina. Appassionato di fitness è istruttore di Body Combat e Body Pump.

lunedì 20 luglio 2009

Benvenuti su Svizzera Italiana Agile

È nato SIAgile (Svizzera Italiana Agile), il Movimento Agile della Svizzera Italiana.

La Svizzera Italiana è una regione economicamente molto attiva. Le ditte di servizi e consulenza, le banche, le assicurazioni e l'Amministrazione pubblica garantiscono a molti di noi un lavoro sicuro e ben remunerato. I tomi di informatica prodotti in questo contesto non si contano. Tutto positivo insomma.

Allora qual'è il motivo per cui alcuni di noi Programmatori, Project Manager, Software Architect, Web Designer, Grafici, Business Analyst e così via (al momento più di una ventina) si organizziamo per incontrarsi per individuare nuove alternative?

Forse perché la percezione è quella di scrivere troppo software per ottenere risultati sempre migliorabili? Forse perché ognuno vorrebbe vivere un evento storico/informatico, come tanti stanno accadendo fuori dai confini regionali? Forse perché la burocrazia dei nostri Modelli di Sviluppo del Software ci rallentano nel processo di crescita ed evoluzione digitale che molti fenomeni esterni (social network come facebook, MySpace, linkedin, per dirne alcuni) ci stanno abituando? Forse perché la morte di diversi progetti faraonici partiti dalle nostre lande, ci ha deluso e amareggiato, convincendoci quasi che l'ambizione di far software che spacca non è per noi? Chi può dire.

Quello che è certo è che con la nascita di SIAgile, alcuni di questi giovani professionisti ticinesi stanno trovando delle risposte. Si organizzano per seguire eventi importanti come Better Software. Si incontrano per fare auto-formazione con membri di Extreme Programming User Group italiani (in particolare con gli amici dello XPUG-Milano). Si scambiano conoscenze apprese dai molti libri ormai pubblicati sul tema. Si esercitano insieme nelle Pratiche Agili per dare sempre più valore commerciale ai propri programmi. Si adoperano per introdurre i valori fondamentali del Manifesto Agile nelle proprie aziende, rischiando anche la collisione con paure e resistenza di colleghi e superiori.

Ciò che li accomuna è la certezza che la strada intrapresa è quella che porta a maggiori benefici per committenti, sviluppatori e soprattutto utenti. L'energia di questi ragazzi e professionisti forse porterà anche alla rivalorizzazione di molte professionalità presenti nell'articolato settore informatico del nostro territorio, le quali a volte non godono del giusto spazio per esprimersi e farsi conoscere alla moltitudine di aziende del settore; aziende che hanno bisogno di innovazione, eccellenza ed efficienza per sfondare, dentro e fuori il nostro cantone, proprio per contrastare la concorrenza che fa passi da gigante.

Per chi vuole tenersi informato e aggiornarsi con noi, rimanga sintonizzato oppure si iscriva al nostro gruppo di discussione oppure si eserciti nel nostro Dojo.

In bocca al lupo e benvenuto a tutti.

SIAgile Team