Une augmentation importante de la vitesse est-elle réaliste dans un environnement Scrum?


89

Mon responsable a récemment beaucoup insisté sur l'utilisation de la vélocité comme cible et mesure de la productivité. Nous travaillons actuellement à une vitesse moyenne de 50 points d'histoire. Mon responsable souhaite que nous augmentions ce pourcentage de 40% à 70 points d’histoire (sans augmentation du nombre de membres de l’équipe). Si nous n'atteignons pas cette augmentation, il souhaite que nous fournissions une analyse détaillée en expliquant pourquoi.

L'idée de mesurer la performance d'une équipe en fonction de sa vitesse et de l'utiliser comme cible me semble fausse, mais j'ai du mal à expliquer pourquoi. De l'aide? Pourquoi n'est-ce pas la bonne façon de mesurer et d'encourager la productivité?


19
sensationnel. Le responsable ne comprend pas ce qu'est la vélocité ou pense que l’équipe est relâchée. ou les deux. Lors de la prochaine réunion de planification, engagez-vous à obtenir 70 points et laissez l'équipe lui dire les risques d'échec que cela entraînera
Steven A. Lowe

25
Cela me semble une requête tellement insensée que j'aimerais que vous lui demandiez pourquoi il pense que cela est possible. Si vous donnez déjà 100%, attend-il de vous que vous donniez 140%? Et si vous ne faisiez que des sprints 40% plus longs?
Jonathan Rich

20
La vélocité est censée être une mesure de la rapidité avec laquelle vous pouvez faire avancer les choses. Si vos points de vitesse et d’histoire sont exacts, cela signifie que vous ne pouvez pas traiter l’arriéré dans son intégralité avant la date limite. La chose rationnelle à faire est d’accepter la réalité et de réduire l’arriéré des arriérés ou de donner la priorité à ce qui est là pour que ce que vous accomplissiez soit le plus important. Ou vous pouvez changer la date limite en quelque chose de réaliste.
Michael Shaw

45
Demandez-lui une augmentation de salaire de 40% si vous atteignez ces objectifs, puis augmentez vos estimations pour obtenir l'augmentation de 40%.
mattnz

18
N’est-ce pas plutôt comme demander à un coureur de marathon de courir le marathon en 1h25 au lieu de 2h?
Scroog1

Réponses:


158

Eh bien, il est parfaitement simple d’augmenter la vélocité de 40% - ajoutez simplement 40% de points en plus à toutes vos estimations et effectuez le même travail.

Etant donné qu'il en est ainsi, il devrait être évident que l'utilisation de la vélocité comme cible est fausse, cela encourage simplement les estimations gonflées.

Une réponse moins délicate est que votre estimation suppose déjà que vous allez aussi vite que vous pouvez tout en faisant tout correctement. Le seul moyen d'augmenter réellement la productivité de 40% est soit de faire des heures supplémentaires, soit de ne pas tout faire correctement. Ces deux choses accélèrent les choses à court terme, mais ralentissent les choses à long terme. Et le long terme dans ce cas n’est pas très long, un mois à l’extérieur. La stratégie optimale à long terme est de ne jamais aller plus vite que votre rythme soutenu.

Peopleware aborde avec éloquence la question de l’ obligation de forcer les programmeurs à accroître leur productivité. C’est un classique souvent cité. Mais en général, il ne sera pas facile de changer l’esprit d’un manager qui s’engage dans la voie qui est la vôtre. Votre projet est peut-être en difficulté - il s'agit certainement d'un drapeau rouge.


28
Je crois fermement qu'il n'y a pas de "rapide et sale". "Sale" me ralentit toujours - même à court terme.
Doc Brown

1
@Paul - Je pensais que c'était bien. Mais les conseils qui y figurent ne peuvent généralement être suivis que par les gestionnaires, et ceux qui pourraient en bénéficier ne les liront probablement pas. Le lire ne changera pas nécessairement non plus le comportement.
psr

2
Et si vous acceptez et que vous augmentez réellement la vélocité de 40%, il semblera aux autres que vous et votre équipe ne travailliez pas au maximum de vos capacités. La façon professionnelle de le gérer est de donner une réponse directe: "Non, je ne peux pas faire.". Une autre référence de livre à ce sujet: "The Clean Coder" de Robert C. Martin.
pablosaraiva


