Qual è il mix ideale di sviluppatori senior-junior in una squadra?

Mi piace molto Eric Brechner ha da dire su questo argomento

Think of your team as a river instead of a lake. A lake stagnates. There’s no energy or impetus to change. The same is true of groups that stagnate. They cultivate mediocrity and complacency; they abhor risk. A river is always running and changing with lots of great energy. You want a river.

A river depends on the flow of water, and your team depends on the flow of people and information. You can think of the people divided into three groups: new blood, new leaders, and elders ready for a new challenge. Here’s how those groups should balance and flow:

• The largest group should be the new blood. Not all of them will become technical or organizational leaders.

• Sometimes you’ll have more new leaders than elders, sometimes the reverse, but ideally you should maintain a balance.

• For flow, you want a steady stream of new blood becoming your new leaders, and new leaders becoming elders.

• The key to flow is new blood coming in and elders moving out. For this to work, you WANT your elders to transfer before they clog the stream and disrupt the flow of opportunitiesfor others.

Not all technologies flow at the same rate. Central engines, like the Windows kernel, flow slowly, while web-based services, like MSN Search, flow quickly. You need to adjust for your situation, but even the most conservative technologies do change and flow. How do you successfully encourage and maintain a healthy flow?

• Keep a constant supply of new people.

• Instill information sharing as a way of life.

• Shape the organization and roles to create growth opportunities.

• Find new challenges for your elders.

Non penso che ci sia un mix ideale - è interamente dipendente dal progetto e dall'ambiente. Un paio di esempi:

Tutti esperti

Potrebbe essere appropriato avere tutti i membri esperti del team su un progetto critico con una scadenza ristretta, in cui non c'è spazio per gli sviluppatori junior per essere al passo.

Tutti i minori

In un altro esempio, potrebbe essere appropriato avere tutti gli sviluppatori Junior in un altro progetto orientato alla R & D. C'era una squadra in una società in cui lavoravo completamente formato da stagisti a cui venivano assegnati progetti che necessitavano di una soluzione innovativa (ma non necessariamente veloce o corretta). Erano problemi reali con i clienti, ma non avevano alcuna soluzione nota, quindi hanno tirocinanti che sarebbero nuovi e hanno poche nozioni preconcette.

Il punto qui non è che uno di questi approcci è spesso giusto - più che i progetti copriranno l'intera gamma tra loro in base alle esigenze aziendali, ai fattori organizzativi e alla disponibilità degli sviluppatori.

Penso che ideale sarebbe di non avere alcuna distinzione specifica tra "junior" e "senior". Le persone dovrebbero essere trattate come individui, non come oggetti in un cassetto. Allo stesso modo, ogni progetto dovrebbe essere trattato come un problema individuale che richiede capacità individuali, talenti o personalità da risolvere. Qualsiasi classificazione di questo tipo in "junior" e "senior" serve solo a trasformare la realtà in un'approssimazione grossolana e grossolana e rende quindi sempre meno probabile che la decisione presa in ogni singolo caso sia in ogni senso "ideale".