Sono molto felice di presentarti il nostro lavoro, dal titolo PHP Best Practices. Un libro molto tecnico, unico nel suo genere in lingua italiana e dedicato ai professionisti dell’ecosistema PHP. Il libro è di ampio respiro e si allarga su tante diverse tematiche.

Il mio titolo, neanche a dirlo, è quello dedicato al Test Driven Development. Ho cercato di dargli un taglio molto pratico, ispirato dal grande esempio di Kent Beck – autore pazzesco, ogni volta rileggerlo è una riscoperta. Nel capitolo ho cercato di rispondere alla “frequently asked” domanda: sì OK, bello tutto, ma poi dal vivo, nel mondo vero? La mia risposta migliore nel mio capitolo.

Ah dimenticavo: il mio sul TDD è l’unico capitolo scaricabile gratuitamente già da oggi, in attesa del lancio ufficiale del libro il prossimo 18 maggio al phpDay di Verona!

Buona lettura!

Il problema da risolvere

I contratti che tipicamente regolano i rapporti nello sviluppo di software sono il vero dramma del nostro mercato. Ereditati da mercati con caratteristiche finanziarie, tecniche e sociali completamente diverse, i classici contratti a corpo ad oggi, secondo me, sono il principale motivo di fallimento dei progetti software. Senza dilungarmi troppo, mi basterà farti notare come

1. mantengano il rischio completamente sbilanciato sul fornitore che, per definizione, non dovrebbe invece partecipare al rischio d’impresa neanche un po’
2. richiedano di prendere le decisioni più cruciali – visto che si tratta di denaro – in modo definitivo nel momento di minima conoscenza riguardo al progetto stesso: l’inizio.

Purtroppo il contratto a corpo, sovrano indiscusso delle gare d’appalto, rimane lo standard di riferimento per i progetti software. Questo problema può essere mitigato dall’impiego di altre forme contrattuali tradizionali: il contratto tempo e materiali con tetto dei costi, per esempio, oggi è la vera spina dorsale di aziende come ideato, che si permettono di chiedere al cliente appena acquisito un briciolo di fiducia in più sulla base della grande fiducia accordata dai clienti già acquisiti.

Il problema dei contratti tempo e materiali è che scalano male. Cosa intendo?

Intendo dire che i contratti che definiscono un prezzo in modo accoppiato al tempo speso per fornire valore ad un cliente hanno alcuni grossi difetti:

1. mantengono il rischio completamente sbilanciato a sfavore del cliente.
2. non incentivano la creatività nel cercare soluzioni migliori di rilascio, fatturazione o pagamento, riducendo quindi il valore medio dell’offerta.
3. non incentivano l’azienda fornitrice allo sviluppo tecnologico, anzi, disincentivando l’innovazione! Un’azienda che fattura il tempo speso a lavorare non ha molti incentivi finanziari a ridurre il tempo impiegato a risolvere un dato problema(*).

Questa insofferenza per i contratti tradizionali – perché di insofferenza nel mio caso si tratta – potrebbe sembrare un dettaglio, un vezzo pignolo da fanatico agilista, ma vorrei invece ti fosse chiaro come un contratto sbagliato possa distruggere ogni sforzo di adozione di un approccio iterativo e incrementale. Lo preciso perché fra questi approcci figura anche quello detto lean start-up – scrivo strizzando l’occhio ad un tema molto in voga in questi mesi.

Nel gennaio 2011, chiamati a sviluppare un’applicazione mobile per la domotica, i ragazzi di e-xtrategy hanno dovuto gestire da subito una grande incertezza: requisiti descritti poco e male, un cliente abituato alla programmazione di dispositivi automatici senza esperienza di design di interfacce utente e tecnologie relativamente nuove rispetto all’esperienza del team. Necessariamente si imponeva su entrambi i versanti cliente-fornitore una forma contrattuale più intelligente, che portasse l’esposizione al rischio di entrambe le parti a convergere.

La soluzione

Cosa abbiamo pensato con e-xtrategy un anno fa per contribuire alla sovversione di preconcetti causa di sprechi tipici? L’idea fondante il nuovo contratto è nota da sempre in altri mercati: soddisfatti o rimborsati. Vediamo un po’ di dettagli.

