Les cookies assurent le bon fonctionnement de notre site. En utilisant ce dernier, vous acceptez l'utilisation des cookies. En savoir plus OK
Vous êtes ici : Accueil / Blog / 2015 / 07 / La vélocité d’une équipe

La vélocité d’une équipe

Comment déterminer la vélocité d’une équipe de développement ?
entente de groupe

entente de groupe

Ce blogpost s'inspire du modèle retravaillé de Mitch Lacey (Mars 2012), The Scrum Field Guide : Practical Advice for your First Year,  ainsi que d'Anis Berejeb (juin 2009), Le cauchemar de l’estimation (www.berejeb.com).

Introduction

Une équipe de développement logiciels peut s'apparenter à un moyen de transport : avant d’opter pour l’un ou l’autre choix, il est nécessaire d'évaluer leur efficience.  Pour les moyens de transport, cela concernera l'économie de carburant, l'importance des distances à parcourir, la fréquence d’utilisation voire le nombre de moyens de transport à emprunter par trajet, etc. Pour les équipes de développement logiciels, nous parlerons d’efficacité quant à la quantité de travail qu’elles peuvent terminer sur une période donnée et déterminée à l’avance.

Cette mesure est appelée vélocité (ou vitesse de développement, rapidité de développement, etc.) et son unité est généralement le point de récits utilisateurs (demandes utilisateurs).

Pour faire simple, la vélocité constitue le nombre moyen de points de récits utilisateurs qu’une équipe de développement peut réaliser sur une période de temps déterminée ("course de développement"), telle que définie par l’équipe de développement logiciels dans le critère "réalisé", aussi appelé critère "terminé" (K.Schwaber et J.Sutherland, Le guide SCRUM, Juillet 2013, p.16; C. Aubry, La vélocité n’est pas une mesure de productivité, Novembre 2007, www.aubryconseil.com).

Un moyen de transport n’en est cependant pas un autre, à l'instar d’une équipe de développement logiciels. Il y a une difficulté supplémentaire et non des moindres : une équipe de développement logiciels n'est pas "emballée" ou "étiquetée" avec une estimation de vélocité comme pourrait l’être une voiture pour sa consommation de carburant, par exemple.

La question qui se pose : comment prédire dans une certaine mesure la future vélocité d’une équipe de développement logiciels ?

Bien que nous pourrions utiliser la vélocité d’une autre équipe pour nous donner un point de départ pour notre future vitesse de développement, nous ne pouvons dire qu’une équipe dans l’entreprise est en quelque sorte plus efficiente, efficace ou rapide car elle a une vélocité plus élevée qu’une autre équipe : chaque équipe estime en effet différemment, selon ses propres bases de connaissance, critères et acquis, l’arriéré du produit.
On en arrive à une conclusion rapide (et un peu trop facile) : prédire la vélocité est une tâche difficile, surtout si l’équipe est nouvellement constituée et/ou béotienne dans le cadre du travail SCRUM.

Le modèle de travail

L’équipe de développement logiciels doit fournir au propriétaire du produit une estimation de ce qu’elle peut accomplir sur la course au développement. Une équipe de développement logiciels n’ayant pas encore participé à un calcul de vélocité ou n'ayant pas encore été actif dans le cadre de travail SCRUM se trouve rapidement confrontée à trois possibilités : l’utilisation de données historiques, l’estimation à l’aveugle et l’utilisation de données réelles.

Pour quelles raisons les équipes de développement logiciels ont-elles très souvent tendance à éviter ou à éliminer l'option des données historiques ainsi que celle de l’estimation à l’aveugle ?

Le souci des données historiques

Le rejet de l’option des données historiques est principalement du au fait que l’équipe n’a pas préalablement travaillé ensemble (et plus particulièrement dans un cadre de travail SCRUM). Il lui semble donc irréaliste et impossible de se baser sur l’historique d’une autre équipe de développement logiciels.

