La capacité individuelle doit-elle être prise en compte dans les récits?

D'après ce que j'ai compris de l'estimation d'une histoire, il faut estimer la taille d'une histoire comme elle le serait pour un développeur imaginaire moyen - un peu comme le concept de «spectateur raisonnable» en droit. Autrement dit, vous ne devez pas estimer la taille de l'histoire en supposant que vous devez le faire .

Pour donner un exemple: dans mon travail précédent, je faisais partie d'une équipe où j'étais de loin le développeur Ruby le plus confiant. Mes coéquipiers estimaient régulièrement que les histoires liées à Ruby étaient beaucoup plus grandes que moi, avec des arguments comme: "Eh bien, je ne sais pas comment X fonctionne dans Ruby, donc cela me prendrait beaucoup de temps."

Mon argument contre cela vient du fait que la planification du sprint est l'endroit où la capacité de l'équipe entre en jeu. C'est le bon forum pour dire: "Notre capacité ce sprint sera légèrement inférieure à la normale car la majorité des tâches sont basées sur Ruby, et nous n'avons qu'un seul développeur Ruby puissant." La prise en compte de cela lors de l'estimation doublerait cet aspect.

J'apprécierais toute référence faisant autorité dans les réponses, mais des opinions simples seraient également excellentes.

Les points d'histoire sont une estimation relative. Donc, deux fois les points signifient deux fois le niveau d'effort. Les estimations relatives sont moins sujettes aux variations du niveau de compétence. La question n'est pas tant de savoir combien de temps vous prendriez pour 1 point, mais que 2 points nécessitent 2 fois plus d'efforts potentiels. Le niveau de compétence pourrait avoir plus d'importance si vous preniez des jours idéaux au lieu de points d'histoire, car vous supposez un niveau de productivité individuel.

Les estimations relatives sont plus robustes. De plus, l'évaluation du récit ne doit pas être effectuée par un individu, mais doit résulter d'un effort collectif de l'équipe . Pour les histoires moins complexes, il y a généralement un accord rapide. Pour les histoires plus difficiles, l'équipe arrivera avec un résultat sur lequel la plupart des membres seront d'accord, et donc implicitement prend en compte le niveau de compétence collective de l'équipe.

Enfin, l'évaluation de l'histoire est effectuée à un moment où les affectations au sein de l'équipe ne sont pas nécessairement déjà décidées. C'est un argument de plus pour ne pas prendre en compte le niveau de compétence individuel. Pour la planification du sprint, vous utiliserez la capacité de points de l'histoire de l'équipe, qui est un chiffre qui évoluera en fonction des performances réelles, afin qu'il s'adapte automatiquement au niveau de compétence global de votre équipe.

En conclusion, la capacité individuelle ne doit pas être prise en compte pour l'estimation. Mais même si cela devait être fait, en raison des estimations collectives et de la robustesse de l'approche relative, cela n'aurait pas tant d'importance.

La réponse canonique est que vous ne devez pas modifier les estimations par développeur. Cela signifierait que vous obtenez des tonnes de points de plus par sprint que vos pairs, et c'est bien parce que les points mesurent la vitesse de l' équipe , pas les développeurs. Les entreprises peuvent estimer la quantité que l'équipe va produire pour obtenir des attentes approximatives de livraison, et tout va bien.

Pourtant, cela cause toutes sortes de problèmes dans la pratique. Que se passe-t-il si vous êtes en vacances cette semaine-là? Que se passe-t-il lorsque le temps de révision arrive et que vous réalisez que vous produisez 200% des points d'histoire moyens pour 110% du salaire moyen? Que se passe-t-il lorsque l'entreprise commence à penser que la vitesse d'une équipe divisée par les personnes est en fait une approximation précise? Que se passe-t-il lorsque l'entreprise se rend compte que vous produisez bien plus de bugs que vos pairs (tout en ignorant que vous produisez bien plus de fonctionnalités)? Qu'est-ce qui constitue des histoires "de la taille d'une bouchée" lorsque les gens ont des morsures aussi variées?

