Ma sì dai, l’importante è avere disciplina, darsi un metodo. Poi agile o non agile non importa, è uguale.

No, hai capito?

No.

[Unified Process] has [a flow with all the steps] formally described. I know [extreme programming] have different philosophies but they are both methodologies and should them both have a formal process.

rispondeva così

Sorry. Agile processes are not formal.

Questa risposta sintetizza (perché chiaramente si tratta di sintesi affatto esaustiva) molti aspetti difficili dell’approccio al mondo agile. Tra i primi che mi vengono in mente ora, mentre devo scappare per tornare al mio lavoro, trovo:

1. I metodi agili non possono essere spiegati top-down. Una spiegazione frontale può aiutare, può introdurre, ma poi basta: bisogna fare e capire. La mera inesistenza di una impalcatura formale scardina ogni tentativo di verbalizzarne una.
2. I processi agili sono facilmente fraintendibili da chi non è disposto ad approfondire il tema perché è più facile fare di concetti dai contorni sfumati quello che si vuole per giustificare le proprie esigenze dirette o addirittura le proprie debolezze. Penso a quanti ritengono che l’agile si risolva nella formula iteratività+incrementalità facendosi sfuggire che anche Unified Process contempla un approccio iterativo e incrementale.
3. I metodi agili sono adatti a fronteggiare la realtà perché ne riflettono la complessa vaghezza. Non esiste squadra di calcio che possa vincere una partita applicando schemi rigidi. Non esiste medico serio che si aspetti che un paziente sia un sistema che restituisce output lineari . Non esiste ecologo che pensi che si possa agire per step contemporanemanete deterministici e lineari per rimettere a posto un ecosistema. Esistono invece molti professionisti IT che credono che un sistema complesso – come un progetto – possa essere controllato da entità (più) semplici – una persona o addirittura un tool.

Quello che credo sia il nostro dovere tutti i giorni è crescere aumentando la nostra consapevolezza della complessità del contesto dei progetti IT e saper galleggiare su quelle onde ridefinendo ogni giorno il nostro equilibrio, senza affetto per quello trovato oggi, senza nostalgia per quello abbandonato ieri.

Trovi sia difficile? Lo è!

L’argomentazione di Martin parte da considerazioni sulla metafisica aristotelica per giungere a dichiarazioni concrete e molto chiare. I riferimenti alla storia della filosofia, devo ammettere, mi permettono di togliermi qualche soddisfazione: se anche luminari indiscussi del software internazionale come Martin li usano, allora io non devo aver fatto troppo male in passato! Scherzi a parte, il passaggio che mi è piaciuto di più è questo

The danger is clear. The word “agile” will become meaningless. It will be hijacked by loads of marketers and consultants to mean whatever they want it to mean. It will be used in company names, and product names, and project names, and any other name in order to lend credibility to that name. In the end it will mean as much as Structured, Modular, or Object.

Io ho smesso di usare la parola agile da qualche tempo. I miei ultimi clienti – perfino quelli che mi contattano perché non vedono l’ora di entrare nel mondo dei metodi agili – non mi sentono più pronunciarla. Combatto una lotta linguistica quotidiana per formulare concetti e frasi che aggirino queste 5 lettere in successione: a, g, i, l, ed e. Sono talmente preso da questa decisione ellittica da nutrire ormai forti dubbi anche sul nome di questo blog.

Perché questa avversione? Perché così all’improvviso? Per diversi motivi.

1. Una parola, usata depauperata del suo significato più denso, è come un magazzino pieno di componenti non usate, come un set di user story iniziate e non completate: è, in sostanza, una forma di waste. Trovo sia più importante per un team mettersi in marcia concretamente verso l’agilità che fregiarsi di tale caratteristica.
2. Persone che in buona o cattiva fede per motivi più o meno legati al marketing si vendono come agilisti e attribuiscono (anche) a passate collaborazioni con me la loro agilità mi danneggiano. Questo danno è vero qualunque sia il grado di evangelizzazione io abbia volontariamente apportato, questo danno è vero quantunque io abbia potuto ritenermi anche solo in grado di evangelizzare. E questo mi porta diritto al terzo punto.
3. Io sono agile? Io posso davvero ritenermi arrivato ad un punto degno di tale fatidico attributo? Domanda difficile da esaurire con una risposta netta e sai perché? Perché l’agilità non è un valore assoluto e con questo non intendo affatto abbandonarmi al più facile dei relativismi. Intendo invece stabilire una natura relativa a priori dell’attributo di agilità: come la sicurezza è definita solo in termini di “fare A è più sicuro che fare B” e non certo di “fare A è sicurissimo”, così l’agilità è definibile in termini di “fare X è più robusto rispetto al bisogno di produttività in un contesto mutevole rispetto a fare Y” ma non certo di “facciamo così, facciamo così tutti e facciamolo sempre perché funzionerà ovunque”!

Qualcuno diceva riguardo l’abuso di cose e concetti:

Inventato il martello, tutto diventa un chiodo

Ecco, io vorrei fare l’uso migliore del mio martello, ma solo sui chiodi.

