Sessions at Better Software 2011 on Tuesday 28th June

Rovesciamo un luogo comune: più che ai manager, le metriche sono utili ai team. Questo è ancora più vero in un contesto Agile. Agile implica sapere cambiare rapidamente, sia i progetti che il processo, e creare valore in modo rapido e continuo. Siamo in grado di misurare tutto questo ? Siamo veramente agili o stiamo solo usando una serie di "rituali" privi di sostanza ? Servono metriche che misurino la nostra agilità e metriche che misurino la nostra efficacia. Ne servono di nuove, senza tuttavia rinunciare ad alcune metriche tradizionali comunque utili. Alcuni esempi da casi reali.

Warning:
- non tutto ciò che è misurabile è importante e viceversa
- le metriche possono ingannare e possono essere ingannate

Agile è anche trasparenza, meglio rimuovere ogni remora e paura: misuriamo e rendiamo evidente quanto facciamo. Solo così è possibile migliorare in modo continuo.

Nota: a differenza di quello presentato all'Italian Agile Day 2010 questo intervento non è inteso come una panoramica introduttiva alla misurazione dei progetti e processi software. Vuole essere più concreto e presentare metriche specifiche usate in casi reali, sottolineandone aspetti positivi e non.

Lo sviluppo del software è una disciplina complessa nella quale è necessario gestire molteplici aspetti sia metodologici che tecnologici. "Il programmatore e le sue api" è una serie di articoli pubblicati sul magazine MokaByte.it in cui si affronta il tema dello sviluppo di una generica applicazione JavaEE: lo scopo è mostrare quali sono le fasi e come si collegano fra loro, per la realizzazione di un progetto Java Enterprise.
Dallo studio di fattibilità, l'analisi macrofunzionale, la definizione del piano operativo e ilproject management, si passerà alle fasi di progettazione e strutturazione della architettura alla scelta delle tecnologie per la realizzazione delle varie parti del progetto. Lo scopo di questo talk, e della serie degli articoli, non è tanto quello di insegnare le varie discipline (gestione, progettazione, implementazione) ma piuttosto di fornire una indicazione di massima su quale sia la procedura migliore per "impostare" e "guidare" il progetto durante la sua evoluzione.

Avete mai provato la sensazione di essere immersi in una melma di codice putrido e maleodorante e di non riuscire a venirne fuori nonostante tutti i vostri sforzi?

In questo workshop cercheremo proprio di simulare questo scenario proponendovi un esempio di progetto mal scritto e che sarete chiamati in prima persona a rifattorizzare.

Con l'aiuto di due coach vi faremo capire come riconoscere il codice che ha bisogno di essere migliorato, ed applicando i solid principles verrete guidati verso un buon design in grado di portarvi in acque più sicure e pulite.

Regole del gioco
- Massimo 24 partecipanti
- Il linguaggio scelto per il workshop è Java.
- Per la partecipazione si necessità di una propria macchina con installato l'IDE di sviluppo e il progetto (Eclipse) che varrà inviato qualche giorno prima dell'evento.
- L'esercizio di refactoring sarà svolto in pair programming. Le coppie verrano formate al momento.

Una buona parte (se non la maggioranza) delle aziende informatiche nascenti, può veder definito il proprio core business come la barbara personalizzazione di software libero ed opensource scovato in rete. La personalizzazione di software esistente è però qualcosa di sacro e tutt'altro che banale. Leggere il codice di terzi è spesso più complesso che scriverne di nuovo. Capiamo quindi di quali tecniche è necessario impadronirsi prima di approcciare la personalizzazione di un software open, soprattutto in vista della partecipazione alla community del software stesso.

In this talk I will describe the use, in a real context, of Kanban and Scrum agile methodologies combined with some practices of Extreme Programming. In the scenery of the agile methodologies, Scrum has certainly gained a position of clear dominance in terms of adoption and obtained successes. This remarkable result is undoubtedly due to its peculiarities to know how to answer to the agile's values and principles in a revolutionary way, and of fostering a very pragmatic approach. Moreover, its characteristic of not being prescriptive with regard to technological aspects, allows a Scrum team to integrate eXtreme Programming practices to agile skills with a great success through their gradual introduction. As also shown and described in my article "Lean Agile Adoption - an enterprise-war story" Scrum can scale to enterprise-level and can be used to guide the transformation process itself of a company into an agile one. Our real-world experience, based on principles of continuous experimentation and adaptation, soon led us to devise and use a form of merging Scrum with Lean methodologies, and in particular with Kanban. The purpose of this short paper is therefore to share the direct practical experience of teams led by me, in order to help others in their process of adopting agile methodologies.