1
"votre estimation suppose déjà que vous allez aussi vite que possible tout en faisant le nécessaire" C'est probablement une hypothèse incorrecte. Nous pouvons toujours continuer à améliorer et à optimiser. Les équipes ne doivent jamais présumer que leur vitesse stable indique qu’elles ne peuvent pas s’améliorer. Mais ils doivent examiner systématiquement l'ensemble de leur processus et rechercher des améliorations mineures.
Curtis Reed

53

Comme le soulignent les commentaires, la demande est manifestement erronée. Mais il n'a pas vraiment tort de vouloir améliorer constamment la productivité. En règle générale, c’est ce que les gestionnaires recherchent (et évaluent).

Cela dit, les gestionnaires cherchent toujours à améliorer les performances, et Scrum and Agile est synonyme d’adaptation. Bien que la vélocité soit une mesure de votre rythme soutenu actuel, vous ne devriez pas vous laisser aller à vos lauriers. Scrum a une place pour évaluer et modifier ce qui fonctionne et ce qui ne fonctionne pas dans votre processus: la rétrospective. Si vous en profitez et ajustez votre processus, la productivité (et éventuellement la vitesse) devrait augmenter.

Alors, cherchez-vous (dans vos rétrospectives) des moyens de devenir plus productifs en équipe? Y a-t-il quelque chose dans vos sprints qui consomme régulièrement une quantité démesurée d'efforts? Peut-il être adressé? Cela ne vous donnera probablement pas une augmentation de 40%, mais 5 à 10% est un début, non? Chaque sprint, vous devez rechercher les goulots d'étranglement et y remédier. Finalement, vous pouvez vous rapprocher de l'objectif qu'il vous a fixé.


7
+1: C'est un bon moyen de le décrire au manager. Vous ne pouvez pas augmenter artificiellement la vélocité, mais vous pouvez regarder en arrière après chaque sprint et apprendre ce que vous pouvez faire pour être plus efficace lors du prochain sprint.
Kevin

3
Les chances sont que supprimer les frais généraux du gestionnaire (réunions forcées, remplir des formulaires, etc.) vous donnerait probablement que 5 à 10%, facilement. Mais comment le convaincre?
AviD

2
Je pense que votre réponse représente une incompréhension de la vitesse. Ce n'est pas une mesure absolue, c'est une moyenne mesurée sur la durée de vie du projet. De plus, les points de vélocité eux-mêmes ne représentent pas le travail effectué, mais des mesures approximatives de la complexité. Ils sont également des moyennes eux-mêmes, et une tâche à point bas peut nécessiter plus de temps qu’une tâche à point élevé. Demander «plus» ne semble pas avoir de sens et représente un malentendu fondamental. Le gestionnaire demande essentiellement un délai fixe.
Ricardo Gladwell

3
@RicardoGladwell - Quand j'ai dit "la demande est manifestement erronée", je reconnaissais qu'il s'agissait d'une mauvaise compréhension de la manière dont fonctionne le scénario. Je disais simplement que ce que le manager veut vraiment, c'est que l'équipe améliore sa productivité, et Scrum fournit un moyen de le faire. En outre, il existe différentes idées sur ce que les points d'histoire représentent, la complexité étant l'une des plus courantes. La plupart des équipes avec lesquelles j'ai travaillé les ont fait correspondre un peu avec le niveau d'effort. Une tâche simple avec beaucoup de quantité n'est plus considérée comme simple.
Matthew Flynn

1
Vous mentionnez qu'une augmentation de vélocité de "5-10% est un début", mais cela semble partager l'incompréhension du manager sur ce que "vélocité croissante" signifie que j'ai décrit.
Ricardo Gladwell

26

TL; DR

Velocity est très utile pour estimer les calendriers ou pour générer des valeurs de planification. Il peut également constituer un contrôle de détection significatif pour évaluer les goulots d'étranglement des processus ou les modifications de la capacité de l'équipe. Ce n'est toutefois pas une mesure valable de la productivité.

