J’ai rapidement mentionné ce concept dans des articles précédents, mais j’aimerais y consacrer plus de temps, car c’est l’une des parties cruciales de Scrum, et l’une des plus difficiles à comprendre, pour les développeurs et pour les managers.

Une blague récurrente que j’entends quand les équipes commencent à utiliser les points de complexité, sans en comprendre pleinement les principes, c’est leurs tentatives de quantifier la valeur boursière des points de complexité par rapport aux heures-homme. Drôle, mais sans intérêt.

Les points de complexité font partie du paradigme Scrum. Mélanger les paradigmes est rarement une bonne idée.

Oui Alice, vous devriez suivre le lapin blanc !

La complexité n’est pas une autre dimension temporelle

La première chose à comprendre, c’est que si cette notion de “points de complexité” a été introduite dans Scrum, ce n’est pas parce que c’est tendance, ni pour donner un autre nom à la dimension habituelle des “heures-homme”.

Si j’essaie d’écrire l’expression mathématique des points de complexité, je pense que ça ressemblerait à quelque chose comme :

Points de complexité (sprint) = Σ((temps de développement de la fonctionnalité + Var(temps de développement))/facteur de compétence moyen(équipe)) + Var(obstacles)

Var() représente la Variance : les points de complexité prennent en compte une part d’incertitude dans la capacité à livrer les fonctionnalités dans les temps.

Tout le monde, dans n’importe quel secteur, a d’une façon ou d’une autre rencontré des obstacles en essayant d’atteindre un jalon de livraison. Et tout le monde a échoué à atteindre ce jalon à cause de certains de ces obstacles.

Tout le monde, dans n’importe quel domaine, a travaillé avec des personnes de niveaux de compétence et de capacités différents. Il ne sert à rien de dire qu’un développeur de votre équipe est meilleur qu’un autre : l’équipe livre le travail ensemble. Par conséquent, nous ne parlerons que du facteur de compétence moyen.

Et tout le monde, du moins dans le secteur du logiciel, a d’une façon ou d’une autre rencontré une situation où il y avait plus de travail à faire que prévu/attendu. Parce qu’à un moment, les développeurs ont trébuché sur un problème technique. Parce qu’à un moment, l’équipe a réalisé qu’un cas d’usage avait été oublié.

Ne tirez pas sur le messager ! Je peux vous dire : il est pratiquement impossible de prédire tous les cas d’usage, et peu importe la qualité de votre Product Manager, il en oubliera toujours.

Bucketing, Poker planning

Ce sont les noms que vous avez peut-être entendus quand il s’agit de votre équipe qui essaie d’estimer des fonctionnalités en points de complexité.

Ces réunions sont généralement appelées Backlog Refinements, et c’est le moment :

1. De s’assurer que tout le monde comprend ce qu’on attend d’une fonctionnalité
2. De s’assurer que tout le monde comprend les specs
3. De challenger les specs et d’essayer d’évaluer la “couverture des cas d’usage”
4. De s’assurer que les développeurs ont une idée de ce qui doit être fait côté technique (attention ! Il ne devrait pas y avoir de discussions intensives sur l’implémentation technique !)

Il est tout à fait acceptable de reporter le travail sur une fonctionnalité qui n’est pas bien comprise, ou qui a une couverture de cas d’usage trop faible.

De toute façon, chaque fonctionnalité est revue du haut en bas du backlog (qui a été correctement priorisé en amont). Quand l’équipe a tout compris, elle peut estimer la complexité du développement et de sa mise en “Terminé”.

Note : la définition de “Terminé” est la vôtre. Une bonne définition est : développé, testé et validé dans un environnement de staging.

Généralement, les estimations sont données selon la suite de Fibonacci : 0, 1, 2, 3, 5, 8, 13, 21…

On peut appeler ça du bucketing ou du poker planning, selon la façon dont vous organisez l’estimation. Ce qui est important, c’est que toute l’équipe de développement y participe et doit parvenir à un consensus. Cela permet de s’assurer que tout le monde a vraiment compris de quoi parle la fonctionnalité, et donne la parole à chacun pour qu’il puisse potentiellement signaler des problèmes non vus.

Pourquoi Fibonacci ?

Plus la fonctionnalité est grande, plus il y a de chances que vous ayez oublié des cas d’usage, ou que vous rencontriez des obstacles.

La suite de Fibonacci illustre ce principe, où chaque nouvelle valeur augmente de façon exponentielle, pour s’adapter à des obstacles toujours plus nombreux.

