Quelles pratiques de gestion / développement changez-vous lorsqu'une équipe de 1 à 3 développeurs passe à 10+?

Mon équipe a créé un site Web pour un client il y a plusieurs années. Le site taffic a augmenté très rapidement et notre client nous a demandé de développer notre équipe pour répondre à leurs besoins de maintenance et de demande de fonctionnalités.

Nous avons commencé avec un petit nombre de développeurs et notre équipe s'est agrandie - nous sommes maintenant à deux chiffres.

Quels changements de gestion / développement sont les plus bénéfiques lorsque l'équipe passe d'une petite équipe de "taille de garage" à plus de 10 développeurs?

Je dirais qu'il y a environ deux routes principales:

• Divisez l'équipe en deux ou trois groupes, chacun responsable d'un domaine / aspect spécifique. cela a l'avantage que vous pouvez toujours travailler comme vous en avez l'habitude, dans les petits groupes.
• "The Surgical Team", sur lequel vous pouvez lire sur The Mythical-Man-Month . aussi ce lien a un merveilleux dessin à ce sujet.

Bonne chance!

Nous sommes passés d'environ 10 à près de 200 au cours des 7 dernières années. La première chose à changer est que vous aurez besoin d'une meilleure documentation et de processus plus standard. Les exigences peuvent également devoir devenir plus formelles.

Vous devriez également envisager d'embaucher des spécialistes à mesure que vous grandissez. Si vous avez un backend de base de données, vous devez avoir au moins un spécialiste de base de données dédié. Vous devriez probablement dépenser de l'argent pour un testeur.

Vous aurez plus de projets en cours et un besoin plus important de gérer cela, donc si vous n'en utilisez pas maintenant, vous avez besoin d'un système de gestion de projet et d'un suivi des bogues. Vous devez créer un déploiement porcess et limiter le droit de production uniquement aux personnes qui effectueront des déploiements, sans plus apporter de modifications directement sur prod. Vos développeurs devront être limités à sélectionner des droits uniquement sur prod.

Comme vous avez de plus grandes équipes, vous aurez plus de problèmes de personnes et vous serez plus susceptible d'embaucher des personnes moins qualifiées (relativement facile d'obtenir trois bons développeurs quand c'est tout ce que vous avez, beaucoup plus difficile d'en embaucher 30 à la fois). Même si vous essayez de trouver les meilleurs candidats, plus vous embauchez, plus il est probable que vous obtiendrez un raté, alors soyez prêt à laisser les gens partir aussi.

La coordination entre les personnes est essentielle. Deux équipes apportant des modifications mutuellement exclusives à un produit sont une mauvaise chose.

Avec seulement deux ou trois développeurs, vous ne pouvez pas vous permettre d'avoir des jeunes - tout le monde doit travailler au niveau supérieur. Avec beaucoup de développeurs, vous ne pouvez pas vous permettre de ne pas avoir de jeunes. Embaucher des juniors et les former comme vous le souhaitez. Il est généralement préférable de travailler dans un endroit dont le cheminement de carrière n'est pas au même niveau.

À mesure que votre équipe s'agrandit, nombre de vos développeurs actuels deviendront le nouveau personnel de gestion. Certains détesteront cela, assurez-vous que ceux-ci ont la possibilité d'une promotion auprès d'un développeur senior plutôt que de la direction. Ne perdez pas toute votre expertise technique au profit de la direction. Récompensez ceux qui ne se lancent pas dans la gestion parce que vous avez besoin de leur connaissance détaillée du système actuel pour mettre les nouvelles personnes au courant.

Si le projet est assez grand pour plus de 10 développeurs, il devrait être facile de le diviser en zones plus petites. Divisez l'équipe en équipes plus petites de 3 à 5 personnes chacune et donnez-leur de l'autonomie sur leur zone. Les API devront être développées entre les équipes. Je recommanderais à chaque équipe de déterminer leurs besoins et de réunir une ou deux personnes de chaque équipe impliquée pour discuter de l'API. Il est plus facile d'avoir une discussion et de prendre des décisions lorsque moins de personnes sont impliquées.