Il team vende il suo tempo a prescindere dalle specifiche di progetto come nel caso del contratto time & material, ma sulla base dell’intera iterazione, come una tariffa flat per intenderci. “Per un’iterazione di sviluppo del tuo team io ti pago tot” ed il team incassa la cifra pattuita per ogni iterazione lavorata alla consegna del deliverable più opportuno (tipicamente il codice, ma anche template grafici, wireframe, prototipi etc etc). Il fornitore può rifiutare arbitrariamente il prodotto dell’ultima iterazione, rinunciando ad ogni diritto su esso, senza pagare il conmpenso stabilito.

“Eh ma così rischio di lavorare gratis!” ti sento già argomentare. Vero, rischio di lavorare gratis per la durata di un’iterazione. Ma nel caso di team sufficientemente maturi un’iterazione dura 5 giorni, quindi il rischio con un contratto di questo tipo è di lavorare gratis 5 giorni. Davvero non conosci alcun team sopravvissuto a 5 giorni di lavoro oltre una deadline stabilita da un contratto a corpo classico? Permettimi di dubitarne.

Fissando iterazioni brevi con questo contratto il cliente gode

1. del controllo del time to market, potendo rilasciare virtualmente ogni 5 giorni in produzione
2. della possibilità di scaricare il team in ogni momento, impegando al massimo 5 giorni per scoprire l’inadeguatezza del team selezionato
3. della possibilità di allocare budget gradualmente, posticipando gli investimenti il più possibile
4. della possibilità di definire con la massima libertà i requisiti senza inutili rigidità upfront

Fissando iterazioni brevi con questo contratto il fornitore gode

1. della sicurezza di lavorare senza garanzia al massimo 5 giornate, scenario preferibile a molti scenari effettivi e tipici dei contratti a corpo
2. di flussi di cassa stabili e ben parcellizzati
3. dell’incentivo interno a migliorare la rapidità di sviluppo senza andare a discapito della qualità: se impiego meno tempo a parità di funzionalità consegnata evidentemente avrò margini più ampi, ma se la qualità degrada il cliente finirà per non pagarmi l’iterazione.
4. della possibilità di servire il miglior ritorno di investimento, recependo i requisiti all’ultimo momento utile e responsabile

La vera morale

Ovviamente questa è una forma contrattuale che si fonda sulla (quasi) certezza del fornitore di apportare fin dalla prima iterazione valore concreto e apprezzabile al business del cliente. Non è quindi un contratto adatto a tutti, bisogna saperlo sostenere fin dalle più remote retrovie, coinvolgendo management, commerciali, programmatori, designer, grafici. Ma e-xtrategy dopo un anno si ritrova con un cliente soddisfatto, iterazioni acquistate e pagate ben oltre l’accordo iniziale e un prodotto completo, di alta qualità e in grado di abilitare il cliente a recuperare l’investimento fin dalle prime battute.

Insomma il vero obiettivo del mio lavoro: sviluppo sostenibile di software. Eh… quante soddisfazioni!

Soprattuto – sono serio – la chance per me di raccontarvi che un altro mercato dell’information technology è possibile e non in un fantomatico paese paradisiaco d’oltralpe. È possibile qui e ora e dipende da noi, tutti noi. Tu allora lo vuoi?

Il nostro ciclo di sviluppo è estremamente veloce e abbiamo costruito strumenti per mantenerlo così. E’ normale scrivere codice e averlo in produzione pochi giorni dopo. Questa è una piacevole sorpresa per gli ingegneri che hanno lavorato in altre aziende dove il codice ci mette mesi o anni a vedere la luce del giorno. Se lavori con noi, potrai avere un impatto immediato.(*)

Hai notato? “Pochi giorni dopo”, “piacevole sorpresa”, “impatto immediato“. Perché loro sì e tu no?

“Eh ma da noi è diverso!”.

Ne sono convinto: quella differenza la stai facendo anche tu.

Lo scorso ottobre sono stato invitato come speaker alla PHPNW 2011, dove ho tenuto il talk intitolato Many to many – No man is an island. Si parla di comunità, di nerd, di social skill e di incidenti aerei. La registrazione è buona; il talk spero.

Buona visione!

