Mesure des logiciels – un aperçu pour les DSI

La mesure logicielle est importante car il est difficile de gérer ce que l’on ne mesure pas. Le travail logiciel est un travail de connaissance. Il s’agit de l’une des entreprises les plus coûteuses entreprises par l’humanité, avec plus de 50 millions de personnes à travers le monde travaillant dans des postes hautement rémunérés dans le domaine des logiciels, et pour la plupart d’entre elles, leurs efforts sont inestimables. Beaucoup de gens ne réalisent pas que la taille des logiciels peut être mesurée. La plupart des autres formes de travail humain ont des mesures standardisées de taille et de productivité. Mais dans le domaine des logiciels, même si des mesures appropriées existent, elles sont rarement utilisées. Les dirigeants de l’industrie, les enseignants, les cadres et même les gouvernements se sont jusqu’à présent montrés plus détendus face à ce phénomène, mais avec l’importance croissante des logiciels pour la survie des entreprises, plus de transparence et une mesure appropriée des logiciels sont nécessaires. L’introduction de mesures logicielles avec le dimensionnement COSMIC aidera les DSI à gérer plus efficacement.

La mesure logicielle aide à répondre à des questions clés

En essayant de répondre aux questions de combien d'efforts est nécessaire pour livrer un projet logiciel ou quand sera-t-il fini, la plupart des organisations s'appuient sur les avis d'experts. Ces estimations logicielles ont tendance à être non scientifiques et sujettes à la manipulation. Ce dont ils ont besoin, c'est d'un moyen cohérent de mesure logicielle. Ils ne constituent pas une base solide pour des décisions de gestion fiables et peuvent souvent conduire à des comportements contre-productifs. Cependant, avec des estimations logicielles standardisées et valides et des métriques logicielles basées sur un dimensionnement fonctionnel standardisé dans les points de fonction COSMIC (CFP), les DSI peuvent améliorer considérablement la visibilité, la gérabilité, la productivité et le rapport qualité-prix du travail logiciel dans leur organisation. Les mesures logicielles basées sur CFP et les mesures de projet correspondantes sont également appropriées pour les rapports au niveau du conseil d'administration. Cette lecture de 15 minutes sera suffisante pour vous lancer dans ce voyage vers des niveaux supérieurs de gestion de logiciels.

Logiciel de mesure de la taille, ça compte.

Considérons quelques caractéristiques générales propres au travail logiciel :

• Le travail logiciel est presque entièrement piloté par l’effort humain.
• De nombreux facteurs déterminent l’effort nécessaire pour développer certains logiciels. Le facteur le plus important est taille fonctionnelle.
• Taille fonctionnelle peuvent être estimés et, dans certains cas, même mesurés avant le début du codage.
• Il existe des dizaines d'autres facteurs qui affectent les efforts nécessaires au développement d'un logiciel, notamment : la compétence de l'équipe, la complexité et le soutien de la direction, mais la taille est le plus important.
• Il existe une grande variabilité de productivité entre les développeurs. 10 fois ou plus entre le moins et le plus productif – et pareil pour les équipes.
• Le travail logiciel n’est pas évolutif. Il existe des déséconomies d’échelle, principalement causées par la proportion élevée de temps passé à communiquer entre les membres de l’équipe. Un langage commun et une connaissance de la taille d'un projet peuvent aider à contenir ce problème.

Depuis que le logiciel est devenu une industrie, le dimensionnement des logiciels a été un sujet de débats sans fin entre développeurs et gestionnaires. Compte tenu du nombre de personnes impliquées dans l’industrie du logiciel, il est surprenant que les dirigeants et les conseils d’administration aient permis que cela se produise.

Bien que de nombreux facteurs affectent le coût et la durée d'un projet logiciel, la taille est le facteur le plus important. Si vous avez analysé les exigences et déterminé la taille fonctionnelle des CFP, vous pouvez prédire, avec une confiance raisonnable, combien de temps cela prendra et combien cela devrait coûter. Ce sont des questions vitales auxquelles les gestionnaires responsables doivent répondre pour planifier efficacement. Connaître la taille fonctionnelle dès le début du cycle de vie d'un projet peut contribuer à améliorer la qualité des décisions prises par les gestionnaires et donc réduire le risque, le coût et la durée du projet. Des références sectorielles sont disponibles ou les organisations peuvent établir leurs propres références de productivité dans CFP, afin de répondre à la question « quand aurons-nous terminé ? » question.

