Nous avons une équipe "typique" de SCRUM et nous nous engageons à travailler pour un sprint tout en maintenant un arriéré. Récemment, nous avons rencontré un problème d’essai d’intégration / de gestion du travail d’un développeur hors pair qui travaille en dehors du groupe (choisir de travailler en dehors des heures normales de travail / du sprint).

Pour donner un exemple, si l'équipe reçoit 50 points de travail, supposons qu'elle achève tout ce travail dans le cadre de SCRUM d'ici la fin du sprint et que l'entreprise et lui sont heureux. Un des membres de l'équipe décide de travailler seul, sur un poste en retard, sur son temps libre. Ils ne vérifient pas ce travail, mais le sauvegardent (nous utilisons TFS et il se trouve dans une étagère).

Comment gérer ça? Quelques problèmes ..

• Lors du prochain sprint, les membres de cette équipe ont déclaré que le travail de programmation était achevé à 99% et nécessitait simplement une révision et des tests de code. Comment gérez-vous cela dans SCRUM et la méthodologie agile?
• D'autres développeurs se plaignent de ne pas être impliqués dans les décisions de conception liées à ces histoires, car le travail a été réalisé en dehors du groupe.
• Notre propriétaire de produit est tenté d'assumer ce travail "gratuit" et les membres surexcellents le font volontairement afin d'obtenir davantage de fonctionnalités que l'équipe ne pourrait autrement réaliser dans le ou les sprints. Certains pensent que cela brise le "processus". De toute évidence, le travail d’assurance qualité, d’assurance-chômage et de documentation doit encore être effectué.

Je vois beaucoup de discussions sur le fait de ne pas forcer une équipe de SCRUM à faire des heures supplémentaires, mais qu'en est-il d'un membre de l'équipe travaillant au-delà des attentes formulées lors de la planification et de l'exécution des sprints? J'hésiterais à faire régner cette personne et à dire que vous ne pouvez pas travailler davantage (en avertissant de l'épuisement des cours bien sûr), mais en même temps, cela semble causer des problèmes avec certains membres de l'équipe (mais pas tous).

Comment intégrer le travail d'un membre surpassant dans le SCRUM et le processus agile de développement logiciel?

Bon, alors quelqu'un écrit avec enthousiasme un bon code qu'il faut faire, mais pas dans l'ordre. Avec tout l'accent voulu:

LAISSE LES

Cela provoque des complications dans vos sprints de mêlée. Est-ce vraiment important dans le grand schéma des choses? S'il accomplit ce qu'il est censé accomplir, alors laissez-le continuer et vous construire de grandes choses.

Je connais plusieurs programmeurs extraordinaires qui ont quitté des entreprises parce qu’ils ne les ont pas laissés en dehors des contraintes d’un système artificiel tel que Scrum (j’ai moi-même quitté mon dernier emploi après avoir été traité comme une assurance qualité glorifiée). S'il y a des plaintes d'autres développeurs à propos de leur contribution (plaintes parfaitement valables, pourrais-je ajouter), il peut être préférable d'introduire un programme "20% de temps" pour lui permettre (ainsi qu'à d'autres) de faire ce qu'ils font le mieux avec un minimum d'interférences.

Au lieu d'histoires futures (pouvant nécessiter la participation d'autres personnes), laissez le développeur expérimenter de nouvelles technologies ou fonctionnalités. Vous pouvez trouver une nouvelle opportunité qui n'aurait jamais été explorée autrement. Je suis sûr que ce développeur a quelques petites choses qu’il aimerait essayer si vous les lui laissez.

Je pense que vous devriez considérer deux choses ici:

1. Ne pas entraver le flux créatif de quelqu'un.
   • Si un développeur souhaite travailler en dehors des heures de travail, laissez-le.
2. Ne créez pas de travail pour les autres.
   • Si un développeur souhaite travailler en dehors des heures de bureau, il est certainement préférable de ne pas créer plus de travail pour les autres .

Le point 2 est probablement ce qui inquiète les autres développeurs.

Comme vous l'avez dit, ils n'aiment pas le fait que le code soit écrit sans la participation de toute l'équipe. C'est peut-être parce que, en termes de conception, il finit par être inférieur. Et le code avec une conception inférieure a un moyen d'infecter un autre code autour de lui.

