Mesures agiles pour les équipes et les projets

Partager!

Il y a quelques semaines, j'ai eu une vidéoconférence avec quelqu'un au sujet de la gestion d'équipes multidisciplinaires, distribuées et à grande échelle. Il y a quelques années, j'ai inventé le terme "agilité pour les adultes"Cela représente en quelque sorte le fait que, au-delà des phrases aspirationnelles et aspirationnelles qui sonnent bien, le défi de l'agilité conçue pour réaliser de grandes choses est de mobiliser une grande structure organisationnelle pour mener à bien des initiatives ou des réalisations d'ordres de grandeur supérieurs. Au cours de cette conversation, la question suivante est apparue : comment construire des indicateurs et des métriques agiles pour suivre l'opération ? des métriques agiles qui nous permettent vraiment de voir si nous sommes bons ou si nous réussissons dans nos projets ? quelles métriques agiles nous permettent de prendre des décisions mieux informées ?

Codificación y texto resaltado en el editor

Toutefois, pour les besoins de cet article, je tiens à préciser que je suis un amoureux du codage ou du développement de logiciels - je ne suis pas un développeur de logiciels. codage. La vie professionnelle m'a conduit sur les chemins de la gestion d'équipe et de projet, mais je n'ai jamais cessé de "jeter" du code. Jamais pendant plus d'un an. Parfois, je le fais comme un hobby. Je prends régulièrement des cours sur une plateforme en ligne pour me tenir à jour ou je participe à des projets de développement en ajoutant quelques lignes de code. Du sous-estimé PHP même puissant Allez sur. Le codage est une chose qui me passionne. Grâce à cette combinaison de gestion des personnes et de rédaction de lettres colorées. [1] Dans les éditeurs de code source les plus populaires, il est habituel d'avoir une fonction appelée coloration syntaxique qui met en évidence les mots clés, les instructions et les symboles, ce qui permet de différencier plus facilement le code et sa structure. J'ai eu la chance de participer, de coordonner et de diriger des projets réunissant quelques, plusieurs ou des centaines de personnes, entre la conception, le développement, les essais et l'exploitation.

Cet article est un bref résumé des métriques, indicateurs et tableaux de bord sur lesquels j'ai travaillé avec succès au fil des ans et qu'aujourd'hui, dans mon rôle de consultant, j'aime mettre en œuvre avec les équipes que je sers.

Mesures, paramètres et indicateurs

Pendant longtemps, j'ai pensé que mesure, métrique et indicateur étaient essentiellement les mêmes. Avec le temps, j'ai découvert des différences subtiles et, avec l'expérience, j'ai fini par comprendre la grande distance qui les séparait.

Quelle est donc la différence entre les mesures, les paramètres et les indicateurs ? Examinons quelques définitions et un exemple de bonnes définitions.

DéfinitionExemple
MesureC'est le résultat de la comparaison entre une quantité (ce que l'on veut mesurer) et une valeur de référence constante ou standard (mètres, octets, kilogrammes).10 exigences
5 défauts de faible priorité
3 livraisons
4 itérations
MétriqueLa combinaison de deux ou plusieurs mesures pour fournir des ratios ou des relations.100 kilomètres par heure
50 gigaoctets par seconde
30 points de récit par itération
IndicateurIl s'agit d'une note ou d'une valeur d'évaluation qui nous indique quelque chose par rapport à un résultat.Conformité 100%
Performance du 3%
A+ à un examen

Exemple comparatif entre mesure, métrique et indicateur

Pour comprendre la différence dans un exemple où nous utilisons des mesures, des métriques et des indicateurs, je voudrais donner l'exemple suivant.

Joanna a passé un test de 100 questions et a obtenu 50 réponses correctes.

Évaluation subjective des données

A votre avis, comment Joanna s'en est sortie ? Voyons voir.

  • Joanna a passé un test de 100 questions (mesure).
  • Selon les créateurs du test, Joanna a répondu correctement à 50 questions (mesure). Cette mesure résulte de la comparaison de chaque question et de sa réponse avec la question et la réponse attendues (norme).
  • Joanna a obtenu 50% de questions correctes (métrique). Cette métrique est le rapport entre le nombre total de questions et le nombre de questions correctes.

Expériences et jugements de valeur

