Cercando un po’ su internet ho trovato due progetti molto interessanti:

• Phonegap
• Titanium

Entrambi si presentano come tool di sviluppo rapidi per creare applicazioni native per dispositivi mobile (iphone, android, blackberry) in html + javascript + css. Conoscendo molto bene questi tre linguaggi, ho pensato di iniziare a studiare questi tool per vederne le capacità.

Con la regola dell’80-20 che applichiamo in ideato (in pratica ogni sviluppatore può utilizzare il 20% dei suo tempo per studiare, fare prototipi, ecc), insieme con Michele e Fullo, abbiamo deciso di sperimentare entrambe le librerie per creare la nostra prima applicazione per iphone e android.

L’idea è quella di creare un’applicazione che, interfacciandosi con il servizio web Joind.in, faccia vedere i talk “on air” durante un evento. L’obiettivo è quello di lanciare l’applicazione durante il phpday 2010 che si terrà il 13, 14 e 15 maggio a Corropoli (TE).

Vi terremo aggiornati sull’applicazione su questo blog.

Se volete seguirci da più vicino abbiamo creato un repository GitHub, dove metteremo tutto il codice.

L’aquila è degli aquilani!!

“Ciccio, ma quali sono le regole del Pair Programming? Facciamo Pair Programming da alcuni mesi, ma a volte non ci sentiamo molto efficaci, perchè discutiamo troppo nel prendere decisioni condivise e perchè il nostro livello di conoscenza non è lo stesso.”

Quando dal team emergono queste domande, i miei occhi si illuminano, perchè solo di fronte alla consapevolezza si possono dare piccole regole per migliorare se stessi.

Di fronte alle loro domande non ho risposto subito, ho rinviato la discussione ad un dojo interno, che organizzeremo in ideato a breve tempo.

Tuttavia, oggi, vorrei raccontarvi quando secondo me il Pair Programming è efficace.

La metafora che uso spesso per far capire il Pair Programming è quella dei guidatori di rally, chi scrive codide è il guidatore, chi sta a fianco e osserva è il navigatore. Se il guidatore non si fida del navigatore, dove va a finire l’auto?

Come in ogni coppia anche nel Pair Programming si è efficaci se si rispettano i ruoli.

1. Il guidatore si deve fidare del navigatore.
   Nella coppia ci deve essere fiducia. Il punto di vista predominante deve essere quello del navigatore. La coppia non può discutere ogni piccola decisione. Il guidatore si deve occupare di fare bene quello che gli viene detto dal navigatore. L’obiettivo è la risoluzione del problema. Se il guidatore non è d’accordo con il design emerso potrà fare refactoring quando sarà lui il navigatore, se necessario.
2. Il guidatore deve stare attento alla tattica.
   Il compito del guidatore è quello di porre attenzione a quello che gli viene detto dal navigatore e al coding style.
3. Il navigatore deve stare attento alla strategia.
   Il compito del navigatore è quello di indicare la strada al guidatore. Il navigatore deve guardare più avanti e scegliere quale strategie attuare. E’ il navigatore che fa emergere il design del codice.
4. Per discutere si chiama un Time-Out.
   Durante la sessione di Pair Programming, se la coppia è in disaccordo, si possono chiamare dei Time-Out. I time out servono a discutere insieme quale strada percorrere e come risolvere un certo problema, o per chiedere aiuto a qualcuno se si è bloccati. Il numero massimo di time out che si possono chiamare durante una giornata non dovrebbero essere più di quattro. La durata di un Time-Out non deve essere superiore al pomodoro.
5. Cambiarsi i ruoli.
   E’ molto importante che nella coppia i ruoli vengano scambiati frequentemente. Un tempo ideale potrebbe essere ogni uno o due pomodori.

Nel dojo che organizzeremo in ideato, vedremo come rendere ancora più efficace il Pair Programming attravero il Ping Pong Pair Programming.

E tu ti fidi del tuo navigatore?

]]> http://www.cphp.it/2010/01/12/alcune-regole-del-pair-programming/feed/ 3 http://www.cphp.it/2009/12/31/per-progetti-software-non-ci-vuole-un-team-grande-ma-un-grande-team/ http://www.cphp.it/2009/12/31/per-progetti-software-non-ci-vuole-un-team-grande-ma-un-grande-team/#comments Thu, 31 Dec 2009 18:30:20 +0000 cphp http://www.cphp.it/?p=307 Come citava la pubblicità dei pennelli cinghiali, “Per fare una grande parete, non ci vuole un pennello grande, ma un grande pennello“, ritengo che lo stesso slogan possa essere applicato oggi alle aziende che producono software. Si pensa che grandi team e aziende fortemente strutturate possano creare software migliori e in tempi brevi.

Beh questa è utopia.

Il software è fatto dalle menti delle persone: chiamale grafico, ingegnere, architetto, db specialist o semplicemente programmatore, ma quello che conta realmente non è l’etichetta ma la loro creatività.

Per fare un grande software bastano poche persone, eccellenti nella loro professione, fortemente motivate, coraggiose, curiose e in grado di comunicare tra loro. Sono questi alcuni degli ingredienti fondamentali di una ricetta che non può sbagliare.

Dall’altra parte nel team non può mancare il committente, colui che ha richiesto il software, sia esso un imprenditore, un utente, un product manager, un business analyst. Per fare un grande software ne basta anche solo uno, ma che ci sia, che sia anche lui farcito degli stessi ingredienti di professionalità, motivazione, coraggio, curiosità, capacità di comunicazione e soprattutto disponibilità.