http://blip.tv/phpnw/phpnw11-jacopo-romei-many-to-many-no-man-is-an-island-5860230

Prima avevamo un solo team di 6-8 persone e un service owner che si occupava del contatto con i clienti e di facilitare la pianificazione. Tutti i progetti di tutti i clienti venivano gestiti in un unico calderone, poco strutturato ma molto fluido, tenendo sotto controllo il work in progress con l’utilizzo di una kanban board e pratiche di rilascio continuo, user story per user story.

Adesso ideato ha esattamente la stessa struttura di prima, duplicata e ogni nuovo team è grande la metà del primo: due team da 3-4 persone, due service owner ormai inglobati nel team (il vecchio service owner ha ricominciato a programmare!) e due kanban board separati.

La mentalità dietro la scelta

Tra i principi dell’Extreme Programming troviamo annoverati l’autosomiglianza e il flusso. I due nuovi team provengono dallo stesso insieme di soluzioni operative e, per certi versi, condividono già tutto l’implicito che regna sovrano nel lavoro di gruppo. L’organizzazione preesistente ci sembrava non avere grossi problemi se non per quanto riguardava il bilanciamento del flusso: troppo lavoro da conoscere (leggi stimare, ma la stima non è il vero obiettivo, quanto comprendere e sciogliere la complessità dei requisiti del cliente) e un team di sviluppo fin troppo efficace, troppo spesso a secco di backlog. Il service owner si trovava in difficoltà a capire quale priorità assegnare alle diverse user story provenienti da diversi progetti e, costituendo il collo di bottiglia del processo, risultava “colpevole” in realtà vittima delle circostanze. Sappiamo dalla teoria dei vincoli che è inutile lavorare sui colli di bottiglia diversi da quello pessimo per migliorare le prestazioni del sistema e pertanto eravamo consapevoli che non avremmo dovuto concentrarci ulteriormente sul migliorare i lead time del mero sviluppo.

Tipico nello studio dei sistemi complessi, quelli costituiti da agenti molto omogenei e con grande fluidità organizzativa e gerachica rivelano grande capacità adattiva e così è stato anche in questo caso. Avere un team crossfunzionale e non tagliato sulle linee del singolo progetto ci ha consentito di dividere il team secondo una linea arbitraria, attuando la pratica chiamata shrinking teams nel contesto XP.

Il comportamento emergente successivo alla scelta

La prossima settimana svolgeremo la prima retrospettiva successiva alla nostra mitosi, e rimando a quella le valutazioni sulla nostra efficacia nel rispondere ai problemi di bilanciamento di carico cui intendevamo rispondere. Fin d’ora però voglio notare con te come i due team, partiti da una kanban board unica, con una struttura rivista e rimaneggiata lungo 14 mesi, abbiano in pochissime settimane lasciato evolvere il proprio modo di lavorare in modo indipendente, evoluzione che si riflette nella struttura diversa delle rispettive kanban board, entrambe ormai già diverse da quella unificata originaria.

In questo io sento davvero l’urgenza di fare alcune, poche considerazioni:

1. Sono convinto che questa evoluzione libera, fermi restando lo stretto contatto informale tra i due team e la lenta rotazione dei membri, facendo leva sul principio di diversità porterà grande vantaggio culturale all’interno dell’azienda. Sarà normale essere diversi, sarà normale confrontarsi e sarà normale copiare le soluzioni di maggior successo.
2. Le due kanban board mostrano chiaramente come i colli di bottiglia noti siano finalmente rilassati e questo non fa altro che spostarci verso l’individuazione del prossimo. Questa è l’essenza del kaizen, del miglioramento continuo.
3. Ancora una volta ho ottenuto conferma che la kanban board esprime il massimo della propria efficacia quando è fisica e cheap, quando buttarne la struttura al vento costa il passaggio di un cancellino e due nuovi tratti di pennarello. Scrivere software per simulare una kanban board per un team co-locato non sarà mai più razionale: il costo della modifica della kanban board sarebbe a quel punto un ostacolo al cambiamento libero.

Si pensi che l’idea di rivedere il layout dei due kanban board ideato non è provenuta dal coach o da qualcuno in fissa per l’agile. Chi può a questo punto dubitare che l’esigenza di una nuova kanban board non fosse realmente sentita dal team? Tu?