À ce stade, vous vous dites probablement : "Joanna a échoué". La vérité est que vous utilisez une métrique comme indicateur. Vous le faites en supposant que le but du test était d'obtenir 100% des bonnes réponses. Cela peut être correct à l'école et à l'université, mais dans le contexte de l'entreprise, ce ne sont que des jugements de valeur - des opinions très subjectives.

Pour définir ou identifier un indicateur, ajoutons un peu plus d'informations à l'exemple.

Après avoir évalué plus de 15 000 tests effectués sur le même nombre de personnes, nous avons constaté que Joanna a obtenu l'un des meilleurs scores, surpassant plus de 99% des personnes testées (indicateur).

Moment où je suis lent ! C'est devenu intéressant. Bien qu'elle n'ait répondu correctement qu'à 50% des questions, Joanna fait partie des 1% les mieux notés. Qu'en pensez-vous maintenant ? Avez-vous une idée de Joanna et de sa performance ? Avez-vous l'impression que 99% vous dit quelque chose ? Pouvez-vous donner une opinion plus objective de Joanna et de son test ?

C'est certainement le cas. La 99% nous indique que Joanna fait partie des 150 premiers sur 15 000. Et bien sûr, nous pouvons être sûrs que Joanna fait partie des bons - ou des moins mauvais, si vous êtes un peu pointilleux sur le fait qu'elle n'a répondu correctement qu'à 50%. Dans les deux cas, ce numéro (99%) est un indicateur. Si 50% était une métrique froide qui, en vertu de certains préjugés ou paradigmes, était considérée comme un indicateur, 99% nous dit quelque chose et réduit l'objectivité de notre jugement.

Comment définir correctement les indicateurs et les métriques agiles ?

Maintenant que la différence entre mesure, métrique et indicateur est claire, je vais donner des exemples d'indicateurs et de métriques pour l'agilité. Cependant, il n'est pas possible de définir des mesures et des indicateurs qui s'appliquent à tous les contextes. Afin de garder l'article simple et agréable, je vais fixer deux objectifs différents :

  1. Mesurer la performance d'une équipe agile à l'aide d'indicateurs et de métriques
  2. Mesurer la performance d'un projet et sa progression jusqu'à son achèvement

Bien que de nombreuses mesures soient les mêmes, les paramètres et les indicateurs cherchent à établir des relations et des indications différentes. Je ne dois pas oublier la temporalité des projets, c'est-à-dire que dès leur conception, ils ont un début et une fin.

Par exemple, si vous êtes responsable du secteur informatique d'une organisation, dans des conditions normales, vous ne penseriez pas à démanteler arbitrairement l'équipe. Cependant, lorsque nous parlons de projets, nous pensons inévitablement à une équipe qui, avec une certitude absolue, doit être désintégrée - et c'est ce dont nous parlons. ajournement diraient les connaisseurs.

Que sont les Story Points ?

Ceci est un article sur les métriques agiles. Un concept que je dois clarifier avant de poursuivre est celui des points d'histoire. Points de l'histoire o SP. Cependant, cela ne veut pas dire que je parle exclusivement de Scrum. Pour comprendre comment fonctionnent les mesures de l'équipe agile, nous devons définir le contexte et déterminer :

  1. Une période de mesure, comme les sprints dans Scrum, les itérations - en termes génériques pour tous les modèles agiles et hybrides, ou les incréments de programme dans Scrum. SAFe.
  2. Définir une unité de mesure de l'effort - qui, espérons-le, inclut la complexité et le risque d'une manière ou d'une autre. Imaginez que vous deviez consolider un tableau de bord multi-équipes avec des heures-personnes, des points de fonction et des PS - c'est de la folie pure !

La première est simple, elle consiste à définir une période de temps fixe - une semaine, une itération, un mois, un trimestre ou une année. Le deuxième point nécessite une discussion plus approfondie. Les unités de mesure les plus courantes que nous utilisons pour mesurer l'effort sans :

  1. Heures-personnes - le nombre d'heures nécessaires à l'exécution d'une tâche ou à la réalisation d'un produit livrable.
  2. Personne idéale pour les journées - le nombre de jours idéaux, c'est-à-dire sans interruption ni changement de tâche, qu'il faudrait à une personne pour accomplir une tâche ou un produit livrable. Les journées idéales sont presque toujours accompagnées d'un facteur de productivité. C'est-à-dire que 3 jours idéaux avec un facteur de 50% signifie qu'il faudra 6 jours pour terminer.
  3. Points de fonction - difficile à expliquer si vous n'êtes pas un programmeur, mais je laisse une lien pour les curieux.
  4. Points d'histoire