Mesure logicielle et génie logiciel

Toutes les autres formes d’ingénierie adoptent des mesures de taille standardisées (ISO). Le génie logiciel est la seule « discipline » de l’ingénierie qui n’y est pas parvenu. Le génie logiciel devrait adopter une mesure de taille standardisée.

Dimensionnement standardisé des logiciels

Beaucoup de gens pensent que la mesure de la taille d'un logiciel ne peut être effectuée qu'une fois le travail terminé. Ce n’est pas le cas. Le logiciel peut être mesuré avant même que le codage ait commencé.

La plupart des personnes impliquées dans l’industrie ignorent que la mesure de la taille d’un logiciel est possible et facile à réaliser, avant même le début de tout travail de codage. La taille fonctionnelle peut être déterminée simplement en examinant les besoins des utilisateurs.  

Vous pouvez compter les lignes de code après l'écriture du logiciel, mais le nombre de lignes de code (LOC) a peu de valeur, sauf si l'on considère le travail de maintenance de ce qui a déjà été écrit. Supposons également que deux développeurs écrivent certaines fonctionnalités, le développeur A peut l'écrire en seulement 4 lignes de code, alors qu'il faut 40 lignes au développeur B pour obtenir la même fonctionnalité. Lequel est plus gros? Qu’est-ce qui est le plus productif ? Qu’est-ce qui est le plus sujet aux erreurs ? Cela nous montre que nous ne pouvons pas utiliser de manière fiable le LOC comme prédicteur de la taille, de l’effort ou de l’estimation du temps.

La mesure de la taille fonctionnelle des logiciels conduit à des décisions basées sur les données concernant les logiciels

En tant que société, nous évoluons rapidement vers une prise de décision fondée sur les données. Même pour les décisions à domicile, nous examinons les avis et les données techniques avant de prendre une décision d'achat. Pour que cette approche soit efficace, nous devons utiliser des données valides, cohérentes et fiables. Après avoir examiné les mesures de base dans le domaine logiciel pendant de nombreuses années, nous avons conclu que les mesures basées sur la taille COSMIC sont les plus fiables.

• Taille ou périmètre (CFP),
• Mesures de productivité (CFP/temps),
• Métriques de qualité logicielle (Défauts/CFP) et
• Ressources (ressource/CFP).

Passer aux bonnes pratiques de dimensionnement des logiciels

Mesurer et estimer les logiciels constitue un défi depuis les débuts de l’industrie du logiciel. Nous allons sauter la leçon d’histoire et passer directement à l’état actuel des lieux. La plupart des équipes logicielles agiles estiment l'effort à l'aide d'indicateurs « d'équivalent d'effort » non scientifiques et incohérents. points d'histoire ou Tailles de t-shirts.  Points d'histoire et Tailles de t-shirts sont des estimations proxy peu fiables, non linéaires et hautement jouables sur le temps qu'il faudra pour effectuer une partie du travail. Le nombre de points d'histoire allouée par un estimateur ou une équipe sera influencée par les motivations de celui qui déclare la taille. Les « story points » sont souvent le seul indicateur proposé aux managers pour les aider à planifier et à gérer le travail, de sorte que ces indicateurs deviennent galvaudés et mal utilisés comme une sorte de mesure fiable, alors qu'ils en sont loin. Dans certains cas, le nombre d’histoires est utilisé comme indicateur de progrès et de taille. Nos études portant sur plus de 250 000 user stories ont montré une variation dans la taille des stories de 2 à 120 CFP, ce qui prouve que la taille des stories est incohérente et que, par conséquent, le nombre de stories n'est pas fiable.

