Possiamo Fare Di Meglio
•Download as KEY, PDF•
3 likes•982 views
My presentation at the Italian Agile Day 2009 in Bologna
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (15)
More from Alberto Brandolini
More from Alberto Brandolini (20)
Recently uploaded
Recently uploaded (9)
Possiamo Fare Di Meglio
- 1. Possiamo fare di meglio
- 2. About me Nell’IT dai tempi dello ZX Spectrum Generalmente in progetti di grandi dimensioni NonSoloCodice Trainer (Freelance & Skills Matter) Technical Writer Blogger: http://ziobrando.blogspot.com Twitter: ziobrando My e-mail: alberto.brandolini@gmail.com Copyright Alberto Brandolini
- 3. www.avanscoperta.it avanscoperta.wordpres s.it alberto.brandolini@avanscoper Copyright Alberto Brandolini
- 8. Pivello
- 11. Sparare sulla croce rossa
- 28. Manca qualcosa?
- 29. Fare ciò che ci viene chiesto
- 33. "Se vogliamo che tutto rimanga come è, bisogna che tutto cambi!" Giuseppe Tomasi di Lampedusa, Il Gattopardo
- 34. Fondatori Banca Camera di Commercial Notaio Commercio ista Scelta nome società Deposito Registrazione Definizione Capitale P.E.C. statuto Sociale societario Indirizzo PEC Certificato di Deposito Scelta Codice ISTAT Costituzione Società Codice ISTAT Attribuzione Partita IVA Atto Costitutivo Registrazione alla Camera di Certificato Commercio Attribuzione Partita IVA Descrizione Attività Visura Storica Prevalente Dichiarazione Apertura Inizio Attività Conto Corrente Codice IBAN Registrazione inizio Attività Certificato Camerale Attivazione Carta di Carta di Credito Credito
- 38. Cosa serve per mettere in discussione i requisiti?
- 39. Technical Debt
- 54. Benefici o costi?
- 56. Come imparare?
- 57. Qual è il valore aggiunto?
- 58. Qual è l’etica?
- 61. Open Discussion
Editor's Notes
- Tutto nasce da un’episodio. Partiamo da una storia d’amore, da un rapporto di reciproca fiducia, che una serie di eventi ha messo in discussione.
- Il rapporto tra me ed il pulsante dell’alzacristalli. Siamo sempre andati d’accordo, ed invece ad un certo punto ha cominciato a fare le bizze. Strani rumori, a comportarsi stranamente. Perchè lo fai? Hai un altro?
- Ripararlo immediatamente… no… possiamo inventarci un sacco di tecniche per compensare questa temporanea defaillance. In questa immagine la ricostruzione dell’”incrocio magico all’approssimarsi al casello”.
- Ovviamente ad un certo punto la situazione peggiora drasticamente. Il finestrino si blocca. Di notte. A Firenze. Si supera l’Appennino imbacuccati come un terrorista. Forse avremmo dovuto pensarci prima.
- Due domande: Per quanto tempo siamo disposti a tollerare questi piccoli fastidi? Quanto spesso incontriamo situazioni simili in cui ci facciamo carico della complessità compensativa di qualcosa che non funziona come dovrebbe? (pensiamo ai post it in cui memorizziamo cose di uso comune che sono anti-intuitive, a certe parti del JDK - Date, per dirne una - o ad un certo modo di interagire con la burocrazia…)
- Ok, ed ora qualcosa di molto semplice. Sparare sulla Croce Rossa.
- Ogni grande stazione italiana ha la sua biglietteria automatica. Questa faccina che ride ci attende. Cosa avrà da ridere è un mistero.
- Non posso pagare in contanti. E va bene. Seleziono “Biglietto Rapido”, ho fretta. Devo prendere il primo treno per Faenza.
- Ops. Faenza non c’è. E non c’è nemmeno “altro arrivo”. Quindi “Rapido” significa “in una destinazione che sceglie trenitalia”. Lo use case è chiaro: lo scopo dell’utente è andare in un posto a caso, ma in fretta (cfr. “Nowhere Fast” - Bonnie Tyler). Quindi utilissimo se avete rapinato una banca ed avete la polizia alle calcagna.
- Per me che devo andare a casa mia si torna alla schermata iniziale. Ho capito perché ride la faccina.
- No contanti, e va bene.
- Ecco che posso selezionare Faenza.
- Oggi.
- Il primo.
- Ops. Che fare? …. vada per il prossimo.
- Sì lo voglio
- Un biglietto, un normalissimo biglietto.
- 2a classe
- Ma non si legge dalla carta…? Vabbè.
- Qui però mi aspettavo un vecchio amico...
- Ok...
- Fatto!
- Ach, fino a ieri c’era. La fantastica schermata in cui ti chiede “Vuoi fare una donazione?” - e chissene frega! Ma se vi trovate - come è successo a me - ad aiutare una famiglia di cinesi a districarsi fra le schermate per fargli fare il biglietto (perché quello dopo siete voi) e vi appare la schermata della donazione, come gliela spiegate? Poi mesi dopo l’illuminazione. Trenitalia è riuscita nel capolavoro di replicare l’intero processo di business dell’acquisto del biglietto, compreso il tossico che mentre sei in coda ti chiede “Che c’hai degli spicci?” Un capolavoro.
- Il problema è che spesso quello che è da fare è già stato “deciso” o comunque “messo nero su bianco” prima. Ed il cliente ci chiede di sviluppare secondo le specifiche.
- Ed il cliente ci chiede di sviluppare secondo le specifiche. Noi siamo agili ed implementiamo un fascicolo alla volta, iterativamente.
- Ma questa cosa ha un nome: mummificazione. I business process esistenti NON sono giusti! “Abbiamo sempre fatto così” è sbagliato sia sul codice che fuori.
- Se costruiamo un’impalcatura informatica su un processo sbagliato stiamo aumentando i costi del cambiamento del processo. E l’informatica serve ad ingessare le organizzazioni. Non era questo quello che avevamo in mente.
- L’IT è una forza al servizio del cambiamento, ma troppo spesso il ruolo che le viene assegnato è gattopardesco. Una pennellata di novità che cambia la superficie delle cose ma non la loro sostanza. La qualità dei servizi offerti in vari settori (bancario, PA, assicurativo, etc) non è cresciuta proporzionalmente alla tecnologia. Ed ora il risultato è che l’IT è percepito come un costo, proprio perchè NON aggiunge valore.
- Questo è il processo necessario alla registrazione di una S.r.l. - è ancora incompleto - ma la cosa folle è che l’impatto dell’IT è stato quello di rendere obbligatoria la posta elettronica certificata. Un passaggio in più. Un’organizzazione in più. 2 giorni in più. Geniale.
- Per cui al cliente che ci porta il malloppone dei requisiti, dovremmo rispondere.
- Questa è SPARTA!
- E spedirlo a calci nel pozzo.
- Noi sappiamo che quei requisiti sono inutili. Nella maggior parte dei casi sono stati scritti non tenendo conto dei problemi di implementazione, e con l’input di finire la raccolta dei requisiti entro una data (ed allora vai di Ctrl-C Ctrl-V). Sono soldi già buttati, negarlo serve a poco. Ma dire questa cosa è complicato. Cosa ci serve per poterlo fare?
- Tutti conosciamo la metafora del Debito: se lascio che il mio codice sia al di sotto degli standard di qualità, allora accumulo debito. E domani pagherò molto di più di quanto risparmio oggi.
- … Quindi accumulare debito significa buttare i soldi nel cesso e questo non ci piace.
- Però “debito” sembra qualcosa di gestibile. Poso fare i conti e vedere di rientrare quando le cose andranno meglio.
- Apparentemente si tratta di una scelta ragionata, qualcuno ha valutato i pro ed i contro di questa scelta.
- E questo qualcuno è un fantastico leader nel quale riponiamo la massima fiducia. ...Basta crederci.
- L’altro problema è che siamo italiani, e che l’idea del debito non ci spaventa più di tanto.
- Perchè pensiamo sempre di poter trovare un modo più furbo per NON pagare il debito.
- La metafora che ritengo più corretta è l’inquinamento. I suoi effetti non sono così facilmente calcolabili.
- L’inquinamento è forse una metafora migliore.
- E inquiniamo quasi inconsciamente. Spesso basta che qualcuno cominci e poi la “broken window” fa sentire i suoi effetti.
- Il punto è che il danno in questo caso non è quantificabile: quanto costa ripulire un fiume? O riportarlo allo stato precedente? In nessun caso il conto corretto può essere effettuato o ricondotto unicamente alla dimensione economica.
- Il processo NON è reversibile. E’ come mollare la puzza nell’ascensore. Non si torna indietro.
- E dove si accumula il danno? Nel cervello, nel nostro.
- In quello degli utenti
- Di tutti gli utenti… (ci siamo capiti).
- Troppo spesso i progetti software sono valutati solo in termini di costi. Se un progetto non porta benefici, questa in effetti e l’unica soluzione possibile. Ma il software dovrebbe portare dei benefici agli utenti. Altrimenti è solo un ulteriore “coso” inutile e dannoso.
- Cosa stiamo rilasciando? Come stiamo scaricando inquinamento cerebrale nelle teste dei nostri utenti? Che senso ha quello che stiamo facendo? Come siamo in grado di misurarlo? Capirlo?
- Un processo di sviluppo è anche un processo di apprendimento. Processi iterativi e burn-down chart danno l’idea di un processo di apprendimento lineare. Non è così. Troppo spesso però la parte di apprendimento relativa ad un progetto è sottovalutata, o delegata. L’apprendimento si limita alla sfera “tecnica” e non al dominio. Anche i modi di apprendere sono spesso dettati dall’abitudine, mentre tecniche diverse sono immensamente più efficaci. Una caratteristica comune a quasi tutti gli ingegneri è “avrei potuto fare qualsiasi facoltà ma ho scelto ingegneria”. ...Ora però leggo solo manuali… c’è molto altro da imparare nel dominio del problema, e molti problemi ai quali possiamo contribuire.
- Cosa da valore al nostro progetto, cosa lo giustifica. Quale valore stiamo dando agli utenti? Siamo in grado di definirlo?
- La mia etica… “Gli accidenti arrivano”. Vista in un altro modo: non possiamo rilasciare un qualcosa che riteniamo al di sotto di determinati standard. Come cuoco non ti faccio uno spezzatino di carne scaduta.
- In ogni applicazione, in ogni dominio c’è un quantitativo di complessità da affrontare. In alcuni casi sta fuori dall’applicazione (es. in Excel la risoluzione del problema sta nella testa dell’utente) in altri casi è l’applicazione che se ne deve fare carico. Quanto? Come? Diminuisce la complessità percepita dell’utente o l’utente percepisce la complessità del dominio sommata a quella dell’applicazione? L’uomo della strada rifugge la complessità. E la complessità è quella che permette di farla franca se stiamo vendendo dei derivati, o di affossare una conversazione se ci mettiamo a spiegare un argomento complesso ad un interlocutore qualsiasi. E’ normale. E’ umano. Noi però siamo pagati per affrontare la complessità, e molto spesso non lo facciamo.
- Quanto tempo stiamo perdendo?