Mais que sont vraiment les Story Points ? Laissez-moi vous expliquer avec un exemple simple.

Définition des points d'histoire

Les points d'histoire - Points de l'histoire o SP - sont une unité de mesure pour exprimer une estimation relative de l'effort. Cette estimation envisage une seule valeur :

  • Effort
  • Complexité
  • Risque

Pour comprendre le concept, voici un exemple.

Une personne doit installer 20 fenêtres dans un bâtiment de 10 étages. Toutes les mêmes, de mêmes dimensions et ancrées avec les mêmes mécanismes. Le bâtiment ne présente aucune modification structurelle qui impliquerait des changements dans le processus d'installation.

Un planificateur pourrait supposer que si l'installation d'une fenêtre prend 20 à 30 minutes, le processus total d'installation des 20 fenêtres prend 400 à 600 minutes.

Cependant, si l'on considère que toutes les fenêtres ne sont pas situées au même étage et qu'il existe un risque supplémentaire dû à la hauteur, on pourrait supposer que : [2] L'exemple des fenêtres est bien sûr simplifié à l'extrême pour souligner le fait que la durée d'une activité n'est pas la seule variable prise en compte dans le calcul de la PS. :

  • Les fenêtres des 3 premiers étages ont un score relatif de 1SP
  • Les fenêtres des étages 4 à 8 ont un score relatif de 2SP - risque et complexité accrus
  • Et les fenêtres des étages 9 et 10 ont un score relatif de 3.SP - un risque et une complexité beaucoup plus grands

Comme vous pouvez le constater, les psychologues scolaires considèrent que plus l'altitude est élevée, plus la complexité ou le risque est grand. Nous n'évaluons pas seulement la durée des activités, nous prenons également en compte d'autres dimensions telles que le risque ou la complexité.

Les points d'histoire sont une unité de mesure relative qui n'a de sens que lorsque vous avez plus d'une demande. Établir qu'une demande ABC, hors contexte, pèse 3SP, 5SP o 20SP n'a pas de sens. Cependant, pour dire que ABC est 3SP et XYZ est 5SPnous indique que Y représente presque deux fois plus de SP (effort + complexité + risque) que X.

Métriques pour une équipe agile

Au-delà des projets, il existe un univers de gestion où l'on peut considérer le travail comme continu et indéfini. Je sais, personne ne vit éternellement et à notre époque, beaucoup de gens ne tiennent même pas deux ans dans leur emploi. Cependant, la façon dont nous comprenons la performance d'une équipe est continue.

Quelles sont les mesures utiles dans une équipe ? Voici les plus courantes

Capacité : combien pensons-nous pouvoir réaliser ?

Capacidad de trabajo del equipo

Ma définition préférée de la capacité - capacité - est : la quantité de travail que nous estimons ou le projet que nous pouvons réaliser dans une période de temps définie.

La capacité est mesurée (métrique) en heures-personnes, en points de fonction ou en points de récit. Nous n'avons pas toujours les informations nécessaires pour définir la mesure dans une unité particulière, et une partie du travail d'un Scrum Master ou d'un facilitateur dans des rôles tels que RTE, DASSM, sera de valider que les métriques et la mesure définies soutiennent le contexte de l'organisation et ne sont pas un "mal de tête" plutôt qu'un "soulagement". [3]Dans le monde agile, l'estimation relative est privilégiée. Parmi les pratiques les plus populaires d'estimation relative, on trouve le Planning Poker - Planification du poker. De même, les story points sont l'unité la plus couramment utilisée, mais ils ne sont pas la seule option.

Vitesse : Quelle est la capacité et combien avons-nous réalisé ?

La vélocité est un concept associé à la quantité de travail qu'une équipe peut effectuer ou terminer dans une période donnée. Il a été conçu à l'origine pour mesurer la "productivité individuelle" dans les équipes de programmation eXtreme (XP) - ce qui n'a pas plu à certaines personnes. Il était à l'origine utilisé pour la vitesse -vélocité- pour déterminer le "facteur de charge" d'une équipe. Le facteur de charge était un concept alambiqué qui a été remplacé par les points d'histoire.