Alors que peux-tu faire?

Laissons l'ambitieux code au contenu qui l'intéresse, mais expliquons clairement qu'il n'y a aucune raison de présumer que son code parascolaire sera utilisé .

Après tout, il fait partie d'une équipe et cette dernière devrait donc être impliquée dans la façon dont tout le code est développé.

Si, toutefois, son travail est correct et s’accorde avec le design convenu par l’équipe, il pourra utiliser une grande partie de ce qu’il a déjà écrit (bonus!). Sinon, cela le forcera à réfléchir davantage à sa conception la prochaine fois qu'il décidera de prendre une longueur d'avance.

De cette façon, personne ne se fait dire NON et personne ne crée de travail supplémentaire pour lui.

Ramenez-le dans l'équipe

Vous devriez vous demander (ou mieux l’équipe, y compris le vainqueur):

Pourquoi ce comportement est-il un problème?

Étant donné que vous qualifiez le développeur de super-performant, je suppose que son travail est de bonne qualité, alors je suppose que ce n’est pas un problème.

Mais il semble y avoir d'autres problèmes:

• Le travail supplémentaire n'est pas testé correctement
• ce n'est pas documenté
• le reste de l'équipe ne le sait pas
• le développeur décide de la prochaine chose à mettre en œuvre, pas du bon de commande
• le développeur ne reçoit aucun retour des différentes parties prenantes à incorporer dans son travail.

La prochaine Pourquoi je voudrais tel quel:

Pourquoi le développeur le fait-il?

• Si à la fin du sprint, il ne reste plus assez de travail, l'équipe (y compris le bon de commande) devrait décider de ce qu'il convient de faire ensuite. Pourquoi le développeur évite-t-il cette décision?

Une fois que vous avez répondu à ces questions, vous pouvez commencer à répondre à votre propre question:

• si ce n'est pas un problème, laissez-le faire son truc. Bien que certaines personnes considèrent SCRUM comme une religion, il ne devrait pas en être ainsi.
• Il est plus probable que vous rencontriez deux problèmes dans l’équipe: le ou les problèmes causés par le développeur non autorisé et le ou les problèmes qui déclenchent le comportement de celui-ci. Trouver un moyen de résoudre le plus tard et le premier partira.

Même si j'aime bien l'idée d'ajouter du travail gratuit dans le mix, c'est une bonne chose, mais ce n'est pas du travail gratuit - à moins que ce développeur unique ne soit également que le testeur, le responsable de la qualité, le concepteur et tout le reste. Si son travail peut être mis dans le prochain sprint sans aucun impact, alors ... allez-y. Mais je pense que ce n'est jamais le cas. Tout le monde, à tout le moins, doit comprendre ce qu'il a fait et quel impact cela a sur eux. Ils doivent comprendre que ses changements sont en place et ne pas faire double emploi avec ses efforts. Il est difficile de dire à quelqu'un qu'ils ont travaillé dur pour la tâche de la découverte du malfaiteur qui l'a fait la semaine dernière.

Cependant, vous travaillez dans un environnement agile, et une chose que je sais de l'agile, c'est qu'il est conçu pour fonctionner pour vous, pas contre vous. Vous devez donc changer votre façon de travailler pour permettre ce type d'activité parascolaire. Cela signifie obtenir l’avis et l’accord de tous, vous ne pouvez le faire sans leur participation. C'est vital. Si l'équipe ne l'aime pas, le voyou cesse de le faire. Fin de. Ce n'est pas un gars qui fait ce qu'il aime, peu importe la qualité de son travail, c'est un travail d'équipe. L'équipe vient en premier.

Il faut donc que tout le monde s'assoie à la prochaine réunion de planification et en discute. Tous les membres de l'équipe doivent décider de l'autoriser ou de changer de processus pour mieux gérer ce type d'activité.

Peut-être obtiendrez-vous une solution où chacun travaillera sur ses projets préférés et les amènera à la table (vous pouvez imaginer le chaos dans votre livraison qui causerait :) qui met en évidence le problème avec cela en premier lieu) ou vous pouvez demander un mandat La zone où chaque développeur a la possibilité de développer la solution qui lui convient est la "contribution" au nombre de projets Open Source qui fonctionnent, ou vous pouvez donner à chacun le temps d’expérimenter (les 20% précédents).