I processi agili sono il mio mezzo, chiunque mai li chiamerà come vorrà. Cercare di essere produttivi nel mondo reale, questo è il mio unico obiettivo.

Saccottino fallato

Sai cos’è questo? Un saccottino.

Non sembra, non è esattamente l’immagine familiare che hai del saccottino che forse ha accompagnato la tua infanzia, ma è invero un saccottino. L’ho trovato ieri nel mio pacco e sono rimasto abbastanza sorpreso. Anzi, devo ammettere di aver provato inizialmente un certo sgomento, una certa diffidenza. Farà mica male? Poi ho capito che si trattava solamente di due mezzi saccottini evidentemente sfasati [1] rispetto alla catena di produzione in azione nello stabilimento industriale dove questi due sfortunati saccottini erano in fase di confezionamento .

Poi ho capito anche un’altra cosa. Il mio sgomento trovava le sue radici nella rarità. Non mi era mai successo di comprare saccottini difettosi. Il prodotto esente da difetti nell’industria del saccottino è una rarità. E così in molte, moltissime altre industrie.

Che l’industria del software sia storicamente di tutt’altra qualità è una cosa che percepisco io e percepisci anche tu, anche senza dati oggettivi.

Ecco, tutto il senso dietro a SCRUM, dietro a Extreme Programming, dietro allo sviluppo agile, dietro al Lean Software Development… è proprio questo: lo sforzo di ricerca di un mondo in cui un software difettoso generi lo stesso sgomento di un saccottino sfasato.

[1] Uno sfasamento di mezzo saccottino è, in termini controllistici, uno sfasamento di 90°. Lo scrivo qui un po’ perché amo le note a pie’ di pagina, un po’ perché l’ingegneria dell’automazione è leggermente off topic in questa sede, ma solo leggermente.

Per avere successo con Scrum, XP o ogni altra metodologia agile, bisogna fare refactoring. Non è opzionale, è indispensabile.

tratto da un post di Ron Jeffries.

Il refactoring è una pratica essenziale. Essenziale, nel caso la sedimentazione linguistica non lo portasse alla luce immediatamente, significa relativo all’essenza, fondamentale, che è assolutamente necessario.

Assolutamente necessario.

Troppo spesso si parla di agile – buzzword che francamente sto cessando di impiegare – e si pensa di poter garantire evolutività incrementale solo con un po’ di iterazioni buttate in un calendario e delle user story scritte male. Bisogna essere produttivi per un mercato che cambia. Bisogna essere pronti a rispondere agli stimoli.

Il codice deve essere pronto a seguirci. Ovunque.

I team XP condividono informazione spesso, volentieri e su più livelli. Utilizzano il pair programming, per trasferire rapidamente conoscenza da uno sviluppatore all’altro; spazi di lavoro condivisi corredati di grandi radiatori di informazione – come tabelloni, lavagne e poster, per permettere a tutti, anche ai non-sviluppatori, di vedere e sentire la situazione; utilizzano i brevi standup meeting quotidiani per aggiornare l’intero team sui problemi percepiti; i test automatici e la continous integration, per condividere un’oggettiva metrica dell’integrità del codice; incentivano il cliente a collaborare attivamente al progetto giorno dopo giorno per facilitare la comunicazione del lavoro svolto da una parte e del mutare dei requisiti più volatili dall’altra.

Una forma forse ancora più preziosa di comunicazione, anzi, di metacomunicazione permette il miglioramento incrementale della comunicazione stessa: la restrospettiva. Con questo meccanismo il team riflette sul proprio operato e sulle pratiche di comunicazione e di condivisione, arrivando a decidere se interrompere quelle meno fruttuose, se provarne di più promettenti o semplicemente se migliorare l’attuazione di quelle che sembra potrebbero funzionare meglio.

La comunicazione insomma è un valore prezioso all’interno di un team Extreme Programming ed ogni dubbio, ogni decisione andrebbero risolti dopo essersi posti questa domanda: cosa permetterà al mio team oggi di comunicare al meglio?

Ieri ti sei posto questa domanda? Oggi te la porrai?

Ho pensato che fosse ora di averne una in giro. Per rappresentanza, per divulgabilità… ci sono un sacco di buoni motivi.

Buona lettura. E buona evangelizzazione!

p.s. Ovviamente, mi fai sapere se ti sembra una buona traduzione? Se vuoi lascia qui sotto i tuoi appunti a commento. Grazie!

Tornato a Roma, perso in riflessioni sull’uso dei wireframe e dei test di usabilità di iterazione in iterazione, ho deciso di ridare uno sguardo a un po’ di testi, tanto per sperare di vedere ancora una volta lontano nei panni del nano seduto sulle spalle del gigante. E infatti… la ricerca ha dato i suoi frutti: la (ri)scoperta più piacevole è stata il paragrafo intitolato Interaction Designers proprio nel più importante tra i libri dedicati ai temi affrontati su questo blog: Extreme Programming Explained di Kent Beck.