Toute équipe diffère logiquement d'une autre. La multitude des facteurs de différenciation est trop importante et ne peut générer un résultat réaliste: pensons notamment à la nouveauté de l’équipe de développement logiciels, à sa composition, à l’environnement politique, à la taille et à la complexité du projet, sans parler du propriétaire du produit et des clients associés :

  • La nouveauté de l’équipe de développement logiciels affectera sa vélocité dans sa réflexion.
  • Le calcul de vélocité dépendra de la qualité de composition de l'équipe.
  • Celle-ci pourrait encore être attachée à certaines approches dites traditionnelles (tel le modèle en cascade, le modèle en V, etc. - Scrum Alliance Inc, SCRUM description, v1.1, 2012-2014, p.2).
  • L’environnement politique peut aussi constituer une variable importante pour le calcul de la vélocité. Au fil du temps, les entreprises évoluent, modifient leur structure, leur stratégie et leur direction. Le plan annuel ou stratégique d’une société est peut-être devenu obsolète, les responsables clés peuvent avoir changé de rôles, changé la dynamique de l’environnement. Parfois ces changements sont évidents, parfois il sont beaucoup plus subtils. Tenir compte des données historiques doit permettre de prendre en compte toutes ces informations, ce qui peut être difficile à réaliser.  
  • Taille et complexité du projet sont tout autant à prendre en considération. Les équipes de développement logiciels, qu’elles soient nouvelles ou établies, qui s'occupent d'un projet qui a une technologie différente ou qui change de complexité ne peuvent s’appuyer sur ces données historiques.
  • Enfin, le dernier facteur concerne le propriétaire du produit et le client. Alors qu’en théorie ceux-ci ne devraient pas être considérés comme des variables, ils en sont et non des moindres. La vélocité en est donc affectée; la relation développée ou naissante devra s’approfondir tout comme les nouveaux membres de l’équipe devront développer au fil du temps cette approche (Scrum Alliance Inc, SCRUM description, v1.1, 2012-2014, p.2).

L’utilisation de données historiques doit tenir compte au minimum des facteurs détaillés ci-dessus. Le calcul de la vélocité d’une équipe établie vous donne une idée de départ, mais utiliser ces données en tant que vélocité estimée et réelle pour sa propre équipe peut se révéler lourd de conséquences et demande prudence.

Ouvrir les yeux sur l’estimation à l’aveugle

Dans l’éventualité où il est impératif de fournir une estimation type avant tout autre travail d’ensemble, l’estimation à l’aveugle est une possibilité à ne pas négliger. Pour ce faire, il est nécessaire de réaliser un travail d’arrière-plan préalable avant « prédication » de la vélocité de l’équipe de développement logiciels.
Quelques étapes-clés d’une estimation à l’aveugle sont à respecter :

  • l’estimation de l’arriéré du produit  (Scrum Alliance Inc, SCRUM description, v1.1, 2012-2014, p.7),
  • la décomposition d'un récit utilisateur de référence,
  • la détermination d'une approximation de point de réalisation par heure,
  • l'identification d'une capacité de base de l’équipe de développement logiciels,
  • l'estimation d'une vélocité théorique de l’équipe de développement logiciels,
  • la communication de cette dernière comme un éventail de travail évolutif (entendons : non-fixe).

D’autres facteurs peuvent entrer en compte selon l’appréciation de l’équipe même. Déterminer ces quelques chiffres permet de faire une supposition, qui n’est qu’une idée. Certains spécialistes diront : « Débarrassez-vous-en, ils sont artificiels, il s'agit juste d'une béquille pour vous aider à démarrer ».

Estimer l’arriéré du produit

La première étape dans cette technique qui peut servir de base de calcul primaire de la vélocité de l’équipe est d’estimer l’arriéré du produit (que nous pourrions comparer à un carnet de commandes).
Dans l’arriéré du produit, avec l’équipe de développement logiciels, il est nécessaire d’identifier un récit utilisateur type, que l’équipe de développement logiciels estime à deux points de développement (pour rappel : c’est l’équipe de développement logiciels qui estime les récits utilisateurs, une bonne pratique d’estimation est d’utiliser la suite mathématique logique de Fibonacci).

Dès ce récit utilisateur trouvé et dès son estimation, il est nécessaire de passer tout l’arriéré des récits utilisateurs (Scrum Alliance Inc, SCRUM description, v1.1, 2012-2014, p.7).
La technique d’estimation préférentielle utilisée par l’équipe est la planification par poker. Toutefois, toute autre technique d’évaluation déjà connue peut être utilisée. Il est cependant important de ne pas mélanger les différentes méthodes d’estimation.

Décomposer le récit utilisateur de référence

Lorsque l’arriéré du produit est estimé en points, il convient de réaliser une liaison entre le temps exprimé en heure et le récit utilisateur.
Cette liaison sera la deuxième échelle permettant de visualiser à long terme une planification et d'établir un calcul de la vélocité.
Pour ce faire, il est nécessaire de prendre un récit utilisateur de référence à deux points (il peut être identique ou non au récit utilisateur précédent). Dans ce récit utilisateur, la découpe en tâches est nécessaire.