Con queste due caratteristiche non avremo mai un software grande, pieno di bug che non fa quello che abbiamo chiesto, ma un grande software, fatto dagli utenti per gli utenti, un software pronto a cambiare quando richiesto, in grado di compiere i task per i quali è stato creato.

Come possiamo raggiungere questo obiettivo in un mondo di speculazione e fanta finanza… sinceramente non lo so, ma credo che un’eccellenza di professionisti e aziende italiane che in questo 2009 ho incontrato stiano iniziando a muoversi verso un mondo più sostenibile, più razionale e più vero, dove i vincitori sono sempre due, sia il cliente che il fornitore, per farlo stanno abbracciando la filosofia delle metodologie agili.

Questo è quello che il 2009 mi ha lasciato a livello professionale, questo è il progetto per il quale voglio impegnarmi nei prossimi anni.

Voglio regalare alle persone e alle loro aziende che mi hanno fatto crescere in questo 2009 un link alla loro professionalità. Ringrazio di cuore:

• Kea, Michele, Paolo, Fullo, Anto, Filo di ideato
• Antonio, Giorgio e Alessio di Digital Natives
• Alberto, Gianfilippo e Cristiano di Doralab
• Luca, Diana ed Alice di Sketchin
• Michele e Lorenzo di e-xtrategy
• il mio caro mentore Jacopo

Buon 2010.

Ho partecipate alle seguenti conferenze:

• eZ International Winter Conference – 29, 30 Gennaio 2009, Barcelona
• PHPCon Italia 2009 – 18 – 20 Marzo 2009
• PHPDay 2009 – 15, 16 Maggio 2009, Verona
• PHP Test Fest – 19, 20, 21 Giugno 2009, Cesena
• eZ Conference & Awards 2009 – 24, 25, 26 Giugno 2009, Parigi
• Javascript Camp – 25 Settembre 2009, Cesena
• HTML 5 Dojo – 18 Dicembre 2009, Cesena

Ho tenuto i seguenti talk:

• PHPCon Italia – Extreme Programming and PHP
• PHPDay – Spaghetti Code Refactoring
• Javscript Camp – Unit test con javascript

A fine ottobre inoltre è uscito il mio primo libro “eZ Publish 4: Enterprise Web Sites Step By Step” ed ho iniziato a scrivere il mio secondo libro “Pro PHP Refactoring with Test-Driven Design“.

Inoltre con la mia azienda ho lavorato ai seguenti progetti:

• Tripshake.com
• eHarmony.it
• TopGirl.it
• Casa Vinicola Zonin e tenute
• Planetek Italia

e alle seguenti estensioni open source:

• eZ Deploy – Deploy automatico con eZ Publish
• eZ Test Browser - Test funzionali con eZ Publish

Ho cercato di migliorare ogni giorno il processo produttivo all’interno di ideato, studiando e mettendo in pratica le metodologie agili.

Dire in conclusione un anno molto produttivo, ora vediamo che cosa il 2010 si riserverà.

Auguri a tutti e felice anno nuovo.

Gruppo dedicato allo studio ed approfondimento delle pratiche dell’eXtreme Programming e dei processi agili in genere con sede in Ancona. (The group is focused at investigation and review of eXtreme Programming practices and agile processes in general based in Ancona, Italy).

Ho deciso di iscrivermi anch’io e penso che il 2010 mi vedrà impegnato in questa bella iniziativa.

–

EN: Hi my friend defaceman, why do you enjoy to deface my web site? I’m not an important person, I have a very small number of vistor every day and you are my friend. Why do you deface me? I’m really curios to know it.

Good bye

–

PS: Il mio caro provider non mi permette di vedere i log di accesso alla mia macchina, per capire dove potrebbe essere il problema. Secondo te che faccio, cambio provider? Ho letto da qualche parte che potrebbe essere un problema di tema wp.

Italian Agile Day 2009!

Venerdi’ 20 Novembre 2009 si terrà a Bologna il sesto Italian Agile Day. Si tratta di una conferenza gratuita di un giorno dedicata alle metodologie Agili per lo sviluppo e la gestione dei progetti software rivolta agli sviluppatori, project leaders, IT managers, tester, architetti e coach che hanno esperienze da condividere o che iniziano solo ora ad interessarsi a queste tematiche. La giornata ha come obiettivo la conoscenza pratica, le esperienze sul campo e un attivo coinvolgimento di tutti i partecipanti. L’accesso è libero previa registrazione, i posti sono limitati. L’evento, per la quarta volta consecutiva, si auto-finanzierà.

PHP Refactoring
Molte aziende ed organizzazioni hanno applicazioni business critical che dipendono da codice obsoleto e di difficile manutenzione.

Le ragioni dietro a questo genere di problema possono essere molte, dalla perdita di know-how relativo a chi ha sviluppato il prodotto, alla mancanza vera e propria di progettazione fino alla totale assenza pratiche di sviluppo che non hanno seguito pattern riconosciuti
e consolidati.

Con questo corso si imparerà ad identificare questi problemi ed aggiornare, o creare, applicazioni più efficienti utilizzando pratiche di Test Driven Design.

Il corso di Refactoring di codice PHP obsoleto sarà basato sul libro, di prossima pubblicazione, scritto da Francesco Trucchia e Jacopo Romei intitolato ”Pro PHP Refactoring with Test-Driven Design“ e tenuto dagli stessi autori.

durata: 2 giorni
maggiori informazioni: http://www.refactoring.it

Se siete interessati a partecipare o volete avere maggiori informazioni contattateci all’indirizzo formazione@ideato.it.