Aujourd'hui, la vélocité est un nombre de points - d'effort relatif, comme les PS - dans une période donnée. Nous pouvons les classer en deux catégories :

  • Vitesse prévueNombre de points qu'une équipe prévoit de réaliser dans une période.
  • Vitesse réelle : Nombre de points qu'une équipe a effectivement achevés au cours d'une période - Il convient de noter que, dans Scrum, "achever" comprend le travail de l'équipe de développement et l'approbation du PO - c'est-à-dire achevé et approuvé.

Conformité : qu'avons-nous réalisé avec succès ?

Métricas al final de una iteración

La réalisation peut être définie comme la quantité (mesure) de travail qui a été effectivement fournie ou résolue dans une période de temps définie (autre mesure). Cependant, dans des contextes de forte variabilité, j'aime séparer ou décomposer cette métrique en deux :

  1. Conformité au plan : quels éléments de ce que nous avions prévu de faire avons-nous pu mener à bien ?
  2. L'épanouissement par rapport à l'effort : quelle proportion de ce que nous pensons pouvoir accomplir a été réalisée ?

Bien qu'à première vue, on puisse penser qu'il s'agit de la même chose. Et sûrement que certains Scrum-maniac considère que dans un délai de Sprint nous ne pouvons pas inclure de travaux supplémentaires. Cependant, ce n'est pas toujours le cas[4]Le terme Scrum-maniac désigne l'amour aveugle et l'ignorance des réalités d'un modèle de gestion académique. Je suis surpris par le caractère politiquement correct de ma définition. .

Si le délai le permet, ou si l'ampleur du travail - portée - est extrêmement variable, il est très probable que nous trouvions de nouveaux éléments ou même que nous en échangions certains - que nous considérons comme d'ampleur similaire. Dans ce contexte, les tâches prévues au début de la période ne sont pas nécessairement un bon indicateur de conformité.

Variabilité : Quelle est la stabilité de notre plan ?

Variabilidad y la necesidad de adaptarnos en el equipo

Par conséquent, si la conformité exige de comprendre dans quelle mesure le plan original - ou le plan défini au début de la période - a changé, envisager une métrique qui évalue dans quelle mesure le plan original a changé peut être très utile et révélateur pour l'équipe.

Le calcul de la variabilité peut être un défi et demande beaucoup de discipline. Ce que nous voulons éviter, c'est de travailler sur des choses qui ne contribuent ensuite en aucune façon à nos mesures. Par conséquent, chaque nouvelle activité ou tâche au cours d'une période donnée doit être marquée ou classée comme faisant partie du plan initial, ou comme nouvelle et inattendue.

Qualité : comment faisons-nous le travail ?

Métricas de Calidad para Equipos

Eh bien, nous ne pouvions pas laisser de côté la qualité. Dans ce cas, j'aime considérer la qualité comme une relation avec la quantité de travail fourni. De nombreuses équipes se contentent de "compter" les défauts ou les incidents. Comme vous le savez peut-être déjà, c'est une erreur. La mesure n'est pas une métrique et encore moins un indicateur.

Le dictionnaire définit la qualité comme suit :

Propriété ou ensemble de propriétés inhérentes à une chose, qui permettent de juger de sa valeur.

Dictionnaire de la langue espagnole

C'est ainsi que certains auteurs appellent une métrique de qualité que j'aime utiliser, taux de défautQuel pourcentage de la livraison est, d'une manière ou d'une autre, compromis ou affecté par des problèmes liés à la qualité ?

Une mesure similaire - et ma préférée - est la densité de défauts. Cette métrique est un rapport entre le nombre de défauts et la livraison.

Mesures pour les projets agiles

Bien sûr, les projets peuvent bénéficier des mesures de l'équipe. Cependant, à la différence de l'équipe, ils se dirigent vers un achèvement ou une fermeture particulière. De même, les indicateurs de projet peuvent être utilisés pour le suivi d'une version - et peuvent être utilisés pour suivre l'avancement d'un projet. libération.

Progrès : quel chemin avons-nous parcouru ?

