Come ottenere nuovi membri del team aggiornati con il progetto? [chiuso]

Venendo da qualcuno che è dovuto venire a conoscenza di molti diversi codebase nella mia carriera, ecco cosa suggerirei:

1. Trascorri un po 'di tempo (forse un giorno o due) con attività legate all'utilizzo del prodotto in modo che possano familiarizzare con ciò che fa il prodotto. Questo potrebbe essere la verifica di bug o l'esecuzione di piani di test di QA o l'addestramento degli utenti.
2. Lavora su piccoli bug localizzati. Ciò consente all'ingegnere di familiarizzare con la modalità di creazione e amp; eseguire il debug dell'applicazione senza dover affrontare l'apprendimento di molte architetture.
3. Idealmente, scrivi una piccola nuova funzionalità che è localizzata. Ciò consente loro di scrivere una porzione di codice e man mano che la scrivono acquisiranno familiarità con i bit di codice circostanti con cui il nuovo codice deve funzionare.

Da lì, espandi l'ambito e la complessità dei compiti nel tempo a seconda del livello di esperienza e dell'idoneità del tecnico. Ciò consentirà allo sviluppatore di espandere la propria conoscenza del codebase in modo naturale.

Eviterei di leggere solo le attività (documentazione o codice). La lettura della documentazione diventa davvero noiosa molto velocemente e la lettura di un codice casuale non è utile poiché non avranno alcun contesto con cui lavorare. È già abbastanza difficile leggere il codice per le revisioni del codice quando conosci già il prodotto & codebase. Non riesco a vedere nulla di utile derivante dall'avere un ingegnere nuovo di zecca solo leggendo il codice.

La mia sensazione è che la tolleranza della maggior parte delle persone per la lettura della documentazione sia piuttosto bassa (buono per un giorno o due, ma oltre a questo probabilmente proveranno a fare qualcosa di un po 'più pratico).

Non penso che tu possa davvero comprendere il codice di un'applicazione senza una ragionevole comprensione dell'applicazione stessa. Il software ha presumibilmente molte funzionalità che potrebbero essere "giocattolo" con un utente; dovranno essere in grado di testarlo alla fine, quindi mi aspetto che sia abbastanza importante sapere come installarlo, configurarlo ed eseguire attività comuni con esso

Personalmente trovo che una panoramica dell'architettura di alto livello sia di solito abbastanza utile per avere un'idea di base su come funzionano le cose - Forse assegnare un'ora o due del tempo di un ingegnere senior (o te stesso se necessario?) nella loro prima settimana semplicemente per passare attraverso i dadi di base dell'applicazione principale. per esempio. comprendere tutti i sottosistemi e come le cose sono legate insieme, sapendo quali bit sono gestiti da software / librerie di terze parti e quali bit devono essere mantenuti internamente. (A meno che la tua organizzazione non disponga di documentazione aggiornata di qualità veramente eccezionale, immagino che non ci sarà modo di afferrare quel genere di cose senza che qualcuno le spieghi direttamente usando una lavagna: - ))

Per dare loro qualcosa di "pratico", le attività di manutenzione / inseguimento dei bug potrebbero essere un buon modo per metterli in moto per un po '(un paio di settimane / mesi?) - saranno in situazioni in cui le aree di funzionalità devono essere capite, testate e debuggate; aiutando a sviluppare la conoscenza del codice, i requisiti, gli strumenti utilizzati dall'azienda, i processi di sviluppo e il / i prodotto / i nel suo insieme, sperando che non sia necessario assorbire troppo tempo dal resto del team di sviluppo

Come lead, trascorro almeno 2 giorni con nuovi sviluppatori. Ho scoperto che sviluppare una relazione in cui ci si sente a proprio agio nell'inevitabile domanda "come vanno i tuoi progressi?" è un dovere. C'è paura in ogni nuova comunità di adattarsi ... nascondiamo gli errori, agiamo in modo perfetto, rendiamo le cose migliori di loro, riduciamo le difficoltà. Un manager che trascorre 2 giorni con qualcuno gli farà sapere che non è ciò di cui tratta la sua cultura e consente loro di dare l'esempio. I nuovi programmatori hanno bisogno di una lezione di storia su da dove vieni e quanto sei lontano. I documenti non rendono giustizia al compito.

Ho lavorato solo nell'industria per 10 mesi (sul posizionamento) ma ho trovato che il seguito mi ha aiutato:

• Collaborare con altri sviluppatori e osservare come affrontano i problemi.
• Test del software aiutato, avrei bisogno di testare la funzione x, il che significa che ho letto la documentazione sulla funzione x. L'ho fatto molto, mi ha aiutato.

Entrambi mi hanno aiutato molto. Buona fortuna.

Vorrei passare dal livello più alto al più basso.

Demo l'app il prima possibile

Una delle cose più importanti è che lo sviluppatore ha un'idea su cosa lavoreranno. Durante la demo, indica alcune delle cose che sono state sviluppate recentemente e la direzione in cui sta andando l'app.

Spiega l'architettura di alto livello

