Quel est le rôle du développeur principal dans une équipe agile?

Dans une équipe de développement non agile, un développeur principal généralement :

• Définit la norme (codage et autre)
• Recherche de nouvelles technologies pour l'équipe
• Définit la direction technique de l'équipe
• A le dernier mot sur les questions
• Conçoit l'architecture d'un système

Cependant, une équipe agile fonctionne différemment:

• Une équipe agile s'appuiera sur un design émergent plutôt que sur le front
• Une équipe agile conçoit ensemble plutôt que d'être dictée par une seule personne
• Une équipe agile décide de sa propre direction technique, ce qui est préférable pour livrer un projet

Où cela laisse-t-il un développeur principal dans une équipe agile? Est-il possible d'avoir un développeur principal dans une équipe agile? Une équipe agile exige-t-elle différentes responsabilités d'un responsable?

Rien dans Agile ne change le fonctionnement du développeur principal. Ils devraient impliquer le reste de l'équipe dans les décisions relatives à l'architecture du système et à la direction technique, quel que soit le modèle de développement suivi.

Donner des décisions par décret est un moyen terrible pour toute équipe de développement de fonctionner. Agile rend simplement plus explicite l’adhésion du reste de l’équipe, et un développeur principal aurait dû le faire de toute façon.

Ce n’est pas parce qu’il n’ya pas de rôle défini de développeur principal dans une méthodologie Scrum que les programmeurs les plus expérimentés ne sont pas les plus respectés. Agile ne laisse pas tout le monde se déchaîner sur ses affaires et essaie ensuite de tout concilier, il reste une vision et une direction unifiées à définir.

Dans une équipe agile, tout le monde est censé mettre son ego de côté.

Si un membre d'une équipe agile a plus d'expérience que les autres, il est probable que le membre expérimenté sera impliqué dans la plupart des révisions de code et que les gens s'en remettront souvent à l'expérience de cette personne pour prendre des décisions.

Ainsi, un développeur "principal" continuera à "diriger", mais comme conséquence naturelle de leur expérience et non comme une fonction obligatoire de leur titre.

C'est dans un monde idéal où les gens peuvent mettre leur ego de côté. Bonne chance!

En plus de la réponse de Ryathal :

Vous parlez de conception émergente et de direction d'équipe comme si elles découlaient de l'équipe en parfaite harmonie et harmonie. Des groupes de personnes, des groupes de programmeurs en particulier, ont des conflits . En tant que chef d’équipe, votre travail dans une équipe agile est davantage un arbitre ou un catalyseur que dans une cascade. Lorsque l’équipe est en conflit sur le design à utiliser, par exemple, vous vous assurez que les gens ont le même droit de parole et s’en tiennent à la discussion sur les mérites. Et vous finissez par être l'arbitre de la solution proposée par l'équipe lorsque le chemin n'est pas clair.

C'est l'une des responsabilités les plus importantes du responsable, mais il reste encore beaucoup à faire pour former un groupe de personnes. Vous devez toujours donner l'exemple en matière de codage efficace et le faire respecter (soit directement, soit en créant une culture pour le faire). Vous devez faciliter la communication entre tous les membres de votre équipe, car une journée de stand-up ne suffira pas.

L'autre chose importante que vous avez négligée, ce sont les réunions. Il n'est pas pratique d'amener toute l'équipe à chaque réunion où elle doit interagir avec des gens d'affaires, d'autres équipes techniques, etc. En tant que chef d'équipe, vous êtes le représentant de l'équipe. Vous assistez aux réunions pour qu’ils puissent rester à leur bureau et faire leur travail. Vous êtes le point de contact pour qu'ils ne soient pas interrompus par des personnes qui passent directement chez vous. Et vous travaillez pour extraire des informations du monde extérieur (sur quoi les autres équipes travaillent, à quoi ressemblent les équipes agiles lors du prochain sprint, quel est le statut de cette demande ouverte, etc.), résumez-les pour elles et communiquez-les.

En bref, vous êtes le lubrifiant pour vous assurer qu’ils peuvent fonctionner sans heurts.

Votre description non agile n'invalide pas votre description agile.

Une équipe agile s'appuiera sur un design émergent plutôt que sur le devant de la scène.

Rien dans votre définition de développeur principal ne dit que la conception doit être réalisée dès le départ. Il peut définir la direction et il peut encore définir un plan initial. Ce design est définitivement émergent.

Une équipe agile conçoit ensemble plutôt que d'être dictée par une seule personne