Est-ce que ce développeur écrit des tests et un code propre / solide ou est-il juste en train de sortir tout ce qu'il peut faire rapidement? Personnellement, je ne permettrais à personne de travailler en dehors des heures définies, cela gâcherait vos estimations et, comme vous l'avez souligné, d'autres problèmes se produiraient.

Cependant, vous ne devriez jamais être rigide dans votre processus. Scrum est juste un cadre, vous pouvez donc toujours ajuster le processus pour inclure le temps supplémentaire (mais encore une fois, il est difficile de planifier ce que quelqu'un pourrait faire).

Vous pouvez également lui demander de travailler sur des choses autres que le projet. En regardant une nouvelle technologie ou en créant une formation sur des choses qu'il fait différemment. En fin de compte, tout ce qui est fait en dehors de votre emploi du temps prévu va détruire vos estimations et je ne le laisserais pas arriver.

nous avons fait face à la même chose aussi, nous avons en gros engagé environ 20 points, mais la semaine dernière ou même au milieu du sprint, nous n’avons plus de tâche de codage. Cependant, à cause des tests et du reste du processus, nous n’avons pas pris le risque de choisir un autre PBI. Les programmeurs avaient pour tâche d'examiner l'arriéré et de commencer à développer de futurs PBI (en silence!) et d'informer le reste de l'équipe lors de la planification pour que PBI soit prêt pour la révision et le test du code! juste comme tu as dit.

Cela a en fait soulevé certaines inquiétudes de la part de nos OP: il semblerait que nous en soyons plus capables, mais nous n'utilisons pas pleinement le potentiel de notre équipe, ce qui était en partie vrai, mais oui, peut-être que nos programmeurs pourraient en faire plus, mais que nos testeurs ne pourraient pas suivre cette vitesse. il y avait un risque d'échec du sprint. Après avoir réfléchi à cette question , nous avons découvert que nous devons changer notre point de vue sur Scrum et le principal problème est que les gens ne veulent pas prendre ce risque parce que nous engageons PBIS si l' équipe ne se sentait pas bien de prendre ce risque de cueillette nouveaux PBI dans le cas où nous avons programmeur libre.

Tout simplement nous avons commencé à prévisions PBIS plutôt que de faire l' engagement. La prévision signifie essentiellement que nous sélectionnons 25 points lors de la planification et du début du sprint. Et lorsque le programmeur est libre au milieu du sprint, car il n’ya plus de tâche de codage, il choisit l’un des futurs PBI et le met dans Current Sprint et commence à travailler. dessus, si le PBI peut passer l’ensemble du processus (tests, fusion, etc.) dans le même sprint, c’est un point bonus pour l’équipe si PAS nous n’échouons pas au sprint à cause de ce PBI et que nous poursuivons le travail restant ( test ou meging ou etc) au prochain sprint et re poker pour rester emploi. Donc, cela peut être fait en deux sprints différents dans le pire des cas. Je sais que cela pourrait ressembler à Scrumbut, mais cela a réellement amélioré notre façon de travailler. Je peux juste résumer ses avantages comme ci-dessous:

• Il élimine la phobie de l'échec du sprint en prenant le risque de prendre plus de PBI
• Cela rend visible le travail supplémentaire de vos programmeurs et de votre équipe
• Cela augmente la vitesse de votre équipe

Cependant, peut-être que pour une équipe moins expérimentée, cela réduira peut-être la pression que l’engagement donne à l’équipe pour terminer les PBI

Certaines des autres réponses suggèrent que le développeur "sur-performant" est un "voyou" ou "une violation des principes de Scrum". Ceci est incorrect et ce développeur devrait être encouragé (bien que vous ne devriez pas demander aux gens de travailler sur quelque chose de spécifique pendant ce temps supplémentaire, mais vous pourriez faire des suggestions et aider à nourrir des idées).

Dans Scrum, rien n’indique comment les gens travaillent, et tout ce qu’il ferait de plus serait naturellement intégré à la vélocité de l’équipe.

Son travail devrait être intégré au carnet de produit et évalué lors de la prochaine réunion de planification. Si vous ne pouvez pas prédire immédiatement quels sont les efforts restants, vous devez prévoir un délai du sprint pour le déterminer (c’est-à-dire un Spike).

Il est intéressant que vous décriviez le développeur comme "dépassant les objectifs". Je suppose que cela signifie qu’il ajoute beaucoup plus de valeur que les autres membres de l’équipe.

Les difficultés liées au travail supplémentaire créé impliquent qu'il y a quelque chose de sous-optimal (voire même de dysfonctionnel) dans votre équipe.

Si tel est le cas, vous devriez vous demander pourquoi il en fait tellement plus, avec probablement un petit effort supplémentaire.

Est-il possible pour vous de permettre au reste de l'équipe d'en faire plus?

J'ai vu la situation dans laquelle des équipes ont été micro-gérées, avec des user stories potentiellement trop normatives, avec une définition du terme done, qui finit par étouffer les développeurs. Ce développeur fait-il le travail qu'il veut? Je suppose qu'il prend de bonnes décisions. Travailler de cette façon pendant la semaine de travail aiderait-il aussi le reste de l'équipe?

Demandez-leur aussi d'être un enseignant

Il est bon que vous ayez un développeur star doté des compétences les meilleures et les plus avancées du groupe. Je voudrais louer et complimenter cela. Ces personnes sont souvent le «ciment» qui unit les organisations.

Je considérerais le défi comme "comment rapprocher les développeurs moins expérimentés de la productivité du développeur le plus avancé".

Une excellente façon de le faire est de faire en sorte que le développeur vedette passe plus de temps à enseigner, former et guider les membres de l'équipe moins expérimentés et plus lents. Je voudrais d’abord en discuter en tête-à-tête avec le développeur star afin qu’il sache ce que vous faites et pourquoi. Sinon, il peut être considéré avec suspicion comme un agenda caché / une mauvaise gestion

Lorsque vous vous présentez debout, une ou deux fois par jour, si cette personne manque de travail et que d'autres personnes effectuent encore des tâches, envisagez la programmation en binôme afin qu'elle puisse s'associer aux membres juniors et lui transmettre ses connaissances et son expérience. Assurez-vous de poser la question "Quelqu'un a-t-il besoin d'aide? Quelqu'un cherche-t-il une paire?"

Vous pouvez également trouver du travail de côté pour le meilleur développeur, par exemple pour améliorer l'ensemble des outils utilisés par tous, gérer un groupe de discussion d'un club de lecture technique ou participer à d'autres projets organisationnels.

Je vais répondre à une question différente. Je pense que la façon de gérer cette situation dans Scrum n’est vraiment pas importante. Scrum est plutôt une ligne directrice. Si vous voulez que cela se produise, trouvez un moyen simple d’adapter votre processus, en supposant simplement que le travail est déjà fait.

La vraie question est de savoir si vous voulez que ce dev fasse ce qu’il fait. Je pense que plusieurs aspects jouent un rôle clé dans la réponse à cette question:

1. Le programmeur fait-il du bon travail?
2. Est-ce que tout le monde est d'accord pour qu'il fasse son travail tout seul (qu'il soit bon ou mauvais). Il esquive le processus de conception, après tout!
3. Les heures supplémentaires sont-elles payées ou non?

Tous ces facteurs déterminent s'il est logique pour votre produit qu'il fasse ce qu'il fait. Encore une fois, l’intégration de votre décision dans le processus de conception n’est pas vraiment un problème. Sois juste flexible.

Ceci enfreint un locataire de Scrum car l'équipe ne décide pas du travail dans le sprint. C'est une équipe de mêlée . L’équipe doit discipliner ce programmeur si la discipline doit être remise.

Un autre problème que cela crée est qu’il est lié à la vitesse de l’équipe. Le travail hors bande ne compte pas dans la vitesse et brûle. Donc, ce travail hors bande est terminé, l'équipe a une vitesse moyenne de 50 points, mais plus de 50 points sont obtenus. Le responsable du produit le verra et exigera une vitesse plus élevée lors du prochain sprint. Une vélocité qui pourrait ne pas être possible.

L’équipe (et non le PO ou le ScrumMaster) doit résoudre ce problème avec le programmeur non autorisé.