Software ...e tutto ciò che comporta
•
6 likes•1,324 views
Slides from my 2010 Better Software talk in Florence. Revised and tuned after the speech.
Recommended
More Related Content
What's hot
What's hot (10)
Viewers also liked
Viewers also liked (20)
Similar to Software ...e tutto ciò che comporta
Similar to Software ...e tutto ciò che comporta (20)
More from Alberto Brandolini
More from Alberto Brandolini (20)
Software ...e tutto ciò che comporta
- 1. Software ...e tutto ciò che comporta alberto.brandolini@avanscoperta.it twitter: ziobrando
- 2. 2 giorni 6 ore e 40 minuti
- 3. Fare Software ...e tutto ciò che comporta alberto.brandolini@avanscoperta.it
- 4. 8 ore e 16 minuti
- 5. Fare Software ...ed alcune cose che comporta alberto.brandolini@avanscoperta.it
- 7. 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.co
- 8. www.avanscoperta.it avanscoperta.wordpress.com alberto.brandolini@avanscoperta.i t © Alberto Brandolini 2009
- 9. Augmented Reality Vedere ciò che ci circonda con occhi diversi
- 11. nel 1988 John Carpenter ci era già arrivato...
- 12. nel 1988 John Carpenter ci era già arrivato...
- 18. Hey sono io nella foto! Cosa si è fumato il Brando oggi? Era meglio se seguivo l’altra track...
- 19. Parte I Costruire software Del come qualche passo in avanti sia stato fatto e di quanti ne restino ancora da fare
- 20. Software Computer software, or just software is a general term primarily used for digitally stored data such as computer programs and other kinds of information read and written by computers. Today, this includes data that has not traditionally been associated with computers, such as film, tapes and records.[1] The term was coined in order to contrast to the old term hardware (meaning physical devices); in contrast to hardware, software is intangible, meaning it "cannot be touched".[2] Software is also sometimes used in a more narrow sense, meaning application software only.
- 21. Main Entry: soft·ware Pronunciation: ˈsȯft-ˌwer Function: noun Date: 1958 : something used or associated with and usually contrasted with hardware: as a : the entire set of programs, procedures, and related documentation associated with a system and especially a computer system; specifically :computer programs b : materials for use with audiovisual equipment A '''computer program tells a computer what to do. It is a sequence of instructions to be executed in order. A computer program consists of a set of instructions that the computer understands.
- 23. 1) Il software scatena emozioni forti 2) Chi produce software è in grado di alterare l’umore della gente
- 24. A '''computer program tells a computer what to do. It is a sequence of instructions to be executed in order. A computer program consists of a set of instructions that the computer understands.
- 25. Il software è ciò che permette all’hardware di fare ciò di cui l’utente ha bisogno
- 26. Qual è il nostro lavoro? Quali sono gli skills necessari?
- 27. Qual è il nostro lavoro? Indovinare? Quali sono gli skills necessari?
- 28. Qual è il nostro lavoro? Indovinare? Capire? Quali sono gli skills necessari?
- 29. Qual è il nostro lavoro? Indovinare? Fare? Capire? Quali sono gli skills necessari?
- 30. Qual è il nostro lavoro? Indovinare? Fare? Capire? Tradurre? Quali sono gli skills necessari?
- 31. Qual è il nostro lavoro? Indovinare? Fare? Capire? Tradurre? Immaginare? Quali sono gli skills necessari?
- 32. Qual è il nostro lavoro? Indovinare? Fare? Capire? Tradurre? Immaginare? Assemblare? Quali sono gli skills necessari?
- 33. Qual è il nostro lavoro? Indovinare? Fare? Costruire? Capire? Tradurre? Immaginare? Assemblare? Quali sono gli skills necessari?
- 34. Produrre valore del come da qualche parte ci sia qualcosa di profondamente sbagliato
- 35. Il processo ideale b ud g et a l ue v time
- 36. Può funzionare
- 37. b ud ge waterfall ideale t v a l ue time
- 38. waterfall reale b ud ge t lu e v a time
- 40. Successo!! b ud ge t lu e Expectations v a time
- 41. … più o meno
- 42. bu dg et P.A. Waterfall v a l ue time
- 44. Si può fare di meglio
- 45. agile “aggressivo” b ud ge t v a l ue Exp e c t at i o n s
- 47. Continuous deployment Test driven development Continuous Integration Code coverage Pianificazione agile Interazione con il business ...
- 49. Interludio Le foto delle vacanze Come abusare di una platea compiacente per millantare doti atletiche ormai sbiadite
- 58. 3 semplici
- 59. 3 semplici osta il primo moschettone
- 60. 3 semplici osta il primo moschettone Sposta il secondo moschettone
- 61. 3 semplici osta il primo moschettone Sposta il secondo moschettone Vai alla piattaforma successiva
- 62. 3 semplici
- 63. 3 semplici Red
- 64. 3 semplici Red Green
- 65. 3 semplici Red Green Refactor
- 68. Vogliamo osare l’impossibile ...è che “non regressione” è un po’ ...limitante...
- 69. Là, dove nessun uomo si è mai spinto prima
- 70. Aspettative e Vincoli Del come il miglior modo per non scontentare nessuno è fare in modo che non si aspettino granché
- 71. Cose da decidere prima di partire
- 72. Cose da decidere prima di partire Budget
- 73. Cose da decidere prima di partire Budget Scope
- 74. Cose da decidere prima di partire Staff Budget Scope
- 75. Cose da decidere prima di partire Logistica Staff Budget Scope
- 76. Cose da decidere prima di partire Logistica Staff Budget Scope
- 77. Cose da decidere prima di partire Logistica Staff Budget Scope
- 78. Cose da decidere prima di partire Logistica Staff Budget Scope
- 79. Cose da decidere prima di partire Logistica Staff Budget Scope
- 81. L’architettura del software di occupa delle decisioni difficilmente reversibili…
- 82. L’architettura del software di occupa delle decisioni difficilmente reversibili… Ma le decisioni più irreversibili hanno poco a che vedere con l’architettura
- 84. Ma la cosa già decisa...
- 85. Ma la cosa già decisa... Legacy
- 93. Abbiamo i test?
- 96. Nel 2010 -...devo ancora aspettare dei 2 ai 5 giorni perché un bonifico abbia esito -...devo ancora recarmi allo sportello per cambiare una prenotazione ferroviaria da Roma a Faenza
- 98. Parte II Cosa stiamo facendo realmente? I mille dubbi del giovane sviluppatore alle prese con l’immaterialità del proprio lavoro
- 99. Il prodotto • Cos’è il prodotto? • Quanta parte di questo è software?
- 100. Complessità Application Complexity Domain Complexity
- 101. Complessità Application Complexity Domain Complexity User
- 102. Complessità Application Complexity Domain Complexity User
- 103. Complessità Application Complexity Domain Complexity User
- 104. Complessità Application Complexity Domain Complexity User
- 105. Complessità Application Complexity Domain Complexity User
- 106. Complessità Application Complexity Domain Complexity User
- 107. Complessità Application Complexity Domain Complexity User
- 108. Intermezzo breve storia di uno username
- 109. Di chi è la palla?
- 110. One product - one team un product owner con una visione complessiva del prodotto un team con tutte le competenze necessarie alla realizzazione del prodotto
- 111. or s s m e in t Ar on ati s u lys ch er B a Project it n ec Web design A t Manager t lis UX ia ec A Cu Q sp Develope Arc st om rs er Coach hit s ec
- 112. Abbiamo tutte le competenze? skill o ruoli? Abbiamo le strutture per lavorare assieme? Sono tutte disponibili? In che forma? Con che contratto? dove? quando? ...
- 114. Parte III L’apprendimento del come far meglio il proprio lavoro significhi far bene il proprio lavoro
- 115. Noop.nl big Agile Practices Survey: “Build a system metaphor” tra le pratiche agili meno
- 116. ...e se provassimo a vederla diversamente? Il software è il prodotto secondario di un processo di apprendimento.
- 117. • Eliminate waste --> cosa è realmente necessario? Ridurre il carico cognitivo • Amplify learning --> amplify learning2 == imparare ad imparare • Decide as late as possible … :-/ • Deliver as fast as possible --> iterazioni brevi, collaborazione creativa con gli esperti, verifica sul campo • Empower the team --> empower the team • Build integrity in --> imparare in maniera consistente • See the whole --> no specializzazioni –
- 118. Posso pianificare l’apprendimento? Posso imparare più velocemente? Posso imparare meno cose?
- 119. Prima elementare Burn Down Chart 10 2 9 3 8 4 7 5 6 6 Numeri 5 7 4 8 Vacanza 3 9 2 1 0 0 1 2 3 4 5 6 7 8 9 10 Settimane
- 120. 1 2 3 4 5 6 7 8 9 10 2 4 6 8 10 12 14 16 18 20 3 6 9 12 15 18 21 24 27 30 4 8 12 16 20 24 28 32 36 40 5 10 15 20 25 30 35 40 45 50 6 12 18 24 30 36 42 48 54 60 7 14 21 28 35 42 49 56 63 70 8 16 24 32 40 48 56 64 72 80 9 18 27 36 45 54 63 72 81 90 10 20 30 40 50 60 70 80 90 100
- 121. L’arte di imparare andando un po’ a cercare qualcosa interessante si trova
- 122. L’istruzione in la scuola inizia a 7 anni no voti individuali fino ai 12-13 anni molte attività di gruppo pochissimi esami
- 123. I migliori docenti Studiati i docenti che ottenevano sistematicamente risultati sopra la media in quartieri disagiati Nessun metodo comune --> continuamente in evoluzione entusiasmo come unico tratto in comune.
- 124. Il metodo multisensorialità sperimentazione argomenti e tempi scelti dai bambini non dai docenti (pull vs push) no pressione ambiente stimolante one-on-one mentoring
- 125. Esempi vs parole
- 126. L’esperimento Tre gruppi di studenti selezionati come migliori Tre docenti selezionati come migliori Obiettivi di eccellenza Obiettivi raggiunti
- 127. L’esperimento Tre gruppi di studenti selezionati a caso Tre docenti selezionati a caso Obiettivi di eccellenza Obiettivi raggiunti
- 128. Cosa imparare? Problem Domain Conventions Admin duties PMP Legacy code Office space Project Management Agile XP TDD CMMI SOA Domain Driven Design CQRS Web 2.0 EDA Scrum Software Craftmanship Kanban Back to Basics System Thinking Groovy JQuery Git User Experience Ruby languages Scala Erlang Information Architecture
- 129. Possiamo farcela da
- 130. Organizational bandwidth Marketing another team team Domain Experts offshore team Operations
- 131. Communication tools Miglioramenti massivi sulle forme di comunicazione e condivisione Convergere su una proposta è un arte Set di strumenti tipici largamente insufficiente
- 132. FARE IMPARARE
- 133. FARE IMPARARE
- 135. Conclusioni In cui il relatore, dopo aver sproloquiato tenta di tirare le somme
- 136. Eleviamo le aspettative: possiamo fare di meglio sappiamo fare di meglio è lecito chiedere di meglio
- 137. Mettiamo il nostro capitale umano in condizione di fruttare
- 138. scimmiottar e?
- 139. scimmiottar e? ...o osare l’impossibi le
- 140. scimmiottar e? ...o osare l’impossibi le
- 141. smettiamo di imboccare il team -Requisiti -Requisiti - -Requisiti Requisiti -Requisiti - Requisiti -Requisiti -Requisiti -Requisiti -Requisiti
- 144. Capo, ho un’idea!
- 145. Capo, ho un’idea!
- 146. Capo, ho un’idea!
- 147. Capo, ho un’idea!
- 148. Ringraziamenti Provato ed affamato, il relatore ringrazia e risponde alle domande del caso. alberto.brandolini@avanscoperta.it twitter: ziobrando
Editor's Notes
- Ok, Brando. Ti sei messo nei casini un’altra volta. Come puoi presentare un titolo così. Ho preparato l’argomento ed il risultato è:...
- Decisamente troppo
- Riduciamo ancora un po’ lo scope...
- ancora decisamente troppo.
- Ok, diciamo che non è “tutto” ma “qualcosa sotto ai nostri occhi a cui non sempre facciamo caso”
- Non vi tedio più di tanto con preamboli ...sapete già cos’è l’augmented reality.
- Quello che forse non tutti sanno è che non è una novità. Nel 1988 il fil Essi Vivono aveva già divulgato l’idea, che alcune devices permettessero di vedere qualcosa in più.
- Permettevano infatti di vedere ciò che ad occhi normali era precluso. Che la terra era in realtà popolata da DUE specie, di cui una decisamente non umana.
- Che si mescolavano ai normali umani anche se questi non erano in grado di riconoscerli.
- L’altro aspetto angosciante era la continua presenza di messaggi subliminali, ovunque. In giornali, cartelloni pubblicitari, televisione. Tutti orientati al mantenimento dello status quo.
- Obbedisci
- Non discutete l’autorità
- Applicato alla platea il risultato sarebbe qualcosa di simile...
- Il momento più imbarazzante della mia giornata è quando incontro un vecchio amico e mi chiede: “Brando, che lavoro fai?”. Gli altri alzano gli occhi al cielo o si dileguano… è lunga da spiegare, e non è affatto chiara. per cui sono andato a cercare qualche definizione ma non sono rimasto particolarmente soddisfatto.
- Anche sul webster… non c’entra granchè con quello che effettivamente faccio.
- La migliore definizione l’ho trovata in un bar. Un’illuminazione.
- E questo ci dà qualche risposta importante. Abbiamo del potere. Suscitiamo emozioni. magari non come Belen Rodriguez, ma meglio che niente!
- ma anche nella definizione di “Computer Program” c’è qualcosa di interessante. C’è l’idea di “ISTRUZIONI” in una forma che può essere COMPRESA.
- Non è tutto qui… perdonatemi. ma questa è la definizione di cui avevo bisogno ora :-)
- Questo, molto schematicamente dovrebbe essere il nostro lavoro. Trasformare il budget a nostra disposizione in valore per l’utente. Semplice ed encomiabile.
- Qualcuno è addirittura riuscito a fare soldi facendo questa cosa.
- Tuttavia per un sacco di motivi si cercano strade strane
- Che viste in maniera più realistica danno risultati sconfortanti.
- Possiamo parlare di successo o di fallimento?
- Se aggiungiamo una variabile… e la collochiamo al punto giusto, allora è un successo.
- Almeno per ora.
- Possiamo vedere altre variazioni sul tema… questa piuttosto diffusa.
- ma ovviamente non può essere messa in discussione.
- Eppure c’è qualcuno che sta facendo qualcosa di molto meglio. C’è chi sperimenta continuos deployment, chi fa scheduling aggressivo, chi parte con un progetto piccolo che si autofinanzia con il valore che genera immediatamente.
- Tutte queste cose migliorano il nostro modo di fare software, permettendoci di fare software più solido, in maniera più efficiente consistente e veloce. Ma il problema di fondo rimane sostanzialmente aperto.
- Qual è la cosa giusta da fare?
- Parco avventura: uno di quei posti tra gli alberi con corde e passaggi sospesi dove anche un ingegnere sovrappeso può sentirsi vagamente “Into theWild” una volta all’anno.
- … e di smaltire qualche caloria. :-/
- Ma la parte interessante è il fatto che ho portato con me mia figlia (o è stato il contrario...) che aveva esattamente l’età (6 anni) e la statura minima per accedere alla struttura. Ovviamente l’istruttore ci ha spiegato ed io le sono stato vicino per aiutarla...
- Ma sostanzialmente era necessario che imparasse a fare da sola. Spostando prima un moschettone e poi l’altro.
- Fino ad arrivare a compiere passaggi anche piuttosto difficili. Ora, perché vi mostro queste cose?
- Perché segretamente voglio che chiamiate il telefono azzurro? ...siamo di fronte ad un consulente che per dimostrare le sue teorie non esita ad usare la propria progenie come cavia. No, è perché in questa situazione ho visto qualcos’altro.
- Una regola semplice, ripetuta ad ogni passaggio. In maniera consistente.
- Una regola semplice, ripetuta ad ogni passaggio. In maniera consistente.
- Una regola semplice, ripetuta ad ogni passaggio. In maniera consistente.
- Una regola semplice, ripetuta ad ogni passaggio. In maniera consistente.
- Una regola semplice, ripetuta ad ogni passaggio. In maniera consistente.
- Vi ricorda qualcosa? A me ricorda molto il TDD. Ed il TDD ha avuto su me esattamente lo stesso effetto: mi ha permesso di muovermi “in sicurezza” anche quando ero goffo, quando ho sperimentato con linguaggi diversi da Java. Trovando il mio ritmo limitando i rischi.
- Vi ricorda qualcosa? A me ricorda molto il TDD. Ed il TDD ha avuto su me esattamente lo stesso effetto: mi ha permesso di muovermi “in sicurezza” anche quando ero goffo, quando ho sperimentato con linguaggi diversi da Java. Trovando il mio ritmo limitando i rischi.
- Vi ricorda qualcosa? A me ricorda molto il TDD. Ed il TDD ha avuto su me esattamente lo stesso effetto: mi ha permesso di muovermi “in sicurezza” anche quando ero goffo, quando ho sperimentato con linguaggi diversi da Java. Trovando il mio ritmo limitando i rischi.
- Ma il punto dell’esempio non è che cosa possa riuscire a fare una bambina di 6 anni. Ma quello che può fare un responsabile dell’ufficio vendite di un’azienda di serramenti in alluminio di Treviso che ci vediamo penzolare sopra la testa a 20 metri d’altezza lasciando un urlo disumano.
- … Credendosi un novello tarzan!!!
- Questi strumenti non servono solo per fare le veccie cose stando tranquilli. Servono a sperimentare, ad avere la tranquillità di tentare nuove strade.
- Vogliamo spingerci lontano.
- Anche chi si professa agile, in un modo o nell’altro deve fare i conti con il fatto che la maggior parte di queste cose sono decise prima di cominciare. - “Siamo un team Java” “Si lavora qui, lo so che stiamo un po’ stretti ma…” “Abbiamo già la licenza di SourceSafe” … senza renderci conto di quanto questo inibisca la nostra capacità di produrre qualcosa di sensato.
- Anche chi si professa agile, in un modo o nell’altro deve fare i conti con il fatto che la maggior parte di queste cose sono decise prima di cominciare. - “Siamo un team Java” “Si lavora qui, lo so che stiamo un po’ stretti ma…” “Abbiamo già la licenza di SourceSafe” … senza renderci conto di quanto questo inibisca la nostra capacità di produrre qualcosa di sensato.
- Anche chi si professa agile, in un modo o nell’altro deve fare i conti con il fatto che la maggior parte di queste cose sono decise prima di cominciare. - “Siamo un team Java” “Si lavora qui, lo so che stiamo un po’ stretti ma…” “Abbiamo già la licenza di SourceSafe” … senza renderci conto di quanto questo inibisca la nostra capacità di produrre qualcosa di sensato.
- Anche chi si professa agile, in un modo o nell’altro deve fare i conti con il fatto che la maggior parte di queste cose sono decise prima di cominciare. - “Siamo un team Java” “Si lavora qui, lo so che stiamo un po’ stretti ma…” “Abbiamo già la licenza di SourceSafe” … senza renderci conto di quanto questo inibisca la nostra capacità di produrre qualcosa di sensato.
- Anche chi si professa agile, in un modo o nell’altro deve fare i conti con il fatto che la maggior parte di queste cose sono decise prima di cominciare. - “Siamo un team Java” “Si lavora qui, lo so che stiamo un po’ stretti ma…” “Abbiamo già la licenza di SourceSafe” … senza renderci conto di quanto questo inibisca la nostra capacità di produrre qualcosa di sensato.
- Anche chi si professa agile, in un modo o nell’altro deve fare i conti con il fatto che la maggior parte di queste cose sono decise prima di cominciare. - “Siamo un team Java” “Si lavora qui, lo so che stiamo un po’ stretti ma…” “Abbiamo già la licenza di SourceSafe” … senza renderci conto di quanto questo inibisca la nostra capacità di produrre qualcosa di sensato.
- Anche chi si professa agile, in un modo o nell’altro deve fare i conti con il fatto che la maggior parte di queste cose sono decise prima di cominciare. - “Siamo un team Java” “Si lavora qui, lo so che stiamo un po’ stretti ma…” “Abbiamo già la licenza di SourceSafe” … senza renderci conto di quanto questo inibisca la nostra capacità di produrre qualcosa di sensato.
- Anche chi si professa agile, in un modo o nell’altro deve fare i conti con il fatto che la maggior parte di queste cose sono decise prima di cominciare. - “Siamo un team Java” “Si lavora qui, lo so che stiamo un po’ stretti ma…” “Abbiamo già la licenza di SourceSafe” … senza renderci conto di quanto questo inibisca la nostra capacità di produrre qualcosa di sensato.
- Ma i punti fermi di oggi si trasformeranno nei vincoli di domani. Una delle definizioni che trovo più interessanti parlando di architetture software associa l’architetto alla capacità di prendere decisioni difficilmente reversibili, o il cui costo di reversibilità è più alto di quelle normalmente prese dal programmatore. Però ci sono decisioni ancora più irreversibili, che sono prese altrove e che impattano in misura ancora maggiore le possibilità di successo del progetto. Chi assumo? Con che contratto? Con che stipendio?
- Ciononostante, ignoriamo la contraddizione ed obbediamo.
- Ma la peggior cosa decisa in anticipo è il codice legacy. Il colore non è casuale. Le strategie più diffuse per la gestione sono:
- Il codice legacy è stato scritto da un’intelligenza suprema. Tanto tempo fa. Forse è sempre esistito. La maggior parte degli sviluppatori non sa esattamente a cosa serva.
- Il codice è una Big Ball Of Mud ma dobbiamo comunque lavorarci - ovviamente per AGGIUNGERE features. Chi becca il task o la story sbagliata dorme in ufficio, ma poi trascinerà anche i colleghi...
- Chi tocca muore. Cerchiamo sistematicamente di NON passare dal legacy, anche a costo di contorsioni. Nel codice o nella pianificazione.
- Mummificazione. Wrappiamo il legacy con strati e strati di codice che non serve a nulla. Così, invece che spostare una piccola mummia dobbiamo gestire una piramide.
- Ma hanno deciso così...
- L’ultimo approccio è ancora più radicale. Buttiamo via tutto. ...ma abbiamo i test?
- L’ultimo approccio è ancora più radicale. Buttiamo via tutto. ...ma abbiamo i test?
- In quale curvatura dello spazio tempo sono i miei soldi nel frattempo? Qualcuno si è reso conto dei costi che queste cose hanno sul sistema Italia?
- In questo scenario, la percezione che hanno le aziende sia che investire nell’I.T. sia sbagliato. Difficile dire che hanno torto, perché questa è stata la loro esperienza. Il fatto è che non è vero. Le aziende che investono BENE nell’IT possono trarre ENORMI benefici.
- All’ultima QCon a Londra Martin Fowler ha citato il dialogo tipico con uno sviluppatore. “Ciao cosa combini?” “Sto lavorando ad un nuovo progetto” “Figo, di che si tratta” “Di una Web application in Java” “Ok, ma che deve fare?” “Si interfaccia a dei servizi web attraverso un ESB, più qualche widget AJAX nel frontend” “…” Se non ci concentriamo su “a che cosa serve” il nostro software è difficile che si possa fare qualcosa di buono.
- Dove sta la complessità? In larga parte è intrinseca nel dominio. Poi c’è la complessità della nostra applicazione che finisce per innestarsi sopra al dominio, aggiungendo complessità tecnologica, realizzativa, architetturale, etc.
- Se siamo stati bravi - ma solo se siamo stati bravi - la maggio parte della complessità è nascosta all’utente, che nel suo percorso di interazione con il nostro sistema ne vede solo una porzione. Dal punto di vista della UX (grazie a Gianluca Brugnoli che mi ha illuminato sull’argomento) questi sono Touch Points. Dal punto di vista dell’applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case però… alcune interazioni sono con il cassiere allo sportello, con il treno, etc.
- Se siamo stati bravi - ma solo se siamo stati bravi - la maggio parte della complessità è nascosta all’utente, che nel suo percorso di interazione con il nostro sistema ne vede solo una porzione. Dal punto di vista della UX (grazie a Gianluca Brugnoli che mi ha illuminato sull’argomento) questi sono Touch Points. Dal punto di vista dell’applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case però… alcune interazioni sono con il cassiere allo sportello, con il treno, etc.
- Se siamo stati bravi - ma solo se siamo stati bravi - la maggio parte della complessità è nascosta all’utente, che nel suo percorso di interazione con il nostro sistema ne vede solo una porzione. Dal punto di vista della UX (grazie a Gianluca Brugnoli che mi ha illuminato sull’argomento) questi sono Touch Points. Dal punto di vista dell’applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case però… alcune interazioni sono con il cassiere allo sportello, con il treno, etc.
- Se siamo stati bravi - ma solo se siamo stati bravi - la maggio parte della complessità è nascosta all’utente, che nel suo percorso di interazione con il nostro sistema ne vede solo una porzione. Dal punto di vista della UX (grazie a Gianluca Brugnoli che mi ha illuminato sull’argomento) questi sono Touch Points. Dal punto di vista dell’applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case però… alcune interazioni sono con il cassiere allo sportello, con il treno, etc.
- Se siamo stati bravi - ma solo se siamo stati bravi - la maggio parte della complessità è nascosta all’utente, che nel suo percorso di interazione con il nostro sistema ne vede solo una porzione. Dal punto di vista della UX (grazie a Gianluca Brugnoli che mi ha illuminato sull’argomento) questi sono Touch Points. Dal punto di vista dell’applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case però… alcune interazioni sono con il cassiere allo sportello, con il treno, etc.
- Se siamo stati bravi - ma solo se siamo stati bravi - la maggio parte della complessità è nascosta all’utente, che nel suo percorso di interazione con il nostro sistema ne vede solo una porzione. Dal punto di vista della UX (grazie a Gianluca Brugnoli che mi ha illuminato sull’argomento) questi sono Touch Points. Dal punto di vista dell’applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case però… alcune interazioni sono con il cassiere allo sportello, con il treno, etc.
- Ho un conto online che uso di rado. Ovviamente, ogni volta che devo usarlo sono dolori. Recupero la macchinetta diabolica che genera la one time password ed il documento della banca con le credenziali. la schermata mi dice inserire ID-qualcosa e la password. Il documento con le credenziali contiene ben 4 codici numerici di 8 cifre ciascuno chiamato ID-quacosaltro. Ovviamente li provo tutti. Nisba. Call center. Filiale (non nella mia città) per recuperare le nuove credenziali. Nisba. Call center. Scopro che id-qualcosa non è una cosa che è sul foglio ma è scritta nel retro del generatore di One Time Password in caratteri microscopici, proprio sotto la scritta “Made in China”… geniale.
- L’applicazione però funziona perfettamente. Chi si fa carico di questa cosa? Come è possibile coordinarsi per evitare che “eh, ma questo è un problema del customer-care”. Non ci interessa di chi è la colpa. Ci interessa che non succeda. La palla non deve toccare terra. Mai.
- Tra i vari processi Agili, Scrum è quello che si sbilancia di più sul problema. Dicendo che ci deve essere una sola persona responsabile del prodotto. E che il team deve avere tutte le competenze necessarie. Dentro il team, non come composizione di pezzi sparsi.
- … ma è un problema tutt’altro che banale, perché si tende a vedere questi ruoli come specialisti, ed ognuno ha le sue esigenze, di contratto, di calendario, di pianificazione, di spazi di lavoro. facile a dirsi.
- Spesso non abbiamo certe competenze, spesso non sappiamo nemmeno di non averle :-( Abbiamo bisogno di un Web Designer o di qualcuno che all’occorrenza lo sappia fare? Gli specialisti sono un GROSSO problema. Possiamo fare lavorare tutti nello stesso posto? E’ in superficie o sottoterra? Ci sono gli spazi e gli strumenti? Entra la luce? Quando sono disponibili le risorse? Chi le paga? Come? Quanto tempo ci mette l’amministrazione a preparare un contratto? E a rinnovarlo? E a pagare?
- Ma in genere non entriamo nel merito di queste questioni...
- Risultato abbastanza interessante. Credo che sia la meno capita. Il succo è “se riesci a definire una metafora del sistema allora lo hai capito in maniera sufficientemente profonda” ma anche “la metafora ti permette di capirlo più velocemente”. Che sia causa o effetto o entrambi il succo è “dovete capire bene che aggeggio è quello che state sviluppando, altrimenti state solo ammucchiando codice”.
- Il software “that matters” implica complessità ed apprendimento. Proviamo a vederla in un altro modo.
- Se è un processo di apprendimento, vorrei che fosse il più efficiente possibile. La prendo alla lean.
- L’apprendimento non è un processo lineare. In prima si imparano i numeri. Uno alla settimana. Ottimo, per non comprare il motorino a mia figlia quando avrà 14 anni mi basterà dirle “solo se mi dici quanto costa!”. In realtà non funziona così e probabilmente non c’è nemmeno bisogno di andare così lentamente. ma andare lentamente è NECESSARIO perché i bambini imparino correttamente. Qualcuno saprà contare fino a 20 o 50 già alla 4a settimana. Ma imporre quel ritmo sarebbe controproducente. E’ necessario lasciare lo spazio perché il bambino faccia quello “scatto” da solo. Altrimenti non lo farà mai e cercherà di imparare tutto a memoria...
- Idem per le tabelline. Io ho giocato con questo quadrato - che trovavo nell’ultima pagina del quaderno Pigna - fino allo sfinimento. Scoprendo che il 5 finisce sempre in 5 0 5 0 c’è una simmetria sulla diagonale la colonna del 9 è reversibile la diagonale dei quadrati ha tutte cifre distanti tra loro la progressione dei numeri dispari se mi sposto in diagonale da un quadrato, ho sempre un numero inferiore di 1 (es 49 --> 48) Per avere questo livello di conoscenza, giocare con la tabellina era fondamentale.
- Ok, siccome di apprendimento si tratta, sono andato a spulciare un po’ di materiale che in un modo o nell’altro mi è capitato sotto mano.
- La Finlandia è sistematicamente intesta alle graduatorie del PISA. Ha poche risorse naturali, ma produce conoscenza e tecnologia. Il loro sistema scolastico ha caratteristiche interessanti.
- Una recente ricerca negli stati uniti aveva il compito di individuare i metodi utilizzati dai migliori docenti. Si è scelto di studiare quelli che tiravano fuori il meglio, sia pure partendo dalle condizioni peggiori. Non è stato trovato nulla - no silver bullet - tranne il fatto che a questi insegnanti piacesse fare il loro lavoro e cercassero di farlo bene. O sempre meglio.
- Le scuole basate sul metodo Montessori hanno una filosofia particolare: usano dei grandi numeri di legno, per rendere i concetti concreti, permettono ai bambini di sperimentare le cose con grande libertà (acquisendo sicurezza). Sono i bambini a scegliere cosa imparare, e solo allora il docente interviene dando le informazioni necessarie.
- Questo esperimento invece prendeva in esame gli studenti di un college americano. 3 gruppi di 30 studenti, ad inizio anno, selezionati come “i più promettenti” per fare parte di classi di elite,con obiettivi di eccellenza. Assegnati a 3 docenti selezionati con lo stesso criterio. Obiettivi ampiamente raggiunti.
- A fine anno è stato detto agli studenti che in realtà erano stati scelti a caso. Anche i docenti erano stati scelti a caso. La motivazione ha fatto il resto.
- Quanta roba dobbiamo imparare per fare bene il nostro lavoro, quanta serve veramente? quanta serve ora? Quanta posso permettermi di ignorare? Quanta di sapere solo superficialmente?
- Le notti insonni con il libro aperto non sono più un’alternativa sostenibile. ma alcuni di noi sono parte di un gigantesco fenomeno di apprendimento collettivo, una comunità che impara simultaneamente e si coordina su twitter, una cosa io, una cosa tu. Non è una cosa da poco. Probabilmente è la prima volta nella storia che succede qualcosa del genere...
- ma per quanto possiamo essere bravi ed organizzati ad assorbire le informazioni, per molte ci scontriamo con la capacità dell’organizzazione di fornircele. In questo caso ho “stiracchiato” le mappe concettuali di DDD mettendo l’enfasi sulla “larghezza di banda” organizzativa. Quanta informazione può passare effettivamente tra due contesti diversi? Scrum dice di stare tutti assieme, ma non sempre si può e non possiamo fare finta che sia tutto perfetto.
- Purtroppo, anche mettendo tutte le persone nello stesso posto non è detto che si parlino. E anche se si parlano non è detto che si capiscano. Ed anche se si capiscono non è detto che si ricordino che cosa si sono dette. Eliminare il deliverable tradizionale come forma di comunicazione è una gioia, ma cosa usiamo per comunicare? una semplice conversazione? Siamo capaci di argomentare senza discutere? Di gestire i conflitti e di organizzare il consenso? E di farlo in tempi rapidi? Come si usa una lavagna? (la domanda è meno scema di quanto sembri). la sala riunioni è accessibile? Utile? Silenziosa? A volte dobbiamo inventarci gli strumenti di ragionamento.
- Alzata di mano: è più importante fare o imparare? ...cambiamo il panorama e ripetiamo la domanda...
- Nessuno si offenda (tra l’altro sono pregiati esemplari di cinta senese) ma se trattiamo il team in questo modo, buttando i requisiti … non otterremo granché.
- Sempre ammesso che si possa fare qualcosa di diverso. Ovviamente :-)
- Cosa ci manca perché si possa verificare un evento di questo genere?
- Cosa ci manca perché si possa verificare un evento di questo genere?
- Cosa ci manca perché si possa verificare un evento di questo genere?
- Cosa ci manca perché si possa verificare un evento di questo genere?