Introduction à Scrum: vélocité d’une équipe

Pace

Image by Shyha via Flickr

Dans ce dernier billet de ma série d’introduction à la méthodologie Scrum, j’aborde le calcul de la vélocité des équipes.

On a vu dans les billets précédents que le travail se fait par itérations. Au début  de chaque Sprint, l’équipe de développement fait une rencontre de planification avec le Product Owner et le Scrum Manager afin de déterminer le lot d’histoires qui seront traitées pendant cette itération. Ce choix se fait par un jeu d’estimation des différentes histoires.

Estimation des histoires

Le calcul de la vélocité est étroitement lié aux estimation de complexité des histoires. Lors de la réunion de début d’itération, l’équipe de développement estime le ‘poids’ de chaque histoire par sa complexité. Traditionnellement, on accorde une unité par demi-journée de travail. Ainsi, si l’équipe s’entend pour dire qu’une histoire donnée prendra 2 jours à réaliser, on lui accorde 4 points. Il s’agit de 4 unité de travail. Si deux travailleurs doivent unir leurs efforts pendant deux jours, on attribuera plutôt 8 points (4 points x 2 personnes). Et ainsi de suite.

NOTE: En réalité, ce n’est pas tout à fait exact, car l’on doit prendre en compte l’incertitude et les imprévus. Ainsi, il y a un vieux concept qui stipule que plus une tâche est complexe à réaliser, plus l’incertitude et le risque d’erreur sera grand. On attribue donc plutôt notre estimation de l’histoire en suivant une suite de numéro. Habituellement, on utilisera la suite de Fibonacci: 1,2,3,5,8,13… etc.

On utilisera donc la valeur qui suit immédiatement notre estimation si celle-ci ne correspond pas exactement à un chiffre de la suite. Dans notre exemple, si l’on estime 4 points pour l’histoire, on attribuera donc la valeur de 5.

Calcul de la vélocité

Une fois les histoires évaluées, viens le moment de déterminer quelles histoires feront parti de l’itération qui débute.

Dans mes lectures sur Scrum, j’ai vu autant de forme de calcul de la vélocité que de blog différents sur le sujet. Certain l’expriment en pourcentage, d’autres encore avec des calculs trop complexes. Mais en général la vélocité s’exprime par le nombre de points d’histoires qu’une équipe peut réaliser entièrement dans un seul Sprint.

Le calcul se veut donc ré-évalué après chaque Sprint. À plus long terme, on peut avoir une idée assez précise de la vélocité moyenne d’une équipe au fil du temps. La mesure deviendra encore plus précise si l’équipe reste la même sur une très longue période.

Il faudra donc quelques Sprint initialement pour connaître avec suffisamment de précision la vélocité d’une équipe. Par exemple, si au Sprint initial du projet, on estime que l’équipe livrera l’équivalent de 80 points d’histoires, et qu’en réalité seulement l’équivalent de 60 points d’histoires ont pu être livrés, l’équipe a une vélocité de 60 points. Avec l’équipe, le Scrum Master devra évaluer les raisons pour lesquelles la vélocité réelle n’était pas égale à la vélocité projetée (ici, 80 points).

En réajustant à chaque Sprint le nombre de points d’histoires estimés pouvant être livrés, l’équipe tendra rapidement à atteindre sa vitesse de croisière.

Il faut en plus tenir compte des autres occupations des membres de l’équipe. En effet il est assez rare, surtout dans les petites boîtes, de voir une équipe de développement entièrement dédiée à un seul projet à la fois.

Importance de la vélocité

Il y a de multiples raisons qui justifient un calcul rigoureux de la vélocité. D’une part, une vélocité permet d’estimer le nombre d’itérations qui seront théoriquement nécessaires pour livrer l’ensemble du backlog pris à un moment donné. Cela permet d’établir une date à donner au client, et permet aussi de fixer des objectifs de réalisation pour l’équipe.

Un autre point intéressant et de permettre à l’équipe de faire un remue-méninges pour essayer de voir comment la vélocité pourrait être augmentée. Est-ce que l’ajout d’une ressource serait à elle-seule bénéfique? Est-ce qu’il y a des amélioration d’équipements ou de locaux à effectuer?

Aussi, le calcul de la vélocité permet d’ajuster nos estimations de points d’histoires, en aprenant à mieux connaître nos forces et nos faiblesses.

Obstacles à la vélocité d’une équipe

Il est très commun qu’en début de projet, ou lors de la formation d’une équipe Srum, ou encore en début d’implantation, les premiers Sprints donnent une vélocité variable et/ou imprécise. Rassurez-vous, c’est tout à fait normal en phase d’ajustement.

Techniquement, si l’équipe n’a pas réussie à livrer tous les points d’histoires qui avaient été estimés, c’est que:

1. Il y a eu à la base une mauvaise estimation: les histoires ont pris beaucoup plus de temps/ressources à être complétées que ce qui avait été estimé initialement par l’équipe

2. Il y a eu des imprévus (maladie, urgences reliées ou non au projet)

3. Il y a eu des événements non-urgents mais hors du contrôle de l’équipe. Par exemple, panne de serveur de développement, problème de communications, etc..

Le point 1 ci-dessus est un point sur lequel l’équipe peut travailler lors de la phase d’ajustement. Après quelques Sprints, l’équipe, le Scrum Master ainsi que le Product Owner connaîtrons avec justesse la quantité de travail qui peut être effectué dans une itération typique. Cela aiguillera le choix et l’ordre des fonctionnalités qui viendront s’ajouter au produit à chaque Sprint.

Conclusion

C’était là mon dernier article de cette série d’introduction à Scrum. Loin d’être une synthèse complète sur le sujet, il s’agit néanmoins d’un tour d’horizon de ma compréhension de cette méthodologie.

On a vu que le concept de base de Scrum est l’utilisation d’itérations. À chaque itération, une certaines quantité de fonctionnalités sont livrées, et le choix de celle-ci est basé sur les histoires. Finalement, le tout est confiné dans le backlog de production.

Au fil des semaines à venir, je poursuivrai ma recherche de l’efficacité au travail, et Scrum restera sans aucun doute un sujet privilégié sur mon blog.

Et vous, quelles sont vos expériences avec Scrum? Faites-nous en part! Plus précisément, comment calculez-vous la vélocité de votre équipe?

Publicités
Tagué , , , , ,

3 réflexions sur “Introduction à Scrum: vélocité d’une équipe

  1. Denis St-Michel dit :

    Merci! Votre article est excellent aussi. J’aime bien le point qui est relevé, à savoir qu’il n’est pas possible de comparer la vélocité de deux équipes. C’est comme comparer des pommes avec des oranges. La seule mesure viable pour moi est de comparer la variation de la vélocité d’une même équipe au fil du temps, afin d’avoir une certaine mesure de son perfectionnement (surtout avec une nouvelle équipe en début de cycle. Qu’est-ce que vous en pensez?

    • Exactement c’est aussi le sens de mon article, pas par team mais pas non plus par développeur. Certains sont sur un rythme de production rapide, d’autres plus sur une démarche de qualité et correction. Je pense qu’il faut un peu de tout, mais la vélocité peut être très différente dans les chiffres.

  2. David Imboden dit :

    Très bonne introduction à la vélocité. Je me permets de compléter en disant de faire attention de ne pas comparer la vélocité des équipes entre elles et de ne pas continuer de mesurer en temps, cela peut avoir des résultats dommageables.
    (plus d’info : http://www.iteration.info/fr/calcul-de-la-velocite-attention-aux-pieges-classiques/)

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Publicités
%d blogueurs aiment cette page :