Vorrei raccontare di come si applica la pianificazione Agile a progetti di medie dimensioni (per intenderci parlo di progetti stimati in 4-8 anni persona). XP ci spiega come fare pianificazione; ma siamo sicuri di avere capito bene come funziona? E siamo sicuri che la pianificazione di XP esaurisca tutto quello che serve sapere? Vorrei raccontare di alcuni comuni fraintendimenti a proposito di Release Planning, di Planning Game e soprattutto di User Story. Per quello che vedo io, spesso si dà troppa importanza ai requisiti funzionali e troppo poca ai requisiti cosiddetti "non funzionali". Questi ultimi si possono specificare con precisione e possono essere la chiave per evitare di confondere "requisiti" con "design". Un esempio di questa confusione si vede quando si pretende che sia il cliente a "progettare" l'applicazione, cosa che non gli compete e che dovrebbe essere responsabilità degli sviluppatori. Quello che vi racconto nasce dalla mia esperienza e da quello che ho imparato a mie spese...

Il software Open-Source rappresenta una grande opportunità in ambito industriale. Questa opportunità si manifesta su due diversi fronti: La possibilità di utilizzare all'interno del proprio prodotto un grande quantitativo di codice già disponibile ad un costo praticamente nullo; La possibilità di rilasciare il proprio codice proprietario sotto licenza Open Source creando così una comunità di sviluppo attorno ad esso, beneficiando dell'attività di sviluppo gratuita da parte di appassionati, enti di ricerca ed altre aziende. Entrambe queste opportunità, tuttavia, spesso richiedono una ristrutturazione del processo di sviluppo interno dell'azienda, per far fronte alle eventuali problematiche derivanti dalla sensazione che l'azienda stia perdendo il controllo sull'implementazione del proprio software. Oltre a questo, è necessario prestare attenzione agli aspetti legali legati all'utilizzo di una licenza Open Source per il proprio codice, esaminando i vari casi di utilizzo e prevenendo per tempo eventuali problematiche legate alle clausole della licenza specifica. Tutte queste problematiche, se non adeguatamente individuate ed affrontate per tempo, possono compromettere la propria strategia industriale e la riuscita del prodotto finale. L'obiettivo del talk è quello di cercare di fornire una visione obiettiva sui reali vantaggi e svantaggi nell'uso di software Open Source in ambito industriale. Il talk prenderà come caso di riferimento il kernel Linux, avvalendosi dell'esperienza pregressa dello speaker, e fornendo anche una breve panoramica sulle licenze Open Source disponibili.

Grazie all'Android Market anche uno sviluppatore o un piccolo team può arrivare a distribuire una applicazione a due milioni di utenti (il numero non è casuale!).

Nel talk vedremo vari aspetti legati allo sviluppo e soprattutto alla distribuzione di una applicazione mobile partendo dalla mia esperienza su Android.

Da Agosto 2009 sviluppo sul sistema operativo Android: quella che era solo una mia passione personale è diventata piano piano un progetto a tutto tondo.

Attualmente ho due applicazioni a disposizione nell'Android Market: Apps Organizer e Folder Organizer. La versione full di Folder Organizer è nelle prime posizioni fra le applicazioni a pagamento nel market italiano.
Partendo da statistiche, considerazioni su successi ed errori commessi derivate dalla mia esperienza vedremo come sviluppare una applicazione per tutti i dispositivi Android (tablet compresi) e come sfruttare al meglio i vari canali di distribuzione pur non avendo un ufficio marketing.

Qual é il ruolo del project manager nell'agile? Quali sono i suoi "nuovi" compiti? Perchè mai un PM dovrebbe appoggiare il cambiamento verso l'agile? Cercheremo di rispondere a questi e ad altri quesiti attraverso un gioco di ruolo: un PM tradizionale, uno agile e il pubblico come giuria...che lo scontro abbia inizio!!!

Lua, da linguaggio utilizzato solo come scripting glue sta guadagnando spazio e diventando sempre più importante per la programmazione mobile. Corona e Moai sono dei tool per la creazione di applicazioni mobili cross-platform completamente Lua based e permettono di sviluppare un gioco per intero in questo interessante linguaggio. In questo talk approfondiremo, con esempi tratti da codice reale, le caratteristiche di Lua e le ragioni del suo recente successo.