En définissant un objectif à atteindre, il est possible d'établir une mesure de la progression. Pour ce faire, nous avons besoin de l'un des éléments suivants - bien que j'essaie personnellement de définir les deux :

  1. Une date - jalon
  2. Un objectif spécifique - en fonction du produit ou du service en cours de développement

Une fois la limite ou l'objectif fixé, nous pouvons définir une métrique de progression basée sur la quantité de travail accompli et son impact sur l'objectif - souvent appelée valeur, par opposition à la capacité totale prévue pour atteindre l'étape.

Danger ! Progression jusqu'à l'achèvement sur une plage variable

La principale difficulté pour mesurer les progrès dans un "adaptatif "contexte est la quête constante de la fermeture du champ d'application. Il est difficile, et pour certains même ennuyeux, de suivre les progrès d'une cible en mouvement. Dans le contexte agile, le concept de objectif o valeur et est préféré à portée. Ainsi, la portée peut varier en fonction de l'objectif à atteindre.

Exemple d'une cible fixe à portée variable

Prenons un autre exemple, mais cette fois-ci, laissons Joanna tranquille.

C'est vendredi soir et Pedro, un célibataire sur le point d'avoir 30 ans, veut sortir et s'amuser. Cependant, il n'a pas beaucoup d'argent et, demain, samedi, il a un déjeuner avec ses parents auquel il veut assister.

Donc, Peter a défini :

  1. Un objectif clair
  2. Un budget prévisionnel - une limite aux ressources
  3. Un délai - disons que vous ne voulez pas avoir la gueule de bois au déjeuner avec vos parents - ou au moins avoir la capacité de masquer votre gueule de bois.

Cependant, Peter n'a pas de plan, et ne sait pas très bien comment il doit "s'amuser". Voyons donc comment la portée est variable en fonction de l'objectif.

Premier scénario

Pedro a décidé d'appeler ses amis et de les retrouver chez l'un d'eux. Si Pedro est comme moi, ils vont probablement boire quelques bières, se remémorer les temps passés, peut-être faire quelques tournois de jeux vidéo et manger une pizza à un moment donné de la soirée. Vers 3 ou 4 heures du matin, Pedro sera à la maison, heureux de retrouver ses amis et d'avoir passé une nuit pleine d'"amitié".

Deuxième scénario

Peter a décidé d'aller dans son bar préféré. Il y a rencontré une personne qu'il aime beaucoup et avec laquelle il a la possibilité de passer une excellente soirée. C'est un moment de "flirt", de romantisme, c'est un moment de conquête. Pedro décide de s'approcher et d'essayer. Le lendemain, sans trop de détails, Peter est heureux et a l'impression d'avoir passé une nuit pleine de "romance".

Troisième scénario

Pedro a décidé de se rendre dans son bar préféré, mais il ne reconnaît personne. Il se sent un peu seul, mais voit l'occasion de parler à de nouvelles personnes. Après quelques verres et de la bonne musique, il se fait de nouveaux amis. À la fin de la journée, il est chez lui, rencontre de nouvelles personnes et a le sentiment d'avoir profité de son bar préféré de manière inattendue.

Chacun des scénarios pose des activités et des comportements différents dans le cadre d'un objectif commun et avec les mêmes contraintes - connues dans le jargon du projet sous le nom de contraintesConsidérez-vous maintenant qu'il est possible de faire varier la portée en fonction de la cible ? Je n'ai pas dit que c'était simple, ni rapide, mais c'est possible dans certains contextes.

Emprunts : quel montant avons-nous ajouté ou négocié par rapport au plan initial ?

Eh bien, si nous disposons d'une mesure de l'avancement et que nous savons que la portée est variable, c'est une très bonne idée de mesurer et de suivre le niveau de la dette du projet par rapport au plan. C'est-à-dire, quel pourcentage du travail initialement prévu ou projeté est maintenant hors des capacités de l'équipe pour la date et l'objectif fixés.

Que se passe-t-il si Pierre est à une table avec de nouveaux amis et qu'à ce moment-là la personne qu'il aime bien apparaît ? C'est inévitable, pour la même nuit et le même budget, il doit prendre des décisions. Chaque décision aura un coût et certaines activités seront au-delà de vos capacités - pour la période.

Exemples de mesures agiles

Je présente maintenant quelques exemples et les accompagne de quelques explications qui, je l'espère, aideront à clôturer les concepts. Voyons voir.

Les métriques d'une équipe dédiée

