La taille du logiciel est le facteur déterminant de l'effort et du coût d'un projet logiciel. Lorsque vous déterminez la taille probable du projet, vous vous retrouvez à prendre de meilleures décisions, basées sur des données, qui à leur tour conduisent à des taux de réussite plus élevés.
Un dimensionnement cohérent des logiciels peut aider à tous les aspects de la gestion du portefeuille de logiciels
Estimation logicielle—et plus précisément Agile estimation de logiciel—est considérée comme difficile et notoirement peu fiable, mais des estimations fiables sont essentielles pour prendre des décisions d’investissement judicieuses et une planification efficace.
L'estimation de la taille du logiciel (et donc du coût et du calendrier) est importante pour permettre aux gestionnaires d'avoir une idée du coût et du temps nécessaires à son exécution. Les gestionnaires et les cadres sont constamment confrontés à des décisions difficiles concernant le travail sur les logiciels. Sur les projets de plus grande envergure, les budgets et les calendriers sont fréquemment dépassés, ce qui entraîne des gaspillages et des inefficacités considérables. Gestionnaires besoin de connaître le coût et la durée probables développer des logiciels afin qu'ils puissent planifier en conséquence. Ils sont censés prendre des décisions fiables concernant les priorités et l'affectation du personnel, mais ils le font souvent sans une estimation logicielle fiable du temps et des efforts nécessaires.
La plupart des professionnels du logiciel pensent qu'il est impossible d'estimer le travail de développement d'un logiciel ou que cela prend beaucoup de temps. Ce n'est pas nécessairement le cas.
Pourquoi les estimations des développeurs ne sont-elles pas fiables ?
Les développeurs sont parfois réticents à proposer des estimations d'effort, souvent parce qu'ils craignent que leurs estimations soient mal interprétées comme des engagements. Ils refusent de procéder à une analyse de dimensionnement trop détaillée en amont au cas où les exigences ne seraient pas mises en œuvre. L'estimation de l'effort en points d'histoire (à l'aide du planning poker) est une pratique courante dans les équipes Agile. Mais malgré sa popularité, il s'agit d'une approche imparfaite, incohérente et maladroite. Les points d'histoire sont un moyen de communication utile dans l'équipe sur la difficulté de faire quelque chose, mais c'est tout ! Ils sont facilement incohérents, manipulés, abusés, jouables et, dans la plupart des cas, dénués de sens.
De plus, les développeurs sous-estiment presque toujours le temps et les efforts réellement nécessaires à la livraison du logiciel. C'est dans la nature humaine. Ils ne prennent en compte que les facteurs connus, mais avec les logiciels, il y a souvent des facteurs qui ne sont pas pris en compte. inconnues qui provoquent des retards. Ces thèses sont rarement autorisées dans l'estimation technique pour cette raison.
Une mauvaise estimation conduit à des décisions non valables au niveau du projet et est souvent citée comme l’une des causes profondes des échecs des grands projets.
Grâce à des estimations plus précoces et plus fiables du travail du logiciel, de meilleures décisions peuvent être prises et les catastrophes du projet évitées.
Alors, comment pouvons-nous estimer de manière fiable le fonctionnement d’un logiciel ?
Des dizaines de facteurs peuvent affecter le temps et les efforts nécessaires au développement d’un logiciel (tels que la complexité, l’environnement de travail, le soutien de la direction, l’expérience technique, la volatilité des exigences). Le facteur le plus important pour déterminer l’effort ou le coût est la taille, en particulier la taille fonctionnelle. Une fois que vous connaissez la taille fonctionnelle, vous pouvez rapidement obtenir des estimations valides pour d’autres dimensions, telles que :
Une fois que vous connaissez le fonctionnel taille, vous pouvez rapidement dériver des estimations valides pour d'autres dimensions, telles que :
- recrutement
- frais
- temps de développement
- tests nécessaires pour obtenir une qualité appropriée
- …et bien plus encore
Qu'est-ce que la taille fonctionnelle ?
La taille fonctionnelle résulte de Mesure de la taille fonctionnelle (MSF)Il s'agit d'une technique normalisée éprouvée et mature de dimensionnement de logiciels, une pratique d'ingénierie formelle approuvée par les groupes de normalisation ISO et indépendante de la technologie, du codage et de la méthodologie de développement. En tant que mesure universelle qui s'applique à tous les types de logiciels, elle est considérée du point de vue de l'utilisateur. Par-dessus tout, la taille fonctionnelle est objective, valide et cohérente. En d'autres termes, deux personnes mesurant la taille fonctionnelle doivent obtenir le même nombre à chaque fois. L'unité de mesure est le point de fonction ; pour le dire plus précisément, il s'agit du point de fonction COSMIC (ou CFP), qui peut être estimé ou compté uniquement et précisément à partir des exigences et des spécifications. Le FSM existe depuis de nombreuses années et s'est avéré être la mesure la plus fiable de la taille des logiciels, vous permettant d'estimer ou de mesurer la taille avant, pendant et après le processus de codage.
Puis-je apprendre à estimer rapidement la taille d’un logiciel ?
Oui, vous pouvez apprendre à dimensionner un logiciel (en utilisant correctement une norme de dimensionnement fonctionnel) en quelques jours ou moins. Vous pouvez devenir pleinement compétent et certifié en quelques semaines seulement. Il faudra peut-être plus de temps pour apprendre à tirer parti de la valeur de la mesure, mais pour cela, il existe des conseillers expérimentés. ScopeMaster fait le gros du travail ici, donc utiliser ScopeMaster accélérera votre apprentissage et votre estimation logicielle !
ScopeMaster est le premier et le seul outil permettant d'estimer de manière fiable la taille fonctionnelle directement et automatiquement à partir d'un backlog d'exigences écrites. Mais ne vous contentez pas de nous croire sur parole ; les experts et les universitaires du monde entier s'accordent à dire que ScopeMaster est un outil de dimensionnement automatisé révolutionnaire.
Si vous souhaitez vous lancer dans une estimation logicielle efficace et rapide, utilisez ScopeMaster pour estimer directement et instantanément les points de fonction COSMIC à partir de vos exigences ou de vos user stories. Avec ScopeMaster, vous pouvez apporter de la sécurité à votre travail logiciel grâce à une mesure automatisée de la taille fonctionnelle.
Pour en savoir plus sur la mesure de la taille fonctionnelle COSMIC, visitez https://www.cosmic-sizing.org.
Si vous voulez commencer avec estimation logicielle efficace et rapide, utilisez ScopeMaster pour estimer les points de fonction COSMIC directement et instantanément à partir de vos exigences ou de vos user stories.
Estimation logicielle automatisée avec ScopeMaster
ScopeMaster a été conçu comme un outil permettant d'automatiser le travail administratif consistant à mesurer la taille fonctionnelle d'un logiciel à partir des exigences. Selon notre fondateur, Colin Hammond, « La raison pour laquelle j'ai décidé d'écrire un outil pour ce faire est que, en tant que chef de projet logiciel, j'ai constaté que taille fonctionnelle « C’est le facteur le plus important dont j’ai besoin pour gérer un projet avec succès. »
ScopeMaster interprète l'intention fonctionnelle de l'histoire utilisateur ou de l'exigence logicielle et est ainsi capable d'automatiser le dimensionnement fonctionnel, qui peut ensuite être utilisé pour d'autres estimation du développement de logiciels.
ScopeMaster est non seulement beaucoup plus rapide que la mesure manuelle, mais il coûte également beaucoup moins cher que le dimensionnement manuel. Les compteurs certifiés sont rares et ScopeMaster simplifie grandement la tâche. ScopeMaster « lit » les exigences, interprète l’intention fonctionnelle et les dimensionne en conséquence. Il peut estimer la taille à environ trois CFP par secondeVous pourriez dimensionner un ensemble d'exigences de 1 000 CFP (environ $1m de logiciels externalisés) en environ deux ou trois minutes. Vous pouvez ensuite examiner les résultats pour corriger les éventuelles erreurs d'exigences et vérifier la taille fonctionnelle de chaque exigence. Une fois vérifiée par l'analyste, l'estimation devient une mesure exacte, qui peut ensuite être utilisée pour l'externalisation à prix fixe du travail de développement logiciel.
Dimensionnement fonctionnel COSMIC
Au fil des ans, plusieurs variantes de la métrique de taille fonctionnelle ont été créées. Seules cinq d'entre elles ont obtenu la reconnaissance ISO (COSMIC, IFPUG, Mark II, NESMA et FiSMA). IFPUG, Mark II, NESMA et FiSMA sont toutes similaires dans la mesure où elles sont dérivées de l'ensemble de règles d'origine créé par Allan Albrecht chez IBM dans les années 1980. La méthodologie de taille fonctionnelle COSMIC a évolué à partir de méthodologies antérieures, spécifiquement conçues pour remédier à leurs lacunes. Les principaux avantages qui font de COSMIC une métrique de taille fonctionnelle Méthodologie de dimensionnement COSMIC les plus pertinents pour les logiciels modernes sont :
- Il est basé sur des principes logiciels, traitant avec élégance des couches logicielles et des architectures logicielles interconnectées.
- Des estimations et des mesures peuvent être effectuées avant que toutes les exigences ne soient connues, ce qui convient parfaitement au développement Agile.
- Il a été automatisé et nécessite donc un apprentissage négligeable.
Les points d'histoire sont répandus dans tous les projets Agile. Ils constituent une mesure indirecte de l'effort propre à chaque équipe. Chaque équipe a une compréhension commune de l'ampleur d'un point d'histoire (généralement de l'ordre de quelques heures d'effort), bien qu'il n'existe pas de règles strictes. Les points d'histoire ne sont pas une monnaie universelle. Ils ne constituent pas une norme et ne peuvent pas être utilisés de manière fiable pour comparer des équipes ou des projets. Les points d'histoire sont un indicateur interne utile de l'effort anticipé lorsqu'aucun autre moyen d'estimation n'est disponible. Les points de fonction, en revanche, sont universels, standard et hautement applicables au développement Agile, tout comme à toute autre méthodologie de développement. Cliquez ici pour en savoir plus sur les avantages du CFP par rapport aux Story Points.
La taille est la pierre angulaire de l'estimation des logiciels
Une fois que vous connaissez la taille fonctionnelle en points de fonction COSMIC (CFP), vous pouvez rapidement établir d'autres mesures directement liées à la taille, telles que le coût, l'effort et le calendrier. Une fois la taille en CFP établie, vous pouvez ensuite utiliser les valeurs de conversion sectorielle qui mappent les points de fonction à ces mesures. Plutôt que d'utiliser les conversions sectorielles, vous pouvez utiliser vos propres données de projet historiques pour établir vos propres repères de vélocité.
Estimation agile
Au lieu de perdre du temps à discuter des points de l'histoire ou à jouer avec les cartes de Fibonacci, nous pensons que l'estimation Agile est idéalement réalisée via le dimensionnement fonctionnel avec COSMIC FP. Cela signifie que vous pouvez mieux estimer :
- Rapidité (moyenne des CFP livrés par semaine)
- Calendrier (nombre de semaines nécessaires pour livrer)
- Coût (coût total de conception, développement, test et livraison)
- Effort (effort nécessaire pour concevoir, développer, tester et livrer)
- Qualité (potentiels de défauts pour chaque élément de la livraison)
À quelle vitesse pouvez-vous obtenir des estimations ?
Manuellement, un analyste compétent peut mesurer des points de fonction à un rythme de plusieurs centaines de FP par jour (ce qui se traduit par un logiciel valant des centaines de milliers de dollars), bien que cela dépende de la qualité et de la clarté des exigences et des spécifications. La vitesse dépend également de l'expérience et de la capacité de l'analyste. Avec ScopeMaster, vous pouvez vous attendre à atteindre ces règles sur quatre fois plus rapide.
Estimer pendant que vous écrivez des user stories dans Jira
En utilisant le Analyseur d'histoires ScopeMaster pour Jira, vous pouvez estimer la taille fonctionnelle de vos stories sans même quitter Jira. Le texte de votre user story est analysé par le puissant moteur de langage de ScopeMaster pour détecter l'intention fonctionnelle et la taille fonctionnelle.
Analyse comparative avec ScopeMaster
Prenez quelques projets antérieurs et insérez leurs exigences dans ScopeMaster pour obtenir la taille fonctionnelle. Étant donné que vous connaissez déjà le coût de ce projet antérieur, vous pouvez maintenant estimer l'effort et le calendrier du nouveau projet.
La taille n'est pas le seul facteur qui détermine les coûts et le calendrier des logiciels, mais c'est le facteur le plus important. La meilleure mesure de la taille est le point de fonction COSMIC.
Pour ceux qui considèrent l'automatisation comme nuisible, sans importance ou tout simplement trop difficile, consultez l'excellent article de Steve McConnelle sur pourquoi l’estimation est une compétence importante et précieuse dont les chefs de projet ont besoin.
Problèmes avec les story points
- Inconsistant
- Jouable
- Non linéaire
Les points d'histoire sont une opinion basée sur l'équipe concernant la quantité d'effort nécessaire pour créer un logiciel du point de vue d'un développeur. Les points d'histoire sont essentiellement un proxy pour les estimations d'effort, par exemple un point d'histoire peut être l'équivalent d'un employé idéal travaillant pendant une journée idéale. Ils sont très subjectifs et dépendent des opinions de l'équipe. De plus, ils varient d'une équipe à l'autre, et même au sein d'une même équipe au fil du temps. Leur incohérence et leur facilité de jeu les rendent impraticables en tant que mesure d'ingénierie fiable.
Lectures complémentaires