Dans le monde de la technologie, la vélocité est souvent le critère de référence pour mesurer la productivité d'une équipe de développement. La vélocité est une évaluation utilisée dans le développement de logiciels Agile pour évaluer la quantité de travail qu'une équipe peut effectuer au cours d'une période de temps donnée, généralement représentée par des story points ou des user stories complétées à chaque itération. En d’autres termes, tout dépend de la rapidité avec laquelle l’équipe crée du code et propose des fonctionnalités. Mais, même si la vitesse est cool et tout, elle peut conduire à de mauvais résultats et à un tas de dégâts en coulisses si elle n'est pas correctement équilibrée.
Bien qu’il existe de nombreuses autres mesures qui, s’accompagnant les unes les autres, constituent un excellent système de suivi des progrès, la vitesse reste l’une des plus populaires et, par conséquent, l’une des plus mal appliquées.
La vitesse occupe souvent le devant de la scène. Les équipes sont fières de la rapidité avec laquelle elles peuvent donner vie à une nouvelle fonctionnalité ou s'adapter aux dernières évolutions du marché. Cette recherche de vitesse témoigne d'un désir de se tenir au courant des concurrents, de maintenir l'engagement des utilisateurs et d'innover continuellement. Le processus de réflexion est simple : plus vous avancez vite, plus vous réalisez de résultats et plus vous apportez de valeur à vos parties prenantes, respectivement.
Décomposons-le maintenant. Aller à toute vitesse peut parfois signifier manquer quelque chose de bien plus important : la capacité de travailler avec moins ou pas d'épuisement professionnel, donc avec cohérence . Imaginez construire un bâtiment très haut très rapidement mais avec une base instable. Au fil du temps, cela peut accumuler une tonne de désordre technologique – c'est le coût caché de ces solutions rapides qui se répercuteront plus tard. Bien sûr, la livraison ultra-rapide a son attrait, mais cela vaut la peine de penser aux maux de tête qu'elle peut entraîner par la suite.
La prévisibilité, en tant que mesure, fait référence à la cohérence et à la fiabilité avec lesquelles une équipe ou un système fournit des résultats sur une période donnée. Plutôt que de se concentrer sur la vitesse, les équipes devraient se concentrer sur l’amélioration de la prévisibilité.
Il y a plusieurs raisons à cela:
Définir des attentes claires avec les parties prenantes.
Une équipe qui fournit des résultats variés – 100 points un mois, puis seulement 10 points les deux suivants – peut être une véritable montagne russe pour les parties prenantes. Les résultats incertains placent les parties prenantes dans un dilemme, ne sachant pas à quoi s’attendre ensuite. Au lieu de cela, une équipe qui fournit régulièrement, disons, 40 points mois après mois devient le MVP – elle devient le joueur fiable du jeu. Et c’est ce à quoi aspire réellement le monde des affaires : la prévisibilité .
Moins il y a d’erreurs, plus le jeu est long.
Même si l’imprévisibilité peut apporter des éclats occasionnels, c’est la stabilité de la prévisibilité qui l’emporte vraiment à long terme. Voici un problème : la feuille de route vers la prévisibilité n’est pas universelle. Chaque équipe a son propre parcours, c'est sûr. Pourtant, il existe une tendance chez les plus performants.
Les pratiques agiles matures sont le fil conducteur des équipes prévisibles et performantes. Qu'elles soient immergées dans Scrum, Kanban ou un mélange de méthodologies, ces équipes ont défini le rythme qui correspond à leur cœur de métier, laissant un espace à la fois pour un travail structuré et une liberté créative. D’un autre côté, il existe une volonté constante d’amélioration, pour que chaque sprint ou itération éclipse le précédent.
Prenons un exemple spécifique. Jira d'Atlassian a commencé comme un simple outil de suivi des bugs et des problèmes, mais est devenu l'un des outils de gestion de projet les plus populaires au monde, fournissant ses services à un large éventail d'industries. Il existe bien sûr un grand nombre de facteurs divers qui ont joué un rôle dans l’ascension de l’entreprise, mais la prévisibilité est sans conteste l’un des plus importants. Avec un historique d'itérations cohérentes (déploiement de mises à jour cohérentes et régulières), une boucle de rétroaction, un écosystème extensible et une feuille de route transparente, Jira a assuré sa position dans de nombreuses organisations à travers le monde.
Bien que mon objectif principal dans cet article soit de montrer pourquoi la prévisibilité l’emporte sur la vitesse, mon devoir est de mentionner que la meilleure pratique consiste toujours à trouver un bon équilibre entre les deux. Il ne fait aucun doute que lorsqu’il s’agit de choisir la mesure la plus juste, la prévisibilité est quelque chose qui promet le jeu le plus long. Mais si vous avez la capacité de construire un système d’évaluation à multiples facettes, trouver le moyen de calibrer les deux mesures (ou même plus) est la meilleure voie à suivre.
Trouver ce juste milieu nécessite une approche hybride. Cela ne signifie pas simplement diviser la différence, mais plutôt intégrer les deux éléments dans le cycle de vie du développement. Le développement itératif, par exemple, peut fournir des accélérations lors de sprints spécifiques, suivis de périodes où la prévisibilité et le raffinement priment. Reconnaissant la valeur de la rapidité et de la cohérence, les équipes auraient la possibilité d'adapter leur approche à des projets et des phases spécifiques, en utilisant les atouts de chacun pour produire un produit à la fois opportun et fiable.
Pour conclure, il est difficile mais véritablement important de garder à l’esprit que le domaine du logiciel ne doit pas être perçu comme un fardeau sans fin. Lorsque des tâches d'ingénierie déjà complexes sont aggravées par des mesures problématiques et parfois superficielles, l'essence véritable du travail est obscurcie, ce qui entraîne souvent une escalade inutile des tensions. Si vous êtes à la tête d'une équipe technique, il est essentiel de réfléchir à la façon dont vous mesurez le succès et guidez votre équipe. Le mieux est de demander et de continuer à vérifier auprès des autres développeurs que vous souhaitez évaluer.