Ho usato "Training Tuesdays", sebbene tu potessi spostarlo a un giovedì e mantenere il titolo "TT", come un'opportunità per il team di condividere ciò che sanno. Ho preso in prestito alcuni kata da Code Kata e li ho elaborati come una squadra, forniscono alcuni piccoli scenari di programmazione che consentono a tutti di avere una possibilità di pensare a un problema quindi proporre una soluzione; una persona potrebbe suggerire a LINQ un altro ciclo for ... quindi hai una buona base per una discussione sui vari vantaggi di ciascun approccio. Non è "mission critical" quindi la pressione è disattivata ed è ok qualunque cosa tu suggerisca. Quindi, se hai una buona conoscenza del database, potresti vedere il problema sotto una luce particolare, spiegando che per qualcuno che è un buon programmatore OO significa che entrambi devi capire l'altra lingua in una certa misura.
Ho utilizzato anche l'eccellente Estate di NHibernate / Autunno di Agile sugli screencast di Steve Bohlen nelle sessioni per comprendere gli ORM e i processi Agile, l'Autumn of Agile mostra i vantaggi dell'approccio agile su cascata ed è stato bello avere visualizzato per noi.
Abbiamo anche presentato mini-presentazioni su argomenti su cui ognuno di noi era strong; quindi c'era un ragazzo strong di UX e l'accessibilità nel team e ha mostrato ciò che ha coinvolto e lavorato attraverso alcune forme che avevamo e ha evidenziato aspetti positivi e negativi.
Quindi, se qualcuno ha interesse a imparare qualcosa di nuovo, può esserci una buona occasione, per esempio scoprire su javascript patterns o unit testing javascript in modo da poterti presentare al team su come possono essere adottati. Attualmente sto spendendo un po 'di tempo libero per imparare il test SQL di Red Gate e in una settimana avrò una sessione di un'ora con il team in cui spero di mostrare loro perché dovremmo iniziare a scrivere test unitari nel database. Quello che ho trovato è che quando devi insegnare qualcosa alza il tuo gioco; Insegno le arti marziali e quando ho imparato una tecnica per un voto ho pensato di capirlo, ma quando ho dovuto insegnarlo a qualcuno ho dovuto vederlo dal loro punto di vista e pensare ai modi in cui potevano capirlo. Lo stesso è stato vero anche quando ho istruito gli sviluppatori; fanno domande diverse rispetto a quello che ho fatto quando ho appreso quella funzione, quindi ho dovuto capirlo davvero.
La programmazione delle coppie potrebbe anche aiutare qui; col passare del tempo tutti lavorano con tutti gli altri su qualcosa, sia che si tratti del tuo core business o di un divertente progetto del venerdì pomeriggio o anche solo di "hey lascia dare un'occhiata a quella cosa pazza di cui tutti parlano", quando abbiamo fatto questo non solo è il codice che scriviamo meglio (non tendi a imbrogliare quando sai che qualcuno sta guardando) ma hai discussioni su come fare xy o z (che è quello che è successo con il codice kata nella squadra, solo qui è solo 2 di voi). Quindi, se provi ad accoppiare gli anziani con i junior, i ragazzi possono lavorare con qualcuno che li aiuti a guidarli e impedire loro di commettere errori. Gli anziani fanno chiedere a qualcuno "perché, perché perché" e questo li obbliga a spiegare / insegnare e quindi a mettere in discussione la loro comprensione e ad approfondire ciò che sanno, o a raccogliere nuove idee da persone che non sono già impostate nei loro modi (I ' Mi sono reso colpevole di questo, pensavo di sapere tutto ciò di cui avevo bisogno e ho smesso di imparare, sono arrivati nuovi approcci ed ero indietro nel tempo)