Quand Velocity est confondu avec les objectifs de gestion

"Velocity" est une gamme qui exprime la capacité moyenne d'une équipe sur une période historique. Il s'agit d'une analyse statistique des performances passées, qui peut ensuite être utilisée pour projeter des estimations probabilistes de la capacité de charge de travail ou des temps de cycle futurs. Cela contraste nettement avec un "objectif de planification", qui est un objectif de gestion qui définit un calendrier ou un objectif à des fins de planification.

Les gestionnaires de projet agiles expérimentés savent que la bonne utilisation de Velocity consiste à déterminer si une équipe a la capacité durable de respecter les objectifs de planification définis par la direction. Parfois, la réponse est oui et tout le monde est heureux. Parfois, la réponse est non. À ce stade, le triangle de fer force les entreprises à prendre des décisions concernant la portée, les coûts, les délais et la qualité.

Évaluez vos options politiques

Nous avons une vitesse moyenne de 50 points d'histoire ... On m'a demandé de l'augmenter de 40% à 70 points d'histoire (sans augmentation du nombre de membres de l'équipe).

En supposant que vos pratiques d’estimation soient saines et que votre vélocité soit raisonnablement stable, votre responsable n’aura aucune joie à ajuster l’échelle d’estimation ou à fixer des objectifs de gestion non basés sur les performances historiques. Comme vous l'avez souligné à juste titre, il s'agit fondamentalement d'un problème de capacité .

La limite de capacité peut être liée au nombre de personnes de votre équipe ou à une limitation de vos processus organisationnels. Bien sûr, ajouter plus de personnes n'augmente pas toujours la capacité réelle du projet. voir la loi de Brooks pour plus d'informations sur cette idée fausse commune.

Le problème que vous rencontrez est politique. D'après le ton de votre message, il semble que votre responsable souhaite une augmentation de la productivité sans modifier réellement la capacité sous-jacente de l'équipe. Les solutions sont donc également de nature politique et essentiellement éducative.

Si vous êtes un magasin Scrum, demandez à votre Scrum Master d’aborder ce problème par le biais des canaux de cadre appropriés. Les rétrospectives de traitement en attente et de sprint sont souvent les occasions idéales d'inspecter et d'adapter ce problème particulier.

Si vous n'êtes pas un magasin Scrum, vous devez choisir le meilleur moyen de répondre à vos préoccupations au sein de votre organisation. Si vous êtes en bons termes avec votre responsable, vous pouvez même lui prêter une copie du logiciel Agile Estimating and Planning pour que vous puissiez en discuter pendant le déjeuner.

Si tout le reste échoue, préparez-vous pour une marche de la mort en révisant votre CV et en faisant de votre mieux professionnel jusqu'à l'implosion du projet. 68% des projets informatiques échouent ; à moins que les objectifs de gestion ne soient fermement ancrés dans la capacité organisationnelle, le vôtre en fera probablement partie.


la qualité n’est pas une variable d’ajustement: c’est pourquoi on parle de triangle de fer et non de carré de fer. En d'autres termes, lorsque quelqu'un essaie de réduire la "qualité", il cause des ravages en termes de retards (livraisons plus longues), d'envergure (les fonctionnalités ne fonctionnent pas et donc pas de réalité) ... et de ressources (les développeurs sont frustrés et partent). Bonne réponse à côté de ce point minute.
Kriss

1
@kriss Quality peut en effet faire partie du triangle. Il est parfois considéré comme faisant partie de "scope" ou, dans certains triangles, il s'agit d'un sommet réel indiquant qu'il s'agit d'une contrainte principale. Voir le triangle bleu dans PMBOK Star comme exemple concret, ou l’ évolution du modèle de contrainte de projet pour plus de détails sur ce sujet. S'il vous plaît apporter cela sur PMSE pour plus.
CodeGnome

C'est une discussion que j'ai déjà eue avec d'autres collègues. En résumé, ce sur quoi nous ne sommes pas d’accord, c’est que le PMBOK est une ressource Agile valide. Elle est née avec le modèle en cascade et est orthogonale à agile. C'est principalement compatible, mais il y a encore quelques problèmes. Considérer la qualité comme une variable d'ajustement en est une. Comme je le vois (et je ne suis pas seul), utiliser (essayer d'utiliser) Quality comme variable d'ajustement interrompt tout le processus Agile. Mais cela devrait être une question à part.
Kriss


