Je suppose que vous êtes le responsable technique.

Demandez des priorités

Dès que vous connaissez la liste des tâches, envoyez un e-mail à votre responsable:

Bonjour [Nom], (ou Bonjour Monsieur (s) [Nom] si vous n’êtes pas si proche)

J'ai vu les tâches que nous sommes censés prendre en charge pour ce sprint et, sur la base des estimations, nous ne pourrons pas nous en occuper toutes. Pourriez-vous s'il vous plaît hiérarchiser la tâche?

Cordialement,

[BlahBlah[/

(vous pouvez également présenter une liste de priorités et demander un accord)

De cette façon, s'ils répondent et que vous ne faites que des tâches prioritaires, vous pouvez l'utiliser comme argument. S'ils ne répondent pas, vous pourrez leur dire que vous avez émis une alerte et qu'ils l'ont ignorée. Vous avez fait votre travail.

Arrêtez de travailler dans une 'zone crépusculaire'

En tant qu'entreprise, une décision doit être prise: voulez-vous évoluer vers une manière Agile de travailler avec les Sprints et toutes les autres choses que cela implique ou voulez-vous adopter une approche plus «classique»?

Si des sprints doivent être utilisés, alors les seules personnes qui peuvent décider du travail qui sera effectué dans un sprint sont l'équipe Scrum: le product owner et les développeurs . Notez qu'il n'y a pas de «chef de projet» dans ce scénario. Le Product Owner est celui qui décide de la priorité de toutes les différentes histoires et fonctionnalités, puis l'équipe Scrum décide lors de la planification du sprint quels éléments ils vont ramasser au cours de cette itération. Il n'y a pas de place ici pour que quiconque oblige les développeurs à faire plus de travail. Si les différents chefs de projet (qui deviendront parties prenantes de la nouvelle structure) veulent que les priorités changent, ils devront convaincre le product owner de changer les priorités. Si, pendant un sprint, il s'avère que les histoires sont toutes terminées (y compris les tests) et qu'il y a de la place pour plus de travail, l'équipe Scrum aura une réunion rapide pour décider quelles histoires elles prendront dans le sprint en plus des histoires qui étaient décidé lors de la planification du sprint. Si plusieurs parties prenantes ont des priorités contradictoires, le propriétaire du produit doit avoir une réunion avec eux tous et leur demander de décider ensemble quelles devraient être les priorités, dont ils peuvent ensuite tenter de convaincre le propriétaire du produit.

Dans une approche plus classique, quelque chose de similaire devrait se produire. Étant donné que les chefs de projet ne sont pas ceux qui font le travail, ils devraient laisser le jugement de ce qui peut être fait dans un délai donné aux experts: la technologie mène. Ils peuvent toujours demander plus, mais doivent faire confiance au jugement des responsables techniques. Si plusieurs chefs de projet dépendent du même groupe de personnes pour accomplir leurs tâches, ces chefs de projet devraient décider entre eux de l'ordre de priorité des tâches, puis faire confiance aux responsables techniques pour s'assurer que cet ordre est respecté. Dans ce cas, il n'y a pas de `` but extensible '': le travail est terminé par ordre de priorité et si quelqu'un arrive à manquer de tâches, il remontera la chaîne alimentaire proverbiale pour demander quelle devrait être sa prochaine tâche.

En essayant de travailler de manière classique dans une structure Agile / Scrum de sprints, une pression incroyable est créée sur les développeurs, ce qui est pratiquement toujours contre-productif. Dans une structure aussi classique, il ne devrait jamais appartenir au développeur de décider s'il doit travailler sur une tâche pour un chef de projet ou pour l'autre, car il est incapable d'évaluer correctement quelle tâche a la plus grande valeur commerciale. La façon de travailler qui semble être décrite dans la question ici mènera à l'épuisement des développeurs, ce qui conduira les développeurs à partir pour des pâturages plus verts.

Que faire si les chefs de projet logiciels surchargent agressivement les responsables techniques?

Vous devez gérer leurs attentes en établissant des limites . C'est un sujet sur lequel vous pourriez écrire des livres entiers. Je ne couvrirai donc que le problème spécifique que vous continuez à rencontrer: les PM surchargent votre équipe de demandes qu'ils savent être déraisonnables.

La façon dont ils ont formulé cela en fait vous aide beaucoup, car il est facile de repousser. La prochaine fois qu'un PM vous demandera pourquoi les fonctionnalités X n'ont pas été effectuées, votre réponse devrait couvrir certaines des phrases ci-dessous:

• Comme vous le savez, nous avons fait plus que nous pouvait livrer donc nous devions prioriser X, Y et Z.

• Comme vous vous en souvenez, j'ai mentionné que nous ne pourrions pas faire plus que X et que nous ne ferions que O si nous étions significativement en avance sur le calendrier.

• Notre estimation initiale était assez précise, nous n'avons donc pas eu le temps de l'examiner.

Si vous prenez une charge de travail régulière, un PM ajoute des fonctionnalités supplémentaires en plus de cela et se plaint ensuite pourquoi ces extras n'ont pas été faits, utilisez une variante de:

• Si je comprends bien, X et Y étaient considérés comme des extras que nous prendrions si nous avions encore du temps. Notre estimation / objectif d'origine était assez précis, nous n'avons donc pas pu prendre celui-ci.

• Je ne suis pas sûr de suivre, vous avez dit que c'étaient des cibles extensibles, n'est-ce pas? Nous nous sommes concentrés sur les cibles principales (X, Y et Z) et celles-ci sont terminées mais nous n'avons pas eu le temps de prendre les cibles extensibles.

Si vous utilisez un modèle de livraison agile, il peut être utile de contourner le jargon:

• comme indiqué, c'était un objectif extensible qui était en dehors de nos prévisions
• nous avons dû affiner le backlog
• nous devrons le pousser au prochain sprint

Le but est de préciser que votre équipe a une capacité limitée et que vous devez évidemment établir des priorités lorsque vous êtes affecté plus que ce que vous pouvez réaliser.

Notez que tout ce qui précède ne fonctionne que si vous êtes dans une position semi-forte, ce que vous devriez être en tant que responsable technique. Repousser les exigences irréalistes est toujours délicat car elles ont tendance à provenir de personnes irréalistes. Vous devez savoir comment repousser les gens qui demandent plus d'heures que votre équipe ne peut pratiquement en offrir, qui insistent sur les heures supplémentaires quand cela n'a pas de sens de demander à votre équipe, qui disent que quelque chose est un objectif ambitieux alors qu'ils pensent vraiment. "Je ne prendrai pas non pour réponse". Bien gérer cela vient avec l'expérience.

En supposant que vous connaissez votre vitesse, vous êtes limité par le nombre de points d'histoire que vous pouvez compléter.

L'entreprise doit hiérarchiser la charge de travail avec le chef de projet.

Je ne peux pas recommander de surcharger le sprint (car si vous ne livrez pas ce qui a été convenu, cela va à l'encontre de l'objectif de planification et d'être Agile). Si les histoires ne sont pas livrées à temps, la responsabilité incombe finalement au PM.

De plus, en supposant que le PM soit raisonnable (et sache comment travailler en Agile), ils devraient savoir que si quelque chose est ajouté au sprint, alors quelque chose d'autre doit être supprimé - c'est aussi leur responsabilité.

Si vous craignez que ce soit votre faute, ne le soyez pas . La responsabilité s'arrête au chef de projet pour gérer correctement le projet.

Modifier: il suffit de relire votre message - une ' cible étendue ' est parfaitement acceptable. Cela signifie simplement que, si l'équipe termine tout le travail de sprint, vous pouvez alors apporter du travail supplémentaire ... mais seulement si vous terminez ce qui a été convenu. Cela arrive rarement, d'après mon expérience.

C'est le travail du responsable technique de gérer les attentes du PM. C'est le travail du PM de faire avancer le projet et de le faire correctement, aussi vite et qu'il le peut.

En tant que responsable technique, voici quelques conseils pour améliorer cela:

• Exigez que toutes les demandes pour compléter "Plus de points" soient des demandes spécifiques pour les histoires qu'ils souhaitent voir priorisées sur le travail en cours.
• Expliquez que vous faites le travail tel qu'il est priorisé sur le tableau. Que votre équipe travaille aussi vite et diligemment qu'on peut raisonnablement s'y attendre, et que si le PM a des inquiétudes au sujet de certains membres de l'équipe qui ne font pas leur poids, il doit s'adresser au chef d'équipe.
• Suggérer que si votre PM souhaite voir une augmentation des points MVP complétée, la meilleure façon serait d'augmenter la taille de l'équipe. Veuillez noter que si vous avez une date limite imminente, cette option n'est pas pratique. S'il vous reste des mois de travail, c'est le cas.
• Lorsque votre PM essaie de faire quelque chose en dehors de la méthodologie Agile, vos pratiques commerciales vous expliquez au PM ce qu'il fait, pourquoi c'est un problème, et comment répondre correctement à leurs préoccupations dans le cadre de la méthodologie utilisée.

Nommer des choses est la moitié de la bataille.

Ne les appelez pas des "cibles extensibles", appelez-les systématiquement "préparer le prochain sprint". Si vous êtes directement mis au défi, vous pouvez dire "nous n'avons pas d'objectifs agiles, nous avons des prévisions et il n'y a pas de prévision étendue".

Si d'autres personnes cessent de les appeler des cibles extensibles, vous ' J'ai probablement gagné.