La solution à ce problème est disponible depuis quelques années maintenant, il s'agit de la mesure standard ISO de la taille fonctionnelle des logiciels connue sous le nom de COSMIC Function Point (CFP). Le dimensionnement COSMIC est une méthodologie gratuite qui constitue un standard international stable, régi par une organisation à but non lucratif.  https://www.cosmic-sizing.org/. La norme COSMIC est une adaptation du concept original de dimensionnement fonctionnel inventé par Alan Albrecht, directeur d'IBM, en 1974.

Le COSMIC Function Point (CFP) est une unité de mesure de taille fonctionnelle qui peut être appliquée à TOUT projet logiciel, travail DevOps, maintenance logicielle ou implémentation de package. Il s’agit d’une mesure de taille cohérente et universelle qui peut être utilisée quelles que soient les méthodes de codage ou les langages utilisés. Il est progressivement reconnu comme la norme leader en matière de dimensionnement et est enseigné dans un nombre croissant de cours d'ingénierie informatique à travers le monde.

Le dimensionnement COSMIC vous permet d'estimer ou de mesurer la taille fonctionnelle (le nombre de CFP) au sein d'un morceau de logiciel. Il représente une vue de la taille du point de vue de l'utilisateur, et non d'un point de vue technique. (Notez qu'un « utilisateur » peut être un autre acteur du système, cette méthodologie peut donc également être utilisée pour les systèmes embarqués). Il est indépendant de la technologie ou de l'architecture utilisée pour fournir le logiciel et peut donc être utilisé dans un portefeuille complet de logiciels et de travaux de maintenance.  En tant que DSI, vous pouvez mesurer chacun de vos projets logiciels et activités de maintenance logicielle. Vous bénéficierez de mesures logicielles valides et cohérentes sur lesquelles vous pourrez prendre des décisions éclairées.  Vous pouvez même mesurer des projets antérieurs pour fournir des références en matière de productivité.

Nous voulons savoir quand sera-t-il terminé

Il s’agit d’un défi courant auquel sont confrontés les DSI. Et il nous est généralement très difficile de répondre. Mais lorsque vous utilisez les CFP comme mesure de taille standard et que vous suivez le rendement des équipes de développement en CFP par mois, ou en CFP par sprint, la date de fin devient alors prévisible. Mesurer la taille d’un logiciel est la pierre angulaire de mesures logicielles valides et répondre à la question cruciale du temps que cela prendra.

Taille de la PCP et sa relation avec l'effort

La taille du CFP s'avère être un excellent indicateur de l'effort, et donc du coût. Des études indépendantes ont montré que le CFP est un prédicteur de coût plus cohérent que la propre estimation d'une équipe en story points (voir les graphiques ci-dessous). Les taux de productivité varient d'une équipe à l'autre, mais n'importe quelle équipe donnée, toutes choses étant égales par ailleurs, est susceptible de fournir un nombre constant de CFP par sprint ou par mois. Ainsi, vous pouvez déterminer rapidement le coût par CFP.

Convient aux contrats

Le CFP étant une mesure cohérente et indépendante, il peut également être utilisé dans les contrats logiciels. Plutôt que d'être contraints de conclure un contrat « temps et matériel » avec un fournisseur de développement, les DSI peuvent demander des contrats basés sur le coût par CFP. Cela permet d'obtenir une plus grande certitude quant aux coûts, même si vous ne connaissez pas encore toutes les exigences. Les contrats de logiciels externalisés basés sur des story points vous coûteront probablement 10% de plus, et prendront environ 10% de plus, que ceux basés sur un prix fixe ferme par CFP. Dans de tels contrats, ils devraient également inclure des objectifs de productivité (par exemple CFP/mois) et de qualité (limites des défauts/CFP trouvés lors des tests d'acceptation, par criticité).

Apprendre à mesurer la taille

La technique de dimensionnement des fonctionnalités logicielles dans CFP prend environ une journée pour apprendre les bases et environ trois semaines pour devenir compétente et certifiée. Avec l'expérience, vous serez en mesure de déterminer la taille équivalente d'une année-personne de travail de développement en moins d'une journée de dimensionnement. Si vous choisissez d'utiliser notre outil de dimensionnement automatisé, ScopeMaster, le dimensionnement CFP peut être effectué encore plus rapidement et avec peu d'effort.

Dimensionnement standardisé des logiciels dans votre organisation

Comme pour toute chose, l’utilisation de poids et mesures standardisés conduit à un marché plus juste et plus transparent. Le dimensionnement standardisé des logiciels aura le même effet sur le marché des services logiciels : ce n'est qu'une question de temps. En attendant, il y a des gagnants et des perdants. Les États-Unis dépensent à eux seuls 1,4 à 500 milliards de dollars par an en logiciels d'entreprise. Nous estimons que plus de 301 TP3T pourraient être économisés grâce à l’adoption d’une mesure standardisée de la taille des logiciels.

Si vous voulez savoir pourquoi les humains font ce qu’ils font, cela vaut toujours la peine de suivre la piste de l’argent. Il existe des institutions multimilliardaires qui prospèrent grâce à des contrats « de temps et de matériel » et dont les intérêts commerciaux seront menacés par l’introduction d’un dimensionnement standardisé. De nos jours, la plupart des travaux logiciels sont commandés sur une base de temps et de matériel, avec peu de risques commerciaux pour le fournisseur. Une fois que les organisations d'achat commencent à insister pour payer sortir au lieu de effort dans le domaine des logiciels, la balance des risques commerciaux se déplacera légèrement du fournisseur vers l'acheteur.

En outre, de nombreux consultants, coachs agiles, fournisseurs de frameworks et même développeurs bénéficient du manque de transparence lié au dimensionnement non formel des logiciels.

En utilisant le dimensionnement CFP, les acheteurs pourront se procurer des services logiciels comprenant des développeurs, des testeurs, des coachs agiles, des architectes et même des consultants sur un coût par CFP. À terme, une large adoption du dimensionnement CFP est inévitable, car ceux qui achètent les services logiciels découvriront que non seulement ils sont plus transparents et mesurables, mais qu'avec un dimensionnement approprié, vous pouvez fournir plus de logiciels, plus rapidement. À terme, cela conduira à une marchandisation du travail logiciel.

La capacité à réaliser des projets de changement logiciel plus rapidement et mieux que la concurrence devient un facteur déterminant de la survie des entreprises. En utilisant des mesures valides, vous pouvez déterminer quelles équipes, fournisseurs et projets réussissent réellement par rapport à ceux qui prétendent l'être. Par exemple, si l'équipe A livre 1 000 CFP en 12 mois pour $1m de dollars, tandis que l'équipe B livre 700 CFP en 20 mois pour $2m, vous pouvez clairement voir qui fait le meilleur travail. Ceci n’est pas possible sans le dimensionnement du CFP.

Il y aura une résistance à l’adoption d’un dimensionnement transparent du travail logiciel. La transparence et la mesurabilité peuvent constituer une menace pour ceux qui bénéficient de leur absence. Vous devez vous attendre à des réactions négatives de la part de vos fournisseurs de développement, et même de vos propres équipes de développement internes, qui bénéficient actuellement d'un degré de liberté qui vient du fait qu'il n'est pas mesuré.

Vous entendrez des réticences du type « nous n’avons pas le temps de faire ça ». Pour une user story raffinée typique, il faudra jusqu'à 2 heures de conversation agrégée pour façonner, analyser et estimer les story points. Alors que le CFP peut être déterminé en quelques minutes seulement.

Une autre réaction que vous rencontrerez est « nous disposons déjà de nombreux indicateurs ». En réponse à cela, vous devrez challenger vos équipes sur la validité des « métriques » qu'elles fournissent actuellement. Voici quelques mesures couramment utilisées, ainsi que leurs échecs par rapport à leurs équivalents basés sur le CFP. Ce sont des indicateurs couramment utilisés, ils peuvent être utiles mais ce ne sont PAS des mesures valides basées sur un système métrique.

• Points d'histoire – ceux-ci sont subjectifs, jouables, non scientifiques et incohérents au sein et entre les équipes. Les story points sont essentiellement un indicateur d’une estimation des heures d’effort. Utilisez plutôt CFP.
• Tailles des t-shirts– sont également des indicateurs d’effort subjectifs, jouables, non scientifiques et incohérents.
• L'histoire compte – les histoires varient en taille absolue, allant généralement de 2 à 120 CFP, avec une médiane de 6 CFP, donc compter des histoires de taille inéquivalente est un indicateur de progrès peu fiable.
• Vitesse agile – cité dans des histoires ou des story points au fil du temps. Voir Points d'histoire, cela doit être considéré comme un indicateur de productivité. Utilisez plutôt : CFP par sprint ou mois`
• Burndown des sprints ou combustion hebdomadaire– basé sur des points d’histoire ou des décomptes d’histoires. Utilisez plutôt Appel à propositions délivré.

Nb. Temps de cycle, délai de livraison, taux de correction des défauts, complexité du code, taux de découverte des défauts, et Couverture de test sont exemples de mesures valides que nous encourageons.

Utiliser CFP comme mesure de base pour contrôler les projets

En plus d'utiliser CFP pour dimensionner votre portefeuille de logiciels et vos projets, vous pouvez utiliser les métriques basées sur CFP comme base pour contrôler l'avancement du projet :

• productivité (CFP/mois),
• qualité (défauts constatés/CFP)*
• planification des ressources humaines comme la répartition du travail (en CFP) par individu.
• portée (CFP), changement de périmètre et volatilité du périmètre

*cela peut être décomposé en défauts par criticité et en défauts par source – le tout par CFP.

Ce sont autant de mesures essentielles pour contrôler efficacement les projets logiciels. Vous commencerez rapidement à voir quels projets se déroulent bien et lesquels ont besoin d'aide.

PCP et Qualité

Jetons un coup d'œil à la relation entre la qualité des logiciels et le dimensionnement ou connaissance de la taille (en CFP).

Le processus de dimensionnement contribue à la qualité

Le processus de dimensionnement nous encourage à réfléchir en profondeur aux exigences fonctionnelles nécessaires pour fournir une capacité commerciale précieuse. Cette réflexion permet d’éliminer rapidement les malentendus potentiels. Autrement, ces malentendus se manifesteraient comme des défauts. Ainsi, le processus de dimensionnement des CFP est, en fait, le « test ultime en matière de décalage vers la gauche ».

La connaissance de la taille contribue à améliorer la qualité

Connaître la taille peut nous aider (lors de l'utilisation de benchmarks) à prédire le nombre de défauts que nous pourrions nous attendre à trouver dans un logiciel. Ces prévisions, à leur tour, nous aideront à déterminer combien de tests sont nécessaires ?   En travaillant avec défauts par CFP, notre appréciation de la qualité s'améliore.

L'analyse automatisée contribue également à améliorer la qualité

En choisissant d'utiliser ScopeMaster® pour analyser et tester les exigences, vous découvrirez immédiatement environ 50% des problèmes d'exigences latents que vous pourrez ensuite résoudre rapidement et précocement. Cela représente environ 8% de tous les défauts d’un projet, et encore plus sur les plus gros.

Gestion de la qualité des fournisseurs avec CFP

Lorsque vous utilisez un contrat qui insiste sur un niveau maximum de défauts acceptables par CFP, vous pouvez encourager les fournisseurs à garantir la qualité. Quelque chose pour lequel, sur les contrats T&M, ils peuvent être moins motivés.

Limites de la mesure de la taille fonctionnelle avec CFP

Les CFP sont une mesure de la taille fonctionnelle du point de vue de l'utilisateur. Ils mesurent les mouvements de données d'un système logiciel. Ils ne peuvent pas mesurer taille de calcul d’une transaction logicielle, et ne peuvent pas non plus être utilisés pour mesurer «non fonctionnel" aspects du travail logiciel, tels que les performances, la maintenabilité, la convivialité (et d'autres fonctionnalités). Il ne s’agit pas seulement d’une lacune du CFP mais d’un échec de l’ensemble du secteur. Personne n’a encore conçu de mesures valides et cohérentes de ces deux dimensions (taille de calcul, et NFR) du logiciel.

Même avec ces limitations, la corrélation entre le CFP et l'effort déployé pour effectuer le travail est exceptionnelle, ce qui signifie que connaître la taille du CFP vous donnera un indicateur très précis de l'effort nécessaire et, par conséquent, du coût et des délais - les deux éléments de base. connaissances en planification dont les chefs de projet et les responsables du développement ont besoin pour prendre des décisions judicieuses.

Quand pouvez-vous estimer ou mesurer la taille

L'estimation du CFP peut être effectuée à tout moment du cycle de vie du développement logiciel, même dès le début, dès que les exigences commerciales commencent à émerger. Les premières estimations peuvent devenir plus raffinées et précises à mesure que votre connaissance des fonctionnalités utilisateur augmente. À mesure que les exigences évoluent, la certitude des estimations augmente et, à terme, les estimations peuvent devenir une mesure précise. Pour effectuer une mesure précise, il suffit de connaître tous les mouvements de données associés à chaque exigence fonctionnelle (ou user story fonctionnelle). Avec CFP, vous pouvez dimensionner n'importe quel ensemble d'exigences donné, vous n'avez pas besoin de connaître toutes les exigences à l'avance, ni de connaître la conception pour déterminer la taille du CFP. Au plus tard, vous devez mesurer la taille CFP d'une user story juste avant qu'elle ne soit acceptée dans un sprint. Vous pouvez même estimer ou mesurer des projets antérieurs afin de constituer des données de référence pour des tests de productivité internes.

Les inconvénients de l’adoption de la PCP

De nombreuses personnes dans le monde du logiciel vivent de l’absence de mesure cohérente de la taille. Parmi les plus grands bénéficiaires figurent les organisations qui vendent des services de développement de logiciels sur une base de temps et de matériel. Cela inclut certaines organisations très grandes et influentes. En outre, de nombreux consultants, coachs agiles, fournisseurs de frameworks et même développeurs bénéficient du manque de transparence lié au dimensionnement non formel des logiciels. Les erreurs peuvent être cachées, la productivité est difficile à évaluer et cela peut servir leurs intérêts. D’un autre côté, pour toute personne responsable de l’achat ou de la gestion des logiciels, la mesure avec CFP ne présente vraiment aucun inconvénient. La mesure demande un effort insignifiant. La connaissance de la taille et le dimensionnement du CFP peuvent aider à réduire les problèmes de portée, à améliorer la qualité et à améliorer la productivité de tout projet logiciel.

CFP est parfait pour l'Agile et l'Agile à l'échelle

Les exigences complètes d'un projet logiciel sont rarement connues au début du projet. Le workflow Agile vous permet de gérer cette incertitude précoce. Les projets agiles se caractérisent par une prise de conscience évolutive des exigences. Heureusement, CFP peut être mesuré avec précision avant même que toutes les exigences d'un système ne soient connues. Vous mesurez simplement ce que vous savez. Vous pouvez également potentiellement estimer ce qui n’est pas encore connu avec certitude. Avec l'expérience, vous pouvez même estimer tôt lorsque seules les capacités générales ou les épopées sont connues. Au fur et à mesure qu'un projet progresse, les epics sont décomposées en user stories fonctionnelles, et ces estimations initiales deviennent des mesures plus précises du CFP avec une marge d'erreur décroissante. Considérez la certitude des exigences comme un spectre allant de « nous savons tout » à « nous savons très peu de choses ». Bien qu’il soit plus facile de dimensionner un projet si vous connaissez toutes les exigences, il est surprenant de constater combien de choses sont connues dès le début. En général, nous ne travaillons tout simplement pas assez dur au début pour découvrir ce qui est connaissable.

Dans les organisations disposant de plusieurs équipes logicielles, les cadres supérieurs doivent connaître la productivité des différentes équipes, afin de contribuer à améliorer les équipes sous-performantes et d’apprendre de celles très productives. CFP résout le problème du manque de cohérence de dimensionnement entre les équipes. En adoptant le CFP dans toutes les équipes, les taux de productivité peuvent être comparés. Les taux de productivité peuvent également être comparés entre les équipes internes et externes. Cela permet de fournir aux responsables logiciels les données dont ils ont besoin pour prendre de meilleures décisions. Il ne faut jamais comparer les équipes avec des story points.

Il est temps de maîtriser la taille des logiciels

Après 70 ans de conjectures et d'approches non scientifiques, le moment est venu pour les DSI et les responsables logiciels responsables d'insister sur l'adoption de mesures d'ingénierie appropriées en fonction de la taille. En introduisant et en insistant sur l’adoption du CFP, vous bénéficierez d’une meilleure visibilité et prévisibilité de votre activité logicielle. Il y aura des opposants dans votre organisation et parmi les fournisseurs, vous devrez donc être prêt à les encourager à voir les avantages d'une mesure de taille valide. La mesure de la taille du logiciel est une bonne pratique. Cela conduit à une meilleure mesurabilité et, en fin de compte, à une gestion plus efficace. En temps voulu, vous pourrez partager les mesures du CFP délivré et du CFP maintenu dans le cadre des mesures au niveau du conseil d'administration. Les DSI avant-gardistes qui souhaitent pouvoir améliorer leurs performances grâce à la mesure bénéficieront considérablement de l’adoption du CFP.

L'automatisation est là pour vous aider

Notre travail révolutionnaire chez ScopeMaster fournit sans effort un dimensionnement automatisé, cohérent et valide des user stories fonctionnelles ou des exigences fonctionnelles écrites des utilisateurs. ScopeMaster estimera le nombre de CFP dans une user story en analysant le langage de la story. La plupart des projets agiles contiennent moins de 500 user stories. Ceux-ci peuvent être automatiquement dimensionnés en une heure à l’aide de ScopeMaster. Les user stories peuvent alors être affinées (améliorées en qualité) et l'estimation deviendra une mesure, cela prend généralement un dixième de temps avec ScopeMaster® que sans.

Prochaines étapes.

Si vous souhaitez en savoir plus sur la façon de mesurer votre portefeuille de logiciels, de connaître les métriques logicielles valides et de mesurer votre productivité de développement pour apporter une plus grande certitude à vos projets logiciels, voici quelques prochaines étapes suggérées :

1. Incitez votre équipe dirigeante à découvrir le dimensionnement COSMIC dans CFP, nous vous recommandons le Guide de mesure des logiciels
2. Encouragez votre PMO à introduire le dimensionnement du CFP comme mesure dans la gestion de portefeuille
3. Demandez à vos fournisseurs de rendre compte des CFP livrés par sprint ou par mois
4. Demandez à vos responsables qualité d'examiner les rapports sur les défauts détectés par CFP.
5. Demandez à votre équipe de contrats d'enquêter sur les contrats à prix fixe par CFP et demandez à vos fournisseurs de proposer un coût par CFP.
6. Anticipez les réticences au sein de votre organisation et de la part des fournisseurs, soyez prêt à y répondre avec votre propre besoin d'amélioration de la transparence de la taille, de la productivité, du rapport qualité-prix et de la mesure de la qualité.

Contactez-nous chez ScopeMaster pour explorer notre outil de dimensionnement automatisé et des conseils sur l'adoption du CFP dans votre organisation.

À propos de Colin Hammond

Colin Hammond est un expert en dimensionnement de logiciels, en assurance de projet et en analyse automatisée des exigences logicielles. Il intervient régulièrement lors de conférences sur la gestion de projet, les tests de logiciels, l'analyse commerciale et l'analyse des coûts. Colin est le fondateur et PDG de ScopeMaster, qui fournit un outil de dimensionnement fonctionnel automatisé primé. ScopeMaster et des services professionnels sur la façon d'adopter et d'utiliser le dimensionnement fonctionnel.

Grâce à

Je suis très reconnaissant à Kirk Bryde (Agile Coach) et Lonnie Franks (expert en assurance de projets logiciels) pour leur précieuse contribution éditoriale à cet article.

Les références

McConnell, Steve. « Estimation logicielle, démystification de l'art noir »

Boehm, Barry et al 2000. « Estimation des coûts du logiciel avec COCOMO II »

Garmus, David et Herron, David. « Analyse des points de fonction : pratiques de mesure pour des projets logiciels réussis. »

Jones, Câpres. « Mesure des logiciels appliqués : assurer la productivité et la qualité »

Symons, Charles "Un guide pour mesurer la taille des logiciels»