21

Je ne comprends pas quel rôle votre manager a dans l'équipe Scrum? Est-il un entraîneur? Est-il un produit propriétaire?

S'il fait partie de l'équipe comme un entraîneur ou autre (il travaille à une tâche de développement), vous pouvez lui demander pourquoi il sous-estime sa propre productivité, car il semble que ce n'était pas le cas pour les autres membres de l'équipe. S'il croit pouvoir assumer personnellement 30 points d'histoire de plus à chaque itération, laissez-le le montrer.

Plus probable: il est en dehors de l'équipe, peut-être le propriétaire du produit? Si c'est le cas, il devrait comprendre qu'il fait une demande aussi stupide qu'il vient d'arrêter l'agilité.

Une règle de base est que le propriétaire du produit définit l'objectif pendant que l'équipe définit ce qui peut être fait lors d'une itération. Ne pas le faire conduit au cercle de fer classique et bien connu: ressources, vitesse, caractéristiques. Choisis en deux! Vous ne pouvez pas en choisir trois à la fois (et rappelez-vous: la qualité n’est pas une variable d’ajustement, essayer de rogner sur une qualité médiocre aggravera encore les choses).

S'il ne veut pas changer l'objectif actuel, peut-être qu'une augmentation de productivité de 40% peut être atteinte en recrutant plus de personnes pour l'équipe? Peut-être investir dans une formation préalable pour certains membres de l'équipe? Les équipes peuvent également gagner en rapidité avec le temps grâce à une amélioration continue, mais certainement pas par une décision arbitraire.

Essayer de changer la vélocité d'une équipe, c'est comme essayer de changer la taille d'une pièce. Cela peut être fait, mais fondamentalement, vous devez changer de pièce.

N'avez-vous pas un Scrum Master, ou d'autres personnes avec une compréhension de base de Scrum, qui pourraient l'expliquer?


15

Dans ce cas, le manager a pris la mauvaise direction après avoir obtenu une estimation honnête et fidèle de l'équipe. Le gestionnaire est censé se tourner vers les parties prenantes et leur faire savoir que leurs exigences ne peuvent pas être satisfaites dans les délais requis. Le responsable / analyste doit ensuite définir les fonctionnalités devant être incluses et les autres pouvant attendre (même quelques semaines). Si la partie prenante se montre déraisonnable, il pourrait alors être nécessaire d'impliquer des gestionnaires supérieurs, ce qui peut généralement être difficile et nécessite toute une série d'autres discussions.

Si j'étais dans vos chaussures , je viens avec un cas en détail pourquoi le projet IS va prendre aussi longtemps que a été estimé. Essayez également d'identifier les articles à faible retour. Recherchez les éléments qui n’ajoutent pas beaucoup de valeur et qui nécessitent des efforts de programmation importants, et plaidez pour les supprimer du sprint. Proposez également une approche itérative qui fournit "X" à la date "Y" et assurez-vous que c'est faisable, puis proposez une itération de suivi qui leur fournira les éléments restants.

Fondamentalement, quelqu'un doit dire aux parties prenantes ce qu'elles peuvent s'attendre à recevoir d'ici la date limite et que cela inclut la majorité de leurs exigences. et que, lors de la publication suivante, ils disposeront des éléments restants. Si le client est déraisonnable, alors la haute direction doit être impliquée, le responsable doit pouvoir y arriver.

Cependant, si le client était promis, et que personne ne s’était exprimé jusqu’à présent, la bataille serait rude. Ce n'est pas une situation rare malheureusement.


1
"estimation honnête et fidèle" peut être le problème.
JeffO

@JeffO - C'est peut-être pour cette raison que j'ai recommandé de justifier les estimations. Lorsqu'ils tenteront de le faire, ils se rendront compte qu'ils ont gonflé leurs estimations ou qu'ils n'ont vraiment pas la capacité.
hanzolo

9

