En principe, l’introduction de l’agilité dans les développements améliore la situation existante. Mais plus ou moins vite et c’est ce rythme qu’il convient de mesurer, pour l’ajuster si nécessaire. On peut associer plusieurs indicateurs aux méthodes agiles et retenir les sept suivants :
- Un indicateur de satisfaction des clients et des équipes. On peut par exemple utiliser le Net Promoter Score, qui représente la différence entre la proportion de promoteurs et celle des détracteurs. Plus le score est élevé, plus la satisfaction est importante : s’il est égal à zéro, il y autant de promoteurs que de détracteurs.
- Un indicateur d’efficacité : il mesure l’écart entre les résultats recherchés et les résultats obtenus. Cela revient à identifier si les finalités poursuivies, les buts fixés, les objectifs programmés ont été atteints ou, si c’est possible, à calculer des ratios d’atteintes de ces finalités. On distinguera ainsi trois notions :
• L’efficacité par rapport aux objectifs (la réussite du projet).
• La réussite par rapport aux buts (les résultats).
• Les finalités (la dynamique du projet en mode agile). - Un indicateur d’efficience : il mesure le rapport existant entre la quantité et la qualité des résultats obtenus et les ressources matérielles, humaines et financières mises en œuvre pour les obtenir. L’analyse de l’efficience apparaît, en quelque sorte, comme un contrepoids à l’appréciation de l’efficacité dans la mesure où elle pondère celle-ci par le calcul des coûts. Le calcul de l’efficience est soumis à deux conditions importantes. D’une part, il faut pouvoir déterminer les taux d’atteinte des objectifs, des buts et des finalités, et, d’autre part, pouvoir déterminer les coûts, directs et indirects.
- Un indicateur sur le nombre de sprints et de stories : c’est à l’échelle d’une entreprise ou d’une DSI, un indicateur de la diffusion des approches agiles, d’autant plus pertinent que l’objectif d’une telle progression est affiché comme prioritaire. On mesurera ainsi le nombre total de User Stories engagées/terminées dans un sprint donné.
- Un indicateur de fiabilité/qualité : il ne sert à rien d’être agile si, au final, cela aboutit à dégrader la qualité des livrables. Il faut donc la mesurer pour chaque projet.
- Un indicateur de Time to Market : l’intérêt des méthodes agiles étant d’aller beaucoup plus vite pour développer et mettre en production, cet indicateur illustre la performance de l’approche. Il faut toutefois l’associer aux indicateurs de qualité. On mesurera par exemple le temps entre l’expression d’un besoin par un métier et la livraison de l’application aux utilisateurs.
- Un indicateur de dette technique. Rappelons que le terme de dette technique a été introduit en 1992, par Ward Cunningham, pour décrire les coûts associés à la maintenance d’un développement logiciel. L’analogie avec la dette vient du fait qu’elle induit des intérêts à payer, qui se traduisent par un effort supplémentaire à fournir pour la maintenance des applications, du fait de la complexité toujours croissante des systèmes, et également par le fait que l’évolution d’un système entraîne toujours une charge de refactoring (action sur le code à fonctionnalité équivalente) et de réécriture de certaines parties de ces systèmes. Cet effort est assimilable à des intérêts. Si l’on accumule trop de dettes, la majorité des efforts seront concentrés au service de la dette, intérêts et capital compris. Il faut veiller à ce que les approches agiles ne conduisent pas à augmenter la dette technique, avec une mesure des bugs, de la documentation technique et de la complexité des applications, des outils existent pour analyser la qualité du code.
Pour en savoir plus sur les indicateurs de l’agile, nous renvoyons à deux sources utiles :
https://www.qualitystreet.fr/2017/11/13/kpi-agiles/
https://www.les-traducteurs-agiles.org/2017/10/24/indicateurs-scrum.html
Développements agiles : les principaux indicateurs clés de succès
- Comment savoir si une démarche de développement agile a réussi ? Plusieurs indicateurs sont utiles, par exemple :
- Le nombre de fonctionnalités délivrées.
- La fréquence des demandes de modification de la part des métiers.
- Le nombre d’erreurs trouvées dans le cycle DevOps.
- La proportion de développeurs qui travaillent de manière indépendante sur une application dont ils ne sont pas familiers.
- La justesse des estimations de temps de développement.
- Le nombre d’erreurs détectées avant la compilation du programme.
- La qualité du code.
- Le nombre de développeurs formés aux méthodes agiles.
- Le degré de collaboration entre les développeurs et les métiers.
- La détection en amont de la consommation CPU.
- La réduction du coût moyen par erreur.
- La baisse du temps moyen de détection des erreurs.
- La réduction du temps de validation du code.
Source : 10 steps to true mainframe agility, Compuware.
Lien : https://resources.compuware.com/ten-steps-to-true-mainframe-agility