L’interaction designer è la persona preposta alla progettazione dell’interazione che avviene tra esseri umani e sistemi meccanici e informatici. Il suo ruolo nella pratica quotidiana è quello di prototipare le funzionalità principali definendo quale sarà la user experience che caratterizzerà il prodotto finale. Addirittura Beck buca il muro del silenzio del manifesto agile riguardo gli utenti scrivendo:

Addressing the concerns of eventual users is a priority for the team.

In un approccio che, per assurdo, potremmo definire tradizionale, in un team di sviluppo software l’interaction designer produrrà una ricca pletora di documenti (i deliverable) atti a descrivere le specifiche di progetto in un’unica fase up-front, in aderenza a questa o a quella variazione sul tema waterfall. In buona sostanza, citando Beck,

first interaction designers figure out what the system is supposed to do, and then programmers go make it do that.

Questo approccio fasico però, come probabilmente già sai, riduce le possibilità di feedback e ostruisce il fluire del valore tra i componenti del team.

Gli interaction designer in un team XP lavorano col cliente e con gli utenti aiutando a scrivere e a rendere chiare le user story. Kent Beck pone l’accento sul nodo fondamentale della collaborazione dei designers con un team XP scrivendo

Interaction designers can use all their usual tools during this process.

e

Interaction designers specify a little bit up front and continue to refine the user interface throughout the life of the project

Queste due frasi dimostrano che mentre è riconosciuto il valore enorme dell’attività di progettazione user centred in un progetto agile, le tecniche attualmente a disposizione dei designers costringono ad un leggero shift del processo produttivo verso il vecchio waterfall.

Almeno per ora.

Hai qualche idea per rendere più agile l’interaction design?

La parola “coraggio” non va letta con riferimento ad un atteggiamento sprezzante del pericolo da parte dei membri del team di sviluppo – ma sì iniziamo a scrivere codice, poi si vedrà! – quanto piuttosto all’assenza di paura.

“Ma io non ho paura quando programmo!” molti di voi staranno pensando in questo momento. Bene, sono pronto a smentirne molti; mi sarà sufficiente porre una sola domanda:

Avete appena finito di lavorare ad un componente che ha richiesto 10 giornate (2 settimane!) del vostro prezioso lavoro. Ora il cliente ha ragionevolmente deciso, sulla base di ulteriori informazioni tecniche e di mercato di cui prima non disponeva, di modificare quel componente. Ciò richiederà di modificare ed integrare il lavoro appena concluso in misura tale da rischiare di compromettere il lavoro perfettamente compiuto fino a quel momento.
L’idea di manomettere il codice già scritto vi lascia perfettamente tranquilli?

Ok. Voi che vi guardate intorno con aria distratta piantatela lì: avete la risposta scritta in faccia. Voialtri che conoscete perfettamente il vostro codice, del quale non vi sfugge nemmeno una riga, che pertanto sapete cambiarne il comportamento modificandolo alla velocità del pensiero (sic) e che vorreste sapere come può mai accadere che uno sviluppatore tema la propria docile, cara, complessa e privatissima creatura… beh… voi siete dei geni che, per manifesta superiorità, non sono nello scope di questo articolo ed in generale del project management agile. Voi che applicate già Scrum o qualche altra metodologia agile forse siete già tranquilli, ma… tutti gli altri, lo so: la risposta è che non vi sentireste affatto tranquilli!

Questa assenza di tranquillità che avete appena immaginato – e forse anche ricordato in situazioni passate – è la mancanza di coraggio cui mi riferisco in questo articolo.

Extreme programming cerca di ingaggiare la tradizionale paura nei confronti del cambiamento direttamente alle sue origini, con una serie di pratiche atte ad indurre gli sviluppatori a fare senza timore – e quando necessario – modifiche al sistema su cui lavorano per migliorarne l’architettura, al scalabilità e la mantenibilità.

Le pratiche del test driven development e del refactoring infondono nello sviluppatore il coraggio di apportare questo tipo di modifiche in maniera incrementale via via che sono richieste, ben supportati da una solida rete di sicurezza costituita dagli unit test e dagli acceptance test.

Il cliente, d’altra parte, non incontrando la tipica resistenza al cambiamento che caratterizza i team di sviluppo tradizionali, ha anche lui la possibilità di vivere il suo ruolo con coraggio, rimuovendo la paura di chiedere modifiche. Nuovi requisiti possono arrivare per un cambiamento del mercato, per l’analisi svolta dagli stessi sviluppatori e anche, perché no, per il semplice fatto che c’è una nuova buona idea che prima non c’era.

I requisiti nei progetti software cambiano, punto e basta. Tentare di lavorare opponendosi a questo dato di fatto significa cercare di progettare un aereo sperando che la Legge di Gravità ci conceda delle pause permettendoci di volare da Malpensa a Lione! Essere bravi sviluppatori e bravi project manager non significa nascondere la testa nella sabbia e dare risposte ad una realtà che non esiste, ma reagire alla realtà dei fatti tutelandosi con strumenti e tecniche che inducano a vivere lo sviluppo con serenità e coraggio permettendo di… accogliere il cambiamento!