L’importante è avere disciplina
Ma sì dai, l’importante è avere disciplina, darsi un metodo. Poi agile o non agile non importa, è uguale.
No, hai capito?
No.
![[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)
July 23 2010 | Base | No Comments »
Archive for the 'Base' Category
Sfuggente e di qualità
Ron Jeffries, nella mailing list extremeprogramming@yahoogroups.com, in queste ultime ore a chi scriveva
[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:
- 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.
- 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.
- 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 è!
June 11 2010 | Base | 1 Comment »
Inventato il martello (agile), tutto diventa un chiodo (waterfall)
Mi sono imbattuto poco fa in questo interessante post di Robert ‘Uncle Bob’ Martin a proposito dell’impoverimento del termine “agile” nell’industria del software. Meglio ancora, l’articolo parla della sovrageneralizzazione di termini il cui significato è invece limitato, per quanto profondo, per quanto vasto, e al tipico sfruttamento pubblicitario che ne consegue. È ovvio – considerato l’autore del post – che il nucleo di questa argomentazione sia posto sull’attributo agile, particolarmente discusso, celebrato o condannato in questi ultimi anni.
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.
- 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.
- 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.
- 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.
February 27 2010 | Base | 3 Comments »
User experience agile con il pair progr…ehm pair design!
In questo post – scoperto via Alberto – si espongono i vantaggi dello UX design – la progettazione della user experience – condotto in coppia. Noto interessanti analogie con uno dei miei primi post… 
November 23 2009 | Base | 1 Comment »
I have a dream! A saccottino dream!
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.
August 25 2009 | Base | 2 Comments »
Scrum non basta. E nemmeno XP.
In un saliente post del caro Alessandro Astarita leggo
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.
June 20 2009 | Base | 1 Comment »
Il valore della comunicazione nell’Extreme Programming
I valori Extreme Programming sono il compendio etico sottostante la metodologia, il metro secondo il quale valutare la correttezza di ogni decisione di progetto. Il valore della comunicazione consiste nella condivisione all’interno di un team XP dello stato di qualsiasi cosa sia ritenuta importante dal team stesso.
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?
April 02 2009 | I valori XP | No Comments »
Il Manifesto Agile in italiano
Una piccola, piccolissima sorpresa: la traduzione italiana del Manifesto Agile.
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!
January 23 2009 | Base | 5 Comments »
Il ruolo: l’interaction designer
All’indomani dell’AgileCamp2009 e delle belle e costruttive discussioni intercorse fra i partecipanti riguardo le sinergie possibili fra sviluppatori e specialisti di interaction design nello sviluppo agile, ho deciso di inaugurare una nuova categoria di post dedicata ai ruoli nell’Extreme Programming proprio con un post – indovina un po! – sugli interaction designer. continue reading »
January 20 2009 | I ruoli XP | 3 Comments »
Il coraggio, un valore nell’extreme programming
Molte pratiche extreme programming hanno a che fare con il coraggio.
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?
May 18 2008 | I valori XP | No Comments »