Métrique Période 1 Période 2 Période 3
Vitesse prévue 35 31 31
Vitesse réelle 29 28 31
Plan de conformité 82% 90% 100%

Bien que l'équipement n'atteigne jamais la conformité au plan 100% - ce qui, selon mon expérience, est le meilleur scénario - nous pouvons déterminer qu'il a une vitesse réelle stable d'environ 30SP. Vous pourriez penser qu'une équipe de planification devrait se conformer à la norme 100%, mais la vérité est que cette pratique compromet l'honnêteté et la transparence des estimations.

Notez que j'utilise le mot période et non Sprint, car il n'est pas obligatoire d'utiliser Scrum avec ces mesures - même si cela fonctionne bien.

Répondre à 100% d'un plan de sprint ou de période.

C'est une très mauvaise idée, et je vais vous expliquer pourquoi.

Imagina que haces parte de un equipo ágil y durante la planificación de la iteración han acordado completar requerimientos por un total de 100SP. Durante la iteración, uno de sus compañeros se ha enfermado y no puede asistir, y algunos de los requerimientos se encuentran bloqueados por dependencias con un proveedor. ¿Qué significa esto?

  1. Es claro que el equipo no va a lograr completar su meta de 100SP.
  2. Si no es culpa del equipo, no podríamos decir de inmediato que es una «mala planificación» – Este es un error común de quienes creen que las personas son máquinas y que los planes se deben cumplir al pie de la letra.
  3. Lo más grave, de los 100SP, el equipo ya no tiene elementos adicionales para tomar y reasignar trabajo y evitar una pérdida de tiempo.

¿Qué deberíamos hacer? ¿Deberíamos suspender la iteración? ¿Hacer una planificación de emergencia? ¿Qué sucede con el compromiso y las métricas ágiles?

El equipo no solo se encuentra bloqueado, no tiene otros elementos para tomar y «recomponer» su meta de 100SP. Para los que disfrutan de las matemáticas, las estimaciones deben ser rangos y no puntos absolutos. Si la capacidad proyectada de un equipo es de 100SP, el equipo debería planificar algo cercano a los 110SP o 115SP, entendiendo que puede tener días de alto desempeño. Así mismo, si algo con impacto negativo ocurre, el PO tiene «un plan B» para reorganizar al equipo entorno a aquello que si podemos trabajar.

Les métriques agiles "en difficulté", que se passe-t-il ?

Métrique Période 1 Période 2 Période 3 Periodo 4 Periodo 5 Periodo 6
Vitesse prévue 35 31 31 33 25 20
Vitesse réelle 29 28 31 25 20 18
Cumplimiento 82% 90% 100% 75% 80% 90%

A simple vista, algo ha ocurrido a partir del periodo 4. ¿Pero qué ha pasado? ¿Por qué está bajando la «velocidad real»?

La solución simple es, desde luego, aprovechar los espacios de reflexión con el equipo, identificar las causas y plantear soluciones. No obstante, a nivel directivo, expresar en datos lo que sucede puede ser útil. No siempre los directivos están en contacto constante con los equipos ágiles y se limitan a los reportes y las métricas. Así que, veamos un poco más de información sobre este caso.

Métrique Période 1 Période 2 Période 3 Periodo 4 Periodo 5 Periodo 6
Vitesse prévue 35 31 31 33 25 20
Vitesse réelle 29 28 31 25 20 18
Entrega No Planificada 0 0 0 5 6 4
Cumplimiento Esfuerzo 82% 90% 100% 75% 80% 90%
Plan de conformité 82% 90% 100% 60% 56% 80%
Variabilidad 0% 0% 0% 20% 30% 22%

Bueno, esta tabla extendida dice mucho. Por alguna razón, al equipo le han empezado a asignar trabajo no planificado dentro del mismo periodo – por ejemplo, ajustes a las funcionalidades existentes, cambios o mejoras. Nunca defectos.

Combien de points dois-je attribuer aux défauts ? Aucun

Este es un punto de debate. ¿Debería o no cuantificar el esfuerzo de los defectos o incidentes que debemos corregir? Si y no. En mi experiencia, las métricas ágiles pueden manipularse si los incidentes o defectos tienen un peso en las métricas del equipo. Sin embargo:

  1. Es bueno cuantificarlos para determinar el esfuerzo relativo.
  2. Es malo cuantificarlos para determinar la velocidad del equipo.

