Français
Phone: + 33 (0) 9 80 89 99 65 - Email: contact@estimancy.com
Site logo
Sticky header logo
Mobile logo
Français
  • Solutions
    • Gestion de la sous-traitance applicative
    • Estimation des charges des projets logiciels
    • Tagger, gestion des exigences
  • Services
    • Mesure et Estimation de projets logiciels à la demande
    • Contre-chiffage des projets logiciels à la demande
  • Formations
    • Cours gratuit : introduction à la mesure et à l’estimation de projets logiciels
    • La mesure logicielle COSMIC
    • La mesure logicielle avec IFPUG – Parcours avancé
    • Formation : La méthode de mesure logicielle SiFP
    • Les bases de l’estimation des projets logiciels avec IFPUG
  • Ressources
    • Blog
    • Webinaires
    • Vidéos
    • FAQ
  • À propos
    • Recrutement
  • Contact
  • Webdemo
PrevApplication outsourcingSous-traitance logicielle : quel type de contrat choisir ?19 mai 2017NextStory PointsStory Points vs Points de Fonctions, lesquels choisir ?07 août 2017
  • Articles

« Big Rock », la méthode pour définir un budget en phase amont

Big Rock

Deux questions essentielles sont abordées dans cet article sur la méthode « Big Rock » :

  • comment évaluer la taille quand on a des macros exigences non totalement définies ?
  • comment déterminer la taille de manière homogène, quand il y a plusieurs produits, projets et équipes agiles, et que vous devez disposer de données historiques de bonne qualité pour construire l’estimation ?

La technique des Grandes Fonctions (« Big Rock ») est utilisée chez Rockwell Automation pour établir la taille et réaliser l’estimation très tôt dans le cycle de vie du projet. L’estimation est réalisée avec des exigences de haut niveau qui seront affinées au cours du projet.

Introduction à la méthode « Big Rock »

La méthode proposée permet d’engager une équipe sur l’estimation d’un projet, son planning et son budget.
Chez Rockwell Automation les équipes utilisent une technique dite « Big Rock » pour réaliser une estimation « Ordre de Grandeur » et établir le budget initial. Le contenu des fonctions majeures est issu de réunions d’estimation réalisées sur plusieurs projets. Cette technique est aussi utilisée pour affiner les estimations de charges et de coûts lors de l’étape de définition du budget. Le but est d’éviter d’estimer des « montagnes », ou des « petits cailloux ». Cette technique va s’appuyer sur les Grandes Fonctions du produit. L’estimation de ces Grandes Fonctions se déroule sur les mêmes principes que les estimations des méthodes agiles.

  1. L’estimation d’un groupe de personnes est plus fiable qu’une estimation individuelle.
  2. Les estimations ne seront pas parfaites. Certaines estimations seront élevées et d’autres seront basses. Les unes compensent les autres, et la loi des grands nombres permet d’obtenir une estimation réaliste.
  3. Se contraindre à choisir seulement les valeurs de tailles proposées par la méthode. Si un composant est entre deux valeurs, il doit être valorisé à la taille au-dessus.
  4. Définir les activités d’un planning d’estimation partagé par tous, et faire au mieux pour établir un planning type s’appuyant autant que possible sur les résultats des projets précédents.
  5. Établir au moins deux plannings différents :
    1. pour un nombre X de développeurs, la date de livraison possible est Y.
    2. pour une date de livraison D, il faut N développeurs .
  6. Décrire l’ensemble des Grandes Fonctions selon le périmètre, la complexité et des risques attendus, sans considérer uniquement le nombre de jours/effort.

Le calcul de la taille ne doit pas durer plus d’une à deux sessions d’estimation. Les participants impliqués dans l’estimation sont les développeurs qui vont contribuer à la réalisation du produit final. Les autres parties prenantes peuvent participer et devront être disponibles pour aider à clarifier le périmètre et le contenu du produit tout au long du processus de l’estimation. Enfin, d’autres participants non techniques, comme les chefs de projet, par exemple, peuvent assister en tant qu’observateurs uniquement.

