Volevo solo scrivere codice iad 2011
Upcoming SlideShare
Loading in...5
×
 

Volevo solo scrivere codice iad 2011

on

  • 1,115 views

 

Statistics

Views

Total Views
1,115
Views on SlideShare
1,058
Embed Views
57

Actions

Likes
1
Downloads
13
Comments
0

9 Embeds 57

http://presentz.org 30
http://lanyrd.com 10
http://localhost 4
http://a0.twimg.com 3
http://iad11.presentz.org 3
http://dev.presentz.org 3
http://local.host 2
https://si0.twimg.com 1
http://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • \n
  • E questa è la mia azienda.\n
  • Ma il punto interessante di oggi, ci riporta alle origini, al punto da cui tutto è cominciato. \n
  • Stiamo parlando del 1983, questi erano i testi sacri. Gruppo Editoriale Jackson era per noi sinonimo di “sapere”.\n
  • E l’obiettivo per molti di noi era molto chiaro. Antesignani dell’”eat your own dogfood” volevamo programmare i nostri videogiochi.\n
  • Anche se l’esperienza utente decisamente non era delle migliori. Sigli schermi si andava decisamente in economia.\n
  • Dall’altra parte della barricata c’era il nemico: l’odiato Commodore 64. Ora le due tribù si sono riappacificate, ma allora era guerra.\n
  • Abbiamo scoperto anche come ha cominciato Caparezza!\n
  • Ma lo strumento forse più caratteristico di quegli anni era il famigerato registratore a cassette. Una sofferenza continua. Famiglie distrutte a causa del fratellino che spinge il pulsantino del counter. I destini del mondo dipendenti dall’azimut della testina.\n
  • Fondamentalmente si trattava di uno strumento di tortura. O almeno adesso lo classificheremmo come tale.\n
  • \n
  • Tuttavia, il ricordo di quel periodo continua a metterci di buon umore. Un po’ come un buon cappuccino di prima mattina.\n
  • O forse semplicemente... sono un po’ paraculo.\n
  • Bastava citarvi qualcosa dell’età felice e spensierata e sareste stati tutti contenti.\nGoldrake.\n
  • Ramaya\n
  • O addirittura Giovannona Coscialunga\n
  • Forse che basta citare i bei tempi andati e tutto sembra più bello. Spero di no, \n\n
  • Altrimenti un giorni ricorderemmo con lo stesso piacere anche questa roba.\n
  • No, credo veramente che ci sia qualcos’altro. Qualcosa che ci è sfuggito.\n
  • E a questo punto sarebbe dovuto partire il mio talk. Ero pronto a portarvi in giro per un tour fatto di battute salaci o di metafore ardite.\n
  • Ad esempio a dimostrarvi che gli unici a fare veramente Scrum in Italia sono Elio e Le Storie Tese: ad ogni iterazione un nuovo piccolo capolavoro.\n
  • O che la metafora migliore per gestire un project portfolio sia di gestire le risorse come se fossero Rock Band (blog post in arrivo, stay tuned)\n
  • Ogni band ha il suo stile e la sua formazione e soprattutto la sua identità. Non posso spostare le persone indefinitamente fra un gruppo e l’altro, nè aspettarmi che un batterista da solo produca tutta la canzone (sia pure in quattro volte il tempo pianificato per l’intero team)\n
  • \n
  • Ad un certo punto ho pensato che non era questo, quello che volevo dire. O meglio ho scoperto che forse c’era qualcosa di più importante che chiedeva di essere raccontato.\n
  • Mi sono fatto la mia bella retrospettiva sui progetti passati, cercando di capire che cosa li aveva caratterizzati in positivo e cosa in negativo. E mi sono reso conto che c’era un po’ di più di quello che avevo pianificato di raccontarvi.\n
  • Ad un certo punto non ho più capito se era più importante la luna o il dito. Del resto il dito è un oggetto riutilizzabile, posso indicare tante altre cose non solo la luna. O forse il dito non era il dito e la luna non era la luna. È imbarazzante quando le metafore si ribellano.\n
  • Ed ovviamente anche le letture del periodo fanno sentire la loro nefasta influenza. Poke the box, di Seth Godin è un istigazione a provare a fare cose che non abbiamo mai fatto prima. Per cui ...proviamo!\n
  • E quindi, ...questo non è il talk che avevo previsto. Ma qualcosa di completamente diverso.\n
  • E chiedo a tutti voi di partecipare ad un piccolo sondaggio.\n
  • Di quali progetti stiamo parlando?\n
  • Beh, in puro stile Loveline...\n
  • Mi interessa a partire dalla vostra prima volta :-)\n
  • \n
  • Non voglio darvi troppe indicazioni. Rischierebbe di influenzare più del lecito.\n
  • Fate il vostro gioco!\n
  • Ok, ho barato ancora una volta.\n
  • No vi ho detto nulla ...lasciando implicitamente credere che un progetto fosse associato al processo di costruzione del software.\n
  • ma in realtà le cose più importanti sono legate all’apprendimento. Alle cose che impariamo nel corso del processo.\n
  • E quindi, come se fossimo dallo psicanalista, torniamo con la mente ai progetti passati e focalizziamoci su un altro aspetto invece...\n
  • Riprendiamo la retrospettiva con un tema specifico. Riesaminiamo i progetti passati alla luce delle cose che abbiamo imparato.\n
  • \n
  • \n
  • Questo forse è stato il ricordo che ha fatto nascere tutto. Com’è possibile che qualcuno tragga il massimo dall’esperienza e per qualcun altro invece le stesse esperienze non insegnino assolutamente nulla?\n
  • Qualcuno impara e cresce. Qualcuno semplicemente invecchia.\n
  • Ma possiamo trovare un qualcosa che ci permetta di distinguere questi due aspetti? Alla fine stiamo facendo lo stesso lavoro.\n
  • E forse la differenza sta tutta qua. Nelle condizioni al contorno.\nIn quello che accadeva nei momenti in cui non eravamo chini sul codice.\n
  • I progetti più interessanti, avvenivano in trasferta ed il viaggio di ritorno con i colleghi era il momento in cui le esperienze finalmente si condividevano. Senza la pressione di un rilascio imminente. Il dubbio veniva messo sul tappeto, e l’alternativa presentata.\n\nA posteriori, quello era il momento in cui si imparava di più. O meglio l’apprendimento ha bisogno di entrambe le fasi. L’esperienza ed il momento in cui - collaborativamente - traiamo insegnamento da esso.\n
  • E come si arriva all’anzianità?\n
  • Questo è il nemico. Settimane e settimane identiche alle altre. Entri in ufficio e accendi l’IDE, spegni l’IDE e vai a casa. Quando ti rendi conto di aver imparato qualcosa?\n
  • Stra-consiglio questo video a chiunque voglia investire un po’ di tempo nell’esplorare possibilità alternative o voglia semplicemente rendersi conto del potenziale inespresso della propria azienda.\n
  • Tornando a quanto abbiamo appreso dai differenti progetti è stato abbastanza impressionante vedere quanto poco abbiamo tratto da progetti in cui per un motivo per l’altro non c’era l’entusiasmo iniziale.\n
  • Allo stesso modo, è stato altrettanto impressionante notare come sia bastata una frase in un momento chiave, o un episodio a trasformare l’entusiasmo in amarezza.\n
  • le classiche situazioni in cui “si è rotto qualcosa” le possibilità di recupero sono rare e faticose.\n
  • Ed ora ...i sassolini dalla scarpa. Retrospettiva universitaria. Nonostante una laurea specialistica “Ingegneria Informatica” ...buona parte di quanto ho studiato è sostanzialmente Waste.\n\nLa butto là: e se ripensassimo all’università in modalità “lean”?\n
  • Quali erano - in un luogo espressamente progettato per l’apprendimento - gli strumenti che avevamo in dotazione?\n
  • Beh sostanzialmente anche questi erano strumenti di tortura\n
  • E questi erano gli strumenti di tortura di quegli anni.\n
  • \n
  • Per quanto mi riguarda la correlazione tra quanto ho imparato e quanto mi sono divertito è molto forte. Diventa difficile dire cosa sia la causa e cosa sia l’effetto! ;-) (o forse lo sappiamo già)\n
  • Così come è stato abbastanza evidente notare che la correlazione vale anche in negativo. Ad un certo punto non si impara più e non ci si diverte più.\n
  • \n
  • Chi vorreste con voi in un progetto di questo genere? Difficile fare generalizzazioni, ma statisticamente i progetti migliori sono stati con persone del primo profilo...\n\nUn po’ di più al riguardo su... http://ziobrando.blogspot.com/2011/11/denial-won-help-you-learning.html\n
  • Ma il vero succo della questione è che le cose che impariamo non sono quelle che ci dicono di imparare. Tocca a noi.\n
  • E le cose che mi sono tornate utili nella mia professione vengono da un sacco di direzioni: essere un batterista, un padre ed un cuoco spesso è importante quanto essere un consulente.\n
  • E se ancora pensate che esista un piano formativo che vi permetta di crescere ...lasciate perdere.\n
  • Perché seguire la strada preconfezionata vi porterà esattamente dove sono tutti gli altri\n
  • Le cose da imparare interessanti non sono sul percorso. E prendendo strade alternative, andando dove gli altri non stanno guardando in questo momento.\n
  • Le cose da imparare interessanti non sono sul percorso. E prendendo strade alternative, andando dove gli altri non stanno guardando in questo momento.\n
  • Possiamo trovarci a vedere le cose da un’angolazione diversa.\n
  • Siete sicuri di fare le domande giuste? Siete sicuri che le persone che selezionate (sulla base di cosa?) abbiano la giusta attitudine ...lo ammetto è un po’ lunga. Blog post in arrivo.\n
  • Ma soprattutto, se avete la rara fortuna di trovare qualcuno che - più o meno consapevolmente - dissemina conoscenza, spunti, idee stimolanti.\n... Tenetevelo stretto. E se non potete tenervelo stretto, non lasciate che scompaia!\n
  • E a questo punto, forse avrei dovuto mettere una bibliografia, ma in questo caso più che i libri contano le persone. Alcune con cui ho condiviso progetti e anni di lavoro, altre con cui ho condiviso solo una birra o un tweet. Troppi per poterli ringraziare tutti senza la paura di avere dimenticato qualcuno. Grazie.\n
  • \n

