Comment est l'environnement de travail dans une grande équipe de programmation?

J'ai toujours eu la chance de travailler dans une petite équipe de programmation. Je pense que le plus avec lequel j'ai travaillé est de 11 programmeurs. Comment est-ce de travailler sur un projet avec des centaines de développeurs? Milliers? Qu'est-ce que l'échelle et ce qui ne fonctionne pas?

EDIT: Merci pour toutes les réponses! Il semble y avoir très peu de points positifs:

• possible de travailler sur de très grandes bases de code
• un meilleur développement de carrière interne
• protection des employés contre une gestion abusive (c'est plus -ve sur petit que + ve sur grand)

Y a-t-il d'autres avantages pour les grandes équipes?

Je trouve les échelles bureaucratiques très bien.

A part ça, pas beaucoup. Les grands projets ont de grandes équipes parce qu'il n'y a pas d'autre moyen, pas parce qu'il est plus efficace (par développeur). Vous payez un coût dès que vous ajoutez une deuxième personne au mix en termes d'inefficacité (ie transfert de connaissances et communication).

Le plus grand projet sur lequel j'ai travaillé comptait environ 70 développeurs sur 5 sites différents. Même un changement d'une ligne a pris un jour minimum, bien que cela soit en partie dû au fait que la construction a pris plus de 45 minutes sur une liaison réseau de Zurich à Londres et le démarrage de l'application a pris encore 45 minutes. Les enregistrements ont pris environ 5 minutes par fichier. Je ne plaisante pas. Les développeurs de Londres pourraient le faire en une fraction du temps.

Quoi qu'il en soit, ce que vous avez tendance à trouver, c'est que sur les grands projets, vous aurez un groupe de membres de l'équipe avec lesquels vous n'interagissez pas beaucoup. Cela ressemble plus à une collection faiblement affiliée de mini-projets. J'ai lu une fois que le développement de Microsoft avait tendance à décomposer les projets en équipes de 5 à 7 développeurs, même pour les grands projets comme Microsoft Office.

Une partie de la différence est également la différence entre les petites et les grandes entreprises: les plus grandes ont généralement plus de processus, plus de règles, moins de flexibilité, etc. Mais ce n'est nullement garanti.

Cela peut être bon pour le développement de carrière. Dans une petite entreprise, quelqu'un doit quitter ou mourir avant de pouvoir obtenir une promotion (ou l'entreprise doit se développer de telle sorte que l'équipe s'agrandisse et que vous montiez), tandis que dans les grands départements de développement, vous pouvez vous déplacer entre les équipes, etc.

De plus, vous pouvez parfois trouver des personnes vraiment intelligentes auxquelles vous attacher et apprendre. Dans les petites entreprises, l'isolement et l'autonomie peuvent être propices à ce que les programmeurs deviennent un peu "étranges", en quelque sorte comme un ermite.

La communication est ce que j'ai trouvé être la plus grande chose qui commence à se dégrader à mesure que la taille de l'équipe grandit. Il devient plus difficile de faire sortir la communication et de s'assurer que tout le monde est toujours sur la même longueur d'onde. Je travaille indirectement sur une équipe d'environ 75 développeurs, nous utilisons une base de code commune, mais la plupart des 75 se répartissent en petits groupes pour des "activités" individuelles. Pour nous, la communication n'est qu'un cauchemar absolu.

La gestion de groupes plus importants est également plus difficile, car dans la plupart des environnements après que 8 à 12 personnes supplémentaires impliquent des membres de la direction, malheureusement cela exagère simplement le problème de communication car cela crée généralement un environnement de type "silo" où les sous-ensembles individuels commencent à se détacher de la grand groupe et essayez de garder les connaissances au sein de leur groupe.

À l'époque où j'ai créé des logiciels pour les systèmes d'armes, nous avions de GRANDES équipes de développeurs de logiciels. Étant donné que personne ne peut se concentrer sur les exigences (dont certaines ont été classées), il s'agissait uniquement d'équipes et de la façon dont les équipes interagissaient.

1. La gestion de la configuration - le processus de construction nocturne - était très importante. À cette époque, il fallait un grand cluster informatique distribué pour recompiler le monde chaque nuit.

2. Les autorisations de travail - et le fait de consacrer votre temps à l'élément de campagne correct dans le calendrier principal du projet - ont été très pénibles. Jusqu'à 0,1 heure. incréments.

Mais le plus gros problème était la notification de changement. Particulièrement les changements d'interface.

C'était tellement important qu'ils ont inventé ce processus fou à deux couches. La majeure partie de l'effort a consisté à s'assurer que la demande d'avis de changement d'interface (pas la notification elle-même, mais la demande de notification) avait un logiciel de support élaboré avec une base de données et des rapports et quoi.

Une fois que la demande a été approuvée, l'avis réel est plus ou moins allé de soi. Cela signifiait que c'était vraiment un processus à une seule couche et la demande était effectivement l'avis. Mais lorsque vous faites du développement en cascade, tout doit être pensé longtemps avant que les développeurs ne se présentent.