Anche questo è molto importante. Permetti al nuovo dev di ascoltare e fare domande. Fai questo come un esercizio di gruppo con gli altri sviluppatori, che si spera suonino e ti aiutino. Questo permetterà al nuovo sviluppatore di sapere che è OK parlare apertamente e onestamente.

Prepara un ottimo documento on-board

Avere un grande documento di bordo non aiuta solo i nuovi sviluppatori, ma anche quelli vecchi. Può contenere aspettative, link utili e informazioni sulla configurazione dell'ambiente. (Non posso dirvi quante volte ho usato il nostro on-boarding per impostare il mio ambiente quando ho un nuovo computer ...) Questo dovrebbe essere ben strutturato e al punto e non indugiare e non essere una discarica per ogni piccolo dettaglio

Incoraggiatelo a porre domande (ed essere disponibile a rispondere)

Con le risposte, guidali, ma non dirgli cosa fare. Fornisci loro suggerimenti ma consenti loro di capirlo finalmente.

Aiuta gli altri membri del team a dare il benvenuto al nuovo arrivato

Ci sono due lati della medaglia quando qualcuno si unisce a una squadra. Il team deve avere gli strumenti per accogliere anche il nuovo sviluppatore.

Lascia che raccolgano una piccola attività o due

Consenti loro di aggiungere qualcosa di nuovo e visibile al progetto che è in grado di dimostrarlo. Quando viene demoato, chiama chi l'ha fatto e che lavoro hanno fatto. Questo può davvero aumentare l'autostima. Più velocemente sentono di aggiungere valore, più velocemente sentono di far parte della squadra. Più velocemente si sentiranno autorizzati a fare il meglio che possono.

Incoraggiali a svolgere compiti più difficili quando si sentono sempre più a proprio agio

I buoni candidati lo faranno naturalmente.

Un flusso di "orientamento" che ho passato (e trovato utile) era qualcosa sulla falsariga di:

1. Una breve presentazione che fornisce al "Big Picture" quali sono i componenti, come si inseriscono e l'architettura generale.
2. Una panoramica del codice, introduzione alle funzioni che gestiscono la logica principale per i componenti a me assegnati. Coprendo alcune cose relative alle convenzioni di codifica e stile.
3. Sono stati assegnati un sacco di problemi aperti e bug a bassa priorità (che erano in gran parte localizzati nel componente a me assegnato e abbastanza semplici).
4. Ci si aspettava che eseguissi il debug dell'applicazione e chiedessi aiuto con cose che non riuscivo a decifrare.
5. Dopo aver effettuato la correzione, sono stato illustrato il processo (revisione del codice, test del livello di sviluppo ecc.) del rilascio all'integrazione.
6. Ripeti per le restanti attività / bug allocati.

Sento che questo approccio (e le sue variazioni) sarà utile perché:

• Questo è stato un lavoro più pratico e relativamente indipendente (costante assenza di mani, ecc.). Quindi, fornisce abbastanza spazio / tempo affinché la nuova persona si abitui al codice e al modo in cui le cose sono fatte nel team.
• È anche vantaggioso per il team nel suo complesso poiché è possibile risolvere un paio di attività / bug a bassa priorità. La persona che aiuta le nuove persone ha anche più tempo per occuparsi dei compiti loro assegnati poiché non è richiesto un costante hand-holding e il tempo può essere pianificato in modo specifico per affrontare i problemi / problemi che la nuova persona potrebbe affrontare.

Le assunzioni iniziali necessitano di un compito piccolo, ma non troppo piccolo e ben definito su cui lavorare. In questo modo possono iniziare a farsi un'idea di come il codice è strutturato cercando di capire come realizzare il loro compito. Nel processo verranno visualizzate le domande e a quel punto sarà possibile indirizzarle alla documentazione o ad altre risorse che possono utilizzare per aiutarli a internalizzare il codice base. Aiuta anche se il tuo ciclo di sviluppo, impegno, dispiegamento è breve e possono vedere i frutti del loro lavoro in azione il più rapidamente possibile.

Ecco come vado

