Points d'histoire et points de fonction, quelle est la différence et pourquoi est-ce important ? Les story points sont des indicateurs arbitraires de l’effort attendu. Ils sont incohérents et ne conviennent pas pour être utilisés comme mesure principale dans les projets logiciels. Nous vous recommandons de passer aux points de fonction COSMIC de la norme ISO et de donner 14 raisons pour cela.
Points d'histoire et points de fonction, quelle est la différence et pourquoi est-ce important ? Les story points sont des indicateurs arbitraires de l’effort attendu. Ils sont incohérents et ne conviennent pas pour être utilisés comme mesure principale dans les projets logiciels. Nous vous recommandons de passer aux points de fonction COSMIC de la norme ISO et de donner 14 raisons pour cela.
Que sont les Story Points ?
Dans les projets logiciels Agile, un story point (SP) est la quantité d'effort convenue par une équipe pour effectuer un certain travail. Les tâches sont estimées en nombre de SP nécessaires pour effectuer le travail. Les story points sont une « monnaie locale » arbitraire. Il n’y a pas de règles strictes quant à la taille d’un story point. Ils ne font même pas partie du Guide Scrum. L'ampleur d'un point d'histoire varie d'une équipe à l'autre. Cela peut également varier dans le temps. Un point d'histoire et l'estimation de la taille d'un travail dans les SP ne sont que la « supposition collective » de l'équipe à un moment donné en utilisant une métrique incohérente. Essentiellement, les story points sont un proxy peu fiable pendant des heures selon Mike Cohn. Pour encore plus de défis avec SP, voir Problèmes avec les story points.
D’où viennent les Story Points ?
Les story points sont le fruit de l'idée originale de certains des signataires du Manifeste Agile. Ils ne sont utilisés que par les équipes de développement logiciel agiles. L'un des principes fondamentaux du développement logiciel Agile est que les équipes s'auto-organisent. Par conséquent, il est devenu courant qu’ils inventent également leurs propres indicateurs d’effort. Les points d’histoire diffèrent d’une équipe à l’autre, ils changent également avec le temps. En conséquence, ils sont incohérents et peu fiables à des fins de gestion. Toute référence à la « vélocité agile » basée sur les story points livrés n’a qu’un mérite modeste en tant qu’indicateur du taux de progrès.
Permettre à l’équipe de déterminer sa propre mesure de taille/effort a une certaine valeur pour améliorer la cohésion de l’équipe. En outre, il est utile de disposer d'un moyen d'estimation du travail auxiliaire (tâches qui ne sont pas spécifiques à la fourniture de fonctionnalités), même si une simple estimation en heures peut également être utilisée.
Les problèmes avec les Story Points
- Les points d'histoire sont inconsistant, au fil du temps et d’équipe en équipe.
- Ils ne peut pas être utilisé comme mesure de base sur des projets
- Ils sont inadapté aux contrats
- Ils sont généralement inadapté à l'amélioration des processus
Points d'histoire vs points de fonction COSMIC
| Objectif/avantage | Points de fonction cosmique | Points d'histoire |
|---|---|---|
| Bon pour l'estimation du sprint | Oui | Oui |
| Bon pour le dimensionnement des applications | Oui | Non |
| Le temps passé à dimensionner les user stories améliore la qualité | Oui | Oui |
| Cohérent entre les équipes | Oui | Non |
| Cohérent dans toutes les organisations et secteurs | Oui | Non |
| Convient aux contrats de développement | Oui | Non |
| Contrats de développement à portée incertaine. | Oui | Non |
| Adapté à l’apprentissage organisationnel | Oui | Non |
| Aide à réduire les coûts de développement externalisé | Oui | Non |
| Convient pour prédire et rendre compte de la qualité | Oui | Quelque peu |
| Convient pour une estimation précoce de la taille et du coût | Oui | Quelque peu |
| Bon pour l'estimation de projet | Oui | Quelque peu |
| Idéal pour dimensionner les travaux non fonctionnels | Non * | Oui |
| Idéal pour le dimensionnement du portefeuille de logiciels et la planification de haut niveau | Oui | Non |
| Le dimensionnement peut être automatisé | Oui | Non |
| Idéal pour les rapports au niveau du conseil d'administration (sur les activités de développement et de maintenance) | Oui | Non |
| Bon pour comparer la productivité des équipes | Oui | Non |
* De nombreuses exigences non fonctionnelles peuvent en fait être réarticulées en exigences fonctionnelles.
Le facteur le plus important pour déterminer un projet logiciel est la taille du logiciel à livrer. Il existe également de nombreux autres facteurs importants. Mais la taille est la #1. Sans une monnaie commune pour la taille des logiciels, les projets sont difficiles à estimer, ils sont encore plus difficiles à mesurer et si vous ne pouvez pas les mesurer, ils sont très difficiles à gérer.
Inconsistant
Les estimations de points d'histoire sont spécifiques à l'équipe qui effectue le travail. Un story point est en fait une approximation de l’effort estimé pour effectuer un travail. Il y a généralement juste une « impression » de taille. Au fur et à mesure que les membres de l'équipe vont et viennent, l'opinion sur la quantité d'efforts nécessaires pour effectuer un travail peut fluctuer, de sorte que l'ampleur d'un point d'histoire peut changer. Par conséquent, les estimations de taille en story points n’ont aucun sens pour les comparaisons avec une autre équipe, sans parler d’un autre projet, d’une autre organisation ou d’un autre secteur.
Prématuré
Les équipes agiles estiment généralement la taille en story points quelques semaines seulement avant d'effectuer le travail. Cela rend le travail de planification à long terme du chef de projet très difficile.
« Le facteur le plus important dans un projet logiciel est la taille du logiciel. Et la meilleure façon de mesurer la taille d’un logiciel consiste à utiliser les points de fonction COSMIC. "
Les organisations doivent s’améliorer
Il est pratiquement impossible dans la plupart des organisations de pouvoir regarder en avant ou en arrière sur un projet et d'utiliser des scénarios pour comparer ou en apprendre davantage sur les caractéristiques d'un projet par rapport à un autre. Les story points inhibent l’apprentissage.
La métrique principale sur un projet logiciel
Les principales préoccupations lors de la gestion d'un projet logiciel sont : la taille du logiciel, l'effort, le temps, la qualité et le risque. Les organisations ont besoin de mesures cohérentes pour tous ces éléments. Si vous connaissez la taille, vous pouvez rapidement déterminer les mesures appropriées en matière de qualité, de calendrier et de ressources. La taille est la mesure essentielle. Les story points confondent la taille et l’effort du logiciel, et ne peuvent donc pas mesurer correctement l’un ou l’autre.
Les organisations ont besoin de mesures incontestables pour estimer et apprendre.
Si vous pouvez estimer de manière cohérente la taille du logiciel à livrer et que vous disposez de données de performances sur des projets comparables antérieurs, vous pouvez rapidement déterminer l'effort et le calendrier estimés et donc les ressources nécessaires. Cela ne peut pas être fait avec des story points lorsqu'il n'est pas clair s'ils mesurent la taille ou l'effort. Ce qui rend la gestion de projet beaucoup plus facile et plus efficace, c'est de disposer d'un ensemble incontestable de mesures avec lesquelles travailler. S’appuyer uniquement sur des story points entrave l’apprentissage et l’amélioration organisationnels.
Les Story Points ne conviennent pas au développement externalisé
Les story points n’ont pas leur place dans les contrats de développement externalisés. Par exemple, vous ne pouvez pas avoir un contrat pour livrer 100 story points, car il n’existe pas de compréhension absolument cohérente de l’ampleur d’un story point. Il en résulte que le client n’a aucune visibilité sur le rapport qualité-prix ni aucun moyen de le contrôler.
La qualité en souffre
Les contrats agiles ont tendance à être caractérisés par l'incertitude et un manque de détails sur les exigences, avant d'engager un entrepreneur en développement. En conséquence, la plupart des contrats de développement de logiciels sont essentiellement temps et matériaux basé. Dans un contrat T&M, il est difficile de négocier un prix pour une fonctionnalité d'une qualité donnée et d'un coût donné. De nombreux fournisseurs accepteront de constituer une équipe qui fournira toutes les fonctionnalités demandées par le client. Dans de nombreuses circonstances que l'auteur a vues, l'organisation de développement est également en droit de facturer les efforts déployés pour corriger les bogues dans les logiciels qu'elle a livrés. Ils peuvent gagner autant d’argent en corrigeant leurs propres bugs qu’en développant la fonctionnalité en premier lieu. Pour résoudre ce problème. nous proposons des contrats basés sur un forfait ferme par point de fonction avec des contraintes de qualité basées sur les défauts découverts par point de fonction.
Les Story Points peuvent gonfler les coûts
Sur un contrat de développement externalisé, nous constatons souvent des retards et des dépassements de coûts causés par un travail de mauvaise qualité. Souvent, les problèmes de qualité sont causés par le client qui a fourni des exigences de qualité médiocres. Il n’est peut-être pas dans l’intérêt commercial de l’organisation de développement de remettre en question la qualité des exigences ou même de souligner les dangers de continuer. Quelle que soit la partie responsable de la création du travail supplémentaire, il est souvent dans l'intérêt commercial de l'organisation de développement de permettre aux problèmes de qualité de provoquer le retard, puis d'être payée en supplément pour effectuer le travail de réparation. En quoi est-ce la faute des story points, demandez-vous ? Les story points perpétuent l'ambiguïté, et cette ambiguïté conduit à des contrats T&M au lieu d'un contrat basé sur un prix unitaire ferme pour les fonctionnalités livrées.
« L'utilisation de Story Points uniquement dans les contrats sous-traités perpétue une mauvaise qualité et des coûts plus élevés. »
STOP, il existe un meilleur moyen, et il est là depuis toujours.
Points de fonction COSMIC – le meilleur ami du responsable du développement
Peu de gestionnaires de logiciels savent réellement qu’il existe des normes universelles éprouvées pour mesurer la taille des fonctionnalités des logiciels. L’idée de mesurer la taille fonctionnelle existe depuis longtemps. Le Function Point est le logiciel équivalent à la mesure du poids en kilos.
L'édition la plus récente est le COSMIC Function Point (CFP). C'est le raffinement moderne d'une technique éprouvée. C'est gratuit (open source) et il est basé sur des principes logiciels fondamentaux et est donc universellement applicable.
Le processus de mesure est appelé dimensionnement fonctionnel et c'est un moyen de mesurer la taille des fonctionnalités d'un logiciel à l'aide d'une métrique qui est toujours la même, et donc comparable entre les équipes, les projets, les organisations et les secteurs.
- Pourquoi est-ce mieux ?
- Il surmonte toutes les limites des story points mentionnées ci-dessus.
- Il est éprouvé et mature (norme ISO)
- Pourquoi n’en ai-je pas entendu parler avant ?
- Bref, c'est pas à la mode
- Jusqu’à présent, le travail de mesure prenait beaucoup de temps.
- Dois-je utiliser CFP ainsi que des story points ?
- Oui, vous pouvez continuer à utiliser des story points avec CFP.
- Les story points fonctionnent pour moi, dois-je changer ?
- Cela dépend de qui vous entendez par « moi ». Dans certaines équipes logicielles internes (mûres et stables), les story points peuvent très bien fonctionner pour estimer les User Stories et les sprints, et il y a peu de raisons de changer en ce qui concerne une équipe individuelle. Mais, pour toutes les raisons évoquées ci-dessus, les faiblesses demeurent au niveau organisationnel. Ces faiblesses ne seront jamais surmontées si vous continuez à utiliser uniquement les story points.
« Le facteur le plus important dans un projet logiciel est la taille. Et la meilleure façon de mesurer la taille est d’utiliser les points de fonction COSMIC »
En savoir plus pour des preuves supplémentaires de l'utilisation réussie et haute prévisibilité des appels à propositions sur les projets agiles
Conclusion et recommandation
Nous recommandons à toute équipe qui utilise déjà des story points de continuer à le faire. Parallèlement à cela, ils devraient également mesurer leur logiciel en points de fonction cosmique. Limitez l’utilisation de SP au travail au sein de l’équipe de développement. Lorsque vous examinez l'estimation, les mesures contractuelles, la capacité de sprint et la gestion de projet, utilisez uniquement CFP. Avec le temps, vous constaterez peut-être que vous n’utilisez plus SP, mais que vous vous concentrez plutôt sur la taille fonctionnelle du logiciel fourni.
Pour en savoir plus sur les Points Fonctions COSMIC : toute la documentation complète de la méthode COSMIC est disponible en téléchargement gratuit sur www.cosmic-sizing.org. Nous vous suggérons de commencer par lire cette introduction au dimensionnement COSMIC . La méthode de dimensionnement est basée sur les principes fondamentaux du génie logiciel et est très simple à apprendre.
Par Colin Hammond, PDG de ScopeMaster Ltd et Charles Symons, Co-fondateur de COSMIC