Rien dans votre définition de développeur principal n’indique qu’il dicte le design. Bien qu'il peut avoir le dernier mot, un pauvre plomb serait complètement ignorer les pensées de ses coéquipiers majoritaires. D'un autre côté, seule une équipe médiocre serait totalement indifférente à la pensée du développeur principal.

Une équipe agile décide de sa propre direction technique, ce qui est préférable pour livrer un projet

Encore une fois, cela ne signifie pas que le chef de file ne définit pas initialement cette direction. Le chef fait partie de cette équipe agile. Même dans un environnement non agile, seule une mauvaise piste continuerait à guider une équipe dans cette direction lorsqu'elle est devenue sciemment irréalisable ou lorsque de nouvelles informations ont été présentées pour invalider cette direction.

La question soulève quelques autres questions. Selon vous, qu'est-ce qui vous permet de dire quoi faire à une équipe d'ingénieurs en logiciel? Est-ce votre expérience? Est-ce le drôle de petit titre que votre patron vous a remis? Est-ce votre ego? Votre mandat à la compagnie? Est-ce votre "panache"? Ton style?" Vos "compétences en leadership?"

Les équipes agiles ne se distribuent pas de badges ni de chapeaux disant: "Félicitations, vous êtes notre super génie - vous êtes le seul autorisé à effectuer un travail double secret super secret." Au contraire, l'accent est mis sur le travail à portée de main. Si vous êtes effectivement plus expérimenté, alors cette expérience doit montrer à quel point vos conceptions permettent de faire avancer les travaux. Vos devoirs (cartes) choisis par vous-même doivent refléter les domaines dans lesquels vous êtes le plus expert. D'un autre côté, si un jeune élève de l'université a une meilleure idée et qu'il est plus adapté au contexte qu'un vétéran de 40 ans avec, pourquoi diable irions-nous avec le design plus pauvre? Nos lieux de travail ne sont pas des bureaux de thérapie - ce sont eux où nous venons pour construire de grandes choses.

Cela soulève une autre question: qui décide ce que "mieux" signifie? La réponse: l'équipe de parties prenantes. Cela signifie que les développeurs, les utilisateurs d'exigences, les testeurs, les entrepreneurs, etc., sont les constructeurs et les utilisateurs de la chose en question. Si vous avez une bonne idée, vous feriez mieux de démontrer pourquoi c'est meilleur. Si vous ne pouvez pas faire cela, l'équipe n'a aucune raison de croire que votre idée est meilleure. Agile encourage la méritocratie.

Alors, qu'advient-il du "responsable de l'équipe de développement?" en agile? Rien - ils méritent simplement d'être à la hauteur de ce nom -, mieux vaut réellement être en mesure de produire un meilleur logiciel que les autres membres de l'équipe. Autrement, il n'y a aucune raison de les appeler un "lead" - c'est juste un petit badge ou un drôle de chapeau, et cela n'a pas de sens. Beaucoup de gens trouvent cela menaçant. Ils ont l'impression de "travailler pour" un badge ou un drôle de chapeau. Les bons développeurs ne fonctionnent pas pour des chapeaux amusants. Ils travaillent à la création de logiciels de qualité et prévoient le faire jusqu'à ce qu'ils croassent - leur objectif est de perfectionner chaque jour la création de logiciels. Si ce n'est pas vous, vous voudrez peut-être vous pencher sur la gestion de projet. Vous serez probablement plus heureux.

Selon mon expérience d’Agile, l’équipe de développement dans son ensemble a moins de responsabilités que ce que vos exemples suggèrent, laissant le développeur principal et l’architecte en charge de coordonner les choix de conception de haut niveau, mais confiant la conception de niveau inférieur à l’équipe agile.

Le développeur principal reste donc responsable de l’architecture du système et des choix technologiques. Ceci est très important: bien que l'agile encourage la conception émergente et la refactorisation, cela devrait se produire au niveau des objets de code. Le système dans son ensemble doit avoir un niveau plus élevé de préconception et de rigidité, sinon le projet risque de devenir un gâchis non coordonné.

Dans notre projet, le développeur principal a imposé les choix technologiques et défini la manière dont les composants du système interagiraient les uns avec les autres. Les réunions de planification agiles ont porté sur la manière de concevoir ces éléments dans le cadre de ses mandats de niveau supérieur. En passant, cela permet de limiter le nombre de réunions de planification par ailleurs fastidieuses.

Il a également fonctionné comme point de dernier recours. Lorsque des programmeurs individuels rencontraient des problèmes qu'ils étaient incapables de résoudre, ils se mettaient en tête et la responsabilité finale de la résolution des problèmes était la sienne.