Argomenti per le sessioni di formazione incrociata del team di sviluppo [chiuso]

• Panoramica dell'architettura - Questa sarebbe la vista di alto livello di ciò che è in ciascuna area e come vedere il mondo a vicenda da 30.000 piedi. Per alcuni questo potrebbe non essere interessante ma potrebbe essere utile per garantire che tutti abbiano una comprensione condivisa. Anche la terminologia potrebbe valere la pena di essere esaminata qui poiché alcuni termini potrebbero essere piuttosto sovraccarichi e vale la pena di essere risolti in una riunione per esaminare cosa si potrebbe intendere con alcuni termini. L'applicazione e il sistema sono termini molto generici, anche se altre parole potrebbero essere caricate se il produttore del software viene spesso usato per riferirsi a qualcosa del tipo "Oracle lo fa", sebbene Oracle produca più di un software diverso.

• Abilità comunicative / relazionali - Questo è abbastanza generale, ma potrebbe essere interessante se qualcuno vuole andare in questa tana del coniglio per esplorare come si relazionano le persone, comunicano e altre cose. Questo può diventare un po 'personale e non essere così tecnico come le persone tendono ad essere più sfumature di grigio che nero o bianco.

• Creazione di team - Questo è leggermente diverso in quanto l'idea è che potresti desiderare che le persone si conoscano piuttosto che discutere sul miglioramento delle abilità specifiche di qualcuno. Questo porta la sfida di inquadrare correttamente questo in modo che le rivalità siano produttive piuttosto che distruttive.

Queste sarebbero alcune idee che avrei visto che ci potrebbero essere dei dividendi diversi da queste riunioni, se configurate correttamente.

SE la tua applicazione richiede un uso intensivo del database, tutti gli sviluppatori potrebbero trarre vantaggio dal training di ottimizzazione delle prestazioni per sapere quali tipi di query possono causare problemi.

Se hai persone di supporto e persone di sviluppo, potrebbe essere utile per il supporto di preparare una presentazione sui tipi di bug che stanno riparando. A volte gli sviluppatori originali possono andare avanti felicemente facendo gli stessi errori perché non sono loro a correggere gli errori. Al contrario, lo sviluppo può preparare una presentazione per supportare come risolvere questa nuova caratteristica di fantasia che stiamo aggiungendo.

Quella sorta di appraoch può funzionare bene per diversi gruppi. Le persone del database potrebbero trarre vantaggio dall'apprendimento dei problemi che le persone con le applicazioni stanno avendo con il database, le persone che hanno segnalato di essere a conoscenza di un sacco di problemi a cui le persone delle applicazioni non pensano mai quando apportano modifiche all'applicazione.

Avere un team multipiattaforma ti consente di avere alcune sessioni specifiche per piattaforma che possono interessare gli sviluppatori che utilizzano le altre lingue / piattaforme. L'unica cosa da tenere a mente è che le sessioni sono orientate più verso le discussioni sull'utilità e sull'applicabilità piuttosto che verso il trasferimento della conoscenza (cioè le sessioni devono mostrare come funzionano le cose in generale anziché insegnare come utilizzare direttamente alcuni strumenti / tecnologie).

Ad esempio, per gli sviluppatori non- .NET, può essere molto interessante vedere LINQ in azione, poiché darà loro idee su come sarebbe bello avere qualcosa del genere (e magari chiedere loro di cercare librerie che fare cose simili nel loro ambiente).

Un altro esempio, un programmatore funzionante esperto può ispirare gli sviluppatori di C # a sfruttare al meglio i lambdas, dal momento che molti sviluppatori di C # hanno uno sfondo che non si concentra molto su quei modelli di implementazione.