Il pensiero di assunto da Cravera nella sua critica è quello di Womack per cui

Per usare le parole dello stesso Womack, il lean thinking è “un modo per fare sempre di più consumando sempre di meno”.

e da questa considerazione Cravera fa conseguire una riflessione sui rischi che il lean thinking comporta quando eventuali ridondanze vengono eliminate in nome della riduzione degli sprechi. Riflessione, questa, legittima perché effettivamente la riduzione tout court di ogni ridondanza è effettivamente a rischio di subottimizzazione, quella condizione in cui un ottimo locale può inficiare la prestazione globale di un sistema. Effettivamente lo scenario dello sviluppo di prodotti può fare tesoro di alcune ridondanze – basti pensare alla creazione di più ipotesi di interfaccia utente,  per fare un esempio banalissimo.  Quello che della riflessione non va, se vogliamo legarla ad una critica sana del lean, è l’assunto che il lean thinking sia devoto e prono alla subottimizzazione quando è assolutamente il contrario!

Nel Lean Primer di Craig Larman e Bas Vodde, la cui lettura consiglio a tutti gli interessati al pensiero lean, gli autori liquidano il punto di vista di Cravera già nella prima pagina (!) con questa considerazione che io riporto,  tradotta da me:

L’immagine e la metafora con cui vorremmo porre l’accento su un errore – ed un’opportunità – chiave è la staffetta.

Considera i podisti di una staffetta in attesa del testimone da parte dei loro compagni di squadra. L’account manager, inorridito da questo spreco da sottoimpiego indicato in qualche report, probabilmente definirebbe una nuova policy con l’obiettivo “dell’impiego al 95% delle risorse” per assicurare che tutti gli staffettisti abbiano da fare e siano produttivi. Forse – suggerirebbe – gli staffettisti potrebbero correre tre staffette contemporaneamente per incrementare l’occupazione delle risorse. [...]

Divertente… ma questo tipo di ragionamento è più tipico del management e dei processi tradizionali nello sviluppo e in altri domini. Invece, per contrasto, ecco l’idea alla base del lean thinking:

Tieni d’occhio il testimone, non gli staffettisti

Già traspare quindi il grave vizio di sostanza dell’ emerso – non capisco se solo per citazione o per effettivo sposalizio – nell’articolo di Cravera: guarda all’approccio lean attraverso le lenti dei processi classici e ne analizza l’eventuale risultato, ormai però distorto. Non mi dilungo oltre: se ti interessa il pensiero lean leggi l’articolo di Cravera con attenzione. Poi leggi quello di Larman e Vodde per capirlo davvero.

1. Domani sarò al jsDay dove potremo apprezzare lo stato dell’arte del know-how Javascript e delle tecnologie a contorno. Trovo sia un bell’evento, considerato che è il primo in Italia nel suo genere e con un’ottima line up fin da questa prima edizione.
2. Da giovedì sarò al phpDay dove avrò l’onore ed il piacere di presentare il keynote venerdì, intitolato Many to many: no man is an island. Tratterò il tema particolarmente importante delle community e dello sviluppo della competenza.
3. Oggi mi trovo a Madrid, dove stasera si terrà il primo ALE Gathering al termine della prima giornata di XP 2011. Si tratta di un neonato network europeo centrato sulla diffusione dei valori agili e lean nello sviluppo del software. L’obiettivo di stasera sarà quello di settare la vision del network. Sarà divertente perché, mentre la delegazione italiana sarà ben rappresentata, io mi sono offerto per rappresentare la comunità bulgara, impossibilitata ad inviare dei propri delegati. Se non è networking questo…

Questo post è solo il pretesto per farti presente dell’esistenza del mio nuovo blog che, lungi dall’essere sostitutivo di questo in italiano, ne sarà invece la ormai dovuta integrazione, rivolta allo scenario internazionale dei metodi agili e dei processi lean. Se apprezzi questo blog di tanto in tanto ci sono buone probabilità che leggerai volentieri anche Thoughts of a strange loop. Ciao!

In economia esiste il concetto di isoquanto, ovvero

l’insieme delle combinazioni efficienti di input che forniscono lo stesso livello di produzione.

