Trop d'aînés dans une même équipe? [fermé]

Le fait d'avoir trop de programmeurs seniors dans une même équipe peut-il être une mauvaise chose?

Ayant comme dire, 4-5 programmeurs seniors dans une équipe de 6-7 personnes. Quel est le nombre / rapport optimal dans ce genre de situations?

Cela peut-il conduire à trop de philosophie et d'arguments sur les idées?

Quelqu'un at-il eu une telle expérience, qui peut la partager avec moi?

Si je pouvais choisir, j'aurais 6-7 personnes âgées dans une équipe (en supposant que le projet en a besoin).

La seule fois où je peux voir que c'est un problème, c'est si les personnes âgées ne sont que des personnes âgées dans la perception de soi et non l'éthique du travail.

Il n'y a rien de mieux que de travailler avec un groupe de personnes qui apprécient que chaque développement de logiciel soit important - la documentation, la planification, le code, le café, tout est important et il faut que les développeurs matures (véritables seniors) soient "au-dessus" rien "et faire le travail correctement.

EDIT : De nombreuses autres réponses ont dit que trop de leaders sont un problème - mais pourquoi y a-t-il une perception qu'un senior doit diriger? Une personne âgée doit être suffisamment mature pour choisir un leader et suivre. C'est le projet qui compte - choisir / obtenir un rôle et le balancer idiot!

Le plus gros problème que je vois avec le chargement d'une équipe avec des programmeurs seniors est qu'il pourrait affaiblir les autres équipes. Si vous avez des développeurs juniors dans d'autres équipes qui ont besoin de mentorat et de conseils, vous devrez peut-être déplacer les gens.

Cela peut-il conduire à trop de philosophie et d'arguments sur les idées?

Bien sûr , il peut , mais ils devraient être assez mûrs pour savoir quelles sont les différences d' importance et ce que les juste ne le font pas. Si vous avez désigné un chef d'équipe respecté, ce type d'arguments philosophiques doit être réduit au minimum avec peu d'effort.

Le fait d'avoir trop de programmeurs seniors dans une même équipe peut-il être une mauvaise chose?

Absolument.

Je suis un grand partisan de l'équipe chirurgicale de Fred Brooks .

Et cela étant dit, si les seniors d'une équipe de développement ne savent pas qui est le "chirurgien en chef", ils se heurteront à des décisions architecturales importantes et tireront dans des directions différentes au détriment de l'équipe.

PS Le besoin d'une équipe de développement pour un "chirurgien en chef" est similaire au besoin d'un orchestre pour un chef d'orchestre. Dans les deux cas, vous aurez probablement de nombreux anciens combattants; mais vous aurez un beau bordel sans une personne qui est incontestablement en charge.

Cela dépend de la répartition des responsabilités. Si TOUS les développeurs principaux sont censés avoir la même responsabilité dans la conception, la révision du code, etc., cela pourrait devenir un problème. S'ils se voient attribuer des responsabilités différentes de sorte qu'ils peuvent travailler sans se battre pour contrôler les domaines des uns et des autres, cela ne devrait pas poser de problème - par exemple, un développeur principal obtient la responsabilité principale de la conception du projet, un autre doit être en charge de mise en place et maintenance du référentiel source, un autre est en charge des tests unitaires, etc ...

Le fait d'avoir trop de programmeurs seniors dans une même équipe peut-il être une mauvaise chose?

Pas nécessairement. J'ai travaillé sur de petites équipes de développeurs seniors qui étaient très productives. Le niveau du discours était très élevé et il n'y avait pas de rancune.

Avec TDD, il y a très peu d'engagements importants en matière d'architecture logicielle, il n'y a donc pas besoin d'en discuter. Les décisions de conception peuvent être résolues en mettant simplement en œuvre les deux approches et en voyant celle qui fonctionne le mieux. Les développeurs étant très rapides, le coût de ces essais est très faible.

Oui, il peut y avoir le problème d'avoir trop de cuisiniers dans la cuisine pour une métaphore qui peut s'appliquer. Cela pourrait également être assez coûteux s'ils s'attendent tous à des salaires élevés. Notez que cela vérifie simplement l'existence d'un mauvais cas et ne dit rien sur sa probabilité.

Optimal dépend d'un certain nombre de variables que vous ne divulguez pas. Quelle métrique voulez-vous utiliser, sachant qu'il y a de bonnes chances de jouer avec le système ici. De même, quelles contraintes avez-vous dans votre monde qui peuvent le rendre différent de ce que Google ou Microsoft peuvent avoir en revanche.

Trop de développeurs seniors peuvent avoir le problème de l'absence de conventions ou de trop de conventions, je pense. Bien que certains développeurs seniors soient capables de s'adapter, si aucun d'entre eux n'est susceptible d'introduire une convention, où commencerait une équipe? Inversement, certains développeurs seniors peuvent être des fans inconditionnels de certaines conventions qui peuvent nécessiter une résolution de conflit pour être résolus.

Je pense que cela dépend des personnalités des seniors. S'ils sont arrogants et argumentatifs, cela peut être une mauvaise chose. Mais s'ils sont tous respectueux, ouverts à d'autres points de vue et désireux d'apprendre les uns des autres, alors vous avez une excellente équipe.

Je travaille actuellement sur une équipe de 8 personnes, dont 5 ou 6 sont seniors, et cela fonctionne très bien pour nous. Nous nous entendons bien, apprenons les uns des autres et c'est un excellent environnement de mentorat pour les nouveaux gars que nous avons.

J'ai travaillé dans une équipe où il y avait 1 développeur principal, 4 développeurs seniors et 1 développeur intermédiaire. Et pour la raison qu'un membre "senior" de l'équipe n'était pas une personne vraiment mature (bon développeur cependant), cela s'est avéré être un cauchemar. Il a essayé de prouver tout le temps (implicitement ou explicitement) que les autres membres de l'équipe n'étaient pas assez âgés. Il a également échoué à comprendre les principes de base du développement logiciel et les spécificités de notre produit, et, par conséquent, a tenté avec arrogance et obstination de prouver qu'il avait raison. En conséquence, cela a sérieusement affecté l'efficacité de l'équipe. Le plus triste, c'est que ce n'était même pas trop d'argument sur les idées / solutions - c'était un argument sur rien . Par exemple:

• qui a cassé la construction (qui la plupart du temps était verte et, techniquement, n'était pas cassée. c'était l'interface utilisateur qui ne fonctionnait pas correctement très souvent en raison des mauvaises solutions architecturales)
• pourquoi il y a des régressions (les modules n'étaient pas couverts par des tests unitaires auxquels nous n'avions pas accès pour contribuer)
• argumenter sur la solution architecturale dans le module qui est la responsabilité de quelqu'un d'autre sans rien savoir des exigences et des spécificités du module.
• ...

Mais j'avoue que c'était plutôt une exception. Je veux croire que les aînés se comportent correctement la plupart du temps :)