Avec autant de personnes travaillant en parallèle, il y avait une carte de contrôle de configuration. Tous les différents chefs d'équipe, ainsi qu'un groupe de personnes dont le travail consistait simplement à coordonner les changements.

Mon premier «vrai» travail de programmation a été de travailler avec une armée et d'autres pour développer des systèmes internationaux de contrôle du trafic aérien. Ce fut une entreprise très réussie et nous étions considérés comme un environnement de niveau 5 du modèle de maturité des capacités. Depuis lors, je suis dans des magasins de taille moyenne et petits. Alors, quel est le meilleur endroit pour être? Personnellement, je prendrais un petit magasin au lieu d'un grand jour. Alors que certains pourraient considérer le niveau 5 comme le Saint Graal, pour moi, c'était étouffant. Tout doit être documenté, approuvé, signé, etc. journée? Voulez-vous la liberté de pouvoir imaginer les choses et ensuite les mettre en œuvre, ou voulez-vous écrire aux exigences? Peut-être que si j'étais resté plus longtemps avec le système ATC, j'aurais peut-être atteint le niveau de conception et de développement, mais même cela nécessitait X années, Y nombre d'approbations, Z nombre de promotions - tout est bien prescrit sans risque de déviation. C'était étouffant.

Une dernière chose, en général, je trouve que la qualité des développeurs est beaucoup plus élevée dans les petites entreprises simplement parce qu'ils ne peuvent pas se cacher. Ce n'est pas difficile d'être médiocre dans une très grande entreprise, mais cela devient douloureusement évident dans une petite et ils ne durent souvent pas longtemps.

J'ai travaillé (brièvement) dans une organisation avec au moins des centaines de développeurs. Mais bien sûr (?), L'organisation est cloisonnée en interne afin que vous, en tant qu'employé unique, n'ayez pas de contact direct avec tous les autres, ce serait très difficile à suivre.

À cet endroit particulier, le logiciel a été divisé en composants, avec des équipes formées autour des composants. Certaines équipes travailleraient avec un seul (grand) composant, tandis que de nombreuses équipes étaient responsables d'un tas de composants (plus petits).

Bien sûr, cela implique tout ce que fait le travail avec une très grande base de code; des choses comme la gestion de la configuration, la construction, l'intégration, etc. deviennent importantes, des choses importantes qui sont à leur tour réalisées par des départements spécialisés et dévoués. Et vous les admirez, pour avoir pu collecter la sortie de tous les départements de développement et régulièrement (une fois par semaine, où j'ai travaillé) l'intégrer tous ensemble dans un ensemble cohérent qui a réellement fonctionné.

Je n'ai jamais travaillé pour une grande équipe de programmeurs , mais le résultat d'une organisation qui augmente en taille est généralement plus de règles. Ce n'est pas forcément toujours une mauvaise chose! En plus des règles qui rendent la vie de chacun difficile, il y a aussi plus de règles pour protéger les employés et assurer un bon processus.

J'ai vu des gestionnaires de petites organisations s'en tirer avec des choses qui auraient immédiatement entraîné leur licenciement par un service RH de l'entreprise.

La seule différence que j'ai remarquée avec les grands projets est la politique du bureau. Plus les projets sont grands, plus la politique est dominante.

Mon premier projet en dehors de l'école était de quelques centaines de développeurs. En tant que développeur arrogant et naïf fraîchement sorti de l'école, je n'étais vraiment pas prêt pour ça. La seule chose qui m'a sauvé hiney (et il est la seule chose qui jamais vraiment vous protéger) était la quantité d'amis que je fait.

C'est la plus grande leçon que j'en ai tirée. Essayez de vous faire des amis avec tout le monde . Même les secousses. En particulier, si vous avez une chance d'arrêter le travail pendant une minute et d'avoir une conversation avec quelqu'un à qui vous n'avez jamais parlé auparavant, faites-le.

Une fois, j'ai passé un an à travailler avec une équipe de plus de 500 personnes, dont environ 200 développeurs. Nous livrions un EOA, intégrant plusieurs solutions SOA différentes.

Dans la pratique, il y avait entre 30 et 50 équipes, chacune avec un nombre variable de programmeurs (3 dans notre équipe), chacune ayant la responsabilité d'un aspect différent du livrable global.

La plus grande équipe sur laquelle j'ai jamais travaillé était d'environ 15 personnes (ce n'était que pour 3 ou 4 mois, dans une entreprise différente). J'étais le responsable technique de l'équipe et j'ai commencé à travailler à 7 heures du matin, j'aurais 2 heures tranquilles avant que tout le monde n'entre, c'était la seule façon de faire mes propres tâches.

Je ne voudrais pas travailler sur une équipe avec plus de 8 ou 10 développeurs, 15 était beaucoup trop pour une seule équipe (l'équipe aurait facilement pu être divisée en deux, pas mon appel malheureusement), 3 ou 4 devs est un belle taille confortable à mon humble avis