Che ne dite di un bel piatto di carpaccio d’elefante?
Anche se siete vegetariani, nel caso vi occupiate di sviluppo software, non potete non apprezzarlo. E, no, non serve un vero elefante per poterlo gustare.
Alessandro Giardina ci consiglierà alcuni pattern e ci darà qualche trucco per questo interessante esercizio.
Ricordandovi che potete trovare tutti gli approfondimenti alle note nel paragrafo Riferimenti, vi auguriamo buona lettura.
The Elephant Carpaccio – significato e vantaggi
The Elephant Carpaccio Exercise [1] fu concepito da Alistair Cockburn, uno dei co-firmatari del Manifesto for Agile Software Development [2], come esercizio destinato agli sviluppatori finalizzato ad imparare come suddividere il lavoro di sviluppo in “fette verticali” molto sottili. Dove per “verticale” si intende una fetta che attraversi tutto lo stack tecnologico dell’applicazione, dalla UI al DB. Suddividere il lavoro in questo modo aveva dei chiari vantaggi sulla qualità del codice, sulle scelte tecniche e sul lavoro di team, ma negli anni è emerso in modo evidente come i vantaggi influenzino tutta la catena di valore dello sviluppo software:
- Continuo rilascio di valore al cliente;
- Feedback loop più corti e quindi maggiore facilità di adattamento ai bisogni del cliente o del mercato;
- Spinta a concentrarsi soltanto sulle funzionalità di maggior valore in ogni momento;
- Facilità di test delle funzionalità e riduzione dei difetti;
- Maggior semplicità nel parallelizzare il lavoro;
- Maggiore predicibilità dei tempi di sviluppo con contestuale (e può sembrare contro-intuitivo) riduzione o eliminazione tout court del tempo da destinare alle stime.
The Elephant Carpaccio – pattern e trucchi applicabili
Ma come si affetta in maniera sottile-sottile un elefante?
Individuando nella feature da sviluppare il pezzetto più piccolo che mantenga un valore dimostrabile per l’utente finale (e quindi end-to-end), implementarlo, dopodiché arricchirlo con i dettagli che in un primo momento si era deciso di posporre.
Pattern
Esistono diversi pattern che si possono applicare, quelli più efficaci nella mia esperienza sono:
- Workflow Steps: implementare prima il percorso più breve possibile attraverso un workflow, e successivamente step e rami secondari;
- Multiple Operations: implementare un’operazione alla volta, dalla più importante alla più triviale;
- Business Rules Variations: implementare prima la regola di business più comune o più semplice, poi quelle meno comuni o più complesse;
- Data Variations: implementare la funzionalità facendole gestire un solo tipo di dato, e successivamente altri tipi di dato;
- Interface Variations: in caso siano previste più interfacce di accesso alla stessa funzione, implementare per prima quella più semplice, o quella più utilizzata;
- Defer Performance: implementare la più rapida soluzione che permetta di dimostrare la funzionalità, e rifattorizzare successivamente per consentire scalabilità e performance in caso di molti utenti concorrenti.
Alcuni trucchi
Sempre dalla mia esperienza maturata sul campo, vi riporto alcuni trucchi:
- Zero, One, Many: una funzionalità che deve lavorare su oggetti multipli può essere implementata a partire da una versione che gestisca una collezione vuota, poi un solo oggetto, e infine n oggetti;
- Hard-code Values First: in una prima versione della funzionalità, considerare valori di input o parametri di configurazione come hard-coded anziché gestirli;
- Defer Validation: omettere la validazione dei dati di input in una prima versione dell’applicativo;
- Defer fancy GUI: considerare un’interfaccia grezza, al limite anche solo testuale, per una prima versione;
- Mock: concettualmente simile a “Hard-code Values First”, ma con oggetti di collaborazione più complessi;
- Release and Feature Toggles [3]: interruttori logici che consentano di accendere o spegnere una funzionalità solo per determinate categorie di utenti.
The Elephant Carpaccio – considerazioni
Pattern e trucchi sono semplici da capire, ma spesso la loro applicazione si scontra con mentalità sedimentate e barriere culturali (ad esempio pre-ottimizzazione, riduzione della duplicazione a tutti i costi, spasmodica ricerca dell’astrazione). Questa resistenza non è del tutto ingiustificata: spesso usare questi pattern e trucchi introduce un certo debito tecnico iniziale, che deve essere gestito oculatamente e rimosso il prima possibile.
Ma l’obiezione più feroce e difficile da scardinare è, tipicamente, “Ma non possiamo rilasciare in produzione una cosa simile!”
E chi ha detto che vada fatto?
Ricordiamoci che una funzionalità dichiarata “Done” deve essere “Potentially Releasable” (conoscete tutti la differenza tra Deploy e Release, vero? [4]). Per essere rilasciata (Deploy), basta che non “rompa” nulla, che non causi nessun disagio agli utenti finali.
Il goal è ottenere feedback dagli utenti in queste fasi. Dare al cliente senso di velocità, di continuo progresso verso la funzionalità completa, tramite il deploy costante di piccoli incrementi.
Sarà poi il Product Owner (o il team stesso in caso di product ownership diffusa), nel pieno dei suoi poteri, a decidere il momento in cui, quando sufficienti micro-funzionalità si saranno accumulate (Deploy) fino a costituire un valore tangibile, rilasciare in produzione (Release).
P.S. Nessun elefante è stato maltrattato durante la redazione di questo articolo.