On dirait que vous faites face à deux problèmes.

La partie qui vous dérange dans la mesure de la vitesse est probablement que la mesure est le coût . Ce que vous voulez vraiment améliorer, c'est la valeur . Malheureusement, mesurer la valeur d'un logiciel est notoirement difficile et subjectif. Néanmoins, même une métrique imparfaite et subjective peut être utile. Le problème réel n’est peut-être pas que votre équipe a besoin d’écrire plus de code, mais que les histoires doivent avoir plus de valeur.

L’autre problème est que, selon votre compte, votre responsable s’attend à une augmentation de 40% de la productivité. Votre question ne précisait pas le contexte de cette demande. Cela pourrait être un désir sincère que votre équipe s’améliore. Ou cela pourrait être une indication peu subtile que votre responsable estime que votre équipe est sous-performante.

edit: En fonction de votre commentaire, la situation semble mauvaise. Il semble que votre entreprise prépare le terrain pour vous licencier, ainsi que votre équipe (peut-être votre responsable également). Je vous suggère de chercher un autre travail.


3
Malheureusement, c’était une demande sérieuse, formulée dans le sens suivant: je ne vois aucune raison pour laquelle vous ne pouvez pas atteindre cet objectif (mais je ne vais pas vous dire comment!). L'implication est qu'il ne pense pas qu'ils travaillent assez dur ou qu'ils ne sont pas aussi compétents qu'ils devraient l'être. La situation a empiré lorsque je suis parti en vacances et que le responsable de produit a déclaré à l’équipe que si elle ne l’atteignait pas, elle aurait de graves répercussions. J'ai donc maintenant aussi une équipe très inquiète (à qui je crois vraiment être une grande équipe) et qui doit également m'inquiéter.
P2l

4
+1 pour "sortir de Dodge". Parfois, c'est le seul moyen (mais le moins souvent le mieux).
Michael

9

Renvoie le. C’est-à-dire qu’il va au-delà de la tête et explique qu’il a perdu toute confiance en son équipe et qu’il n’a aucune valeur pour l’entreprise. Expliquez que les gestionnaires présentant ce niveau d'incompétence sont beaucoup plus faciles à remplacer que l'équipe ci-dessous.

Il n'y a pas de bonne raison de supporter un tel manager, mais cela ne signifie pas automatiquement que les développeurs doivent démissionner. Il n'y a pas nécessairement quelque chose qui ne va pas dans l'entreprise, juste avec cette personne. Résoudre ce problème.

Et pour éviter toute confusion de la part de la haute direction, faites bien comprendre que ce n’est pas une erreur pardonnable. Cela indique que le responsable n’a aucune idée de l’équipe qu’il gère. Cela ne se prête pas à la réparation, et il n’est pas nécessaire de le faire sur le marché du travail actuel. Les gestionnaires sont éminemment remplaçables, tout comme les entraîneurs sportifs. Les propriétaires ne renvoient pas d'équipes.

Maintenant, cela pourrait ressembler à une stratégie qui peut se retourner. Mais considérez que si les cadres supérieurs avec votre supérieur, peu importe, vous seriez déjà dans une position perdante de toute façon. Donc, si vous ne considérez que les situations dans lesquelles vous n'êtes pas déjà dans cette position de perdant, le résultat sera probablement beaucoup plus positif. Le vrai risque, c’est que la haute direction congédie l’ensemble de l’équipe, y compris le responsable. Vous seul pouvez estimer ce risque. Apparemment, votre production est recherchée, sinon ils n'en demanderaient pas davantage, mais à quel prix?


5
En d'autres termes, mettez vos mains en l'air, gémissez et faites une crise. Ce genre d'attitude ne résout jamais les problèmes. Il existe de bien meilleurs moyens de gérer la situation.
MrFox

Non. Les lamentations ou les crises sont des actions dramatiques. Cela peut être ignoré. Ce que je propose, c'est un ultimatum. Soit ce manager s'en va, soit l'équipe s'en va. Pas de drame, seulement de la logique commerciale froide. Il n'est pas apte au travail et c'est à la haute direction de le faire. Mais leur option préférée pourrait être d'ignorer la situation, si vous le leur permettez. C'est pourquoi vous devez supprimer ce choix.
MSalters

