Come aggiornare i nuovi membri del team con il progetto? [chiuso]

Stiamo per assumere 1-2 nuovi ingegneri per il team del software (composto da 3 sviluppatori, 1 tester).

Quali sono i passaggi per integrarli nel team?

Le mie idee sono:

• leggi la documentazione (standard di codifica, documenti nelle metodologie di sviluppo che utilizziamo)
• convincili a leggere il codice esistente
• assegnare loro alcune semplici attività
• alla fine, renderli responsabili della parte di codice

cos'altro potremmo fare?

Il progetto è in un settore medico (sistema ad ultrasuoni) e dura già 5 anni. Abbiamo versioni annuali e stiamo per terminare una versione, quando vogliamo aggiungere 1-2 ingegneri.

Il progetto è in fase di manutenzione (refactoring del codice legacy, oltre ad aggiungere nuove funzionalità). Le cose sono praticamente in programma (più o meno).

Proveniente da qualcuno che ha dovuto accelerare molte basi di codice diverse nella mia carriera, ecco cosa suggerirei:

1. Trascorrere un breve periodo di tempo (forse un giorno o due) con attività correlate all'utilizzo del prodotto in modo che possano acquisire familiarità con le attività del prodotto. Ciò potrebbe essere la verifica di bug o l'esecuzione di piani di test QA o la formazione degli utenti.
2. Lavora su piccoli bug localizzati. Ciò consente all'ingegnere di familiarizzare con il modo in cui compilare ed eseguire il debug dell'applicazione senza dover imparare molto sull'architettura.
3. Idealmente, scrivi una piccola nuova funzionalità che è localizzata. Ciò consente loro di scrivere un pezzo di codice e man mano che lo scrivono acquisiranno familiarità con i bit di codice circostanti con cui il loro nuovo codice deve funzionare.

Da lì, ampliare l'ambito e la complessità delle assegnazioni nel tempo a seconda del livello di esperienza e dell'attitudine dell'ingegnere. Ciò consentirà allo sviluppatore di espandere naturalmente la propria conoscenza della base di codice.

Eviterei di leggere solo le attività (documentazione o codice). La lettura della documentazione diventa davvero noiosa molto velocemente e la lettura di codici casuali non è utile poiché non avranno alcun contesto con cui lavorare. È abbastanza difficile leggere il codice per le revisioni del codice quando si conosce già il prodotto e la base di codice. Non riesco a vedere qualcosa di utile che emerge dall'avere un ingegnere nuovo di zecca che legge solo il codice.

La mia sensazione è che la tolleranza della maggior parte delle persone per la lettura della documentazione sia piuttosto bassa (buona per un giorno o due, ma oltre a ciò probabilmente avranno il desiderio di fare qualcosa di più pratico).

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

Personalmente trovo che una panoramica di architettura di alto livello sia di solito molto utile per avere un'idea di base di come funzionano le cose - magari allocare un'ora o due del tempo di un ingegnere senior (o te stesso se necessario?) Nella loro prima settimana semplicemente per passare i dadi di base dell'applicazione principale. ad es. 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 gestiti internamente. (A meno che la tua organizzazione non abbia una documentazione aggiornata di qualità davvero eccezionale, immagino che non c'è modo che possano afferrare quel tipo di cose senza che qualcuno le spieghi direttamente usando una lavagna: - ))

Per quanto riguarda il dare loro qualcosa di "pratico", le attività di manutenzione / inseguimento di bug potrebbero essere un buon modo per farli accelerare per un po '(un paio di settimane / mesi?) - si troveranno in situazioni in cui specifiche aree di funzionalità devono essere compresi, testati e sottoposti a debug; aiutare a sviluppare la conoscenza del codice, i requisiti, gli strumenti utilizzati dall'azienda, i processi di sviluppo e il prodotto (i) nel suo insieme, sperando non sia necessario assorbire troppo tempo dal resto del team di sviluppo