En mi opinión, si un equipo debe invertir gran parte de su tiempo y capacidad en corregir errores – cosas que no funcionan como acordamos que deberían funcionar – el mejor reflejo en las métricas es una «pérdida de capacidad». De otra forma podrías tener equipos con puntajes relativos altos que no entregan nada más que defectos solucionados.

En conclusión, un equipo que invierte su tiempo en correcciones debería ver como su velocidad se reduce.

Comment mesurer la qualité du travail fourni dans une équipe agile ?

Veamos un poco más de información de nuestro equipo ágil.

Métrique Période 1 Période 2 Période 3 Periodo 4 Periodo 5 Periodo 6
Vitesse prévue 35 31 31 33 25 20
Vitesse réelle 29 28 31 25 20 18
Entrega No Planificada 0 0 0 5 6 4
Cumplimiento Esfuerzo 82% 90% 100% 75% 80% 90%
Plan de conformité 82% 90% 100% 60% 56% 80%
Variabilidad 0% 0% 0% 20% 30% 22%
Defectos Asociados 3 3 5 7 8 7

Contar los defectos de manera simple es una mala idea. Un defecto no es igual a otro. Algunos defectos requieren más trabajo que otros, así que es buena idea utilizar valores relativos para cuantificar los defectos – recuerdan que escribí «Es bueno cuantificarlos para determinar el esfuerzo relativo".

Así que clasificarlos en tallas o usar algo similar a SP es buena idea.

No obstante, lo mejor es establecer una relación entre los SP entregados y los defectos inyectados en un periodo – es cierto, inyectar suena extraño.

Métrique Période 1 Période 2 Période 3 Periodo 4 Periodo 5 Periodo 6
Vitesse prévue 35 31 31 33 25 20
Vitesse réelle 29 28 31 25 20 18
Entrega No Planificada 0 0 0 5 6 4
Cumplimiento Esfuerzo 82% 90% 100% 75% 80% 90%
Plan de conformité 82% 90% 100% 60% 56% 80%
Variabilidad 0% 0% 0% 20% 30% 22%
Defectos Asociados 3 3 5 7 8 7
Densidad de Defectos 0.15 0.10 0.16 0.28 0.40 0.38

En esta segunda oportunidad vemos como la densidad de defectos – cantidad de defectos inyectados por SP entregados aumenta. Es posible que, al introducir nuevos requerimientos al periodo, no esté estableciendo bien el plan o el impacto de dichos requerimientos. Esto, desde luego, afecta la capacidad de entregar – menor velocidad real – y la calidad de la entrega – mayor densidad de defectos.

Modèles à l'échelle et incréments de programme

Bueno, hasta ahora solo hemos discutido las métricas a nivel de equipo. Todas y cada una de las métricas presentadas se pueden usar en múltiples equipos – si usamos normalización – y para diferentes periodos, como las iteraciones, los meses y los incrementos de programa (PI).

Si aún te ofende la «variabilidad» piensa en lo siguiente:

  1. Es posible que decidas no aceptar nada dentro de una misma iteración.
  2. Aquello adicional o nuevo entrará en la siguiente iteración – variabilidad 0% de la iteración
  3. No obstante, esa iteración hace parte de un PI, y por lo tanto, es prudente medir la variabilidad de la iteración para mejorar las mediciones y proyecciones durante el siguiente PI Planning.

Considérations

Como ves, las métricas ágiles aplican para proyectos ágiles, equipos ágiles y temas a gran escala. Si solo mantienes las métricas para el equipo, pierdes la oportunidad de escalar. En organizaciones grandes, con cientos o miles de empleados, no es posible realizar retrospectivas y comunicar fácilmente las razones y las acciones. Por eso, establecer métricas y apoyar la buena lectura y comprensión de estas, te puede ayudar a ganar el apoyo organizacional que necesitas. Todos necesitamos del apoyo «político» en una gran organización es clave, y dar visibilidad de lo que ocurre es el primer paso para obtenerlo.

Partager!

Commentaires et notes de l'auteur[+]

Image par défaut
Alberto Dominguez
Diriger des équipes de la théorie à la réalisation réelle et durable de produits et services informatiques innovants.
Publications: 33

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

fr_FR