La démarche de l’estimation Grandes Fonctions est la suivante :

  1. introduction – Règles de base pour le « workshop » et agenda ;
  2. travaux préliminaires ;
  3. tailles de référence ;
  4. estimation ;
  5. revue finale.

Travaux préliminaires

Le travail préalable comprend la préparation d’un schéma d’architecture et des définitions claires des éléments. Si le schéma d’architecture n’est pas disponible, un groupe devra y travailler pour déterminer de la structure initiale. Cette structure ne doit pas être figée pour la suite du projet. La clé est de capturer l’information avec précision et de la sauvegarder pour référence future.

Pour éviter que la structure ne soit pas trop détaillée, il est recommandé de conserver trois niveaux de descriptions des Grandes Fonctions :

  • premier niveau : description au niveau Direction / Haut niveau ;
  • deuxième niveau : description au niveau des principaux intervenants / Manager ;
  • troisième et plus profond : description au niveau de l’équipe de développement / Ingénieur.

Il est fortement recommandé de garder le nombre de Grandes Fonctions de premier niveau à dix ou moins, mais autoriser une plus grande complexité pour les niveaux deux ou trois. La plupart du temps, l’estimation des Grandes Fonctions ne nécessite que deux niveaux. Occasionnellement, construire des fonctions de niveau 3 peut être nécessaire lorsque le projet est très complexe. Les stories se trouvent au niveau suivant, et ne doivent pas être écrites avant que l’ensemble des Grandes Fonctions ne soient estimées.

Base de référence

Le but de l’estimation est d’établir un consensus sur les valeurs utilisées lors de l’estimation de la taille des Grandes Fonctions. Ceci peut être l’une des parties les plus difficiles de l’activité d’estimation. Les équipes ont presque toujours tendance à sous-estimer le nombre de points, ou sont étonnées lorsque les points sont nombreux, et de voir ainsi le planning se charger. Beaucoup d’équipes projets Waterfall sous-estiment énormément les délais et livrent en retard. Il faut, en réalité, se concentrer sur la complexité et le risque, en valorisant chaque fonction. Il faut par la suite normaliser le nombre de points par rapport à la base de référence construite à partir d’autres projets. Dans de nombreux cas, une activité moins complexe mais chronophage peut finir par avoir la même taille qu’une activité très complexe et de courte durée.

Chez Rockwell Automation, la plupart des équipes préfèrent le T-shirt Sizing, en particulier pour l’estimation  des Grandes Fonctions. D’autres déterminent la taille selon la taille de chiens (du chihuahua au St Bernard), ou avec différents types de données non numériques. Il est important de ne pas assigner de points à la taille tant que le calibrage T-shirt n’est pas achevé. Affecter des points trop tôt amène l’équipe à penser uniquement en termes de points et non à comparer les tailles des Grandes Fonctions.

La plus petite taille de T-shirt devra être supérieure à la Story la plus grande. Occasionnellement beaucoup de petites fonctionnalités connexes, pas assez grandes pour être le plus petit T-shirt, peuvent être collectées dans les Grandes Fonctions de regroupement. Ce sont généralement des éléments importants qui peuvent être achevés rapidement.

La première étape est de décider de ce qu’est une fonction Extra Small (extrêmement petit) ou Medium (taille moyenne) en termes de complexité, de taille et de risque. Il est utile que certaines personnes aient une expérience dans Scrum et que les estimations puissent s’appuyer sur les données réelles d’une équipe Scrum. De nombreuses équipes aiment avoir plus de granularité, il est alors recommandé d’ajouter d’autres tailles de T-shirt si besoin.

