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 autres)
- 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 une conception émergente plutôt que sur le devant
- Une équipe agile conçoit ensemble, plutôt que de concevoir dictée par une seule personne
- Une équipe agile décide de sa propre direction technique, ce qui est le mieux 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 des responsabilités différentes d'un lead?
Rien dans Agile ne change le fonctionnement du développeur principal. Ils doivent impliquer le reste de l'équipe dans les décisions d'architecture du système et la direction technique, quel que soit le modèle de développement suivi.
La distribution des décisions par édit est un moyen terrible pour toute équipe de développement de fonctionner. Agile fait simplement obtenir l'adhésion du reste de l'équipe un processus plus explicite, et un développeur principal aurait dû le faire de toute façon.
Ce n'est pas parce qu'il n'y a pas de rôle de développeur principal défini dans une méthodologie Scrum que les opinions des programmeurs les plus expérimentés ne sont pas les plus respectées. Agile ne laisse pas tout le monde se déchaîner sur son propre truc et essaie ensuite de tout coller ensemble, il y a encore une vision et une direction unifiées qui doivent être définies.
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, ce qui se produira probablement, c'est que le membre expérimenté sera impliqué dans la plupart des révisions de code et les gens s'en remettront souvent à l'expérience de cette personne lors de la prise de décisions d'équipe.
Ainsi, un développeur "principal" continuera à "diriger", mais comme une conséquence naturelle de son expérience et non comme une fonction mandatée de son titre.
C'est dans un monde idéal où les gens peuvent mettre leur ego de côté. Bonne chance!
En plus de 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 en 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 plus un arbitre ou un catalyseur que celui d'une cascade. Lorsque l'équipe a un conflit sur la conception à utiliser, par exemple, vous vous assurerez que les gens ont leur mot à dire et s'en tiennent aux arguments sur les mérites. Et vous finissez par être l'arbitre auquel la solution proposée l'équipe ira lorsque le chemin n'est pas clair.
C'est l'une des responsabilités les plus importantes du responsable, mais beaucoup d'autres choses sont nécessaires pour faire un groupe de personnes dans une équipe. Vous devez toujours donner l'exemple en ce qui concerne le bon codage, et souvent l'imposer (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 fois par jour au standup ne va pas le couper.
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ù l'équipe 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 allez aux réunions afin qu'ils puissent rester à leur bureau et faire des choses. Vous êtes le point de contact pour ne pas être interrompu par des personnes qui passent directement. Et vous travaillez pour prendre des informations du monde extérieur (sur quoi travaillent les autres équipes, à quoi ressembleront les équipes agiles au prochain sprint, quel est le statut de cette demande ouverte, etc.), les résumer et les communiquer.
En bref, vous êtes le lubrifiant pour vous assurer qu'il fonctionne bien.
Votre description non agile n'invalide pas votre description agile.
Une équipe agile s'appuiera sur une conception émergente plutôt que sur le devant.
Rien dans votre définition d'un développeur principal ne dit que la conception doit être faite à l'avance. Il peut définir la direction, et il peut encore établir un plan initial. Cette conception est définitivement émergente.
Une équipe agile conçoit ensemble, plutôt que de concevoir dictée par une seule personne
Rien dans votre définition d'un développeur principal ne dit qu'il dicte la conception. Bien qu'il mai ait le dernier mot, seule une mauvaise avance ignorerait pleinement les pensées de ses coéquipiers majoritaires. D'un autre côté, seule une équipe médiocre ferait totalement abstraction des pensées du développeur principal.
Une équipe agile décide de sa propre direction technique, ce qui est le mieux pour livrer un projet
Encore une fois, cela ne signifie pas que le plomb ne soit pas initialement set dans cette direction. Le lead fait partie de cette équipe agile. Même dans un environnement non agile, seule une piste médiocre continuerait à diriger une équipe dans cette direction quand elle devient 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 qualifie pour dire à une équipe de collègues ingénieurs logiciels quoi faire? Est-ce votre expérience? Est-ce le drôle de petit titre que votre patron vous a remis? Est-ce ton ego? Votre mandat dans l'entreprise? Est-ce votre "panache"? Ton style?" Vos "compétences en leadership?"
Les équipes agiles ne se distribuent pas de badges ou de chapeaux qui disent "Félicitations, vous êtes notre super génie - vous êtes le seul autorisé à faire un travail de double génie super secret." Au contraire, l'accent est mis sur LE TRAVAIL AT HAND. Si vous êtes en effet plus expérimenté, cette expérience devrait MONTRER dans quelle mesure vos conceptions font avancer le travail vers la fin. Vos missions choisies par vous-même ( cartes) devraient refléter les domaines dans lesquels vous êtes le plus expert. D'un autre côté, si un enfant sortant de l'université a une meilleure idée, et cela correspond mieux au contexte que quelque chose qu'un vétéran de 40 ans propose, pourquoi diable nos lieux de travail ne sont pas des bureaux de thérapie - c'est là que nous venons pour construire de grandes choses.
Cela soulève une autre question: qui peut décider ce que signifie "mieux"? La réponse: l'équipe d'acteurs. Cela signifie que les développeurs, les personnes requises, les testeurs, les gens d'affaires, etc. qui sont les constructeurs et les utilisateurs de la chose en question. Si vous avez une bonne idée, vous feriez mieux de pouvoir démontrer pourquoi elle est meilleure. Si vous ne pouvez pas le faire, il n'y a aucune raison pour que l'équipe pense 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 feraient mieux d'être à la hauteur de ce nom - ils feraient mieux de RÉALISER réellement un meilleur logiciel que les autres personnes de l'équipe. Sinon, il n'y a aucune raison de les appeler un "chef de file" - c'est juste un petit badge ou un drôle de chapeau, et cela n'a aucun sens. Beaucoup de gens trouvent cela menaçant. Ils ont l'impression d'avoir "travaillé pour" un badge ou un drôle de chapeau. Les bons développeurs ne travaillent pas pour des chapeaux amusants. Ils travaillent pour créer d'excellents logiciels, et ils prévoient de le faire jusqu'à ce qu'ils croassent - leur objectif est de s'améliorer chaque jour en matière de 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.
D'après mon expérience d'Agile, l'équipe de développement dans son ensemble se voit attribuer moins de responsabilités que ce que vos exemples impliquent, laissant le développeur et l'architecte principaux coordonner les choix de conception de haut niveau, mais en transmettant la conception de niveau inférieur à l'équipe agile dans son ensemble.
Ainsi, le développeur principal reste 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 plus grand niveau 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 mandaté les choix technologiques et conçu la manière dont les composants du système interagiraient entre eux. Les réunions de planification agile se sont concentrées sur la façon de concevoir ces composants dans le cadre de ses mandats de niveau supérieur. Comme côté agréable, cela limite la portée des réunions de planification autrement fastidieuses.
Il a également fonctionné comme point de dernier recours. Lorsque des programmeurs individuels rencontraient des problèmes qu'ils n'étaient pas en mesure de résoudre, ils se mettaient en tête et la responsabilité finale de réparer les choses était la sienne.