Velocity, velocity, velocity… (updated!)

Traggo questi spunti da uno speech di Kevlin Henney.

Definizione della parola “agile” dal dizionario Treccani.it:

“àgile agg. [dal lat. agĭlis, der. di agĕre «spingere»]. — 1. Che si muove con facilità, svelto.”

ma, dato che i nostri neuroni sono continuamente bombardati da milioni di informazioni, per difenderci tagliamo un po’ facendola diventare: “Che si muove svelto”. In fondo, quattro parole sono più facili da ricordare rispetto a sei.

Se agile è un aggettivo, allora è una proprietà osservabile e non un processo o una cosa da fare: ”sono agile” invece di “faccio agile”. E se è osservabile allora la possiamo misurare in qualche modo; e come la vogliamo misurare la sveltezza dei team agili? Ovviamente la metrica principe usata è la “Velocity”.

Chiediamoci allora quale sia il significato di “Velocity”?

In italiano lo traduciamo con la parola “Velocità”. In inglese hanno 2 parole diverse per indicare la velocità:

Speed per indicare la grandezza fisica scalare, cioè un numero schietto, in formula:

Velocity invece serve per indicare la grandezza vettoriale, mette in relazione uno scalare con le sue componenti (le direzioni), in formula:

Torniamo all’agilità e proviamo a traslare queste definizioni nel mondo della produzione, possiamo dire quindi che:

Speed indica la quantità di cose/funzionalità/attività fatte, senza chiederci se sono quelle che servono o che hanno più valore (azzardo… processi tradizionali).

Velocity indica la quantità (lo scalare) e la qualità (la direzione) quindi il valore delle cose fatte (qui sono sicuro… cultura agile)

Non è un caso quindi che gli agilisti parlino di velocity, ma siccome, sempre il nostro cervello è costretto a subire attacchi alla sua integrità, anche qui preferisce capire la cosa più facile… sceglie di utilizzare l’accezione monodimensionale con tutte le conseguenze che conosciamo sul team, sulla produttività, sul codice, sul progetto e sul prodotto: ci ritroviamo team velocissimi a rilasciare cose…e velocissimi nel far crescere il debito tecnico del sistema che stanno costruendo, tanto che ad un certo punto cominciano a dire: “ehi boss dobbiamo sospendere gli sviluppi sul sistema…ora è necessario fare refactoring altrimenti non riusciamo più a lavorare.” Siamo ancora sicuri che veloce sia un bene?

Vi porgo una domanda: “Perché le automobili hanno i freni?”. La prima risposta che dareste è: “perché ci permettono di rallentare!”… si giusto. Vi propongo un’altra risposta che potrebbe aprire diversi scenari: “perchè ci permettono di andare più veloci!”. Riflettiamoci un po sù, quanto veloci andreste se sapeste che nella vostra auto non ci sono i freni?

Quali pratiche per lo sviluppo software possiamo considerare i freni che ci consentono di viaggiare più veloci e sicuri? TDD, Refactoring, il Pair Programming, Continuous Integration, test automation etc etc. Queste pratiche, la cui efficacia è provata da decenni di utilizzo ed evoluzione, ci permettono acquisire conoscenza per supportare quel grado di cambiamento necessario a costruire i sistemi di cui abbiamo bisogno.

Concludo con questa citazione:

“I have made this longer than usual because I have not had time to make it short” — Blaise Pascal.