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…

La situazione in cui si trova un equipaggio di una barca è di costante pressione: da una parte, banalmente, lo scenario agonistico di competizione verso gli altri equipaggi, dall’altra la stessa procedura di regata richiede la conformità a tempi e standard ben definiti. Ho scritto standard a ragion veduta, perché è su questo campo che si gioca tutta la partita delle checklist. Considerato che un equipaggio è costituito da persone che collaborano per un obiettivo comune e che ogni ruolo comporta delle responsabilità e delle azioni che inevitabilmente possono essere interpretate in modo diverso da persone diverse, si pone il problema per il gruppo di sincronizzarsi con una certa uniformità sui sub-obiettivi, sulla sequenza delle azioni da svolgere e sulla qualità minima garantita.

Per raggiungere questo allineamento, che ci si augura il più raffinato possibile, si può quindi descrivere l’obiettivo globale per mezzo di un insieme di vincoli (uno standard, appunto) e lasciare che ogni membro dell’equipaggio svolga le azioni locali che ritiene più opportune prendendosene carico, accettandone la responsabilità. In altre parole si rinuncia al micro-management che detterebbe legge sui singoli gesti di ognuno a bordo per esaltare l’arbitrio individuale su come eseguire in pratica la manovra necessaria.

Una checklist quindi cos’é? È un elenco di condizioni che devono essere soddisfatte per garantire il successo di un processo e spesso le usiamo senza dare loro questa importanza. Esistono checklist per far decollare aerei; per fare i bagagli; per fare la spesa al supermercato; per progettare social network; per definire i passaggi da rispettare per un deployment di un’applicazione e per allestire una barca da regata rimanendo sicuri di aver pensato a tutto, liberando la testa per dedicarla a problemi più critici, come la tattica.

La tattica è infatti quel calcolo che una mente pensante fa tutte le volte che una data strategia – devo comprare certi prodotti per mangiare – si incontra e si scontra con un ambiente mutevole – c’è fila al banco carni, intanto penso alla frutta. Nessuno sarebbe così pazzo da cercare di pianificare gli acquisti al supermercato al livello del singolo passo fra i corridoi, ma ogni nonna che manda un nipotino a fare acquisti lo dota di una rudimentale quanto efficace checklist che garantisce il set di prodotti da acquistare in qualsiasi modo e sequenza il bravo nipotino riterrà validi. Purché siano leciti!

Su Wikipedia si legge:

A tactic is a calculated action determined by the absence of a proper locus. The space of a tactic is the space of the other

oppure

Tactics, then, are isolated actions or events that take advantage of opportunities offered by the gaps within a given strategic system, although the tactician never holds onto these advantages.

Due estratti molti affascinanti.

La cosa importante è che in uno scenario tattico – come la regata, come il deployment di un’applicazione – le persone coinvolte possano flessibilmente risolvere gli imprevisti mantenendo il focus su cosa sia necessario completare per ritenere l’operazione un successo. Tra le mille opzioni possibili

1. lasciamo all’individuo la libertà di scegliere quali compiere nel dettaglio – tattica
2. comunichiamo dei vincoli corrispondenti alla strategia – checklist
3. lasciamo che la soluzione emerga

Il commitment di ogni elemento del team garantisce che il miglior sforzo possibile sia impiegato sul problema tattico posto dall’incontro tra checklist e variabili ambientali.

Ovviamente lo standard, la checklist, non è niente di più che una delle possibili e inevitabilmente parziali rappresentazioni della conoscenza del team. Di fatto costituisce un tentativo di esplicitarne la massima quota possibile. Non sia mai che non possa essere messo in discussione a valle di nuove informazioni o valide considerazioni ridefinenti la strategia del team! Probabilmente un team di principianti tenderà ad affidarsi alle checklist con più pedissequità di un team esperto, ma l’importante è che sia vivo uno spirito critico di gruppo che favorisca il miglioramento continuo dello standard, un processo che nel mondo lean si chiama kaizen.

Un paio di spunti di riflessione per te e per me: le user story si possono considerare come una checklist per il completamento di un wireframe? Ed il Test Driven Development? Non è forse sviluppo lungo le linee guida di una checklist sui generis che evolve fianco a fianco con il codice stesso? Tu che ne pensi? Io qualche idea me la sono fatta…

È il quarto anno di fila che partecipo a questo evento come speaker, l’anno scorso con Sue me sue you blues – Contratti e preventivi nei processi agili, quest’anno con Qualità totale. Diventa sempre più difficile di anno in anno rimanere all’altezza dei nomi di fama nazionale e internazionale previsti in programma. Di questo come al solito non ringrazierò il Gr.U.S.P., che organizza tutto come sempre in passato.

Anche questa volta sarò al phpDay in compagnia di Bonacivita, il mio lealissimo motociclo. Dopo un inverno di arresto forzato, coglierò l’occasione dell’evento e la sua insolita prossimità con Roma per inaugurare la mia nuova stagione di mototurismo.

Bilancia (23 settembre – 22 ottobre) “Tutto quello che complica il lavoro”, scrive il poeta Jason Shinder, “fa parte del lavoro”. Se nei prossimi giorni incontrerai qualche ostacolo, tieni presente il suo consiglio. Se ti accorgi che stai pensando “Accidenti! Se non fosse per queste complicazioni farei molti più progressi”, prendi in considerazione la possibilità che le complicazioni non siano distrazioni, ma indizi essenziali. Che non siano affatto seccature insopportabili, ma stimoli utili che ti indicano dove stanno le vere opportunità.

Al di là dell’innegabile saggezza di Shinder riguardo cosa rientri nella definizione di lavoro, io trovo questo un consiglio validissimo per il mio lavoro di ogni giorno.

I problemi o sono indizi essenziali o sono opportunità. Certe volte giocano un ruolo doppio. In extreme programming due modi di catturare i problemi in una di queste modalità sono rispettivamente la retrospettiva ed il principio di opportunità.

La morale è sempre quella: meglio pianificare per il mondo vero in cui inevitabilmente accade quello che non vorremmo mai che assumere per ipotesi un mondo più controllabile di quanto persino la teoria ci autorizzi a sognare.

p.s. no, non mi piace l’astrologia