Le processus de développement logiciel est complexe. Cela implique diverses tâches qui doivent être réparties entre les équipes et achevées dans un délai déterminé. Les responsables doivent maîtriser le processus de développement logiciel et établir un flux de travail qui peut être tracé, car une mauvaise gestion, même d’une taille infime, peut amener les équipes à faire des compromis sur les délais. C’est là qu’une métrique comme Sprint Velocity peut aider à définir des objectifs réalisables et à gagner en visibilité sur le processus.
Qu’est-ce que la vitesse de sprint ?
Dans le cadre de développement agile, les équipes divisent le temps disponible en plus petites durées ou sprints, qui peuvent être certains jours ou semaines. Le nombre de tâches terminées à la fin de chaque sprint est la vitesse de ce sprint particulier, et la valeur de vitesse moyenne sur ces sprints est la vitesse de sprint de l’ensemble du processus de développement. Le calcul de la vitesse de sprint est crucial dans le processus de développement car il détermine le taux de réussite dans le respect des délais. En plus d’aider à déterminer des délais réalisables, la métrique de vitesse de sprint trouve également d’autres applications dans le processus de développement agile et dans le bien-être du développeur.
En quoi Velocity est-il utile pour les équipes Scrum ?
Le suivi régulier de la vitesse du sprint peut aider les équipes logicielles à gagner en visibilité sur la progression du projet et les obstacles qui l’entravent. Ne pas atteindre la vitesse de sprint cible peut signaler des problèmes que les gestionnaires peuvent examiner et analyser. Cela leur permet de comprendre les obstacles au processus de développement et d’identifier les lacunes, tant internes qu’externes. Voici d’autres informations qui peuvent être obtenues en calculant la vitesse de sprint :
- Comprendre les difficultés techniques du projet
- Optimiser l’allocation des ressources entre les sprints
- Découvrez les bloqueurs à différentes étapes du processus de développement, qu’il s’agisse d’écrire des codes, de tester ou de faire des commentaires et de retravailler
- Découvrez s’il y a des divergences dans les objectifs fournis par les parties prenantes
- Découvrez si les exigences changent fréquemment
Bien que les avantages du calcul constant de la vitesse de sprint soient nombreux, il n’y a pas qu’une seule façon de le faire. Les organisations ont plusieurs concepts pour calculer la vitesse de sprint dans leur processus de planification agile.
Comment mesurer et visualiser la vitesse de sprint ?
Chaque équipe, chaque projet et chaque client est unique. Par conséquent, le calcul de la vitesse sur ces verticales peut être difficile. Au fil des ans, les organisations ont mis au point différentes variables et constantes qui peuvent les aider à calculer et à analyser la vitesse de sprint. Les plus courants d’entre eux sont :
- Histoire de l’utilisateur
- Capacité
- Définition de terminé
- Graphique de vitesse
- Tableau de combustion
Histoire de l’utilisateur
Une user story est la traduction quantifiable des exigences nécessaires pour compléter une fonctionnalité, un module ou un produit particulier en fonction des avantages du point de vue de l’utilisateur final. La user story se voit attribuer des points en fonction de la complexité et des efforts nécessaires à partir d’une histoire mineure ou d’une correction de bogue, gagnant 1 point et un développement important ou des modifications allant de 5 à 8 points. Encore une fois, cela varie selon les sprints, les équipes et les départements.
Capacité
La capacité de planification de l’équipe permet d’arriver à une valeur réaliste disponible pour compléter les user stories. La planification de la capacité permet d’estimer la bande passante disponible pour développer, tester et modifier les user stories. Cette métrique est obtenue en calculant la disponibilité individuelle et en la mappant à la liste des user stories, donnant ainsi le temps total dont dispose l’équipe pour accomplir la tâche. En supposant qu’un développeur dispose idéalement de 6 heures de bande passante de productivité après les réunions, les pauses et autres activités de routine, et qu’une équipe compte environ huit développeurs travaillant cinq jours par semaine pendant trois semaines, la capacité est de 720 heures.
Définition de Terminé (DoD)
La définition de la définition de terminé est un ensemble convenu de conditions ou de critères d’acceptation qu’un processus doit respecter pour qu’il soit complet du point de vue de l’utilisateur final. Il peut contenir divers paramètres tels que les tests, la révision, la documentation, etc., mais doit répondre aux critères complets définis par l’utilisateur final.
Graphique de vitesse
Le graphique de vitesse est pratique lors du calcul de la vitesse de sprint car il met en évidence la quantité de travail effectué et la quantité de travail restant dans la user story ou la tâche. Il fournit des informations sur la quantité moyenne de travail à effectuer pour obtenir les résultats souhaités dans le sprint. Le point d’histoire est tracé le long de l’axe des y et les sprints terminés sont sur l’axe des x, et les deux se rejoignent pour fournir une compréhension des performances de l’équipe et définir des objectifs futurs.
Tableau de combustion
Bien que presque similaire au graphique de vitesse, le graphique burndown donne un aperçu de la progression de l’équipe dans l’exécution de la tâche engagée dans toutes les user stories au cours d’un seul sprint. La pente du burndown chart aide à prédire si l’histoire sera terminée tôt, à temps ou en retard.
La vitesse de sprint n’est pas la seule mesure dont vous avez besoin
Comme mentionné précédemment, la formule de vitesse du ressort peut différer selon les équipes, les processus, les projets et les clients. Les managers ne doivent pas viser une vitesse de sprint plus élevée et aligner les objectifs pour augmenter le nombre. En fait, la vitesse de sprint est :
1) variables
2) Descriptif
3) Arbitraire
L’augmentation de la vitesse seule peut être complexe et contre-productive, surtout sans données ni outils pour la sauvegarder. Les responsables doivent également tirer parti d’autres facteurs d’évaluation tels que de meilleures révisions de code, une évaluation de la qualité et une meilleure planification tout au long du processus de développement en adoptant une position axée sur les données plutôt que sur l’achèvement. Les responsables doivent avoir accès à d’autres métriques de développement logiciel telles que le taux de rotation du code, le temps de création et même les stand-ups asynchrones pour identifier efficacement les bloqueurs et tirer parti des informations recueillies à partir de ces métriques pour améliorer la vitesse de sprint. Pour ce faire, ils ont besoin d’une plate-forme d’analyse d’ingénierie qui englobe les outils et analyses critiques pour optimiser le processus de développement logiciel.