Lorsque l’équipe de développement logiciels a identifié les tâches pour la réalisation du récit utilisateur de référence, il faut estimer le nombre d’heures de ces tâches. A nouveau, la planification par poker permet de parvenir à des estimations réalistes. Une différence est notable : le travail s’effectue sur des heures et non sur un nombre de points.
De nombreux spécialistes de la méthode d’évaluation dans le cadre de travail SCRUM plaident pour une limite de maximum 13 heures par tâche (certains s’entendent qu’une tâche est égale à une journée de travail - Claude Aubry, Ne plus mesurer les tâches d’un sprint en heures, Février 2007, www.aubryconseil.com). Si ce n’est pas possible, cette tâche sera elle-même découpée afin de ne pas dépasser ce nombre (ou la journée de travail). A nouveau, la suite mathématique logique de Fibonacci est utilisée. Elle sera limitée à 13 (1,2,3,5,8,13).

Cette découpe est un peu plus complexe que la découpe en points car l’équipe estimera son propre travail et non pas une valeur métier sur un nombre de points. Dès lors, si un membre de l’équipe estime que la tâche peut se réaliser en 4 heures, il ne pourra pas choisir ce nombre d’heures mais devra prendre soit 3 ou 5 heures. Cette suite permet donc de maintenir un niveau de précision correct sans l’être trop.

Approximation horaire

Lorsque toutes les heures pour chaque tâche comprise dans le récit utilisateur de référence sont additionnées, nous pouvons alors extrapoler que tout récit utilisateur de 2 points vaut ce nombre d’heures. Prenons l’exemple que le récit utilisateur de référence vaut 15 heures : nous pouvons estimer que tous les récits utilisateurs précédemment jugés à 2 points devront être terminé en 15 heures. Cette estimation grossière est aux fins de l’estimation à l’aveugle.
Dès cette estimation réalisée, nous pouvons calculer une évaluation globale et non fixe de l’ensemble du projet en heures. Si le projet comporte 240 points dans son arriéré produit, nous pouvons estimer que le projet demandera environs 1800 heures de travail. A nouveau, s’il s’agit d’une nouvelle équipe dans un cadre de travail nouveau, ces données seraient trop incertaines. Le rapprochement de points vers le nombre d’heures permet de donner une estimation initiale. A nouveau, il ne peut être utilisé comme cadre de référence ou comme valeur précise (mais ce travail est utile, si si, je vous l’assure ! Nous le verrons par la suite…) !

La capacité de l’équipe

Pour déterminer la capacité de l’équipe, il est au préalable nécessaire de déterminer la période sur laquelle portera la course au développement. Cette période ne peut dépasser un mois (K Schwaber et J. Sutherland, Le guide SCRUM, Juillet 2013, p.9). L’échelle de temps de cette période est l’heure (Claude Aubry, Mon enquête sur les estimations, Novembre 2013, www.aubryconseil.com).
Chaque membre de l’équipe de développement de logiciels donne le nombre d’heures qu’il tient à disposition par semaine pour contribuer au projet. Ce nombre ne compte pas les activités qui interfèrent avec le temps de projet dédié. Cette estimation de contribution au projet est rentrée sous 2 formes : le meilleur des cas (le plus haut rendement) et le pire des cas (le plus bas rendement).
Les estimations les plus pessimistes sont additionnées. Ilf aut ensuite multiplier le nombre obtenu par le nombre de semaines de la course de développement. Faites à l’identique pour le meilleur des rendements. Ces deux nombres sont représentatifs quant à la capacité de l’équipe : celle-ci fournira au minimum autant d’heures et au maximum autant d'heures.

Estimer la vélocité de l’équipe

Lorsque tous les facteurs sont connus, estimer la vélocité de l’équipe n’est plus qu’une affaire de mathématiques. Il sera nécessaire de déterminer une vitesse de développement en éventail (à savoir une vélocité élevée et faible, afin de garder une période de développement et non une valeur précise).
Cette dernière se calculera avec le nombre d’heures de l’équipe de développement logiciels dans le pire des cas (plus bas rendement), divisée par la nombre de points par heure : le résultat sera la vélocité estimée à petite vitesse. Ce sera identique pour la vélocité à grande vitesse en remplaçant le premier nombre.
Nous pouvons maintenant communiquer que notre vitesse de développement est comprise entre telle et telle capacité ; l’arriéré du produit pourra être absorbé entre tel et tel mois.

L’utilisation des données réelles