L’équipe doit se mettre d’accord pour choisir quelles fonctions et sous-fonctions sont de taille moyenne. S’il n’y a pas d’accord, il faut trouver une autre fonction candidate, et recommencer jusqu’à l’obtention d’une de taille moyenne qui serve de référence. Une fois que celle-ci est définie, il faut créer des intervalles pour définir XS  et XL.  Le reste des tailles peuvent être définies au cours de l’estimation.

Par exemple, Rockwell Automation utilise souvent l’Intégration d’Interfaces Internet pour les fonctions de taille moyenne. La plupart réutilise des logiciels existants ou des outils pour implémenter les interfaces. Le périmètre et les fonctionnalités sont similaires quelques soient les produits, ce qui en fait un choix parfait pour une fonction de référence.

Il faut essayez d’éviter de définir la fonction de référence en termes d’heures/effort ou de jours/homme car un Développeur A peut travailler plus vite qu’un Développeur B.

Estimation « Big Rock »

« Big Rock » est une estimation de type « Ordre de grandeur » et non une estimation détaillée. L’objectif est de parcourir l’ensemble des fonctions, et d’estimer de manière raisonnable, mais pas parfaite, le nombre de points de chacune d’entre elles en tenant compte de la complexité et des risques.

Pour l’estimation, les grandes étapes sont les suivantes.

  1. La considération d’une fonction. La taille peut être estimée en moins de 5 minutes ? Alors passez directement à l’étape 3.
  2. Si la taille est trop grande, ou la fonction trop complexe, divisez-la en sous-fonctions. Certaines d’entre elles peuvent déjà être énoncées dans des sous-exigences, des exigences du produit, des exigences fonctionnelles ou d’autres documents.
  3. Discutez de la fonction, de préférence en cinq minutes ou moins, jusqu’à ce que les estimateurs partagent une compréhension commune.
  4. Les estimateurs indiquent la taille de la fonction. Si quelques personnes ont une influence sur d’autres, vous aurez peut-être à utiliser des cartes de planning poker, un vote ou une autre méthode. Si nécessaire, l’animateur pose la question : « est-ce plus ou moins complexe que la fonction moyenne ? ».
  5. Les estimations élevées et faibles sont discutées. L’incertitude favorisera le choix d’une taille plus élevée.
  6. Les estimateurs parviennent à un consensus sur la taille finale.
  7. L’animateur enregistre le résultat, et l’équipe passe à la fonction suivante.

Revue finale

Lorsque l’équipe a fini le Sizing de l’ensemble des fonctions, l’animateur les révise et revient sur ce qui reste à discuter. On demande à l’équipe s’il reste des préoccupations ou des problèmes associés au Sizing. Tout le monde doit partager les réponses.

L’animateur prend la grille de taille des T-shirts et la convertit en points. L’animateur doit travailler avec un expert en estimation ayant une expérience dans Scrum. Si possible, il faut que votre fonction moyenne de référence corresponde à peu près à la taille moyenne d’une fonction connue par l’équipe. Les points pour Medium peuvent être extrapolés ainsi à partir d’une estimation « Ordre de grandeur ».

Lorsque vous valorisez les points pour le Sizing des fonctions, utilisez des tailles supérieures à la plus grande story sur laquelle les équipes envisagent de travailler.

Par exemple, si l’équipe convient que la plus grande story est de 20 points, la plus petite fonction doit être de 40 points.

La série Fibonacci modifiée peut être utilisée pour définir les points pour les tailles restantes de T-shirt.

Le tableau ci-dessous est basé sur cet exemple :

T-Shirt Epic Points
XS 40
S 100
M 200
L 300
XL 500
XXL 800

 

Rappel : chaque équipe aura sa propre vélocité. Cette vélocité est indépendante des hypothèses faites avec les ordres de grandeur. Les points affectés aux fonctions peuvent être affinés à une date ultérieure pour correspondre à la vitesse réelle de l’équipe. Différentes équipes auront des vélocités différentes. Le redimensionnement des estimations est donc essentiel au suivi et à la gestion du projet.

