2009-07-30 14 views
6

Sono interessato a ciò che costituisce una grande squadra e quale rapporto di sviluppatori, architetti, tester, manager ecc.Quanto è grande la GRANDE? (team di sviluppo)

Qualcuno ha cifre per le dimensioni della squadra in progetti ben noti come Windows o SQL Server per esempio?

risposta

1

Dipende da cosa intendi per "squadra". Ho lavorato per una grande banca statunitense su un "team" .NET di oltre 60 sviluppatori, oltre a architetti, manager e QA.

Il mio attuale "team" è composto da circa 12 sviluppatori di livelli diversi, una manciata di controllo qualità e un architetto di soluzioni.

Ma in entrambe le situazioni, non lavoro mai con più di ~ 3 persone alla volta. Di solito solo 1 o 2. Quindi in questo senso, siamo suddivisi in squadre di 2-4 a seconda dei compiti a portata di mano. Per un singolo progetto, sembra essere al limite.

1

È possibile trovare il seguente articolo di interesse.

http://www.qsm.com/process_01.html

Ma, per rispondere alla tua domanda è difficile senza la comprensione del processo che si sta utilizzando. Ad esempio, il modello a cascata richiederà una squadra più grande rispetto al metodo agile XP.

Sono stato in una squadra con 13 membri, ma che tende a dividere in gruppi più piccoli, ognuno dei quali lavora su determinati compiti. Se la squadra è abbastanza grande da far entrare in gioco la politica, allora è troppo grande. Potresti avere un gran numero di persone che possono lavorare bene insieme, tutte concentrate sul finire il progetto, e non cercare i propri interessi personali, e il grande numero non può causare un problema, ma, quello avere quei tipi di persone sono improbabili.

Qualsiasi cosa più grande di 9 persone è probabilmente troppo grande in quanto si romperà in gruppi più piccoli, quindi, se una squadra è abbastanza grande da dividere in piccoli gruppi, allora basta che le piccole squadre siano la dimensione della squadra, e rendersi conto che quello che hai iniziato era troppo grande.

1

I team dovrebbero essere grandi quanto necessario per il progetto in questione, quando leggo "big" ho l'impressione che stai cercando "quanto è troppo grande". Ho lavorato per progetti con centinaia di sviluppatori per lo sviluppo di switch telefonici ma sono stati sempre assegnati a team di 5 o 6 con un team leader ciascuno: hardware, software, documentazione, test & QA, installazione, formazione e così via. Per i team stessi, qualcosa di più di 5 diventa difficile da gestire.

7

Se si chiede Jeff Bezos, si desidera in modo ottimale un "two-pizza team": Se non si può alimentare una squadra con due pizze, è troppo grande. Questo ti limita a 5-7 persone, a seconda del loro appetito.

+3

Se ho trascorso la maggior parte della giornata di programmazione, posso mettere da parte due pizze ... – SingleNegationElimination

+0

Alcuni di questi take out hanno una pizza piuttosto piccola. Mi dispiacerebbe pensare che sono condannato a lavorare da solo tutto il tempo !! Fortunatamente l'appetito diminuisce con l'età ... alla fine dovrebbe essere in grado di far entrare qualcun'altro sulla torta !! :-P – Newtopian

+0

Ha quindi dovremmo iniziare a classificare i programmatori in base alle loro divisioni di peso: P? – rezzif

2

Sogno il giorno in cui tutte le diverse fasi di sviluppo fanno parte di un'unica squadra, invece di avere una squadra "convenientemente" suddivisa in base alla descrizione del lavoro. Questa visione organizzativa tende ad inclinare pesantemente i processi verso la terribile cascata (dio odio questo processo!).

Ma per rispondere alla tua domanda, penso che il team non debba superare le persone di 10 o più persone che gravitano intorno ad esso senza essere a tempo pieno parte di esso (formazione, marketing, clienti, implementazione, supporto). In tutti gli 80% - 20% degli sviluppatori e del management/QA dovrebbero tendere verso una buona produttività. Se i tuoi architetti possono anche scavare nel codice un po 'meglio. Frequenti revisioni del design con tutta la squadra dovrebbero anche consentire a tutti di avere una buona supervisione sull'intero progetto e non solo sulla loro pila di banane.

Ecco un esempio della squadra di abbattere che aveva funzionato molto bene per me:

  • 2 Sr sviluppatori che hanno una buona conoscenza sull'architettura
  • 4 sviluppatori Jr in grado di gestire il lavoro sporco
  • 1 codice ninja che può fare un po 'di esplorazione tecnologica (pur partecipando al tutto)
  • 1 project manager, team lead, interfaccia con il mondo esterno per introdurre le 2 pizze
  • 1 rumoroso QUn tipo per sondare l'applicazione, scrivere test di accettazione ecc. La parte rumorosa era per la metrica WTF/giorno. Più tranquillo era, meglio era il nostro lavoro e meno ibuprofene abbiamo consumato.

Intorno a questo gravitavano alcuni clienti su cui facevamo frequenti test di usabilità.

ha i bei vecchi tempi !!!

+0

Nessun analista di business? Meglio aggiungere alcune risorse per tutto il supporto che avrai in seguito. –

+0

Penso che un analista di business sia un po 'sopravvalutato, forse non ne ho mai incontrato uno competente. La maggior parte di essi ha lavorato con requisiti dettati e ha anche imposto scelte tecnologiche e attuative. Sinceramente abbiamo molto più materiale di convergenza quando trattiamo direttamente con i clienti con test oggettivi regolari piuttosto che affidarsi a un analista aziendale. Non mi imbarcherò nemmeno su quale approccio abbia prodotto il peggiore incubo di supporto. Poi di nuovo forse non ho mai lavorato con uno buono. – Newtopian

+0

Sono come tutti gli altri: ce ne sono di buoni e cattivi. E ammettiamolo, penso che ci siano probabilmente più cattivi di quelli buoni. Ho lavorato in abbondanza come quelli che descrivi: fantini di MS Outlook glorificati. I rari bravi con cui ho lavorato hanno fatto molto per aiutare gli sviluppatori a capire il business ea difendere i bisogni degli utenti (e anche degli sviluppatori). –

0

Dove lavoro utilizza Scrum e per avere uno standup effettivo di 15 minuti, non ci possono essere più di 6 o 7 sviluppatori insieme a pochi altri gestori, ciascuno dei quali richiede circa 1,5 minuti per adattarsi entro l'intervallo di tempo. Gli altri manager includono alcuni utenti finali dei nostri sistemi, la garanzia della qualità e il team ha portato alcuni esempi.

Penso che se la squadra fosse molto più grande, il lavoro avrebbe dovuto essere definito più finemente poiché ho già un piccolo problema a cercare di tenere a mente tutte le cose del progetto attuale.

1

Quello che ho visto in genere è un rapporto di 2 sviluppatori per ogni 1 architetto (analista) e 1 QA (tester) - quindi 25% architetto, 50% sviluppatori, 25% QA - a seconda di come il team è rotto su

  • funzionale - si dovrebbe avere 1 manager per area per ogni 6-9 persone - quindi 1 per architetti, 1 per sviluppatori 1 per QA min.
  • progetto - si dispone di 1 dirigente a capo di ogni progetto, se il progetto è superiore a 9 persone con cui suddividere con i cavi del team (direttore di parte/parte architetto o sviluppatore o tester)

Un team di solito cambia nel tempo - Di fronte avremo più Architetti e poi passeremo a più sviluppatori e quasi alla fine della vita del progetto arriveranno altri tester.

Ho gestito team da 6 a 100 e il rapporto di solito è circa lo stesso.

Problemi correlati