Francesco (cphp) Trucchia

Dopo il bellissimo regalo che ideato mi ha fatto il giorno del suo compleanno, ho iniziato ha studiare come poter scrivere applicazione su iphone senza conoscere objective-c.

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.

Qualche settimana fa, una coppia di sviluppatori del team nel quale lavoro, mi ha chiesto:

“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?

Proprio oggi stavo facendo una riflessione sui metodo agili e sul famoso dilemma della responsabilità del bug-fixing.

In un processo waterfall la responsabilità del bug fixing è (quasi) sempre a carico del fornitore (azienda che sviluppa software), spesso causando gravi disagi nei tempi di consegna e nel pagamento delle risorse.

In un processo agile, dove l’azienda fornitrice mette a disposizione un team full-time (o con effort concordato) sul singolo progetto di un cliente, chi paga il bug fixing?

Dal mio punto di vista ritengo che se un team adotta tutte le buone pratiche agili dovrebbe essere in grado di creare software esente da bug. Ovviamente questo non è sempre possibile.

I punti deboli della catena possono essere:

• scrittura di un test non completo;
• storie troppo poco granulari;
• poco feedback tra team e cliente;

Ok, ammettiamo che il bug è stato creato, quindi siamo caduti in uno dei tre punti precedenti. Tutti e tre i punti indicano che è stato tolto tempo all’implementazione di una storia, poichè:

• scrivere test completi richiede tempo;
• splittare storie significa più tempo di sviluppo;
• più feedback significa più tempo con il cliente

La mia domanda a questo punto è: “Che cosa ha fatto il team di questo tempo non utilizzato?”

Se c’è un rapporto di fiducia e trasparenza tra cliente e fornitore direi che il team se non ha speso il tempo per le attività viste sopra lo ha speso per continuare lo sviluppo dell’iterazione, quindi ha sempre venduto valore al cliente.

Con ciò direi che il bug-fixing rientra nella normale vendita di valore che il team fa nei confronti del cliente e che ogni bug, come ben spiegato in tutti i manuali agili, va trasformato in storia, stimato e pianificato nelle iterazioni successive.

Il team agile vende il maggiore valore al cliente nel minor tempo possibile, il cliente deve pagare tutto il valore che il team crea.