Come lead, passo almeno 2 giorni con i nuovi sviluppatori. Ho scoperto che sviluppare una relazione in cui ci si sente a proprio agio nel porre l'inevitabile domanda "come vanno i tuoi progressi?" è un dovere. C'è paura in ogni nuova comunità in cui inserirsi ... nascondiamo errori, agiamo perfettamente, rendiamo le cose migliori di loro, diminuiamo le difficoltà. Un manager che trascorre 2 giorni con qualcuno farà loro sapere che non è la loro cultura e permette 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.

Lavoro nel settore industriale da 10 mesi (sul posizionamento) ma ho scoperto che mi ha aiutato:

• Collaborare con altri sviluppatori e osservare come affrontano i problemi.
• Testare il software mi ha 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 un po '. In bocca al lupo.

Vorrei passare da un livello alto a un basso.

Demo l'app il prima possibile

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

Spiega l'architettura di alto livello

Anche questo è molto importante. Consenti al nuovo sviluppatore di ascoltare e porre domande. Fallo come esercizio di gruppo con gli altri sviluppatori, che si spera possano entrare e aiutarti. Questo farà sapere al nuovo sviluppatore che è OK parlare apertamente e onestamente.

Tieni pronto un ottimo documento di bordo

Avere un ottimo documento di bordo non aiuta solo i nuovi sviluppatori, ma anche quelli vecchi. Può contenere aspettative, collegamenti utili e informazioni sulla configurazione dell'ambiente. (Non posso dirvi quante volte ho usato il nostro sistema di imbarco per impostare il mio ambiente quando avrò un nuovo computer ...) Questo dovrebbe essere ben strutturato e preciso 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 dire loro cosa fare. Dai loro dei suggerimenti, ma consenti loro finalmente di capirlo da soli.

Aiuta gli altri membri del team ad accogliere il nuovo arrivato

Ci sono due facce della medaglia quando qualcuno si unisce a una squadra. Il team deve disporre degli strumenti per accogliere anche il nuovo sviluppatore.

Lascia che prendano un piccolo compito o due

Consentire loro di aggiungere qualcosa di nuovo e visibile al progetto che è dimostrabile. Quando viene demo, chiama chi lo ha fatto e che bel lavoro hanno fatto. Questo può davvero aumentare l'autostima. Più velocemente si sentono come se aggiungessero valore, più velocemente si sentono parte della squadra. Più velocemente si sentiranno autorizzati a fare il meglio che possono.

Incoraggiali ad affrontare compiti più difficili una volta che si sentono sempre più a loro agio

I buoni candidati lo faranno naturalmente.

Un flusso di "orientamento" che ho attraversato (e che ho trovato utile) era qualcosa del tipo:

1. Una breve presentazione che fornisce al "quadro generale" quali sono i componenti, come si adattano e l'architettura generale.
2. Una panoramica del codice, introduzione alle funzioni che gestiscono la logica principale per i componenti che mi sono stati assegnati. Sono state descritte alcune cose relative alle convenzioni e allo stile di programmazione.
3. Sono stati assegnati un sacco di problemi aperti e bug a bassa priorità (che erano in gran parte localizzati al componente assegnato a me e abbastanza semplice).
4. Mi aspettavo di eseguire il debug tramite l'applicazione e chiedere aiuto con cose che non riuscivo a decifrare.
5. Dopo aver apportato la correzione, sono stato guidato attraverso il processo (revisione del codice, test a livello di sviluppo ecc.) Di rilascio all'integrazione.
6. Ripetere l'operazione per le attività / i bug rimanenti assegnati.

Sento che questo approccio (e le sue variazioni) saranno utili perché:

• Questo era più pratico e relativamente indipendente (costante senza mani ecc.). Quindi, fornisce abbastanza spazio / tempo per la nuova persona per abituarsi al codice e al modo in cui le cose vengono fatte nel team.
• È anche vantaggioso per il team nel suo insieme poiché è possibile risolvere un paio di attività / bug a bassa priorità. La persona che aiuta le nuove persone ha anche più tempo per occuparsi delle attività assegnate loro in quanto non è necessaria una mano costante e il tempo può essere programmato in modo specifico per affrontare i problemi / problemi che la nuova persona potrebbe dover affrontare.

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

È così che vado

