Trucs et astuces pour gérer une nouvelle équipe avec un nouveau code [fermé]


9

Comment vous gérez-vous dans une nouvelle équipe où vous êtes le développeur le plus senior et la plupart des autres membres de l'équipe sont juniors pour vous de plusieurs années. La tâche qui attend l'équipe est quelque chose que personne d'autre, vous compris, n'a accompli auparavant.

La direction insiste sur une productivité plus élevée de toute l'équipe, et en tant que développeur senior, vous êtes responsable.

Des conseils pour sortir des atouts dans une situation comme celle-ci? De toute évidence, toute l'équipe a besoin de temps pour apprendre et n'oublions pas la nouvelle équipe. Cependant, les délais sont également à venir ...


Devrait être sur pm.stackexchange.com
JBRWilkinson

5
@JBRWilkinson Je ne suis pas d'accord. Il s'agit d'être un leader technologique de développeurs juniors avec un délai serré. Je serais d'accord s'il s'agit de savoir comment gérer un projet de développeurs juniors, mais être un responsable technique est différent d'un PM.
maple_shaft

Réponses:


13

Ne laissez pas un délai serré ou la nouveauté du projet nuire aux bonnes pratiques d'ingénierie. Mettre en place un référentiel de logiciels, convenir d'un style de codage, proposer une suite de tests, etc. travailler dur et apprendre la tâche qui les attend.

Ou pour le dire autrement: vous avez été mis en charge parce que la direction estime que votre parcours et votre expérience vous ont donné les outils nécessaires pour construire des logiciels de qualité. N'oubliez pas soudain vos compétences simplement parce que cette tâche semble intimidante maintenant.


Assurez-vous que tous les membres de l'équipe ont la possibilité d'estimer toutes les tâches qui leur seront assignées, afin d'avoir une certaine adhésion aux délais. Étant donné que votre équipe apprend toujours les cordes, n'engagez personne pendant plus de cinq heures par jour, lorsque vous transformez les estimations en un temps écoulé. Et si les délais ne peuvent pas être respectés, assurez-vous que la direction en soit informée le plus tôt possible.
Dawood ibn Kareem

1
@David - Comment avez-vous travaillé pendant 5 heures (ce n'est en fait pas un mauvais chiffre à utiliser, mais comment le savons-nous)? Admettez simplement que l'estimation d'un tel projet est une prise de merde et dites à la direction.
mattnz

3
Je pense que la plupart des gens sont productifs pendant environ 6 à 6,5 heures par jour. Quelques-uns réussissent mieux que cela, mais je pense que c'est une bonne moyenne. Mais comme l'équipe est nouvelle, au moins une heure par jour sera consacrée à l'apprentissage. Et je crois à l'estimation - bien que tout le monde ne soit pas bon dans ce domaine, il faut que ce soit mieux que de simplement intervenir et programmer sans savoir combien de temps une tâche prendra.
Dawood ibn Kareem

Cela permet d'obtenir l'adhésion si vous demandez aux membres de l'équipe de développer leurs estimations avant de voir l'heure prévue et qu'ils ne dépassent pas de manière significative le plan. Les faire estimer avant de voir d'autres estimations évitera également de biaiser l'estimation.
BillThor

@ BillThor: Vous obtenez sûrement le gars qui fait le travail pour l'estimer, et utilisez ses chiffres comme point de départ. Je viens d'estimer un emploi et on m'a dit "Nous pensions que ce serait 1/3 de cela". Pourquoi ont-ils même pris la peine de me demander s'ils savaient combien de temps cela prendrait?
mattnz

7

Tout d'abord, commencez à utiliser un système de contrôle de code source à partir de la toute première ligne de code. Prenez l'habitude de vérifier le code tôt et souvent.

Deuxièmement, décidez d'une stratégie de test . Bien sûr, cela devrait signifier des tests unitaires, mais vous devez également réfléchir à la façon d'automatiser les tests d'acceptation.

Troisièmement, établir un serveur d'intégration continue afin que votre code soit construit régulièrement et testé régulièrement.

Une fois que vous avez cela, en équipe, établissez des normes de codage simples . Vous voulez que votre code soit facilement lisible par tout le monde. Peu importe les normes. Retrait avec des tabulations, retrait avec des espaces, accolade sur la même ligne, peu importe. Peu importe ce qu'ils sont, seulement que chacun les applique systématiquement.

Étant donné que l'équipe est principalement composée de développeurs débutants, prévoyez de revoir le code souvent pour vous assurer qu'il n'ajoute pas trop de dette technique à votre système.

Enfin, envisagez d'utiliser SCRUM . Si vous le faites, embauchez un entraîneur ou suivez une formation. Puisque vous faites tous quelque chose que vous n'avez jamais fait auparavant, il est tout simplement impossible d'établir des délais réalistes. Avec SCRUM, votre direction aura une visibilité sur ce que vous faites au quotidien afin qu'elle puisse voir quels progrès sont (ou ne sont pas) en cours. Et, puisque vos délais vous ont apparemment été donnés, SCRUM garantit au moins que si vous ne pouvez pas respecter le délai, au moins vous livrez des histoires terminées sur une base incrémentale, ce qui est sans doute mieux que d'arriver à la fin avec un géant système qui ne fonctionne pas du tout.


2
+1 pour le contrôle de version et la révision de code tôt et souvent.
jmq

2
Je suis d'avis que le contrôle des sources est un processus si nécessaire qu'il devrait être fait indépendamment de la composition de l'équipe, indépendamment de quoi que ce soit.
maple_shaft

6

En plus de la réponse de @chrisaycock ... Ne sous-estimez pas le temps que vous devrez consacrer au mentorat / à la formation, etc. En tant que responsable, vous devrez apprendre à laisser aller les détails et à faire confiance à votre équipe. Votre travail consiste à devenir le facilitateur, le suppresseur de barrages routiers et à exécuter des interférences lorsque la direction y pénètre. Dans une équipe "normale", vers 7 ou 8 heures, le responsable ne programme plus. Dans votre situation, cela tombe à 3 ou 4 (Peut-être encore moins), Vous n'êtes pas une ressource de programmation pour le projet.


+1 sur l'allocation de temps pour le mentorat et la formation. Une avance technologique efficace rend les développeurs juniors productifs.
maple_shaft

"Vous n'êtes pas une ressource de programmation pour le projet". Je me demande si sa direction ressent la même chose, heh. J'espère que vous ne finirez pas en tant que programmeur "héros" pour le projet.
jmq

J'avais l'impression que le PO était simplement le développeur le plus expérimenté et n'avait pas de titre ou de fonctions spéciaux (c'est-à-dire qu'il n'est pas un "responsable technique" ou un "architecte"). Dans ce cas, il est très certainement une ressource de développement et devrait probablement être la plus productive.
TMN