L’auto-organizzazione dei team è una caratteristica essenziale ed imprescindibile del mondo Agile, e che ha un suo valore anche in gruppi di sviluppo non Agile. Sappiamo che auto-organizzarsi è un fattore chiave per qualunque team di successo, e sappiamo che questo richiede fiducia, rispetto, disponibilità e responsabilità. Dunque, perché per molti team è così difficile raggiungere questo risultato? L’auto-organizzazione altera le dinamiche manager/team e all’interno dei team stessi, con possibili resistenze. La causa si trova spesso in varie abitudini mentali e comportamentali, quali: trovarsi in una cultura latente di colpevolezza; confondere guida e comando; paura di assumersi responsabilità o di perdere status; tratti collettivi. Questa sessione propone dei casi reali, vissuti dal relatore nella sua attività di coach per trasformazioni Agile, per illustrare alcune dinamiche che bloccano l’auto-organizzazione, le loro cause e quali sono i possibili rimedi. Il pubblico viene direttamente coinvolto in alcune attività che rendano più chiari e personali i temi trattati. Per chi è interessato a migliorare il modo in cui proprio team lavora, questa sessione fornisce spunti nuovi e moderni.

Come garantire che tutto il codice prodotto da una squadra di sviluppatori e` corretto, efficiente, leggibile, ben testato, ben documentato, privo d'errori? Come assicurarsi che tutta la squadra e` familiare con ogni aspetto del codice (cosi` che l'improvvisa assenza di uno o due membri della squadra non puo` bloccare il progetto perche` sono gli unici a conoscere certe parti del codice)? L'uso corretto delle code review puo` sicuramente aiutare a perseguire tutti questi ambiziosi e validi obbiettivi. Non e` un tema controverso: in teoria, tutti amano e onorano le code review... e allora perche` tanti sviluppatori le odiano, e sono spesso usate solo "ritualmente", se non addirittura completamente evitate? Risposta: perche` piu` spesso che no non sono fatte nel modo giusto. Troppa enfasi su quali strumenti usare per portarle a termine, ignoranza delle trappole e trabocchetti che aspettano l'ignaro al varco, ignoranza delle "best practices" del settore. Le code review, per essere produttive, devono allinearsi con ogni altro aspetto del progetto: aspetti tecnici, certo (ma paradossalmente sono i meno cruciali!), ma soprattutto aspetti relativi alle persone, alla comunita`, al business model. Questo talk introduce questo cruciale strumento per lo sviluppo di software, toccandone le basi e offrendo vari esempi e consigli, sia generali, sia specifici.

Sviluppare siti che siano veloci è importante, ma lo è ancora di più se la fruizione degli stessi avviene tramite dispositivi mobile dove le tecniche di caching assumono un nuovo connotato.

Questo breve talk aggiungerà lo stack "mobile" al precedente presentato a BetterSoftware nel 2010 completandone la visione ad un più alto livello:
http://www.bettersoftware.it/con...

In un mercato già particolarmente competitivo, se l'acqua è poca, far galleggiare la papera diventa ancora più difficile. Reagire alla siccità economica significa asciugare le infrastrutture, ma soprattutto asciugare il modo di pensare. Focus sui clienti, potenziale sistemico dell'azienda, flusso di valore e policy sprecone sono i 4 specchi delle nostre brame per stabilire chi sia il più lean del reame.

Purtroppo nella programmazione per mobile di oggi si trova molto codice quick e dirty. Nella sessione verranno proposte delle tecniche per combattere questa brutta tendenza su piattaforma Android. Partiremo da come impostare un sviluppo TDD, passeremo alla scrittura di test di integrazione che, tra le altre cose, registrano l'input dell'utente e lo rieseguono in modo automatico per verificare interi workflow senza la presenza del QA. Il tutto condito da librerie di mock, script e tool per automatizzare il puo' possibile ogni passaggio.

Adobe AIR 2.5 è presente su oltre 84 milioni di dispositivi mobili a livello mondiale; 50 tablet di diversi manufacturers usciranno con Flash Player 10.1 installato e compatibili con AIR; 20 milioni di smartphone usciranno prima dell'estate del 2011 con compatibilità con la Flash Platform; Flash Player ed AIR son disponibili su diversi sistemi operativi mobili come iOS, Android, WebOS e BlackBerry OS.

Ormai la Flash Platform non è più un sogno ma una realtà, su dispositivi mobili in particolare. Durante questo talk andremo a vedere le potenzialità della tecnologia, consigli pratici per iniziare a muoversi in questo mondo e previsioni sul futuro della piattaforma.

Gestire una transizione verso un nuovo paradigma, implica la capacità di riuscire a convincere e motivare gli artefici del cambiamento, ma anche di trovare una risposta alle immancabili resistenze. Difficile discutere, difficile capirsi anche perché "il modo di ragionare è differente". In questo argomento affrontiamo la questione degli strumenti concettuali a disposizione per modellare e gestire le transizioni tipiche di una transizione agile, e di come possano rendersi utili nel nostro lavoro di tutti i giorni.

Suggerimenti, trucchi, strategie per capire, parlando in modo distratto con uno sviluppatore alla macchina del caffé, se il prossimo anno esista una minima speranza di ottenere il premio di produzione o se da subito convenga iniziare a lavorare sul proprio profilo linkedin.

Il mondo dei linguaggi di programmazione è dominato da due filosofie diverse: quella dei linguaggi "statici", come Java e C#, e quella dei linguaggi "dinamici", come Ruby e Python.

Gli esponenti di questi due mondi comunicano poco e si guardano con sospetto. Hanno valori, abitudini e modi di lavorare diversi. Un bravo sviluppatore dovrebbe sapersi muovere senza difficoltà da un mondo all'altro, ma la cosa sembra più difficile di quello che potremmo pensare.

Cosa impedisce a chi lavora (ad esempio) in Java di apprezzare pienamente Ruby, e viceversa?

In questo talk parlerò degli ostacoli che dobbiamo superare per diventare madrelingua in un linguaggio statico e uno dinamico allo stesso tempo. Prendendo a prestito qualche idea dalla psicologia cognitiva, spiegherò perché troviamo così difficile "pensare in un altro modo" rispetto a quello cui siamo abituati.

In particolare mostrerò come gli stessi principi di design e architettura portano ad un sistema software completamente diverso a seconda del linguaggio con il quale lavoriamo.

In un quadro economico in continua discesa prima o poi ogni illuminato imprenditore viene colto dal miraggio di un incredibile risparmio, ottenuto spostando la propria produzione in paesi esotici. Dietro al miraggio si nasconde una quotidianità fatta di barriere di ogni tipologia, non sempre banali da superare. Lo scopo di questo talk è di condividere l'esperienza maturata dal nostro team: gioie e dolori, miti e verità a partire dal lontano 2007. (1) I criteri con cui scegliamo partner tecnologici offshore tra le migliaia disponibili. (2) Come impostiamo degli standard di comunicazione e collaborazione (strumenti, modalità di documentazione, analisi e sviluppo). (3) Come gestiamo un team geo distribuito e multiculturale. (4) Go live del progetto: verificare e integrare nel proprio progetto quanto sviluppato in offshoring. (5) Cosa abbiamo imparato in questi 4 anni di esperienza.

Agile viene spesso calato in un contesto di contrapposizione con il management, visto più come un ostacolo all buon riuscita di un progetto. Quel è dunque il ruolo del manager e del management in un'organizzazione agile? E' davvero solo un ostacolo o può essere qualcosa di diverso e anzi utile? In questo intervento, della serie "... ma che ciazzecca" verrà trattato come inquadrare il ruolo manageriale nell'ambito di un processo di sviluppo agile, con riferimento alla realtà del team di sviluppo di Funambol.

PostgreSQL è un sistema open-source multi-piattaforma per la gestione di database relazionali estremamente versatile, noto per robustezza, estendibilità e aderenza agli standard. Funzionalità di classe enterprise come replica, alta disponibilità e disaster recovery fanno di PostgreSQL una soluzione affidabile in molti ambienti di tipo business critical. L'assenza di costi di licenza rende infine PostgreSQL un candidato ideale per quelle aziende che intendono ridurre il costo di proprietà totale (TCO) delle loro soluzioni di database senza alterarne i requisiti funzionali. La recente versione 9.0 ha visto l'introduzione di Hot Standby e replica nativa in streaming, mentre la release 9.1 - attesa per il prossimo autunno - includerà la replica sincrona.

Per ogni problema dello sviluppo software ogni soluzione passa per una buona interazione fra persone. Per ogni ottimo software troviamo un gruppo di persone in grado di comunicare con efficacia. Intelligenza sociale, aziende fondate sulla competenza, user group e progetti open source sono il vero motore dietro la nostra crescita, anno dopo anno. Abbiamo leve potentissime per aumentare la nostra forza: gli altri.