Com'è lavorare in un grande team di programmazione?

Trovo molto bene la bilancia burocratica.

Oltre a questo, non molto. Grandi progetti hanno grandi team perché non c'è altro modo, non perché sia più efficiente (per sviluppatore). Paghi un costo non appena aggiungi una seconda persona al mix in termini di inefficienza (ad es. Trasferimento di conoscenza e comunicazione).

Il più grande progetto su cui ho lavorato contava circa 70 sviluppatori su 5 siti diversi. Anche un cambio di una riga ha richiesto un minimo di giorno, anche se ciò è dovuto in parte al fatto che la costruzione ha impiegato più di 45 minuti su un collegamento di rete da Zurigo a Londra e l'avvio dell'app ha richiesto altri 45 minuti. Il check-in ha richiesto circa 5 minuti per file. Non sto scherzando. Gli sviluppatori di Londra potrebbero farlo in una frazione del tempo.

In ogni caso, quello che tendi a trovare è che su progetti di grandi dimensioni avrai un gruppo di membri del team con cui non interagirai più di tanto. È più simile a una raccolta di mini-progetti poco ampia. Una volta ho letto che lo sviluppo di Microsoft tendeva a suddividere progetti in team di 5-7 sviluppatori, anche per progetti di grandi dimensioni come Microsoft Office.

Parte della differenza è anche la differenza tra aziende piccole e grandi: quelle più grandi tendono ad avere più processi, più regole, meno flessibilità e così via. Ma questo non è affatto garantito.