@TMN: Je reflétait la réalité de ce qui se passe dans une équipe avec un gars qualifié / expérimenté et tous les autres beaucoup moins qualifiés. Nul doute que le gars expérimenté, s'il code, sera le plus productif et devrait coder. L'ÉQUIPE sera plus productive s'il ne le fait pas. Dans une organisation non éclairée, les managers mesurent les performances individuelles, de sorte que le meilleur gars semble mal faire ce qui est le mieux - faire fonctionner l'équipe et obtenir peu de récompense pour cela. Il vaut mieux accrocher les juniors au sec et se faire bien paraître.
mattnz

1

Concentrez-vous sur la communication dans deux domaines.

Ce n'est pas facile à faire, et c'est une des raisons pour lesquelles ce travail est difficile. Si le respect de la date limite signifie des fonctionnalités de coupe, passez-en plus. La seule chose que vous essayez d'éviter dans tout cela est un code rapide pour fixer une date limite. C'est le début de la fin d'une base de code qui ne durera pas bien et le début d'une dette technique qui s'étouffe.

2) Communication inter-équipes. Mettre en place des pratiques formelles comme Bryan et d'autres recommandent. Assurez-vous de vous réunir régulièrement en équipe, par exemple une fois par semaine en plus des mêlées quotidiennes. Gagnez du respect et de la confiance en écoutant , votre outil le plus important. Assurez-vous de vous concentrer sur l'aide. Évitez à tout prix les critiques négatives. Si nécessaire, utilisez des critiques positives et des encouragements, par exemple "c'est super, une fois que vous voudrez peut-être considérer que X est" plus "que ce dont nous avons besoin, vous devez faire X à la place"


0

Ce que j'ai fait, c'est identifier ceux qui sont capables et diviser pour mieux régner. Je prends les 2 ou 3 premiers et j'en fais des capitaines. Les autres sont ensuite répartis également en équipes en suivant les capitaines dans leurs propres petites équipes.

Je donne aux capitaines des morceaux ou des modules pour faire un programme.

Les capitaines donnent aux débutants de plus petites tâches de programmation ou de recherche tout en s'expliquant ce qu'ils font, de sorte que le mentorat se fait en faisant.

J'essaye d'aménager la salle pour que tout le monde soit dans le même espace ouvert mais chaque équipe a son propre cercle d'ordinateurs. J'aime être à distance de tout le monde pour que les choses bougent rapidement.

Jusqu'à présent, cela fonctionne bien pour environ 10 à 20 programmeurs. Les petits groupes sont juste mieux d'être dans un groupe et je n'ai pas encore travaillé avec quelque chose de plus grand.


Divide & Conquer a ses pièges. J'ai vu cela finir par chaque sous-équipe réinventer (mal) la roue pour des problèmes similaires auxquels toute l'équipe est confrontée.
NWS

Oui, si vous êtes dans des bâtiments séparés, donc j'essaie de garder tout le monde dans un espace ouvert et de me promener régulièrement. Ce que je fais, c'est créer des signatures API principales et configurer les équipes pour les construire afin que tout se connecte.
Jason Sebring
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.