Virtù emergente: continuous integration

Una riflessione snella, senza pretese, un divertissement estivo. Sarò breve, seguimi.

La teoria della complessità ci insegna che comportamenti complessi possono emergere da sistemi costituiti da agenti semplici in relazione tra di loro in virtù di regole semplici. Craig Reynolds può introdurti a questi concetti sul web con spettacolari sciami virtuali.

Bene. Poniamo ora un team soggetto a queste due regole:

  1. ogni sviluppatore – ogni coppia – deve fare commit del codice solo a test verdi sulla sua macchina
  2. ogni sviluppatore – ogni coppia – deve prendersi carico della risoluzione dei conflitti che incontrerà al momento del proprio commit

È evidente che la probabilità di avere conflitti nel codice tende a 1 col passare delle ore; i commit degli altri sviluppatori infatti avranno sempre maggiori possibilità di introdurre linee di codice non integrabili automaticamente con le nostre. Questo dato sommato al fatto che eventuali conflitti su poche righe sono comunque preferibili a conflitti su interi moduli del nostro software fanno sì che ogni sviluppatore sarà quindi fortemente incentivato a fare frequenti commit che, in virtù della prima regola, non violeranno la stabilità della repository. Abbiamo quindi introdotto con queste due semplici regole una delle pratiche più preziose del contesto agile: la continuous integration.

Spesso introdurre pratiche nuove nei team può essere complicato anche quando il vantaggio che ne deriverebbe può essere facilmente dimostrato. Individuare regole molto semplice e deburocratizzanti può essere molto utile ad indurre i giusti comportamenti nel team di sviluppo con una redditività molto elevata, anche – perché no – in termini di morale.

August 07 2009 | Esperti | 1 Comment »

La vera agilità: passare dalle regole ai principi

Un post molto interessante di Jurgen Appelo mi ha ricordato un applet che avevo visto già alcuni anni fa, tangibile e lampante esempio dell’ordine che può emergere dal caos in base a poche regole ad un primo sguardo insufficienti a creare strutture tanto coese. La morale del post è: basta dirigere i progetti, i gruppi di lavoro, le situazioni complesse in base a regole da applicare caso per caso, cominciamo a definire solo dei vincoli e lasciamo che tutto si auto-organizzi. Cosa ha a che vedere con lo sviluppo agile tutto ciò?

continue reading »

December 18 2008 | Visione agile | 2 Comments »

Caos, diodi e regressione: una metafora per il test driven development

Intuisco una certa analogia fra il moto degli elettroni in un conduttore elettrico e il percorso che le user story fanno dalla loro scrittura al loro completamento.

Gli elettroni, se non è applicato un campo elettrico, si muovono per la sola agitazione termica e quindi il loro moto ubbidisce alle leggi della statistica e al principio di equipartizione dell’energia, secondo il cosiddetto moto browniano. Se applichiamo un campo elettrico il moto delle particelle resta caotico e non diventa affatto uniforme e rettilineo, ma la somma dei moti caotici presenta una deriva che costituisce per sé la corrente elettrica.

L’implementazione delle user story è soggetta, nostro malgrado, ad una certa caoticità di moto: scritta la storia il percorso alla completa realizzazione della feature descritta non è mai senza regressioni e, addirittura, per certi versi il destino di una user story non è mai certo, perchè la sua corretta implementazione può essere corrotta, dopo anche molti mesi, dall’integrazione nel nostro sistema di nuove storie.

I test automatici – come li conosciamo nel test driven development – danno a questo moto caotico un punto di soglia, di non ritorno. Una storia chiusa in un test non può più tornare indietro, perlomeno per gli aspetti caratterizzanti che ne abbiamo voluto testare. Come se lungo il conduttore in cui scorre una corrente elettrica avessimo installato un diodo, senza certo impedire agli elettroni di vagabondare in ogni direzione possibile all’interno del conduttore a livello locale, ma allo stesso tempo assicurandoci che ad un livello più globale la corrente scorra solo nella direzione voluta.

Le nostre user story, con l’applicazione rigorosa del test driven development, rimangono così naturalmente caotiche, ma soggette ad andare dalla scrittura all’implementazione certa senza regressioni impreviste.

April 25 2008 | Termodinamica | 1 Comment »