Però può essere buono per lo sviluppo della carriera. In una piccola azienda qualcuno deve andarsene o morire prima di poter ottenere una promozione (o la società deve crescere in modo tale che il team si espanda e si muova verso l'alto) mentre in dipartimenti di sviluppo più grandi è possibile spostarsi tra squadre e così via.

Inoltre a volte puoi trovare persone davvero intelligenti da cui attaccarti e da cui imparare. Nelle piccole aziende essere così isolati e autosufficienti può essere favorevole ai programmatori che diventano un po '"strani", un po' come un eremita.

La comunicazione è ciò che ho scoperto essere la cosa più grande che inizia a peggiorare man mano che le dimensioni del team crescono. Diventa più difficile ottenere comunicazioni e più difficile assicurarsi che tutti siano ancora sulla stessa pagina. Lavoro indirettamente su un team di circa 75 sviluppatori, usiamo una base di codice comune, ma molti dei 75 si dividono in gruppi più piccoli per singole "attività". Per noi la comunicazione è solo un incubo assoluto.

La gestione di gruppi più grandi è anche più difficile, poiché nella maggior parte degli ambienti dopo 8-12 persone vengono coinvolti altri membri della gestione, purtroppo questo semplicemente esagera il problema di comunicazione in quanto in genere crea un ambiente di tipo "silo" in cui i singoli sottosistemi iniziano a rompersi fuori dal grande gruppo e cerca di mantenere la conoscenza all'interno del loro gruppo.

All'epoca in cui creavo software per sistemi di armi, avevamo GRANDI team di sviluppatori di software. Dal momento che nessuna persona può avvolgere la testa attorno ai requisiti (alcuni dei quali sono stati classificati), si trattava di squadre e di come i team interagivano tra loro.

1. Configuration Management - il processo di compilazione notturno - era un grosso problema. In quei giorni ci voleva un grande cluster di calcolo distribuito per ricompilare il mondo ogni notte.

2. Le autorizzazioni di lavoro e l'addebito del tempo per l'elemento pubblicitario corretto nella pianificazione generale del progetto principale - è stato un grande dolore al collo. Fino a 0,1 ore. incrementi.

Ma la cosa più importante era la notifica di modifica. In particolare le modifiche all'interfaccia.

Questo era così importante, hanno inventato questo pazzo processo a due strati. La maggior parte dello sforzo è stato fatto per assicurare che la richiesta di avviso di modifica dell'interfaccia (non la notifica stessa, ma la richiesta di notifica) avesse un software di supporto elaborato con un database e rapporti e quant'altro.

Una volta approvata la richiesta, l'avviso effettivo più o meno era ovvio. Significa che si trattava in realtà di un processo a un livello e la richiesta era effettivamente l'avviso. Ma quando fai lo sviluppo a cascata, tutto deve essere pensato per molto tempo prima che gli sviluppatori si presentino.

Con così tante persone che lavoravano in parallelo, c'era una scheda di controllo della configurazione. Tutti i vari team manager, oltre a un gruppo di persone il cui compito era semplicemente quello di coordinare i cambiamenti.

Il mio primo lavoro di programmazione "reale" era quello di lavorare con un altro esercito per sviluppare sistemi di controllo del traffico aereo internazionale. Si è trattato di uno sforzo di grande successo e siamo stati considerati un ambiente di Livello di maturità Capability 5. Da allora sono stato in negozi di medie e piccole dimensioni. Quindi, qual è il miglior posto dove stare? Personalmente, vorrei portare un negozio più piccolo a quello più grande ogni giorno. Mentre alcuni potrebbero considerare il Livello 5 come il Santo Graal, per me è stato soffocante. Tutto deve essere documentato, approvato, firmato, ecc. Non fraintendetemi, ne vedo decisamente il valore, soprattutto per sistemi critici come il controllo del traffico aereo, ma la domanda è: come volete passare il vostro giorno? Vuoi la libertà di poter sognare le cose e poi implementarle, o vuoi scrivere ai requisiti? Forse se fossi rimasto più a lungo con il sistema ATC avrei potuto raggiungere il livello di poter progettare e sviluppare, ma anche quello richiesto numero X di anni, numero Y di approvazioni, numero Z di promozioni - tutte ben prescritte senza possibilità di deviazione. Stava soffocando.

Un'ultima cosa, in generale, trovo che la qualità degli sviluppatori sia molto più alta nelle aziende più piccole semplicemente perché non possono nascondersi. Non è difficile essere mediocri in un'azienda molto grande, ma diventa dolorosamente ovvio in un piccolo e spesso non durano a lungo.

Ho lavorato (brevemente) in un'organizzazione con almeno centinaia di sviluppatori. Ma ovviamente (?), L'organizzazione è partizionata internamente in modo che tu come singolo dipendente non abbia un contatto diretto con tutti gli altri, sarebbe molto difficile stare al passo con i tempi.

In quel particolare luogo, il software è stato suddiviso in componenti, con team formati attorno ai componenti. Alcuni team lavoravano con un solo componente (grande), mentre molti team avevano la responsabilità di un gruppo di componenti (più piccoli).

Ovviamente ciò implica tutto ciò che funziona con una base di codice molto ampia; cose come la gestione della configurazione, la costruzione, l'integrazione e così via diventano importanti, grandi, cose che vengono a loro volta create da reparti specializzati dedicati. E li stupisci, per essere in grado di raccogliere l'output di tutti i dipartimenti di sviluppo e regolarmente (una volta alla settimana, dove ho lavorato) integrarlo in un unico insieme coerente che ha funzionato.

Non ho mai lavorato per un grande team di programmatori , ma il risultato di un'organizzazione che aumenta di dimensioni è solitamente più regole. Questo non è necessariamente sempre una brutta cosa! Oltre alle regole che rendono difficile la vita di tutti, ci sono anche più regole per proteggere i dipendenti e garantire un buon processo.

Ho visto manager nelle piccole organizzazioni farla franca con cose che li avrebbero immediatamente risolti da un dipartimento delle risorse umane.

L'unica differenza che ho notato con i grandi progetti è la politica dell'ufficio. Più i progetti sono grandi, più la politica è dominante.

Il mio primo progetto fuori dalla scuola era di un paio di centinaia di sviluppatori. Essendo uno sviluppatore impertinente e fresco di scuola, ero davvero non pronto per quello. L'unica cosa che ha salvato il mio hiney (ed è l'unica cosa che mai ti ha davvero protetto) è stata la quantità di amici che ho creato.

Questa è la più grande lezione che ho imparato da questo. Cerca di fare amicizia con tutti . Anche i cretini. In particolare, se hai la possibilità di interrompere il lavoro per un minuto e di avere una conversazione con qualcuno con cui non hai mai parlato prima, fallo.

Una volta ho passato un anno a lavorare in un team con oltre 500 persone, circa 200 di questi erano sviluppatori. Stavamo consegnando un EOA, integrando diverse soluzioni SOA.

In pratica c'erano da 30 a 50 team, ognuno con un numero variabile di programmatori (3 sul nostro team), ciascuno con responsabilità per un aspetto diverso del risultato complessivo.

La squadra più grande su cui abbia mai lavorato era di circa 15 persone (era solo per 3 o 4 mesi, in una società diversa). Sono stato il capo tecnico del team e ho iniziato a lavorare alle 7 del mattino, mi ci sarebbero volute 2 ore prima che entrassero tutti, era l'unico modo in cui potevo svolgere le mie attività.

Non vorrei lavorare su un team con più di 8 o 10 sviluppatori, 15 erano troppi per una singola squadra (la squadra avrebbe potuto facilmente essere divisa in due, non la mia chiamata sfortunatamente), 3 o 4 devs è una bella dimensione comoda IMHO