A la suite du post précédent Quelle est la première question ? au sujet des deux questions majeures – coûts vs. risques – quelqu’un m’a demandé si existaient quelques processus ou best practices qui permettent d’atteindre ces deux objectifs.

Existe-t-il un “best of both worlds” afin de produire du code de qualité sans dépasser budgets et plannings ?

En fait, il n’est pas nécessaire de rechercher ce meilleur des deux mondes. Par exemple, si je dois réaliser un audit d’un système bancaire, je vais d’abord vérifier que les priorités en termes de business sont:

• Asset management: time to market, pas de bugs empêchant ou gênant le fonctionnement du système dés le premier jour, pas de souci de performance ou de sécurité évidemment. L’argent n’est pas un problème: on peut doubler l’équipe afin de respecter le planning. La maintenabilité n’est pas vraiment un problème: cette application peut être obsolète d’ici quelques années. Et dans le pire des cas, on peut la jeter et la réécrire, ou acheter un progiciel.
• Bank retail (service aux particuliers): systèmes anciens, généralement Mainframe-Cobol, souvent outsourcés pour des questions de coûts. Les utilisateurs ont l’habitude de voir une nouvelle release retardée de 2 ou 3 semaines, et ne sont pas surpris si certaines fonctionnalités sont défaillantes après mise en production.

Il est important de qualifier quel est l’alignement business/IT. Dites à la première équipe (Asset management) que vous allez mesurer les dérives de maintenabilité afin de contrôler le budget ou dites à la seconde équipe (Bank retail) que vous allez instaurer une politique de tolérance zéro en matière de non-respect des bonnes pratiques de performance, et vous vous verrez répondre “Et alors? Cela n’a aucune importance”.

Je ne crois pas qu’il existe une recette-miracle qui conduise au meilleur de ces deux mondes. Cependant, imaginons un instant qu’on vous demande de prendre en charge un projet sans connaître son “alignement”, voici ce que je ferai.

1. “You cannot control what you cannot measure” (Tom deMarco). Je commencerai d’abord par implémenter un outil d’analyse de code qui permette de tracer une carte de la qualité de l’application. Mesurer et contrôler.

2. Je définirai une stratégie pour cette application, avec les experts sur ce projet. Cette zone présente des risques : évitons de la modifier. Mais s’il faut vraiment toucher à un de ces composants, alors tester de manière exhaustive toute évolution. Il va falloir réécrire cette partie de l’application car il y a trop de code dupliqué qui va nous coûter beaucoup d’effort pour la maintenir. C’est une priorité de la redévelopper sous forme de composants réutilisables. Documenter cette partie ? Ok, cela peut attendre. Combien de temps pour faire tout cela ?
Ceci ménera à un plan d’actions avec différentes priorités à différents coûts à court / moyen / long terme. Il faut connaître quel est “l’alignement” de l’application pour construire ce plan.

3. Les défauts de programmation sont faciles à identifier et à résoudre. Réalisez régulièrement des analyses de code à l’aide de l’outil mis en place et définissez un processus de résolution de ces violations auquel vous intégrez votre plan d’action. Ces mesures constituent un premier pas vers un processus de Continuous Inprovement. Sur ce sujet : Amélioration continue de la qualité.

4. Les défauts de spécifications (absentes, erronées ou mal comprises) sont les plus coûteux mais aussi les plus difficiles à identifier. Mettre en place une méthodologie à base de revues utilisateurs, prototypage, agile, etc. Celle que vous préférez mais, selon moi, elle doit:

• Impliquer l’utilisateur : il doit valider à la fois l’interface (utilisabilité) et les fonctionnalités. Ce peut-être des utilisateurs finals ou une maîtrise d’ouvrage, peu importe, mais ils doivent être intégrés au projet. Combien de ‘défauts fonctionnels’ sont en fait des spécifications qui ont évolué en phase de projet ? En tant que responsable de celui-ci, je veux qu’il soit bien clair que je n’en assumerai pas les coûts.
• Etre compatible avec la technologie : je ne vois pas beaucoup de Scrum ou de méthodes agiles sur des projets Mainframe-Cobol.

5. Tests. Ils pèsent beaucoup sur le budget et le planning. D’abord, définir le niveau de QA requis. Si l’application n’est pas très volumineuse ni très complexe, des tests unitaires et d’intégration peuvent s’avérer suffisants. En fait, la difficulté provient des applications lourdes et complexes : combien investir dans la réalisation des plans de test, en charges de test et en outils ?
C’est là que la collaboration entre l’équipe de projet et les équipes de QA prend toute son importance. Par exemple, un client souhaite un audit sur la scalabilité d’une de ses applications : les données et le nombre d’utilisateurs vont être multipliés par 3. Une première analyse de code identifie les ‘fuites’ potentielles de performance, que l’on corrige. Le résultat des analyses ultérieures est partagé avec l’équipe de QA pendant la phase de développement, afin de les assister dans la définition de leurs plans de test. Il est décidé d’automatiser les tests de performance et de concentrer les tests manuels sur les nouvelles fonctionnalités utilisateur. Une Quality Gate est mise en place, afin de garantir la qualité du code livré et autoriser un ‘GO’ pour la phase de tests.
Vous pouvez perdre beaucoup de temps et d’argent en tests: essayer d’obtenir le maximum de visibilité sur la qualité de l’application afin de concentrer les efforts sur les zones qui permettront d’optimiser votre investissement.

6. Un retour du terrain est toujours appréciable. Récupérez les défauts rencontrés en production et corrélez ce nombre avec celui des défauts rencontrés lors des analyses de code. Montrez les résultats à votre équipe mais aussi aux utilisateurs/la maîtrise d’ouvrage et votre management. Normalement, vous devez pouvoir démontrer que cela va dans le bons sens et tout le monde est content de savoir que cela va dans le bon sens.

7. Munissez vous d’un outillage adéquat. Un outil d’analyse de code connecté àl’outil de développement et de gestion des changements/des versions, et des outils de tests. Cela dépend des technologies.

8. Il faudra une équipe avec un certain niveau de maturité.

Cela peut prendre des années avant de mettre en place un tel processus qui optimise les coûts en limitant les risques. Donc il est souhaitable de prioriser ces actions en fonction des objectifs et de l’alignement business/IT plutôt que de viser de prime abord un “best of both worlds”.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.