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
11. nel 1988
John
Carpenter
ci era già
arrivato...
12. nel 1988
John
Carpenter
ci era già
arrivato...
13.
14.
15.
16.
17.
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.
22.
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?
82. L’architettura del software
di occupa delle decisioni
difficilmente reversibili…
Ma le decisioni più
irreversibili hanno poco a
che vedere con
l’architettura
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
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?
...
113.
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
–
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.
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
131. Communication tools
Miglioramenti massivi sulle
forme di comunicazione e
condivisione
Convergere su una proposta è
un arte
Set di strumenti tipici
largamente insufficiente
148. Ringraziamenti
Provato ed affamato, il relatore ringrazia e
risponde alle domande del caso.
alberto.brandolini@avanscoperta.it
twitter: ziobrando
Notes de l'éditeur
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?