Eh bien, disons que je m’en tiendrai au “Niveau 2”, et que je laisserai quelqu’un d’autre donner plus d’informations sur pourquoi utiliser Fibonacci.

Vélocité

Revenons aux formules. La vélocité pourrait s’exprimer comme :

Vélocité = Σ(complexité(sprint n-1) à complexité(sprint n-6))/5

Donc oui, avant d’avoir une idée de la vitesse à laquelle vous livrerez des fonctionnalités, il vous faudra attendre le 6e sprint ! Ensuite, vous pourrez dire que grossièrement, vous pouvez imaginer livrer X points de complexité par sprint.

NON ! C’est pas là qu’on peut recommencer cette blague sur la bourse ! Sauf si vous assumez pleinement la métaphore et comprenez que la “valeur” changera avec le temps.

Ce qui est important, c’est que vous créez votre propre référentiel !

Votre équipe peut comprendre des développeurs brillants, ou des débutants, ou un mélange. Bien sûr, il y aura une corrélation directe entre leur niveau de compétence et la vélocité de l’équipe. Mais vous obtiendrez en réalité une métrique fiable, car elle dépend directement de votre équipe, travaillant ensemble.

Les itérations permettront d’obtenir de la prévisibilité là où il n’y avait que du flou dans la planification.

Tout comme n’importe quel système adaptatif, les sprints Scrum vous permettront de :

• évaluer vos estimations après avoir livré les fonctionnalités, d’apprendre et de mieux estimer la prochaine fois
• faire face à divers types d’obstacles (bugs en développement, crash de production, équipe absente), qui impacteront directement votre vélocité, absorbant ainsi ces obstacles dans la partie Var() de la formule ci-dessus.

Tout cela créera votre propre référentiel. Et si vous commencez à travailler avec une autre équipe, ce travail devra être recommencé.

Chronophage, dites-vous ? Peut-être. Mais ça en vaut définitivement la peine. Les gens ont tendance à dire qu’il est impossible de planifier une roadmap fiable dans le développement logiciel. Mon expérience est que, en restant fidèle à ce paradigme, j’ai pu planifier une release complète de produit un an à l’avance avec un delta d’un mois de travail. Oui, il y avait quand même un delta à la fin. Et il y en aura probablement toujours. Mais en regardant le rythme rapide des changements de specs, le même projet aurait probablement pris 2 ans à compléter avec un périmètre équivalent.

Moins on contrôle, plus on contrôle

Il est important d’amorcer les évaluations de points de complexité (par exemple avec la méthode Elatta), mais après un certain temps, l’évaluation devrait se faire par rapport aux évaluations précédentes, et finalement uniquement sur instinct. Quand ce stade final est atteint, votre équipe a suffisamment de précision pour estimer le coût réel de développement et intégrer tous les risques (délais liés aux humains, nécessités de refactoring, problèmes de production et autres recentrages urgents et temporaires).

Diviser pour régner

Gardez à l’esprit : plus une estimation est grande, plus il est risqué de commencer à développer la fonctionnalité. Jusqu’à présent, j’ai constaté qu’à partir de 8 points et plus, il y avait un taux élevé de stories qui n’étaient pas livrées comme prévu, faute de spécifications fonctionnelles ou techniques et d’informations suffisantes. Clairement, si vous atteignez une estimation de 13 points :

1. Vérifiez avec votre équipe si elle a bien compris la fonctionnalité, son objectif et son fonctionnement.
2. Essayez de diviser le travail en plusieurs stories, qui pourront ensuite être estimées (espérons-le) en dessous de 8 points chacune. Et assurez-vous que le périmètre et les objectifs sont clairs pour chacune d’elles.

Les bonnes questions

En général, quand votre équipe ne comprend pas au bout d’un moment comment fonctionnent les points de complexité, elle commence à remettre en question leur utilisation ou leur nature, et à revenir à l’ancien paradigme. Ce sont de mauvaises questions. J’essaierai d’en lister quelques-unes de bonnes :

• Estimons-nous correctement ?
• Comparons-nous avec nos estimations précédentes ?
• Avons-nous généralement assez de visibilité/compréhension sur les fonctionnalités ?
• Ne devrions-nous pas essayer de diviser les stories en unités plus petites ?
• Avons-nous réussi à stabiliser notre vélocité ?

Image de une par Tim McDowell