@nathanhayfield Typique? Je pense que l'équipe serait composée d'un éventail de personnalités et de personnes. Les plus paresseux doivent être adressés individuellement et non par une requête globale à l'équipe.
James Khoury

1
@MSalters Il y a beaucoup de gens dans différentes couches de l'entreprise qui ne comprendront pas certaines choses. La bonne approche consiste à atténuer les conflits et à éduquer toutes les personnes impliquées. Peut-être que ce manager ne comprend pas Agile, mais il peut avoir d’autres qualités qui l’écartent (ce qui pourrait être bien plus important). En tant que professionnel, vous devez tirer le meilleur parti de chaque situation et travailler avec tous les types de personnalité, car c'est réellement constructif et utile à long terme. Faire ce que vous suggérez n'échelle pas.
MrFox

3
@MrFox: Les gestionnaires directs sont supposés comprendre la planification; en fait, ils en sont la couche la plus directement responsable. Les membres de l'équipe sont censés être des experts en la matière et les cadres supérieurs sont plus éloignés de l'action. Donc, ce responsable, dans une position où il fait des déclarations sur les horaires, prouve qu’il ne comprend pas quelle est peut-être sa tâche la plus importante. Si le marché du travail était tendu, il pourrait être gênant de trouver un meilleur gestionnaire. Mais aujourd'hui, vous pouvez trouver quelqu'un de mieux.
MSalters

6

D'après mon expérience, il était très, très difficile d'augmenter la vélocité réelle d'une équipe, car ni l'équipe, ni le domaine problématique, ni la pile de technologies ne changent.

