Suggerimenti / trucchi per gestire una nuova squadra con nuovo codice [chiuso]

Come ti gestisci in una nuova squadra in cui sei il maggiore sviluppatore e la maggior parte degli altri membri del team è più giovane di te da diversi anni. Il compito davanti alla squadra è qualcosa che nessun altro, incluso te, ha mai svolto nella sua carriera prima.

Il management insiste per aumentare la produttività dell'intero team e come senior developer sei responsabile.

Qualche consiglio per uscire di briscola in una situazione come questa? Chiaramente, l'intero team ha bisogno di tempo per imparare e non dimentichiamoci del nuovo team. Tuttavia, anche le scadenze sono in anticipo ...

Non lasciare che un termine stretto o la novità del progetto interferiscano con le buone pratiche ingegneristiche. Imposta un repository di software, accetta uno stile di codifica, crea una suite di test, ecc. La novità del compito non dovrebbe essere un grosso problema fintanto che hai persone di qualità sotto di te che sono disposte a lavorare sodo e imparare il compito davanti a loro.

O per dirla in altro modo: sei stato incaricato perché il management crede che il tuo background e la tua esperienza ti abbiano fornito gli strumenti necessari per creare software di qualità. Non dimenticare improvvisamente le tue abilità solo perché questo compito sembra scoraggiante ora.

Per prima cosa, inizia a utilizzare un sistema di controllo del codice sorgente dalla prima riga di codice. Prendi l'abitudine di controllare il codice in anticipo e spesso.

In secondo luogo, decidere una strategia di test . Ovviamente ciò dovrebbe significare unit test, ma dovresti anche considerare come automatizzare i test di accettazione.

In terzo luogo, creare un server di integrazione continua in modo che il codice venga creato regolarmente e testato regolarmente.

Una volta che lo hai fatto, come gruppo stabilisci alcuni semplici standard di codifica . Vuoi che il tuo codice sia facilmente leggibile da tutti. Non importa quali siano gli standard. Rientro con linguette, rientro con spazi, parentesi graffa sulla stessa linea, qualunque cosa. Non importa cosa siano, solo che tutti li applicano in modo coerente.

Poiché il team è composto principalmente da sviluppatori junior, pianifica di rivedere spesso il codice per assicurarti che non stiano aggiungendo troppi debiti tecnici al tuo sistema.

Infine, considera l'utilizzo di SCRUM . Se lo fai, noleggia un pullman o vai a un allenamento. Dal momento che tutti state facendo qualcosa che non avete mai fatto prima, stabilire scadenze realistiche è semplicemente impossibile. Con SCRUM, la tua direzione avrà visibilità su ciò che fai su base giornaliera in modo che possano vedere quali progressi sono (o non sono) in corso. E, poiché le tue scadenze ti sono state date apparentemente, SCRUM garantisce almeno che se non riesci a rispettare la scadenza, almeno stai consegnando storie complete su base incrementale, che probabilmente è meglio che arrivare alla fine con un gigante sistema che non funziona affatto.

Inoltre alla risposta di @chrisaycock ... Non sottovalutare il tempo che dovrai dedicare per il tutoraggio / formazione, ecc. Come lead, dovrai imparare a lasciar andare i dettagli e fidarti del tuo team. Il tuo compito è diventare l'attivatore, il dispositivo di rimozione dei blocchi stradali ed eseguire le interferenze quando la direzione entra in gioco. In un team "normale", a circa 7 o 8, il lead non programma più, Nella tua situazione, questo scende a 3 o 4 (forse anche meno), non sei una risorsa di programmazione per il progetto.

Focus sulla comunicazione in due aree.

Non è facile farlo, ed è uno dei motivi per cui questo lavoro è difficile. Se rispettare la scadenza significa tagliare le caratteristiche, andare oltre. L'unica cosa che stai cercando di evitare in tutto questo è il codice rapido per fissare una scadenza. Questo è l'inizio della fine di una base di codice che non durerà bene e l'inizio del debito tecnico che soffoca.

2) Comunicazione inter-team. Impostare pratiche formali come Bryan e altri raccomandano. Assicurati di incontrarti regolarmente come una squadra, ad esempio una volta alla settimana oltre alle mischie quotidiane. Ottieni rispetto e fiducia ascoltando , il tuo strumento più importante. Assicurati di concentrarti sull'aiuto. Evita le critiche negative a tutti i costi. Se necessario, usa critiche e incoraggiamenti positivi, ad es. "È fantastico, una volta che una cosa che potresti prendere in considerazione è X" oltre "che non è ciò di cui abbiamo bisogno, devi invece fare X"

Quello che ho fatto è identificare quelli capaci e dividere e conquistare. Prendo i primi 2 o 3 e li faccio capitani. Gli altri vengono quindi equamente divisi in squadre seguendo i capitani verso le loro piccole squadre.

Dò ai capitani pezzi o moduli per fare un programma.

I capitani danno ai neofiti piccoli compiti di programmazione o di ricerca per tutto il tempo spiegando loro stessi cosa stanno facendo così il tutoraggio accade mentre lo fanno.

Cerco di sistemare la stanza in modo che tutti siano nello stesso spazio aperto ma ogni squadra ha la propria cerchia di computer. Mi piace essere a distanza urlando da tutti, quindi le cose si muovono rapidamente.

Finora funziona bene per circa 10-20 programmatori. I gruppi più piccoli sono semplicemente meglio stare in un gruppo e non ho ancora lavorato con nulla di più grande.