L’équipe de développement logiciels peut prévoir sa future vitesse moyenne de développement. Pour certains, il y a un gros avantage dans cette méthode, à savoir l’utilisation de leurs propres données sur le projet en cours ; pour d’autres, il y a un gros désavantage : l’incertitude sur le laps de temps de la période de collecte de données. Refléter le fait et non la fiction l’emporte bien souvent sur l’inconvénient. Pour rassurer les responsables d’équipes de développement logiciels, il est toutefois utile de fournir une prédiction basée sur les méthodes précédemment citées en mettent en évidence le fait que seules les données réelles pourront donner une vélocité plus précise.

Pour réaliser l’estimation à l’aveugle, il est nécessaire de disposer de données réelles d’au moins 3 courses au développement. Cette collecte d’informations se réalise sur plusieurs points : collecter et calculer la vitesse de développement sur au moins trois courses au développement, calculer la vitesse moyenne et communiquer celle-ci comme nouvelle estimation, coordonner la capacité de l’équipe sur l’arriéré du produit.

Collecter les données réelles

La collecte de données de l’équipe de développement logiciels permet d’avoir une idée précise de la rapidité de développement fournie. Celle-ci est mensuellement affichée sous forme d'un graphique et discutée au sein de l’équipe de développement logiciels.
Calculer la vitesse moyenne de développement est maintenant réalisable. Toutefois il est nécessaire de ne pas la communiquer dans l’immédiat. Les raisons sont simples :

  • une nouvelle équipe
  • instabilité des données réelles sur un laps de temps plus pérenne
  • malentendus possibles sur des objectifs découlant d’un nombre prédéterminé

Lorsqu’on communique un délai fixe, on s’attend au fait que la tâche demandée dans le délai soit accomplie, sans report...

Prenons un exemple : notre bus doit passer à l’heure et non en avance ou en retard, sinon nous aurons la frustration soit de l’avoir raté, soit de devoir attendre un laps de temps plus long que ce qui est annoncé. A contrario, si j’indique un laps de temps (par exemple entre 5 et 10 minutes au maximum), la frustration ne sera pas présente - à condition que ce laps de temps soit effectivement respecté ! (Claude Aubry, Bacs, prévisions et incertitudes, Février 2015, www.aubryconseil.com )
La fourchette de temps permet donc de communiquer un délai raisonnable, si cette fourchette et l’échelle de temps le sont tout autant. L’idée est donc de sortir d’un laps de temps imposé pour passer dans l’éventail de planification : une proposition pessimiste, et une optimiste.

Pour en revenir à l’estimation à l’aveugle : dans un premier temps, ne communiquez pas cette échelle de grandeur hors de l’équipe de développement logiciels. Lorsque la collecte de données est terminée sur le laps de temps défini de 3 courses au développement, il est nécessaire d’additionner le nombre de points définis comme terminés sur chaque course au développement. Par la suite, divisez ce nombre par le nombre de courses de développement. Le nombre obtenu est le nombre moyen de points que vous pourrez sortir (la fourchette étant le nombre le plus petit et le plus grand). Si un trop grand écart est constaté, il est nécessaire de se rapprocher de la moyenne obtenue.

En conclusion

Il est nécessaire de prendre un laps de temps concret pour calculer la vitesse de développement d’une équipe. Privilégiez au maximum  une fourchette de développement, un éventail de temps, une période plutôt qu'une estimation proposant un nombre précis ou une décision précise (Claude Aubry, Vélocité, productivité et rock’n roll, Mai 2011, www.aubryconseil.com).

Les différentes méthodes de calcul présentées présentent chacune des avantages, des inconvénients et des spécificités. La plus préconisée est le calcul d’une vélocité sur des données réelles, mais c’est aussi celle qui demande le plus de temps pour gagner en certitude. Il faudra prévoir tout d'abord un calcul réalisé sur une estimation théorique puis une estimation sur des données réelles (David Baumier, Evaluer une équipe Agile, Janvier 2014, www.developpementagile.com).

Toutes ces méthodes de calcul de vitesse de développement font partie intégrante du cadre de travail SCRUM et facilitent la vie du responsable de produit, du responsable du cadre SCRUM au sein de l’équipe mais aussi celle des dirigeants pour la planification d’une livraison complète du produit. La souplesse de calcul et la fourchette gagnante permettront de modifier rapidement le planning si nécessaire...

Ajouter un commentaire

Vous pouvez ajouter un commentaire en complétant le formulaire ci-dessous. Le format doit être plain text. Les commentaires sont modérés.

Question: Combien font 10 + 4 ?
Votre réponse:

Tous nos posts