Là où j'ai pu atteindre des augmentations, c'est une question de:

  • épuration de la dette technique; s'assurer que tout fonctionne avec la bonne version (pas nécessairement la version la plus récente!), que le code est bien factorisé et qu'il n'y a pas de redondance dans le système (code dupliqué, code inutilisé, etc.)

  • amélioration des pratiques; le jumelage si possible (oui, j'ai trouvé que cela augmentait la vitesse), en prenant le temps de refactoriser de manière agressive (idem!) et en étant impitoyable quant à la portée et à la focalisation

  • trouver et / ou acheter les meilleurs outils pour le poste (par exemple, ReSharper pour .NET vaut son pesant d'or, Airbrake et Splunk pour le développement de Ruby, etc.)

Je suis d’accord avec d’autres ici qui disent que votre responsable qui demande une augmentation arbitraire de la vitesse est un drapeau rouge. Je chercherais un autre travail en priorité.


3

Votre responsable demande (ou dit) à votre équipe de travailler des heures supplémentaires. Si éliminer les goulots d'étranglement et gagner en efficacité peuvent améliorer quelque peu votre vitesse, le seul moyen d'obtenir cette augmentation (40%) est de travailler plus longtemps, car vous devez augmenter le nombre d'unités de travail au cours de cette période.

Prenons un scénario.

Pour un échange de deux semaines, disons 10 jours. L'utopie serait de 8 heures par jour, un point d'histoire étant résumé par une journée de travail. Donc, en partant du haut, votre vitesse serait de 8. Mais, de manière réaliste, les gens commencent probablement à passer 6 bonnes heures par jour avec des courriels, des réunions, des pauses dans la salle de bain, etc. Donc, votre niveau de référence est 6. Supposons que vous souhaitiez que les gens fassent des heures supplémentaires, maintenant à 10 heures par jour. Donc, ce serait 10 points de vitesse par développeur.

Votre vitesse fluctuera toujours, peut-être était-elle basse parce que vous avez dû faire face à de nombreux bugs lors de cette itération, que les exigences manquaient peut-être, que quelqu'un est tombé malade pendant quelques jours. C'était peut-être élevé parce que le travail avait été surestimé ou que votre équipe avait consacré des heures supplémentaires.

Mais si vous êtes à 50, vous aurez besoin d’heures supplémentaires.


2

Le problème avec Velocity est qu’il s’agit d’une variable dépendante, d’une sortie mesurée de votre processus de développement. Demander d'augmenter la vélocité de 40%, c'est comme essayer de se mettre au travail plus tôt en criant aux voitures d'aller plus vite. La vitesse augmente en introduisant plus de carburant et d'air dans le moteur ou en obtenant une voiture plus rapide, en plus de trouver un itinéraire avec moins de circulation.

Travailler plus d'heures n'augmente pas la vélocité si vous la mesurez correctement, disons en points de fonctionnalités par heure de développeur. Cela ne fonctionne que si vous mesurez des points par jour, puis redéfinissez ce qu'est un "jour" au milieu d'une mesure. Cela ne fournit que l'illusion de vitesse.

Une augmentation de la vitesse nécessite l'amélioration des variables indépendantes dans le processus de développement; des ordinateurs et des compilateurs plus rapides, un système de construction plus efficace, un meilleur processus de conception, des développeurs plus capables, un meilleur espace de travail, une motivation extrême. Une amélioration de 40% nécessiterait des changements très importants.

Demandez si votre responsable envisagerait de regrouper votre équipe dans des bureaux fermés autour d'une salle de travail commune, achetant à l'équipe du tout nouveau matériel de développeur, ou embauchant deux développeurs vraiment expérimentés pour guider l'équipe si cela lui permettrait d'atteindre ses 40%. S'il n'y a pas de ressources disponibles pour améliorer les entrées dans votre processus de développement, cela exclut quasiment tout intérêt sincère à l'amélioration. Cela laisse l’ingénierie inverse à votre responsable pour déterminer ce qui le motive réellement, ce qui ferait l’objet de tout un fil conducteur.


1

Eh bien, je suis un peu surpris que les autres réponses prennent la demande du patron au sérieux. Quelqu'un qui exige une augmentation de 40% de sa productivité ne connaît pas le développement de logiciels.

J'aime toujours lire Phil Factor sur ce sujet:

Il existe deux itinéraires de base dans la gestion informatique. Vous pouvez apprendre votre métier à travers le sang, la sueur et les larmes et gravir progressivement les échelons, en vous basant sur la crédibilité que vous avez acquise grâce au savoir-faire technique durement acquis et aux projets couronnés de succès. Alternativement, vous pouvez enfiler un costume pointu et une cravate, apprendre le jargon et parler en douceur pour vous rendre au sommet.

Les deux voies semblent également efficaces. Traiter avec cette dernière race peut certainement causer des moments de consternation et d'incrédulité… voire de désespoir… et une partie de cela est documentée dans ces histoires.

Cependant, il est facile de devenir triste et aigri lorsque l’on rencontre une incompétence technique aux postes de pouvoir et de ternir tous les cadres. Phil déconseille cela. La plupart des managers travaillent dur et contribuent bien à l'entreprise. Même les plus démunis peuvent être formés selon les normes requises, si vous ne suivez que quelques directives simples. Cela fait partie de la responsabilité de votre équipe d'aider votre responsable à fonctionner de manière à profiter à tous.

En fin de compte, si vous ne pouvez pas les former, obtenir leur promotion ou les éviter, vous pouvez peut-être apprendre à les aimer simplement pour leur contribution involontaire à la riche comédie du monde du travail.

Le conseil de ne pas devenir "triste et aigri" est le meilleur que vous puissiez obtenir. Ne combattez pas un patron techniquement incompétent pour des questions techniques. Il verra cela comme une attaque personnelle.


Eh bien, je pense que cela dépend du modèle de gestion auquel vous souscrivez. Coaching Leader: expert reconnu qui se salit les mains et enseigne aux autres comment être bon, mais reste généralement "le gourou". Directeur de leadership: "l'expert" qui sait tout (ou pense le faire) et donne juste des ordres aux autres et leur dit quoi faire. Leadership par délégation: peut ne pas être l'expert, il fait confiance à son expertise et le facilite. Leadership de soutien: la pom-pom girl du groupe les aide à les renforcer, à les motiver, à persuader l'équipe de le faire et les aide à le réaliser.
Curtis Reed

0

Votre responsable a mal compris l'utilisation de la vélocité. Ce n'est pas une métrique et ce n'est pas une cible. Son but est de calibrer la charge de travail de l'équipe par sprint.
Si vous y réfléchissez, votre vélocité émerge d’une meilleure estimation, que vous réévaluez après chaque sprint. Habituellement, à mesure que le temps passe, il devrait devenir quelque peu stable. Mais cela ne change pas le fait que c'est un sous-produit de ce que votre équipe fait réellement: créer de la valeur pour vos clients.

La raison pour laquelle il est erroné de l'utiliser en tant que cible et / ou métrique est que cela en ferait une métrique de vanité. Cela semblerait bien sur papier, mais cela ne ferait absolument rien de refléter si vos produits répondent pleinement aux besoins de vos clients. Et c'est ce qui est le plus important (j'espère).


pour autant que je sache, ceci est déjà expliqué dans une autre réponse : "une plage qui exprime la capacité moyenne d'une équipe sur une période historique. Il s'agit d'une analyse statistique des performances passées, qui peut ensuite être utilisée pour projeter des estimations probabilistes de la charge de travail future. capacité ou temps de cycle ... "
gnat

@gnat en fait partie, oui, bien que cette réponse ne dise rien sur l'utilisation de la vélocité comme métrique de vanité, ce qui est toujours important, car de nombreux gestionnaires font des choses stupides basées sur des nombres proxy. L'OP a déclaré qu'il pensait que c'était faux, mais ne pouvait pas l'expliquer. J'ai senti que le terme métrique de vanité (de The Lean Startup) offrait une bonne explication.
Stefan Billiet

-1

En ce qui concerne mon expérience et aller droit au but.

Premièrement, vous pouvez gonfler l'estimation, mais cela ne signifie pas que vous en faites plus.

Deuxième (principe: sans gonfler, se concentrer uniquement sur la vitesse de l’équipe),

Essayez de trouver les compétences au sein de votre équipe. Travaillent-ils sur ce qu'ils sont les meilleurs? Avez-vous besoin d'un architecte de systèmes pour prendre les décisions difficiles concernant la construction de l'application et les choses complexes? Comment l'équipe dépense-t-elle ses efforts? Ils passent du temps à chercher des solutions à leurs problèmes, à refactoriser, à prendre des décisions commerciales ou quoi?

Sont-ils à l'aise, concentrés et estimés? Quelle est la suite pour eux?

Ce n'est pas "je suis poussé sur les limites" ... c'est plutôt une question pour toute l'équipe "Sommes-nous sur les limites?" et "Comment pouvons-nous repousser les limites?" ...

J'ai des équipes dirigeantes de haut niveau (pour les premières constructions et / ou les migrations) ... la motivation de l'équipe est la clé du succès ... et il est essentiel de prévoir la base de l'application. Parfois, un collaborateur ou moi-même acquérons le rôle d'architecte de systèmes et décidons comment et où la "chose" devrait aller.

Parfois, quand je vois que mes coéquipiers perdent en efficacité, j'essaie de faire une pause et je les invite à sortir boire un verre de bière ou quelque chose qu'ils aiment. Cela résout tous les conflits et le lendemain, ils sont à nouveau concentrés.

VENTE...

Si vous expliquez les raisons pour lesquelles vous ne pouvez pas augmenter la vitesse est difficile, utilisez le retour sur investissement.

Scrum se concentre sur ce qui est le plus important pour le client. Théoriquement les tâches les plus rentables.

Si vos problèmes concernent la vente de l’effort de développement, que pensez-vous de la valeur du retour sur investissement de l’effort de développement, convertissez directement les points d’histoire en "prix". Si vous pouvez prouver que votre équipe travaille avec un retour sur investissement élevé, qui va vous interroger? De plus, chaque équipe a ses limites si l’équipe a trouvé sa "taille confort", essayez d’augmenter légèrement de mois en mois, si elle ne peut pas terminer toutes les tâches, c’est (probablement) la limite.

Affichez l’historique des tâches, le chiffre d’affaires (le cas échéant), le récit que vous avez utilisé et montrez que la productivité n’est pas l’effort de l’équipe est un calcul déterminé par l’équipe pour évaluer la complexité et peut-être le temps d’obtenir quelque chose. terminé

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.