1. Fornisci loro alcune attività correlate al progetto (ad es Il progetto è un'applicazione di database che chiede loro di creare solo un applicazione per connettersi con il database ed eseguire alcune semplici operazione.)
2. Quando trovi che hanno capito l'idea di lavorare, dai loro una demo del Progetto
3. Chiedi loro di leggere la documentazione.
4. Rendili familiari con gli stili e gli standard di codifica
5. Successivamente esegui alcuni esercizi di debug (per conoscere il flusso del progetto).
6. Chiedi loro di correggere un punto che hai già corretto (solo per scoprire la loro logica con esso).
7. Infine rendili parte del progetto.

Ricorda: non importa quanto ci provi, finché ea meno che il candidato non comprenda completamente il progetto, non sarai in grado di far funzionare il lavoro con la massima efficienza.

Numero uno: in primo luogo, impara come utilizzare il software per scoprire quali problemi risolve dal punto di vista dell'utente. Se non ha un'interfaccia utente (ad es. È un servizio di backend o qualcosa del genere), permetta loro di utilizzare qualsiasi interfaccia disponibile per consumarla. Ottenere una nuova visione del software da parte degli utenti è sempre una buona idea e potrebbe aiutare il nuovo dipendente a vedere cose che non è possibile, a causa del fatto che sei già incorporato nel progetto.

Dopo questo, un buon primo progetto potrebbe essere qualcosa come un add-on o un nuovo modulo da aggiungere al software, riducendo al minimo la quantità di conoscenza necessaria per la base di codice esistente. Scrivere qualcosa di nuovo sarà sempre più facile che eseguire una correzione di bug, che potrebbe richiedere molte modifiche su molti file sorgente. A mio avviso, dare a un nuovo dipendente un compito di correzione dei bug probabilmente spegne la tua azienda.

Il tuo schema per familiarizzare con il nuovo progetto sembra ragionevole. Ma tieni presente che avranno molto da imparare all'inizio. Questa è di solito una situazione travolgente. Dovrai essere paziente e rispondere ripetutamente alle stesse domande. Questo è normale, i nuovi sviluppatori devono imparare molto, non sottovalutarlo. Se ti arrabbi con queste ripetute domande rischierai che non chiederanno e cercheranno di scoprire le cose da sole che forse sono molto lente al massimo ma spesso impossibili. Inoltre dovranno imparare il gergo. La maggior parte dei progetti di team sviluppa la propria lingua. Quando spieghi coscientemente cerca di evitare il gergo. Spiega questa roba come se lo spiegassi a tua madre. Ancora una volta, sii paziente.

Inoltre, potresti provare a integrarli con gli altri già presenti nel team provando alcune attività in stile centro di valutazione, ad es. costruire un ponte in 45 minuti da 4 fogli di carta che supportano una tazza di caffè. Usiamo questa tecnica in un corso pratico di ingegneria del software per ottenere un gruppo di 8 studenti per rompere il ghiaccio prima di lavorare su un singolo progetto per 3 settimane. Aiuta ad accelerare le fasi di formazione del team.

1) Fornisci loro una spiegazione delle regole e delle linee guida del codice. Fornisci anche una spiegazione generale del funzionamento della tua applicazione e della struttura generale del codice.

2) Trova alcuni piccoli bug o progetti che sono ampiamente indipendenti da altri codici. Spiega cosa è necessario fare, dove si trova nel codice e controllalo regolarmente.

3) Inizia lentamente a dare progetti sempre più grandi controllandoli sempre meno.

4) Sedetevi accanto a loro di tanto in tanto. Puoi imparare molto guardando semplicemente come qualcun altro affronta un problema. Piccole cose come "oh, puoi cercare le funzioni nel tuo codice presagendo ctrl-." sono molto utili.

Ora, ho trovato che ci sono due estremi :

• Qualcuno che fa una domanda ogni cinque minuti. "Che cosa fa questo Path.Join?". Dovrebbero prima Google per una risposta e venire da te solo quando non riescono a trovare una risposta.

• E l'altro estremo, qualcuno che lavora per mezza giornata senza fare una sola domanda. Dovrebbero sentirsi come se fosse una buona cosa fare domande. Voglio solo che provino prima loro stessi.

Queste erano la mia formula e sono state usate con molti nuovi arrivati - questi passaggi si sono rivelati estremamente efficaci.

a) A tutti i nuovi sviluppatori verrà fornita un'introduzione sui requisiti del progetto e sui processi di sviluppo per 2 giorni.

b) Assegnazione di 3 settimane di attività di scrittura dei test di Junit per il codice che non ha copertura sufficiente.

c) Al termine di 3, assegna le piccole attività

d) Assegna compiti complessi e fatto.

Penso che assegni solo alcuni piccoli compiti, chiedi loro di scrivere alcuni test unitari, di fare in modo che il loro debug non registri. Niente di troppo grande o impegnativo, ma abbastanza da averli in piedi.

Dovresti anche assegnare uno sviluppatore senior, preferibilmente per ogni nuovo sviluppatore che potrebbe aiutare a guidare il candidato.

E sì, falli documentare ciò che stanno imparando sul sistema. Presumo qui che tu abbia una sorta di pagine wiki interne. In caso contrario, è assolutamente d'obbligo sia nel lungo che nel breve periodo - un modo sorprendentemente rapido per far salire le persone. Le pagine wiki non devono contenere solo la documentazione del codice, ma anche roba come le limitazioni note (questo è il software: D), soluzioni temporanee, metriche delle prestazioni di tempo / memoria, ecc.

Non spiegare solo le buone pratiche e gli standard di codifica, ma spiega come è strutturato il codice letto. Spiega cosa dovrebbe fare il software e come questo sia o sarà raggiunto.

Non capiranno finché non ci sarà un lavoro da fare, quindi suggerisco di dividere in due parti, una prima di iniziare il vero lavoro, e la seconda, dopo che hanno iniziato a lavorare. Guarderanno in qualche codice o documentazione e pensano " WTF!? ". Quando ciò accade, qualcuno li accompagnerà e spiegherà i dettagli minori.