Un des indicateurs qu’il faut maîtriser afin d’assurer le pilotage d’un projet Agile est la date de fin du projet. Dans nos missions, nous avons observé que les mêmes questions reviennent sans cesse à propos de ce sujet. Par conséquent, avec cet article, nous avons souhaité restituer une synthèse de nos retours d’expérience et de nos bonnes pratiques sur ce thème.

La date de fin d’un projet Agile est la date à laquelle tout le périmètre fonctionnel prévu a été implémenté. L’opération de calcul en elle-même est très simple puisqu’elle consiste à diviser le « Reste A Faire » (RAF) sur la vélocité. Cependant, plusieurs interrogations subsistent…

La vélocité est-elle la vitesse de développement de l’équipe ?

La vélocité est plus large que la vitesse de développement. En effet, c’est la vitesse à laquelle le système produit des fonctionnalités implémentées, validées par la MOA et déployables en production. Ici, par système, nous entendons l’équipe projet dans son ensemble (MOA, MOE, Marketing, Exploitation…). Il faut insister sur ces critères car :

• Une fonctionnalité implémentée qui ne respecte pas la demande des utilisateurs (spécifications manquantes) n’apporte pas de valeur et nécessite encore du travail. D'où le projet n’a rien produit
• Une fonctionnalité implémentée qui contient des erreurs (tests insuffisants) n’apporte pas de valeur et nécessite encore du travail. D'où le projet n’a rien produit
• Une fonctionnalité implémentée qui n’est pas prête à être déployée en production n’apporte pas de valeur et nécessite encore du travail. D'où le projet n’a rien produit

Quelle unité dois-je utiliser pour mesurer ma vélocité et mon RAF ?

Pour pouvoir calculer la date de fin du projet, il faut utiliser la même unité pour la vélocité et pour le RAF. Cette unité peut être …

• Soit la complexité fonctionnelle. Cette unité est l’idéal en terme de pilotage car elle permet de calculer l’apport de valeur fonctionnelle du projet. Cependant, elle n’est pas toujours facile à mettre en place et certaines équipes la trouvent contre-intuitive pour l’estimation.
• Soit la complexité technique. Cette complexité est le reflet de l’effort de développement à fournir. Elle peut s’exprimer directement en charge (j.h) ou en points. L’avantage de cette unité est que les développeurs la trouvent intuitive pour la phase d’estimation. Par contre, elle ne mesure que l’effort de production et non pas la production de valeur fonctionnelle du système.

Remarque : nous avons délibérément choisi de ne pas entrer plus en détail dans la comparaison entre la complexité fonctionnelle et technique car c’est un sujet très riche. Ceci sera traité plus en profondeur dans un article à paraître bientôt sur notre blog.

Ma vélocité n’est pas stable, que puis-je faire ?

Si la vélocité bouge tout le temps, il devient très difficile de piloter le projet (essayez de conduire une voiture où la vitesse augmente et baisse sans prévenir !). Par conséquent, il est indispensable de stabiliser au maximum le système et les processus afin de stabiliser la vélocité. Réalisez des rétrospectives afin d'identifier les problèmes et leurs causes profondes : La MOA fait-elle des spécifications incomplètes ? Les tests sont-ils mal faits ? L’équipe est-elle instable (beaucoup d’entrées et de sorties dans l’équipe) ? Y-a-t-il des dépendances avec des équipes externes qui plombent le projet ? … Une fois les causes identifiées, cherchez les améliorations les plus adaptés à la situation du projet.

Ma date de fin est trop lointaine et ne convient pas au client que puis-je faire ?

Il y a 4 variables d’ajustement dans un projet

• Date de fin
• Budget
• Périmètre fonctionnel
• Qualité

Dans un projet Agile (du moins chez OCTO ;)), la qualité est non négociable. En effet, baisser la qualité des développements en espérant gagner en vélocité crée un cercle vicieux néfaste au projet : baisse de la qualité induisant la création de dette technique provoquant une baisse de la vélocité poussant à une baisse supplémentaire de la qualité. Par conséquent, nous n’allons pas l’inclure dans les arbitrages. Intéressons-nous aux 3 autres variables :

• Date de fin
• Budget
• Périmètre fonctionnel

A ce niveau, l’arbitrage dépendra du contexte du projet et des priorités du client en face. Nous avons les trois possibilités suivantes :

• Maintenir le périmètre en décalant la date et en augmentant le budget en conséquence. Dans les projets de refontes, les clients optent souvent pour cette possibilité.
• Diminuer le périmètre fonctionnel en maintenant la date de fin. Dans les cas d’un nouveau projet (surtout si le time-to-market est important), les clients privilégient cette approche.
• Maintenir le périmètre fonctionnel et la date en acceptant une augmentation du budget (en d’autres termes, ajouter des personnes à l’équipe). Il faut noter que nos différents retours d’expérience montrent que cette option est plus risquée que les précédentes pour plusieurs raisons.
  • Ajouter une nouvelle personne sur un projet provoque une baisse de la vélocité du système sur le court terme. En effet, la personne a besoin de temps et d’aide pour monter en compétence sur le projet et devenir productive. Donc adopter cette solution lorsqu’il ne reste que 3 semaines sur la date de livraison ne peut que mettre en péril le projet
  • Augmenter la vélocité du système en augmentant la taille de l’équipe est une solution qui ne peut fonctionner que jusqu’à un certain seuil. Au-delà de ce seuil, la charge de coordination et de synchronisation nécessaire plombera la productivité de l’équipe. Par conséquent, plus l’équipe grandira, plus la productivité baissera

Conclusion

Pour conclure, il faut insister sur une recommandation. Respecter la date de fin d’un projet est une chose importante mais il ne faut surtout pas le faire au détriment de la qualité du produit final. Effectivement, en cas de rush, beaucoup d’équipes ont tendance à sacrifier la qualité de l’application produite. Ces équipes créent de la dette technique qu’elles paieront très cher par la suite !