Ce que j'ai découvert au cours de ma carrière, c'est que cela n'a pas d'importance. Le processus est là pour vous servir, et non l'inverse. Si votre organisation doit évaluer si les développeurs sont surchargés, les points d'histoire par développeur sont une bonne solution. Si votre organisation a besoin de mesurer la vitesse de l'équipe, les points d'histoire dev-agnostiques fourniront une image plus claire. Pourtant, ils sont toujours une approximation et vont toujours être maltraités et mal interprétés.

En fin de compte, ce sont des points constitués pour un processus inventé que vous devez adapter à votre environnement.

TL; DR
Nous devons toujours supposer que seuls les développeurs compétents seront affectés à une histoire particulière.

La compétence (ou son absence) n'est pas une insulte. Il s'agit simplement d'une mesure raisonnable des compétences d'un développeur qui n'est ni en retard ni exceptionnellement expérimenté.

Cela peut être une question d'approche d'une entreprise particulière. J'ai vu des entreprises adapter des estimations à des développeurs particuliers. J'ai également vu des entreprises qui appliquaient un système dans lequel trois développeurs sélectionnés au hasard font des estimations d'histoires avant d'assigner un développeur (et non l'un des trois) au hasard à la tâche.

Chaque système peut fonctionner, chaque système peut échouer. La question n'est pas tant de savoir quel système est le meilleur, mais plutôt quels défauts l'entreprise est capable / désireuse de traiter .

En principe, le temps d'étude pour maîtriser la langue / le cadre ne devrait pas être inclus. Tangente mineure: bien qu'ils ne devraient pas exister dans un monde idéal, le temps d'étude des obstacles spécifiques au projet ou à l'histoire doit être inclus.

Il y a de nombreuses raisons de le faire, mais je pense que cette approche est généralement un meilleur choix, car elle reste fidèle à l' intention d'estimer une charge de travail. Cela pourrait être une question de mon avis plutôt que d'objectivité. Je ne peux pas dire avec certitude.

Le temps d'étude est personnel . Il est à la portée d'un développeur particulier qui doit travailler sur une technologie particulière. Elle n'est pas pertinente lors de l'évaluation de la charge de travail d'une user story, car une user story ne concerne que l'application (et la technologie qu'elle utilise).

Le temps d'étude ne s'empile généralement pas. Disons que notre recrue connaît peu C #, et nous estimons qu'il a besoin de trois jours supplémentaires pour comprendre l'environnement avant de pouvoir faire le travail. Comme cela est courant dans de nombreuses entreprises dans lesquelles j'ai travaillé, nous sommes maintenant dans une réunion où nous devons estimer plusieurs histoires d'utilisateurs (individuellement). Par exemple, disons que nous avons trois histoires à aborder.

• Ajoutons-nous trois jours à chaque histoire? Si les trois histoires ont une orientation technique similaire, cela signifie que la recrue n'aura pas réellement besoin de temps supplémentaire sur les deuxième et troisième histoires. Nous avons surestimé le travail de six jours.
• Ajoutons-nous un jour à chaque histoire? Ce n'est pas correct non plus. Si nous finissons par assigner la recrue à l' une des trois histoires, alors nous lui avons échangé deux jours de temps d'étude nécessaires; et nous avons accordé deux jours de temps d'étude inutiles à d'autres développeurs.
• Ajoutons-nous trois jours à une histoire? Comment pouvons-nous garantir que cette histoire sera traitée avant les deux autres? L'intérêt de créer des user stories séparées est que les stories peuvent généralement être abordées indépendamment les unes des autres. La justesse de notre estimation dépend maintenant à la fois de l'hypothèse que notre recrue fera le travail, ainsi que de l'ordre dans lequel il est affecté à ces tâches (si cela est important, par exemple si la charge de travail combinée dépasse un seul sprint).

Remarque :
Il y a d' autres cas où le temps d'étude ne pile, par exemple , si les trois histoires sont sur des sujets différents et nécessitent une manière extravagante des compétences différentes.
Mais pour savoir si c'est le cas ou non, nous aurions besoin de regarder les trois histoires en même temps, ce qui commence lentement à violer le principe d'avoir des user stories indépendantes . Si nous avions abordé ces estimations lors de réunions séparées, éventuellement avec différents développeurs présents; nous ne pourrions pas évaluer avec précision le chevauchement entre les histoires.

Parce que nous ne pouvons pas garantir quelles histoires finiront réellement par être réalisées (le client pourrait refuser une estimation importante) et qui leur sera affecté, il est vain d'essayer de tenir compte d'un développeur particulier à affecter à une histoire particulière. Cela finit seulement par brouiller l'eau.

Au lieu de cela, nous devrions rendre une estimation de la charge de travail en supposant que la recrue a déjà été mise à niveau (et est donc un développeur égal à ses collègues).
Une telle estimation est indépendante du développeur, et l'exactitude de l'estimation ne varie donc pas en fonction du développeur qui finit par être affecté à l'histoire.

Remarque
Il est toujours pertinent de reconnaître qu'un développeur particulier peut avoir besoin de plus de temps pour étudier avant de pouvoir s'attaquer à une histoire particulière. C'est toujours une considération très pertinente. Mais cette considération ne doit pas être attachée à l' histoire , mais plutôt à l' affectation de ce développeur particulier à cette histoire particulière.

Mais, comme je l'ai commencé, cela peut varier d'une entreprise à l'autre. Certaines entreprises pourraient ne pas se soucier du temps d'étude (par exemple, si le développeur devra inévitablement apprendre à utiliser la technologie de toute façon). D'autres peuvent fortement compter sur l'exactitude de ces estimations, car elles influencent la facturation à un client.

En fin de compte, il s'agit de choisir votre poison. Aucune de ces approches n'est garantie d'être plus précise que les autres.

Il s'agit d'un sujet complexe, et il y a des débats fréquents sur le sujet. Je n'aime pas le concept d'opinion "canonique" à ce sujet: il existe différentes opinions qui ont de la valeur. Mais il existe des valeurs, des principes et des pratiques qui devraient guider l'approche.

Ce qui suit est basé sur mes propres opinions travaillant avec des équipes de mêlée depuis plus de 10 ans. Mais c'est juste MON avis.

1. Les récits comme méthode de prévision L'intention initiale des récits était de trouver une méthode rapide pour estimer l'effort dans le but de prévoir ce qu'une équipe peut accomplir pendant une certaine période. Certains des "sommités" indiquent que les points sont utilisés uniquement pour prévoir la portée à long terme (sur une version, par exemple), et non pour déterminer la capacité au niveau du sprint. De plus, le concept est que les équipes appliquent un "dimensionnement relatif" basé sur des valeurs historiques (l'effort X est similaire à l'effort B, qui était de 3 points). Cela accélère le processus d'estimation afin que les équipes n'aient pas à décomposer le travail futur en modules de travail détaillés et à appliquer des heures à toutes les tâches. Les équipes hautement performantes s'efforcent de faire de tous les travailleurs techniques des membres très compétents de niveaux de compétences similaires. (Ce concept sera exploré plus en détail au point 4). Lorsque cela est atteint, le niveau de compétence individuel n'est vraiment pas une variable de dimensionnement. MAIS: Il faut généralement beaucoup de temps et d'efforts concertés pour atteindre cet objectif. Alors ... que faisons-nous avant d'y arriver?

2. Les heures de tâche déterminent la capacité de sprint: selon les mêmes "sommités" qui déclarent que les points sont utilisés pour des prévisions à long terme, ils proposent également que les heures de tâche soient utilisées pour déterminer la capacité de sprint, plutôt que des points. À mon avis, c'est très bien, mais je dirai que lorsque j'ai aidé des équipes de coach à "Haute performance", leurs compétences nivelées se sont établies en moyenne à un niveau où elles pouvaient déterminer avec précision ce qu'elles pouvaient accomplir dans un sprint en utilisant uniquement des Story Points . Encore une fois, cela peut être un objectif vers lequel nous nous efforçons, mais les nouvelles équipes ne sont pas prêtes pour cela. Par conséquent, vous pouvez trouver dans un seul sprint une histoire avec 2 points qui a 12 heures d'effort et une autre avec 25 heures d'effort. Donc que fais-tu? Certaines personnes que j'appelle des "puristes agiles" diront que la taille de l'histoire (en points) doit être indépendante de la durée. D'autres ne sont pas d'accord. Lisez la logique du point 3 et voyez ce que vous en pensez.

3. Story-Pointing par consensus: application du volume, des inconnues, de la complexité, des connaissances

Les équipes se penchent donc sur un travail et doivent se mettre d'accord sur les points qui seront un proxy pour le niveau d'effort. Droite? En supposant que toutes les compétences sont égales, le consensus est facile à atteindre. Mais souvent, les équipes ont un gars qui est un gourou de Java, un autre qui n'est pas si bon en Java (peut-être qu'elle était une personne C # ou .Net ou Cobol et apprend Java). La tâche X pour Bob est donc très simple. Pour Jane, c'est plus difficile.

Les équipes agiles essaient de promouvoir la propriété collective du code et l'expansion / l'expertise. Nous n'attribuons donc généralement pas d'histoires aux personnes en fonction de leur expertise: nous préférons que les équipes travaillent collectivement sur des histoires et apprennent ensemble. Cela correspond au concept de "ralentir pour accélérer": si nous prenons le temps de donner à Jane une expérience avec Java, alors que cela peut nous ralentir au début, nous aurons plus tard des développeurs Java plus compétents. En fait, si nous n'avons qu'un seul expert Java et que chacun travaille sur ses propres domaines d'expertise, nous créons une situation avec de multiples «points de défaillance» potentiels. Que se passe-t-il dans le sprint lorsque 90% du travail est Java, mais Bob (notre expert Java) est malade ou en vacances? En élargissant les compétences, nous éliminons les goulots d'étranglement potentiels et réduisons les risques. Dans cet esprit: Lorsque l'équipe regarde une histoire, elle doit avoir plusieurs concepts à l'esprit lors du dimensionnement. Vous pouvez penser à l'acronyme VUCK pour vous en souvenir.

Volume: Certains efforts sont assez simples, mais nécessitent un grand volume de tâches répétées. (J'ai eu un gars qui a dû copier et reformater plus de 50 tableaux qui a dit que c'était 1 point parce que c'était simple. être déplacé et optimisé. Nous avons donc dû réajuster les points en raison du volume de travail)

Inconnus: Parfois, nous pensons savoir quoi faire, mais nous identifions également certaines inconnues - elles représentent des RISQUES . Et cela implique que nous pouvons rencontrer des problèmes inattendus que nous devons résoudre, repenser ou essayer une solution différente.

Complexité: Celui-ci est assez évident. Certaines solutions sont techniquement complexes. Nous savons exactement quoi faire, mais cela nécessite une expertise technique. La complexité implique également un certain risque, n'est-ce pas? Donc, même si nous avons tous des compétences égales, la complexité technique implique que nous pourrions rencontrer des défis imprévus. Nous pourrions donc agrandir cette histoire.

Connaissances: savons-nous vraiment ce que nous résolvons? Parfois, les clients ne sont pas entièrement clairs sur la solution qu'ils souhaitent, et nous expérimentons un peu. Ou peut-être que personne n'a jamais mis en œuvre cette solution (nouvelle technologie jamais utilisée auparavant) et donc nous ne savons pas ce que nous ne savons pas.

À mon avis, chacune de ces considérations est en fait une approximation de la durée prolongée. Histoire facile, beaucoup de volume? Cela prendra plus de temps, ou nous devons diviser l'histoire. Inconnus? Risque supplémentaire, recherche, expérimentation, cela peut prendre plus de temps ou nous devons diviser l'histoire. Complexe? Risque supplémentaire, besoin de corriger les bugs, de refonte, etc., cela peut donc prendre plus de temps. Je ne sais pas si nous avons les connaissances requises? Nous avons un risque supplémentaire, nous pouvons avoir besoin d'expérimenter, etc., cela peut donc prendre plus de temps ...

Vous voyez où cela va? Ainsi, alors que le concept de points d'histoire nous décourage de penser à la durée lors de l'estimation, d'un autre côté, il serait illogique d'avoir une histoire en 1 point que nous pouvons terminer en 4 heures et une autre histoire en 1 point qui est simple mais qui prendra 2 semaines.

4. Les équipes hautement performantes éliminent les silos et les goulots d'étranglement: parce que les équipes tentent de mettre à niveau tous les membres, elles ont parfois des membres moins expérimentés qui relèvent de nouveaux défis ou vont coder par paires pour partager les connaissances afin de s'améliorer en équipe. Comme mentionné précédemment, c'est une condition requise si l'équipe atteint un jour de vrais niveaux de haute performance.

Donc, si Jane se porte volontaire pour entreprendre cet effort Java et que cela ferait l'effort 2x ou 3x la durée du même effort si Bob le faisait, que faites-vous? Au fil du temps, mes équipes ont décidé de dimensionner les histoires en fonction du niveau d'effort (LOE) / VUCK pour les personnes travaillant. Cela n'a aucun sens pour Bob, le gourou de l'équipe, de dire "c'est un 1" alors que pour Jane, ce ne sera pas facile et cela prendra une semaine, et il faudra du temps à Bob pour le codage des paires et la révision du code. Par conséquent, nous avons augmenté ces points pour refléter la véritable LOE. La prochaine fois qu'une histoire similaire est venue, ce qui était un 8 pour Jane est devenu un 5. Finalement, tout le monde a convenu que c'était un 3. facile. À ce stade, nous savions que nous grandissions en équipe.

TLDR

Non, mais peut-être pas pour la raison que vous pensez.

Version longue

De nombreuses autres réponses ont expliqué que les Story Points devraient être calculés uniquement par rapport à d'autres travaux. C’est absolument vrai. Comme les Story Points estiment la quantité de travail plutôt que le temps nécessaire pour le terminer, il est peu logique de donner des Story Points basés sur un individu.

Par exemple (un de mes favoris), pensez à votre tâche "Creusez un trou". Vous pouvez soit estimer cela en fonction de la quantité de terre à enlever ou du temps qu'il vous faudra pour enlever la terre. Mon ami creuse un tout à un rythme de 3 mètres par heure, j'ai une grande pelle mécanique pour pouvoir en gérer 100! La seule constante est la quantité de terre - c'est donc ce que nous utilisons comme unité d'estimation.

Cependant, une deuxième raison (et à mon avis plus importante) pour écarter la capacité du développeur à estimer les user stories est le fait que presque chaque user story sera probablement travaillée par plusieurs personnes.

Vous pouvez avoir un architecte, un développeur, un testeur, peut-être un deuxième développeur pour faire l'interface utilisateur. Avant que votre histoire d'utilisateur ne soit marquée comme terminée (idéalement déployée et terminée), de nombreuses personnes différentes y auront travaillé. Du coup, l'idée d'estimer sur la base du développeur en question n'a que très peu de sens, la seule façon d'estimer avec précision les efforts de l'équipe sera de mesurer la vitesse des équipes et d'estimer le travail à effectuer par l'équipe.

Il n'y a pas de «je» dans l'équipe et absolument pas de «je» dans la planification agile!