1. Assegna loro alcune attività correlate al progetto (ad esempio: se il tuo progetto è un'applicazione di database, chiedi loro di creare semplicemente un'applicazione per connettersi con il database ed eseguire alcune semplici operazioni).
2. Quando scopri che hanno capito l'idea di lavorare, dai loro una demo del Progetto
3. Chiedi loro di leggere la documentazione.
4. Familiarizzare con gli stili e gli standard di codifica
5. Successivamente fornisci loro alcuni esercizi di debug (per conoscere il flusso del progetto).
6. Chiedi loro di risolvere un punto che hai già risolto (solo per scoprire la loro logica con esso).
7. Finalmente li rendono parte del progetto.

Ricorda: non importa quanto ci provi, fino a quando il collaboratore non capirà completamente il progetto, non sarai in grado di svolgere il lavoro in modo più efficiente da lui.

Numero uno: scopri innanzitutto 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 back-end o qualcosa del genere), lascia che utilizzino qualsiasi interfaccia disponibile per utilizzarla. Ottenere una nuova visione del software di un utente è sempre positivo e potrebbe aiutare il nuovo dipendente a vedere cose che non è possibile, perché sei già incorporato nel progetto.

Dopodiché, un buon primo progetto potrebbe essere qualcosa come un componente aggiuntivo o un nuovo modulo da aggiungere al software, riducendo al minimo la quantità di conoscenza necessaria della 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 di origine. Secondo me, dare a un nuovo dipendente un'attività di correzione di bug probabilmente li spegnerà la tua azienda.

Il tuo schema per familiarizzare con quelli nuovi con il 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 sottovalutare questo. Se ti arrabbi per queste domande ripetute rischierai che non ti chiederanno e proveranno a scoprire cose da sole che forse nella migliore delle ipotesi sono molto lente ma spesso impossibili. Inoltre dovranno imparare il gergo. La maggior parte dei progetti dei team sviluppa la propria lingua. Quando spieghi consapevolmente, cerca di evitare il gergo. Spiega queste cose come le spiegheresti 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 esempio 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 convincere un gruppo di 8 studenti a 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 dell'applicazione e della struttura del codice generale.

2) Trova alcuni piccoli bug o progetti che sono in gran parte indipendenti da altri codici. Spiega cosa deve essere fatto, dove nel codice e controllali regolarmente.

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

4) Sedersi accanto a loro di volta in volta. Puoi imparare molto guardando semplicemente come qualcun altro affronta un problema. Piccole cose come "oh, puoi cercare funzioni nel tuo codice premendo Ctrl-." sono molto utili.

Ora, ho scoperto 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 pensare che sia una buona cosa porre domande. Voglio solo che provino prima loro stessi.

Questa era la mia formula e utilizzata con diversi nuovi arrivati: questi passaggi si sono dimostrati altamente efficaci.

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

b) Assegnare 3 settimane di compito di scrivere i test Junit per il codice che non ha copertura sufficiente.

c) Al termine di 3, assegnare piccoli compiti

d) Assegnare compiti complessi e fatto.

Penso che basta assegnare alcuni piccoli compiti, chiedere loro di scrivere alcuni test unitari, farli fallire la regressione alcuni fallimenti. Niente di troppo grande o impegnativo, ma abbastanza per averli in piedi.

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

E sì, fai loro documentare ciò che stanno imparando sul sistema. Presumo che tu abbia una sorta di pagine wiki interne. Altrimenti è sicuramente un must sia nel lungo che nel breve periodo - un modo sorprendentemente veloce per far salire la gente. Le pagine Wiki non devono contenere solo la documentazione del codice, ma anche elementi come limiti noti (questo è software: D), soluzioni alternative, 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 è o sarà raggiunto.

Non capiranno fino a quando non ci sarà del lavoro da fare, quindi suggerisco di dividere in due parti, una prima di iniziare il vero lavoro, e la seconda parte, dopo che hanno iniziato a lavorare. Guarderanno un po 'di codice o documentazione e penseranno " WTF !? ". In questo caso, qualcuno li accompagnerà e spiegherà i dettagli minori.