Questa arcana formula equivale a dire che più di una combinazione di ingredienti potrà darmi lo stesso risultato valido. Un esempio classico è quello del rapporto tra lavoro e capitale: fermo restando l’obiettivo di una start-up (il nostro output), se ho molto capitale e poco know-how potrò finanziarne una senza scrivere una riga di codice – il concetto di venture capital; se ho invece molto know-how e poco capitale potrò chiudermi in un garage tutte le notti e lanciarmi nell’impresa nerd.
Per opportune coppie capitale/know-how le chance di successo saranno le stesse e queste, in un diagramma cartesiano, saranno disposte lungo linee continue.

Isoquanti (fonte Wikipedia)

Un concetto simile esiste in fotografia: date certe condizioni di luce, sulla carta infinite coppie tempo di scatto/apertura diaframma mi garantiscono una corretta esposizione del fotogramma. Potrò chiudere il diaframma ed esporre per tempi più lunghi o potrò aprire il diaframma ed esporre per tempi più brevi.
Anche in un diagramma tempo-apertura perciò tutte le coppie accettabili saranno disposte lungo una linea continua. Ognuna di quelle linee corrisponderà ad un valore ISO della pellicola e sarà analoga all’isoquanto (hai notato qualcosa?) di cui sopra.

Cosa cambia di isoquanto in isoquanto? E di in ISO in ISO?

Banale ed intuitivo: se io posso disporre dello stesso know-how e di più capitale di un concorrente, avrò, ceteris paribus più chance di successo; se io posso disporre di un sensor… ehm di una pellicola caratterizzata da maggiori ISO, avrò, in condizioni per esempio di scarsa illuminazione, la possibilità di usare tempi di esposizione rapidi a parità di apertura diaframma, evitando un indesiderato effetto mosso.

Bene. E la competenza?

Si parla spesso di scegliere nel design del software fra una soluzione quick & dirty e soluzioni più “lente” ma più pulite. Se ne parla sempre. Se ne parla troppo. Il compromesso che si stabilisce è fra la massimizzazione del lavoro non svolto oggi e quello non svolto domani, tra 3 mesi o tra un anno. È possibile però ipotizzare l’esistenza di uno sviluppatore molto bravo che riesca a trovare una soluzione gagliarda oggi e facilmente estendibile in futuro, riuscendo quindi ad operare scelte win-win che trascendano il compromesso apparentemente inevitabile.

Un trade-off spinoso: semplicità a breve termine vs. a lungo termine.

Il diagramma qui sopra spero sia sufficientemente chiaro da farti afferrare che a parità di lavoro non svolto nel futuro – il nostro A, la competenza può farci saltare da una linea all’altra (le linee di isocompetenza? ) permettendoci di raggiungere i livelli crescenti B’, B” e B”’ di semplicità sul breve termine, salvando capra e cavoli.

Ipotizzare l’esistenza di uno sviluppatore molto bravo è utile ai fini di questo post. Diventarlo, una missione impossibile. La parola d’ordine è competenza, la sua espressione più diretta il refactoring.

[...]

Ad occhio mi sembra che “ci siamo”; abbiamo fatto la retrospettiva di gennaio ed abbiamo identificato le cose da migliorare che verificheremo a fine febbraio.
In questi giorni sta cambiando tutto “in tempo reale” (entrano progetti che devono essere consegnati dopo 2 giorni) e, incredibilmente, le persone continuano ad avere il sorriso in viso!

Il cambiamento epocale è stato questo:

prima qualsiasi evento (il cliente è contento, il cliente rompe le palle, c’è una cosa da modificare, etc) era legata all’e-xer [membro del team e-xtrategy, n.d.r.] responsabile del progetto (neanche al team). oggi qualsiasi evento diventa una “cosa di e-xtrategy” a cui dare una priorità e tutti si sbatteranno per portarla avanti prendendosi oneri ed onori.

in passato la telefonata al cliente era una delle cose più critiche. oggi è diventato: “Non riesci a chiamare Tizio? ok, allora lo chiamo io per te!”.

A presto

Miki

Capisci che fare il coach agile e parlare di lean development con persone così coraggiose è il lavoro più bello del mondo?

Miki, ci vediamo presto!