Volevo solo scrivere codice iad 2011 Volevo solo scrivere codice iad 2011 Presentation Transcript

  • Volevo soloscrivere codice ziobrando
  • About meIn the IT field since ZX SpectrumGenerally in large scale projects (I mightbe biased)Freelance consultant: NotOnlyCodeTrainer (Freelance & Skills Matter + Zenika)Technical WriterBlogger: http://ziobrando.blogspot.comTwitter: ziobrandoMy e-mail:alberto.brandolini@gmail.co
  • @avanscopertawww.avanscoperta.itavanscoperta.wordpress.comalberto.brandolini@avanscoperta.it © Alberto Brandolini 2009
  • I testi sacri
  • Il nemico
  • .
  • Ciònonostante...
  • Ci mette di buon umore...
  • Forse sono un po’ paraculo
  • Non è solo il tempo...
  • ...
  • C’è qualcos’altro
  • Non è solo il tempo...Ero pronto a
  • L’unico vero Scrum Team in
  • Rock Band Planning
  • Song SongSong Song Song Song
  • ma...
  • ...mi sembrava di barare
  • Aguardarcibene...
  • Proviamo
  • Fase 2Quella in cui Brando parte per la tangente
  • Foglio 1 : A: Il nome del progetto (e qualche info) B: I fattori chiave per l’esito del progetto C: La loro origine avanscoper ta
  • Quali progetti? avanscoper ta
  • La vostra prima volta
  • Quali progetti? I più Il primo L’ultimo Il migliore Il peggiore ... a voi la scelta, sorprendetevi! avanscoper ta
  • Esempio? ImplementazioneProgetto Fattori chiave OrigineZXSpectrum Gioco ??? ??? Fantozzi avanscoper ta
  • Fate il vostro
  • Ovviamente ho barato...
  • Non è un processo di costruzione
  • È un processo di apprendimento
  • Riproviamoci
  • Foglio 2 : APPRENDIMENTO A: Il nome del progetto (e qualche info) B: Le cose più importanti che avete imparato C: La loro origine avanscoper ta
  • Fate il vostro
  • Conclusioni? per quanto mi riguarda
  • “Sono 20 anni che faccio questo lavoro e non ho mai visto un progetto che nonavesse questi problemi” Anonimo collega
  • AnzianitàEsperienza
  • effetto (passivo) Anziani del tempo che scorre)Esperien risultato dell’atto consapevole di
  • È la cornice!
  • Non avrei maipensato di dover
  • Non avrei maipensato di dover
  • Anzianità
  • Abitudine
  • http://www.youtube.com/watch?v=u6XAPnuFjJc
  • relativament e semplice da distruggere
  • quasiimpossibile da ricostruire
  • Utilità degli esami 14% 17% Utili Parzialmente utili 17% Inutili Nocivi 52% avanscoper ta
  • avanscoper ta
  • Il tavolo dell’equilibristaLA BACHECA L’esamedella giraffa- Lo spigolo fantasma lince Trafiggi- Il laboratorio Rotula segreto Il cammino penitenziale Le dispense La pancaIl coefficiente senza verbi paralizzante segreto La fessura nell’angolo divora- Il meno che sembra cieco floppy un punto
  • FUN
  • Nofun
  • Imparare incompagnia è meglio
  • Non ho la piùpallida idea di ChiarissimoChe ci vuole?
  • Imparare senzachiedere ilpermesso
  • Effective About me Scrum TDD Design Patterns Agile OOD Software Grails Development Agile Software Lean Software Development What? Kanban Development Skills Matter Domainziobrando.blogspot.com Driven Design Zenika Consultant Trainer Blogger Cook Where? Drummer Me Entrepreneur @ziobrando Husband avanscoperta Twitter Father PHPDay Technical Writer Java Day Speaker InfoQ NHDay Mokabyte Better WebTech DDD Exchange Software Agile Day
  • Il piano formativoIl ponte sullo stretto Babbo Natale La fatina dei denti
  • Il piano formativoIl ponte sullo stretto Babbo Natale La fatina dei denti
  • E se anche fosse...
  • Percorso?
  • Percorso? Posti
  • Percorso?Posti Posti
  • Prospettive
  • Cosa si chiede ad un colloquio?
  • Mentors
  • Bibliography oSocial Nework
  • E’ tutto, grazie! Domande?alberto.brandolini@avanscoperta.it @ziobrando