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.
- L’estimation d’un groupe de personnes est plus fiable qu’une estimation individuelle.
- 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.
- 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.
- 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.
- Établir au moins deux plannings différents :
- pour un nombre X de développeurs, la date de livraison possible est Y.
- pour une date de livraison D, il faut N développeurs .
- 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 :
- introduction – Règles de base pour le « workshop » et agenda ;
- travaux préliminaires ;
- tailles de référence ;
- estimation ;
- 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.
- La considération d’une fonction. La taille peut être estimée en moins de 5 minutes ? Alors passez directement à l’étape 3.
- 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.
- Discutez de la fonction, de préférence en cinq minutes ou moins, jusqu’à ce que les estimateurs partagent une compréhension commune.
- 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 ? ».
- Les estimations élevées et faibles sont discutées. L’incertitude favorisera le choix d’une taille plus élevée.
- Les estimateurs parviennent à un consensus sur la taille finale.
- 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.
