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ò?
Mi piace pensare, lavorare e scrivere questo blog in base ad un sano principio di multidisciplinarietà: amo stabilire ponti fra concetti apparentemente distanti, scovando pattern in giro e costruendo quelli che nella scienza delle reti vengono chiamati legamideboli tra piccoli mondi culturali. Oh parbleu!!! L’ho appena fatto! Beh, lo sto per rifare tirando in ballo Socrate. continue reading »
Tempo fa promisi una risposta ad un post di Alberto in cui lui esponeva parte di alcune nostre elucubrazioni sulla differenza fra ciò che vale per l’utente e ciò che vale per il cliente. Finalmente ho avuto il tempo di… disegnare i diagrammi!
In buona sostanza il diagramma che preferisco contrapporre a quello da lui pubblicato è questo
Peraltro lo stesso Alberto in un altro suo post discute anche questo approccio.
Nelle metodologie agili, ed in particolare in Extreme Programming, si prende come obiettivo il valore realizzato per il cliente – inteso come colui che possiede il sistema finale e ne finanzia lo sviluppo, mentre nella disciplina dello user centred design i bisogni, le volontà e le limitazioni dell’utente finale sono poste al centro dell’intero processo di progettazione.
Mentre si potrebbe pensare in un primo momento che gli interessi dell’utente siano sempre coincidenti con gli interessi del cliente, che immaginiamo tutti puntare ad ottenere un pubblico soddisfatto, un’analisi più approfondita mostra immediatamente che le cose non sono così semplici. Esistono cioè casi in cui il cliente ha degli obiettivi diametralmente contrapposti alle esigenze dell’utenza del sistema. I sistemi di e-commerce sono spesso contraddistinti da questa contrapposizione, mentre le community online vedono un maggiore allineamento fra interessi del cliente e dell’utente.
Nel diagramma sopra quindi, benché il valore per l’utente di una feature non sia mai trascurabile per calcolarne il valore per il cliente, abbiamo una rappresentazione troppo semplicistica della realtà che, effettivamente, viene a galla in fase di assegnazione delle priorità delle user story.
Direi quindi che questo diagramma possa essere considerato più fedele al vero
Come si vede il valore utente, se considerato, deve esserlo in maniera in linea di principio indipendente dal valore per il cliente o cmq in correlazione controllata ovvero consapevole.
Quanto le due metriche di valore siano correlate tra loro è quindi dato, in questa rappresentazione, dall’angolo formato dai due piani individuati: il primo che pone in relazione le priorità delle user story con il valore per il cliente, il secondo che pone in relazione le priorità delle user story con il valore per l’utente. Minore l’angolo formato dai due piani, maggiore la concordanza tra le due assegnazioni di valore e la conseguente corrispondenza di assegnazione di priorità.
Quindi, in relazione ulteriore, possiamo porre la coincidenza di interessi tra clienti e utenti
e arrivare ad una morale conclusiva: se il design delle applicazioni ancora soffre troppo spesso di rigidità di processo, mentre le metodologie agili non forniscono veri e propri strumenti per la progettazione macroscopica delle stesse applicazioni, il vero sforzo da compiere nei prossimi anni è quello di far convergere i due mondi, individuando metodologie che sappiano da una parte accogliere il cambiamento senza waterfalliane eredità, dall’altra produrre e sostenere la vision di ogni progetto.
Come a dire: ok, con le user story sappiamo cosa farci, ma una metodologia di spessore per scriverle non sarebbe bello averla? Con Luca lo scambio a tal proposito è nel vivo…
Circostanza frequente: team agile approntato, progetto intrapreso secondo la metodologia preferita (extreme programming o scrum o entrambe o…), hai terminato di stimare le user story, hai assegnato le dovute priorità insieme al resto del team e ora devi approntare un release plan che permetta di capire per quanto ne avrete. “Facile!” esclama il giovane agilista, “Basta prendere la somma degli story point e dividerla per la velocity del progetto!”. Senza dubbio corretto in linea di principio – e comunque non è mai così semplice nella pratica – ma soprattutto: alla prima iterazione che valore di velocity userai? Tu e il tuo team non avete mai lavorato su questo progetto, non hai dati retrospettivi su cui contare. E quindi? Affiderai tutto al caso?
Assolutamente no, ci sono delle tecniche per (aiutarci a) sciogliere questo nodo e voglio illustrartene qualcuna.
Una delle problematiche principali del software project management è l’ordinamento degli obiettivi e dei task relativi. Ci sono delle cose da fare prima e altre dopo, mentre nel frattempo dobbiamo essere in grado di dimostrare responsabilità da una parte e progressi concreti dall’altra. L’extreme programming non ci risparmia questa difficoltà, pur mettendo a nostra disposizione strumenti – come il planning game – atti ad analizzare queste problematiche e a sostenere le decisioni del team.
Ieri ho partecipato al primo giorno del phpDay 2008, in attesa di pubblicare con Francesco il nostro workshop oggi pomeriggio. Giornata divertente come ogni anno mi aspetto che sia, resa più frizzante dalla richiesta improvvisa di Fullo di aiutarlo a riempire un buco venuto improvvisamente a crearsi nell’agenda della giornata. Pensavo di fare un talk veloce sulle metafore fisiche con cui mi capita di descrivere (o di veder descritti) i processi agili, poi però Francesco mi ha dato l’idea migliore – parlare del Domain Driven Design – che ho poi deciso di integrare con riferimenti all’extreme programming.
Il domain driven design è una metodologia di modellazione del software che parte dal presupposto per cui gli sviluppatori devono nel tempo distillare una sempre maggiore porzione di conoscenza di dominio nella struttura del codice scritto, conoscenza che proviene dal contributo degli esperti di dominio, tipicamente il cliente.
Un obiettivo fondamentale di questo processo è quello di creare un ubiquitous language che sia condiviso tra team di sviluppatori ed esperti di dominio, che si rifletta fino in fondo alla scelta dei nomi delle classi, dei metodi, delle interfacce e delle strutture relazionali tra oggetti, in modo da
rendere più affidabile il design dell’applicazione
rendere più semplice la partecipazione del cliente alla progettazione stessa
Il che già di per sé sembra fortemente propedeutico per la pratica extreme programming denominata customer on site che richiede al cliente di essere presente direttamente – o per delega – presente presso il team di sviluppo del progetto di cui è committente.
Ma se poi andiamo a fondo nell’apprendimento del domain driven design scopriamo anche il concetto di continous learning e di new insight che riflettono il fatto che gli sviluppatori, man mano che vivono all’interno di un progetto, ne assimilano i concetti di dominio fondamentali e sono perciò portati a modificare il codice per riflettere questo incremento di conoscenza. Il libro di Eric Evans fornisce molti utilissimi consigli per ottenere codice che sia facile da manutenere e far crescere, ma per noi agilisti è chiaro che vengono alla mente i concetto di design emergente e, ancor di più, di refactoring.
Extreme programming quindi ci fornisce delle pratiche che, se seguite con attenzione, ci permettono di modificare il codice senza timore, di tenerlo pertanto aderente alla realtà di dominio e quindi di perseguire il continous learning senza attriti ed ostacoli di sorta.
È chiaro quindi come il domain driven design possa essere propedeutico alle pratiche agili, ma anche come extreme programming possa esserlo per l’incremento di conoscenza del dominio che una modellazione domain driven presuppone.
Uno sviluppatore con cui ho terminato oggi un’importante fase di un progetto web mi ha detto:
[...] Io diffido di chi propone un rimedio come panacea di tutti i mali. Nei progetti open source che vedo utilizzare i test automatici io vedo ancora liste di bug lunghissime.
Affermazione che equivale più o meno a dire:
Ritengo gli antibiotici un immenso bluff. Sono decenni che vengono impiegati e ci sono ancora milioni di malati in ogni parte del mondo
Ok, ci ammaliamo ancora tutti e ancora ovunque, ma rinuncereste agli antibiotici?
Gli antibiotici non ci regalano l’immunità totale, ma hanno abbattuto l’impatto dei batteri sulle nostre vite. I test automatici non sono una panacea, ma abbattono il tempo speso a fare debugging – che è sempre tempo perso, poiché non è passato a creare valore ma a verificarlo.
Intuisco anche una certa analogia fra il moto degli ioni attraverso una membrana osmotica da una soluzione ad un’altra e il percorso che le user story fanno dal loro concepimento al loro compimento.
Anche gli ioni in una soluzione, in condizioni normali, si muovono per la sola agitazione termica e quindi anche il loro moto è browniano, all’insegna cioè della caoticità più radicale.
L’osmosi è quel fenomeno che consiste nel movimento di diffusione di due liquidi miscibili di diversa concentrazione, una membrana, semipermeabile o permeabile ai due mezzi. È un fenomeno molto importante e studiatissimo in biologia e perfino due metodi di conservazione dei cibi con cui tutti noi abbiamo a che fare ogni giorno sfruttano l’effetto osmotico: la salatura e la salamoia.
Anche in questo caso quindi con i test automatici ed il test driven development possiamo immaginare di porre una membrana semipermeabile tra due soluzioni di user story: quelle da fare e quelle fatte. Le storie così, nel loro moto comunque caotico, diffondono in maniera non reversibile verso lo stato di completamento e vengono messe al riparo da regressioni per sempre.
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.
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.
![[del.icio.us]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/delicious.png)
![[Digg]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/digg.png)
![[Facebook]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/facebook.png)
![[Google]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/google.png)
![[LinkedIn]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/linkedin.png)
![[Technorati]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/technorati.png)
![[Email]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/email.png)