Exemple de résultats de taille

Le tableau ci-dessous représente les résultats d’une estimation « Big Rock » pour une application avec des interfaces PC et Web. Les éléments du portefeuille principal sont : la communication, le processus métiers, l’interface utilisateur et l’infrastructure. Ceux-ci sont décomposés en ensembles de travaux plus spécifiques, mais toujours généraux pour être estimés. Ces listes sont préparées dans le cadre du travail préalable à l’estimation. Cela aide à organiser l’activité de l’estimation. Pour la plupart des projets, ce sera probablement une liste beaucoup plus longue avec au moins un niveau de complexité supplémentaire.

 

Portfolio Portfolio Taille T-shirt
Communication Ethernet Stack integration XS
Communication REST Library integration S
Communication Caractéristique spécifiques de l’intégration L
Communication Test M
Processus métiers Database services M
Processus métiers Algorithm update M
Processus métiers Business Logic testing S
Interface utilisateur Interface de développement Pc S
Interface utilisateur Interface Web S
Interface utilisateur UI Testing M
Infrastructure Configuration du système de construction S
Infrastructure Devops Update S
Infrastructure Support de cycle de vie M

 

Une fois que la taille est définie, on peut attribuer des points et un premier devis peut être produit après examen et discussion avec les parties prenantes. À l’aide des tailles indiquées plus haut dans ce document, cet exemple permet d’évaluer la taille à 1 940 points. En supposant que l’équipe soit capable de réaliser 60 points par Sprint et des Sprints de 3 semaines, ce projet pourrait être achevé en environ 32 sprints ou 96 semaines.

 

Pour conclure

Les équipes et les parties prenantes discutent du périmètre, de la complexité et du risque pour les fonctionnalités clés du produit logiciel, sans confondre cela avec les contraintes de planning. Lorsque le planning est considéré en premier lieu, l’estimation du travail tend à se compresser comme par magie pour obtenir la durée souhaitée. En sortant de la première séance d’estimation, les résultats seront probablement inacceptables pour les principaux intervenants. Lorsque cela se produit, la définition du projet devrait être décomposée, redéfinie ou affinée pour décomposer les fonctions trop grandes. Une session d’estimation ultérieure sera effectuée après la mise à jour du périmètre du projet.

La méthode de taille par Grandes Fonctions équilibre l’estimation entre les méthodes top-down et bottom-up utilisées pour estimer la taille du logiciel. Le « Big Rock Sizing » fournit également aux intervenants, la connaissance du périmètre, la complexité et les risques du projet. L’estimation par « Big Rock » peut être ajustée pour répondre aux besoins organisationnels du projet.

Découvrez les offres de produits et de services Estimancy permettant de mesurer ou d’estimer des projets logiciels à partir des exigences utilisateurs rédigées en langage naturel.

  • Projet agile
  • Story Points

Related posts

Livres blancs Projets agiles
4 février 2019in Livres blancs 0 Comments 0 Likes

Comment sous-traiter les projets agiles au forfait ? – Livre blanc

Articles Agilité
7 août 2017in Articles 0 Comments 1 Likes

Estimation logicielle : comment réconcilier agilité et Points de Fonction ?

Contre-chiffrage COSMIC Estimation IFPUG Mesure logicielle Points de Fonction Projet logiciel Software Sizing sous-traitance Story Points

Categories

  • Articles
  • Blog
  • Événements
  • Livres blancs
  • Webinaires

Estimancy est un éditeur de logiciel spécialisé dans le calcul et le contrôle automatique des coûts des projets logiciels.

  • enAnglais
  • frFrançais

Estimancy

Gestion de la sous-traitance de projets logiciels

Estimation des coûts et délais des projets logiciels

Mentions légales

La société

À propos

Blog

Webinaires

Recrutement

 

Contact

Estimancy

contact@estimancy.com

Cookies

Ce site utilise des cookies : En savoir plus.