Mon équipe de 4 développeurs expérimentés travaille sur une grande application Windows modulaire (environ 200 KLoC). Je me suis concentré sur la base de code principale depuis le début du projet (il y a 3 ans) et j'ai progressivement évolué vers un poste de développeur semi-principal, même si je ne suis pas le chef d'équipe.
Notre itération actuelle est une actualisation de l'interface utilisateur hautement prioritaire demandée par la haute direction, impliquant environ 15 modifications de la base de code principale. Interrogé par le directeur, j'ai estimé que chacun des 15 changements prendrait moins de quatre heures pour moi de terminer , un total de moins de 7 jours de travail. Je me suis ensuite porté volontaire pour effectuer le travail. Au lieu de cela, le gestionnaire a décidé de répartir uniformément les 15 tâches entre les quatre développeurs.
Dans les trois jours qui se sont écoulés depuis que nous avons commencé à travailler, j'ai observé deux choses:
Les autres membres inexpérimentés de l'équipe ont effectué environ 1 tâche ou moins chacun.
La loi de Brook en action: j'ai passé environ la moitié de mon temps à fournir de l'aide (en essayant de les coacher sur l'utilisation des composants). En conséquence, je n'ai terminé que 2 tâches moi-même, au lieu des 5 ou 6 attendues.
J'ai approché mon manager avec ma préoccupation que nous étions en retard et j'ai de nouveau suggéré que je termine les tâches restantes. Ma demande a été aimablement refusée et les raisons invoquées pour répartir la charge uniformément étaient doubles:
- Limitez le facteur camion / bus - incitez les autres développeurs à développer ces compétences maintenant, afin qu'à l'avenir, tout travail puisse être confié à n'importe qui, pas seulement à moi.
- Pour éliminer un «goulot d'étranglement» (moi) et accélérer le travail.
Pour être clair, je n'ai aucun problème avec: a) investir le temps d'enseignement, b) les personnes touchant mon code, ou c) la sécurité d'emploi. En fait, je suggère régulièrement au chef d'équipe de former d'autres développeurs sur certains aspects de la base de code principale pour réduire les risques.
Dans cette itération, nous avons également une grande collection de correctifs de bogues de haute priorité ciblés, il semblerait donc que plus de progrès pourraient être réalisés si la charge de travail était redistribuée.
Dans Mythical-Man-Month, Brooks propose une " équipe chirurgicale " où chaque équipe est composée d'un responsable + sous-responsable (le manager et moi), et de quelques rôles mineurs. J'ai l'impression que nous tombons naturellement dans cette organisation, mais mon manager y travaille. Je pense que le facteur de bus est déjà pris en charge (le gestionnaire connaît bien le code de base) et que le goulot d'étranglement n'existe pas réellement (impliquer plus de développeurs ne fera pas accélérer le travail). Je pense qu'à cet égard, une équipe chirurgicale est une bonne chose.
Ce sont mes sentiments, mais je ne suis pas un gestionnaire expérimenté, et nous n'avons pas eu à faire face au facteur bus (frapper du bois). Brooks avait-il raison? Avez-vous travaillé dans une "équipe chirurgicale" où le facteur bus est entré en jeu? Existe-t-il de meilleures techniques pour gérer la distribution de l'expertise?
Questions similaires: