Pourrez-vous soutenir le rythme?

Publié par Philippe Tremblay le vendredi 27 janvier 2012 à 13:00

Lors d’un précédent billet intitulé « OÙ EN ÊTES-VOUS DANS VOTRE PROGRESSION AGILE », nous avons énuméré quelques techniques permettant d’évaluer la progression d’une adoption Agile dans une organisation.

Bien que ces mesures permettent l’évaluation de l’état actuel de la situation, bien peu d’entre elles permettent d’estimer si le produit développé permettra à une organisation de soutenir le rythme et contribuer à la prédictibilité espérée en développement itératif.

Soutenir le rythme

Au cours de sa durée de vie, est-ce que votre logiciel pourra évoluer tout en maintenant un niveau de coût linéaire plutôt qu’exponentiel? La figure suivante illustre la différence entre les coûts de développement au cours du temps d’un produit répondant aux (nombreux) critères de qualité et un autre qui minimise ou voir même néglige l’importance des principes de qualité logicielle.

Cout Logiciel Duree Vie

Figure A - Coûts du développement d’un produit dans le temps

Un logiciel de qualité pourrait avoir un coût initial plus élevé qu’un autre de moindre qualité. Il est cependant indéniable que les raccourcis pris (consciemment ou non) lors de la conception de ce dernier rattraperont et dépasseront rapidement les coûts de celui développé selon les caractéristiques d’un logiciel de qualité.

Un « nouveau » produit deviendra assez tôt un « ancien » sans ces caractéristiques de qualité. Il sera bientôt difficile de défendre le produit contre les attaques des coûts de maintenance astronomique et l’incessante croissance de la complexité. Ironiquement, ce sera probablement l’équipe de développement qui militera face aux gestionnaires afin de remplacer l’ancien produit par un (autre) nouveau. Et malgré les bonnes intentions, il est fort possible que les caractéristiques de qualité soient encore absentes et que le gaspillage se répète tout en dilapidant les précieux revenus de l’organisation.

Un logiciel de qualité, c’est quoi exactement?

Pour bien répondre, nous devrions faire plusieurs billets sur le sujet, mais de façon (très) concise, voici quelques-unes des caractéristiques d’un logiciel de qualité

Feuilles de thé ou lignes de la main?

Vous pouvez toujours essayer les méthodes « alternatives » afin de faire des prévisions sur la capacité du logiciel à soutenir le rythme, mais ce ne serait pas notre premier conseil. Quelles mesures pourraient bien nous aider?

La vélocité? Pas vraiment. Bien que la vélocité permette d’estimer la capacité de l’équipe, elle dépend de beaucoup de facteurs subjectifs et variables. Dont celui de notre définition de « Terminé ». Ce qui signifie que nous pourrions avoir une vélocité moindre en ajoutant des critères de qualité à notre définition de « Terminé ».

Le nombre de défectuosités? Après tout, avoir la plus petite quantité de défectuosités possible, n’est-ce pas ce qu’on entend par « un logiciel de qualité »? Non, non et non! On peut atteindre un nombre limité de défectuosités en investissant une quantité de temps indécente dans le « contrôle de qualité » d’un produit plus que déficient.

Le taux de couverture de nos tests automatisés, ça c’est bon…N’est-ce pas? Désolé, un logiciel de piètre qualité peut avoir 100% de couverture en tests automatisés tout en demeurant illisible et sans respecter les principes SOLID ou Clean code etc.

La beauté, c’est à l’intérieur

Hé oui, vous devrez « regardez sous le capot » pour savoir si vous avez un logiciel de qualité entre les mains. Vous me direz peut-être que vous faites de la revue de code régulièrement. Que signifie régulièrement pour vous? Plusieurs fois par année, par mois? Peut-être avez-vous la discipline de le faire plusieurs fois par semaine. Même cette fréquence ne peut probablement pas permettre d’obtenir une idée objective de la qualité du logiciel au cours des itérations.

Afin de soutenir le rythme d’un développement itératif et de vous assurer que vous n’êtes pas en train d’alimenter le spectre d’une dette technique grandissante, plusieurs outils et techniques sont à votre disposition. En voici quelques-uns

  • Outils automatisés pour les mesures statiques
    • Sonar (Java, C#, C, PHP)
    • TFS avec CodeMetric
    • NDepend (mesures statiques et analyse des dépendances)
    • Revue de code entre les pairs intégré dans votre définition de « Terminé »
    • Programmation en pair

Conclusion

N’oublions jamais le paradigme sous lequel nous devons concevoir les projets sous les principes Agile. La qualité ne doit plus être une variable, mais bien une constante (Figure B). La meilleure façon d’obtenir cette régularité est d’inspecter et adapter assidûment ce que l’on crée afin que l’organisation génère un actif plutôt qu’un passif.

C’est ainsi que l’organisation sera en meilleure posture afin de répondre aux besoins de ses clients…aujourd’hui et demain.

Agile Triangle

Figure B – Paradigme des contraintes de projets Agile

©Cette image est une gracieuseté de M. Patrik Malmquist (http://www.applitude.se)

blog comments powered by Disqus

0 Comments:

Post a comment

Comments have been closed for this post.