Quali pratiche di gestione / sviluppo cambiate quando un team di 1-3 sviluppatori cresce a 10+?


14

Il mio team ha creato un sito Web per un cliente diversi anni fa. Il sito taffic è cresciuto molto rapidamente e il nostro cliente ci ha chiesto di far crescere il nostro team per soddisfare le esigenze di manutenzione e richiesta di funzionalità.

Abbiamo iniziato con un numero limitato di sviluppatori e il nostro team è cresciuto, ora siamo a doppia cifra.

Quali cambiamenti di gestione / sviluppo sono i più vantaggiosi quando il team passa da un piccolo team di dimensioni "garage" a oltre 10 sviluppatori?


1
Potresti voler dividere la parte gestionale della domanda e porla
blueberryfields

2
Quali pratiche di gestione utilizzava il team prima?
chrisaycock,

Inizialmente avevamo 2 sviluppatori di livello senior, quindi di solito parlavano semplicemente. Poiché il team e il progetto stavano iniziando a crescere, c'erano sviluppatori junior, quindi abbiamo introdotto WIKI, sistema di tracciamento dei bug, controllo del codice sorgente ecc ... Ora sembra che il team sia troppo grande per essere gestito da uno sviluppatore senior, quindi forse dovremmo iniziare dividendolo in squadre più piccole.
Mag20,

Compra più caffè.
Hayylem,

1
Che grande "problema" avere. Complimenti per la squadra in crescita!
Agile Scout,

Risposte:


8

Direi che ci sono circa due strade principali:

  • Dividi la squadra in due o tre gruppi, ognuno responsabile di un campo / aspetto specifico. questo ha il vantaggio che puoi ancora lavorare come sei abituato, all'interno dei gruppi più piccoli.
  • "The Surgical Team", in cui è possibile leggere il Mese-uomo-mese . anche questo link ha un disegno meraviglioso al riguardo.

In bocca al lupo!


4

Siamo passati da circa 10 a quasi 200 negli ultimi 7 anni. La prima cosa che deve cambiare è che avrai bisogno di una migliore documentazione e di processi più standard. I requisiti potrebbero dover diventare anche più formali.

Dovresti anche considerare l'assunzione di specialisti mentre cresci. Se si dispone di un back-end di database, è necessario disporre di almeno uno specialista di database dedicato. Probabilmente dovresti spendere soldi per un tester.

Avrai più progetti in corso e una maggiore necessità di gestire tham, quindi se non ne usi uno adesso, hai bisogno di un sistema di gestione dei progetti e di un localizzatore di bug. È necessario creare un processo di distribuzione e limitare la produzione solo alle persone che eseguiranno le distribuzioni, senza più apportare modifiche direttamente al prodotto. I tuoi sviluppatori dovranno essere limitati a selezionare i diritti solo su prod.

Dato che hai team più grandi, avrai più problemi con le persone e avrai maggiori probabilità di assumere persone meno qualificate (relativamente facile ottenere tre buoni sviluppatori quando è tutto quello che hai, molto più difficile assumere 30 contemporaneamente). Anche se cerchi di ottenere le persone migliori, più assumi, più è probabile che otterrai un disastro, quindi preparati a lasciar andare anche le persone.

Il coordinamento tra le persone è la chiave. Due team che apportano modifiche reciprocamente esclusive a un prodotto sono una cosa negativa.

Con solo due o tre sviluppatori non puoi permetterti di avere persone giovani: tutti devono lavorare a livello senior. Con molti sviluppatori, non puoi permetterti di non avere persone più giovani. Assumi alcuni junior e allenali come preferisci. Di solito è meglio lavorare da qualche parte che abbia un percorso professionale che non sia mai stato allo stesso livello.

Man mano che il tuo team cresce, molti dei tuoi attuali sviluppatori diventeranno il nuovo staff di gestione. Alcuni lo odieranno, assicurandosi che quelli abbiano l'opportunità di una promozione per uno sviluppatore senior piuttosto che un management. Non perdere tutte le tue competenze tecniche per la gestione. Premia coloro che non entrano nella gestione perché hai bisogno della loro conoscenza dettagliata del sistema attuale per rendere le nuove persone aggiornate.


4

Se il progetto è abbastanza grande per oltre 10 sviluppatori, dovrebbe essere facile suddividere in aree più piccole. Dividi la squadra in squadre più piccole di 3-5 persone ciascuna e dai loro autonomia sulla loro area. Le API dovranno essere sviluppate tra i team. Consiglierei a ogni team di capire i loro requisiti e di far incontrare una o due persone di ciascun team coinvolto per discutere dell'API. È più facile avere una discussione e prendere decisioni quando sono coinvolte meno persone.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.