Éléments essentiels du dimensionnement du backlog
Examinez chaque User Story ET l'ensemble
ScopeMaster fournit automatiquement une estimation de taille basée sur le texte de la user story.
Pourquoi le dimensionnement automatisé avec ScopeMaster est meilleur que le dimensionnement en équipe
Non seulement ScopeMaster fournit une estimation raisonnable de la taille du backlog, mais il peut le faire sans effort, instantanément et peut dimensionner les éléments du backlog manquants !
Dimensionnement du backlog logiciel automatisé par ScopeMaster®
Dimensionnement et estimation du backlog logiciel sont normalement une perte de temps et un jeu. Pourtant, des estimations fiables sont essentielles pour prendre des décisions d’investissement judicieuses et une planification efficace.
Il est important d’estimer la taille du backlog logiciel (et par la suite le coût et le calendrier) pour permettre aux responsables de comprendre combien cela coûtera et combien de temps cela prendra. Les managers et les cadres sont constamment confrontés à des décisions difficiles concernant le travail sur les logiciels. Sur les projets plus importants, les budgets et les calendriers sont fréquemment dépassés, ce qui entraîne un gaspillage et une inefficacité 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 estiment qu'il est impossible d'estimer le travail de développement de logiciels ou que cela prend beaucoup de temps. Ce n’est pas le cas.
Pourquoi les estimations des développeurs ne sont-elles pas fiables ?
Les développeurs ont souvent du mal à faire des estimations. L'estimation utilisant des techniques telles que les story points ou la taille des t-shirts n'est en réalité qu'un indicateur pour deviner les heures ou les jours de travail. Les équipes diront le contraire, mais c’est surtout de l’obscurcissement à promouvoir. Lorsque les développeurs fournissent des estimations pour une partie d’une œuvre, ils peuvent délibérément sous-estimer le travail, peut-être pour « gagner » le travail et protéger leur travail. Ils peuvent également surestimer pour éviter d'avoir à faire un travail qu'ils ne veulent pas faire.
L'utilisation abusive des estimations des développeurs est répandue
Une fois que les développeurs ont fourni à un manager une estimation d'une user story, d'un sprint de travail ou même d'un backlog complet, le manager peut alors utiliser cette estimation comme un objectif, une mesure de contrôle ou même un engagement, tout cela sont des utilisations inappropriées de l’estimation de l’effort de base.
Sous-estimer est la nature humaine
Les développeurs sous-estiment presque toujours le temps et les efforts réellement nécessaires pour livrer un logiciel. C’est dans la nature humaine de le faire. Ils ne prennent en compte que les facteurs qu'ils connaissent, et pourtant, avec les logiciels, il existe souvent des inconnues qui entraînent des retards, ces thèses étant rarement prises en compte dans les estimations techniques. De plus, les propositions initiales des développeurs sont généralement faibles afin de « gagner le travail ».
Comment estimer le backlog des produits logiciels de manière fiable ?
Des dizaines de facteurs peuvent affecter le temps et les efforts nécessaires au développement de logiciels (tels que la complexité, l'environnement de travail, le soutien de la direction, l'expérience technique, la volatilité des exigences). Le Le facteur le plus important pour déterminer l’effort ou le coût est la taille., spécifiquement taille fonctionnelle.
La taille fonctionnelle du logiciel est le fondement de l’estimation du backlog
Une fois que vous connaissez le fonctionnel taille, vous pouvez rapidement dériver des estimations valides pour d'autres dimensions, telles que :
- recrutement
- il est temps de développer
- frais
- tests nécessaires pour obtenir une qualité appropriée
- et beaucoup plus
Qu’est-ce que la taille fonctionnelle ?
La taille fonctionnelle découle de la mesure de la taille fonctionnelle (FSM). Il s’agit d’une technique standardisée et éprouvée pour le dimensionnement des logiciels. C'est un pratique d'ingénierie formelle approuvée par les groupes de normes ISO. Il est indépendant de la technologie et de la méthodologie de développement. La taille fonctionnelle est une mesure universelle qui s'applique à tous les types de logiciels. Il est considéré à partir du point de vue des utilisateurs. C’est objectif, valide et cohérent. Deux personnes mesurant la taille fonctionnelle devraient trouver le même chiffre à chaque fois. L'unité de mesure est le point de fonction, plus précisément le point de fonction COSMIC ou CFP. Le CFP peut être estimé ou compté (exactement) uniquement à partir des exigences et des spécifications. La taille fonctionnelle est indépendante du langage de codage utilisé pour la développer. Le FSM existe depuis de nombreuses années et s'est avéré être la mesure la plus fiable de la taille d'un logiciel. FSM vous permet d'estimer ou de mesurer la taille avant, pendant et après l'écriture du code.
Estimation révolutionnaire du backlog produit
ScopeMaster est le premier et le seul outil permettant d'estimer de manière fiable la taille fonctionnelle, directement et automatiquement, à partir d'un arriéré d'exigences écrites. Ne vous contentez pas de nous croire sur parole. Les experts et les universitaires du monde entier s'accordent sur le fait que ScopeMaster® est un outil de dimensionnement automatisé révolutionnaire : Validation académique de ScopeMaster comme outil de dimensionnement automatisé.
Apportez de la certitude à votre travail logiciel grâce à la 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
L’avantage de connaître la taille avant de coder est que vous pouvez allouer le temps et les fonds appropriés pour faire le travail. En connaissant simplement la taille, vous pouvez généralement économiser 10% ou plus sur un projet logiciel plus important, parfois même plus.
Estimation logicielle automatisée avec ScopeMaster
Trois standards leaders en matière d'automatisation :
ScopeMaster a été conçu comme un outil permettant d'automatiser le travail de bureau consistant à mesurer la taille fonctionnelle d'un logiciel à partir des exigences. « La raison pour laquelle j'ai décidé d'écrire un outil pour ce faire est parce qu'en tant que chef de projet logiciel, j'ai découvert que taille fonctionnelle est le facteur le plus important dont j’ai besoin pour gérer un projet avec succès. Colin Hammond, fondateur.
ScopeMaster interprète l'intention fonctionnelle de la user story ou de l'exigence logicielle et est ainsi capable de automatiser le dimensionnement fonctionnel, qui peut ensuite être utilisé pour d'autres estimation du développement de logiciels.
Non seulement ScopeMaster est beaucoup plus rapide que la mesure manuelle (au moins 4 fois plus rapide), mais il coûte beaucoup moins cher que le dimensionnement manuel, les compteurs certifiés sont rares et ScopeMaster simplifie grandement le travail. ScopeMaster « lit » les exigences, interprète l'intention fonctionnelle, puis les dimensionne en conséquence. Il peut estimer la taille à environ 3 CFP par seconde. Vous pouvez dimensionner un ensemble d'exigences de 1 000 CFP (environ $1m de logiciels externalisés) en 2 ou 3 minutes environ. Vous pouvez ensuite examiner les résultats pour a) corriger les erreurs liées aux exigences et b) vérifier la taille fonctionnelle de chaque exigence. Une fois vérifiée par l'analyste, l'estimation devient un décompte/mesure exact, qui peut même être utilisé pour l'externalisation à prix fixe du travail de développement de logiciels.
Dimensionnement fonctionnel COSMIC
Au fil des années, plusieurs variantes de mesures de taille fonctionnelle ont été créées. Seuls cinq d’entre eux ont obtenu la reconnaissance ISO (COSMIC, IFPUG, Mark II, NESMA et FiSMA). IFPUG, Mark II, NESMA et FiSMA sont tous similaires dans le sens où ils sont dérivés du jeu de règles original créé par Allan Albrecht chez IBM dans les années 1980. Le Méthodologie de taille fonctionnelle COSMIC ont évolué à partir de méthodologies antérieures, spécialement conçues pour remédier à leurs lacunes. Les principaux avantages qui rendent la méthodologie COSMIC Sizing plus pertinente 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.
- Les estimations et les mesures peuvent être effectuées avant que toutes les exigences ne soient connues – ce qui est très adapté au développement Agile.
- Il a été automatisé et nécessite donc un apprentissage négligeable.
Les story points sont répandus dans tous les projets Agile, ils constituent une mesure indirecte de l'effort spécifique à l'équipe. Chaque équipe a une compréhension commune de l’ampleur d’un story point, cela représente généralement quelques heures d’effort, mais il n’y a pas de règles strictes. Les story points 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 story points sont un indicateur interne utile de l’effort prévu, si aucun autre moyen d’estimation n’est disponible. Cependant, les points de fonction sont universels, standards et hautement applicables au développement Agile ainsi qu'à 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 logicielle
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 alors utiliser les valeurs de conversion de l'industrie qui mappent les points de fonction à l'effort, au coût et au calendrier. Plutôt que d'utiliser des conversions sectorielles, vous pouvez utiliser vos propres données historiques de projet pour établir vos propres références de vitesse.
Estimation agile
Plutôt que de perdre du temps à discuter de points d'histoire ou à jouer avec les cartes de Fibonacci. Selon notre expérience, l'estimation agile est mieux réalisée via le dimensionnement fonctionnel avec COSMIC FP.
Que pouvez-vous estimer en fonction de la taille ?
- 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 compter (mesurer) les points de fonction à un rythme d'environ 100 à 500 FP par jour (environ $100k – $500k de logiciel). Cela dépend de la qualité et de la clarté des exigences et des spécifications. La rapidité dépend également de l’expérience et des capacités de l’analyste. Avec ScopeMaster, vous pouvez vous attendre à respecter ces règles environ 4 fois plus rapidement.
Estimation pendant que vous écrivez des user stories
Grâce à ScopeMaster Story Analyzer pour Jira, vous pouvez estimer la taille fonctionnelle de vos histoires sans même quitter Jira. Le texte de votre user story est analysé par le puissant moteur linguistique de ScopeMaster pour détecter l'intention fonctionnelle et la taille fonctionnelle.
La taille n’est pas le seul facteur qui détermine les coûts et le calendrier des logiciels, mais c’est le plus important.
Problèmes avec les story points et les T-shirts
- Inconsistant
- Jouable
- Non linéaire
Les story points sont une opinion d'équipe sur la quantité d'efforts que cela pourrait prendre pour créer un logiciel du point de vue d'un développeur. Les story points sont essentiellement une approximation des estimations d'efforts, par exemple, un story point peut être l'équivalent d'une journée-personne idéale. Ils sont très subjectifs et dépendent des opinions de l’équipe. Ils varient d’une équipe à l’autre et même dans le temps au sein d’une même équipe. Leur incohérence et leur capacité de jeu les rendent peu pratiques en tant que mesure d'ingénierie fiable.
Pour ceux qui considèrent l'estimation comme nuisible, sans importance ou tout simplement trop difficile, consultez l'excellent article de Steve Mconnell expliquant pourquoi l’estimation est une compétence importante et précieuse dont les chefs de projet ont besoin.
