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

Non lasciare che una scadenza ravvicinata o la novità del progetto interferiscano con la buona pratica ingegneristica. Imposta un repository software, accetta uno stile di codifica, entra in una suite di test, ecc. La novità del compito non dovrebbe essere un grosso problema finché hai persone di qualità sotto di te che sono disposte a lavora duro e impara il compito davanti a loro.

O per dirla in un altro modo: sei stato messo in carica perché il management crede che il tuo background e la tua esperienza ti abbiano fornito gli strumenti necessari per costruire 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.

Secondo, decide una strategia di test . Ovviamente questo dovrebbe significare test unitari, ma dovresti anche considerare come automatizzare i test di accettazione.

Terzo, crea un server di integrazione continua in modo che il tuo codice sia compilato regolarmente e testato regolarmente.

Una volta ottenuto ciò, come una squadra stabilisce alcuni semplici standard di codifica . Vuoi che il tuo codice sia facilmente leggibile da tutti. Non importa davvero quali siano gli standard. Rientro con tabulazioni, rientro con spazi, parentesi graffa sulla stessa linea, qualunque cosa. Non importa quello che sono, solo che tutti li applicano in modo coerente.

Poiché il team è per lo più sviluppatori junior, pianifica di riesaminare il codice spesso per assicurarsi che non aggiungano troppo debito tecnico al tuo sistema.

Infine, considera l'utilizzo di SCRUM . Se lo fai, assumi un allenatore o vai ad allenarti. Dato che tutti voi state facendo qualcosa che non avete mai fatto prima, stabilire delle scadenze realistiche è semplicemente impossibile. Con SCRUM, la tua gestione avrà visibilità su ciò che fai ogni giorno in modo che possano vedere quali progressi sono (o non vengono) fatti. E siccome le tue scadenze ti sono state date, SCRUM garantisce almeno che se non puoi rispettare la scadenza, almeno stai consegnando storie complete su base incrementale, il che è probabilmente meglio che arrivare alla fine con un gigante sistema che non funziona affatto.

In aggiunta alla risposta di @chrisaycock ... Non sottovalutare il tempo che dovrai dedicare al mentoring / training ecc. Come guida, dovrai imparare a lasciare andare i dettagli e fidarti del tuo team. Il tuo compito è quello di diventare l'enabler, il dispositivo di rimozione del blocco stradale e interferire quando la gestione prende il sopravvento. In una squadra "normale", a circa 7 o 8, il lead non funziona più, Nella tua situazione, questo scende a 3 o 4 (Forse anche meno), Non sei una risorsa di programmazione per il progetto.

Concentrati sulla comunicazione in due aree.

1) Come si e membri del team di ottenere una migliore comprensione di ciò che è coinvolto (quasi sempre "più di quanto originariamente pensato", è la chiave per spendere un sacco di tempo a spiegare questo alla gestione. Ci sono poche scadenze reali. Io di solito dico che una sonda NASA per un asteroide che sarà in una certa posizione orbitale solo una volta ogni 200 anni, ora che è un vero e proprio termine. Diverso da quello che la maggior parte delle scadenze sono artificiali e spesso non basato sul lavoro. di solito fisso suono becuase "abbiamo solo più di tanto denaro", 'programmatore bob lascia in 2 settimane', 'Dobbiamo presentare agli investitori la prossima settimana' Tuttavia, se il lavoro non è finito, quindi queste scadenze inevasa allora cosa succede -.. rivalutare e decidere cosa fare allora In realtà, la gestione preferirebbe ottenere quelle "cattive notizie" in anticipo, non è facile farlo, e questo è uno dei motivi per cui questo lavoro è difficile: se rispettare la scadenza significa ritagliare le caratteristiche, allora passate oltre. cercare di evitare in tutto questo è un codice veloce per fare una scadenza. Questo è l'inizio della fine di un codice base che non durerà molto e l'inizio del debito tecnico che soffoca.

2) Comunicazione inter-team. Stabilire pratiche formali come Bryan e altri raccomandano. Assicurati di incontrarti regolarmente come una squadra, ad es. una volta alla settimana in aggiunta alle mischie quotidiane. Ottieni rispetto e fiducia con ascolto , il tuo strumento più importante. Assicurati di concentrarti sull'aiutare. Evita le critiche negative a tutti i costi. Se necessario, usa critiche e incoraggiamenti positivi, ad es. "è grandioso, una cosa che potresti voler considerare è X" oltre "non è quello che ci serve, devi invece fare X"

Quello che ho fatto è identificare quelli capaci e dividere e conquistare. Prendo i primi 2 o 3 e li rendono capitani. Gli altri vengono poi suddivisi equamente in squadre che seguono i capitani nelle loro piccole squadre.

Dò ai capitani chunk o moduli da fare per un programma.

I capitani danno ai neofiti piccoli compiti di programmazione o di ricerca per tutto il tempo spiegando loro stessi cosa stanno facendo in modo che il tutoraggio avvenga mentre si fa.

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

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