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 »

Lo sviluppo agile è olistico!

Nel corso dell’ultimo anno mi è capitato più di una volta di sentir parlare delle metodologie tradizionali – in contrapposizione a quelle agili – come di metodologie olistiche, in quanto imperniate sulla conoscenza completa dei requisiti di progetto.

Il ricordo della lettura di bellissimi libri anni fa e un breve ripassino sul concetto di olismo su Wikipedia rinforzano le mie diffidenze su questo uso del termine olistico.

Mi spiego: olismo significa concepire un sistema nella sua globalità e studiarne il comportamento e le reazioni emergenti non solo dalle sue singole componenti ma anche – e soprattutto – dall’interazione tra le parti stesse. L’approccio riduzionista – in diversi ambiti della scienza e della filosofia – si oppone a quello olistico e promuove la riduzione di un ente, di un concetto o di una metodologia alle entità più elementari possibili. La tendenza della scienza classica e, quindi, anche dell’ingegneria classica è sempre stato proprio quest’ultimo: cercare di conoscere l’intimo dettaglio perdendo di vista l’insieme, perdere di vista la foresta contemplando l’albero.

Negli ultimi decenni la nascita di nuove discipline scientifiche come la scienza della complessità hanno posto al centro dell’attenzione la necessità per la comunità scientifica di saper abbracciare anche un approccio olistico.

Nello sviluppo agile una serie di pratiche manageriali o ingegneristiche cerca di regolamentare alcuni dettagli della vita di un progetto software producendo come risultato globale – epifenomeno, direbbero alcuni – un successo dipendente dalla sinergia di quelle pratiche.

In questo riconosco olismo. Nel ben tristemente noto tentativo di raccogliere tutte le specifiche di un progetto software in un unico documento iniziale riconosco riduzionismo.

April 27 2008 | Visione agile | No Comments »