Productif OUI ! Mais pas sans la qualité !

_

La productivité des développements

Sans rentrer dans les détails du document, je vous laisse le télécharger et le lire mais voici les points qui me semblent clés :

• Disposer d’un socle technique (jdk, frameworks…) qui permet d’être productif. La sphère java est très nébuleuse et il est parfois difficile de s’y retrouver dans tous les frameworks disponibles. Privilégier les standards de fait, autrement dit les frameworks qui, à force d’utilisation, sont devenus des références et qui grâce à cette renommée, ont également pu s’améliorer. On citera notamment hibernate pour le mapping objet relationnel, spring qui couvre pas mal de domaines aujourd’hui (configuration, injection de dépendances, sécurité, batch, IHM web…). Ce dernier est particulièrement productif, tout au moins dans ses dernières versions, où la configuration XML a laissé place aux annotations. Annotations d’ailleurs apparues avec le jdk 5, qui apporte beaucoup du point de vue productivité et efficacité.

• Disposer d’un environnement de développement optimum sur le poste de travail du développeur; à savoir un éditeur efficace (Eclipse, IntelliJ) et correctement configuré (raccourcis, syntaxe du code…) avec des plugins additionnels aidant à être productif (Spring Ide si on fait du Spring par exemple). Mais ca ne s’arrête pas à l’éditeur. Le serveur d’application, si l’on développe une application JEE, est tout aussi important. Comptez le nombre de minutes passées à attendre qu’un ear se déploie et multipliez par le nombre de déploiement effectués par jour, vous allez simplement haluciner. Personnellement, j’apprécie beaucoup jetty qui est simple à configurer, démarre très vite et peut être lancé depuis Maven. Vous verrez que vous aurez moins peur de votre code quand vous saurez qu’en moins de 30 secondes, c’est plié, comparé à un certain serveur qui commence par web et fini par sphere…

• Disposer d’une usine de développement et tous les composants qui s’avèrent nécessaires :
  • Gestionnaire de sources, dans un premier temps, afin de garantir un échange plus fluide entre les développeurs et un gain de temps sur l’intégration du code.
  • Mécanisme et process de build, autrement dit un outil à la Maven et les bonnes pratiques qu’il apporte, afin de se baser sur un standard éprouvé et ne pas chercher midi à 14 heures où sont vos fichiers et comment construire votre application.
  • Intégration en continue, pour éviter l’ »effet tunnel » et les longues soirées la veille d’une livraison parce que le module foo ne correspond pas à ce qu’appelle le module bar…
  • Outil de suivi de tâches et anomalies, au moins pour faciliter les échanges MOA/client  – MOE.

• Enfin, rester « aware » concernant la productivité. JCVD, sors de mon corps ! Blague à part, on est productif si on est dans un état d’esprit productif, c’est à dire qu’on cherche à limiter les tâches répétitives manuelles en les automatisant, on ne reste pas dans l’inconfort (je citais Websphere plus haut : si vous perdez une heure par jour au moins à déployer votre application, remontez le au manager qui généralement n’aime pas ce temps gaspillé, ça facilitera peut-être un changement), on parle de productivité et on lève les problèmes pour les résoudre au plus tôt mais sans tout changer…

• J’allais oublier quelque chose qui me semble prépondérant et qui va faire la transition avec la deuxième partie : les tests. Bien sûr, certains médisants diront que les tests consomment du temps et qu’ils sont contre-productifs. A ceux-là, je dirai faites un calcul simple : comptez le nombre de bugs dans vos applications, multipliez par le temps de correction et par le taux de réapparition moyen :

nombre de bugs  x  temps de correction  x  taux de réapparition moyen  =  consommé

Exemple :  50  x  1j.h  x  0.30  =  15

Maintenant, pour chaque bug apparu et chaque nouvelle fonctionnalité, ajoutez un ou plusieurs tests unitaires (JUnit par exemple) qui valident (et valideront au cours du temps) le bon fonctionnement et la non-régression. Refaites ensuite le calcul précédent au cours du temps. Non seulement vous réduirez le nombre de bugs, mais vous réduirez également le temps de correction et le taux de réapparition : les tests permettent de cibler plus rapidement un bug qu’en passant au travers de tout le code avec un debugger, et ils limitent également les régressions.

Exemple : 30  x  0.5j.h  x 0.10  =  1.5

Alors, c’est pas de la productivité ça ?

Et la qualité ?

On a souvent tendance à délaisser la qualité au profit de la productivité et des coûts. Rappelez vous du fameux triptyque coûts – délais – qualité :

Le problème c’est qu’on oublie tout aussi souvent que les trois sont étroitement liés et qu’une mauvaise décision sur l’une des branche peut impacter les deux autres :

• « Il faut livrer vite, à telle date, je veux tout ça ! »
• Pour palier à la réduction des délais de livraison, on augmente généralement le nombre de développeurs, c’est à dire les coûts. De même, on met de côté la qualité (doc, tests…) pour s’attacher aux fonctionnalités.
• Le problème en délaissant la qualité, est qu’on augmente les délais (cf. calcul ci-dessus) et généralement aussi les coûts (100j.h, c’est plus cher que 50…).
• Au final, on a voulu réduire les délais et c’est le contraire que l’on a obtenu.

Maintenant on peut envisager les choses autrement :

• On mise sur la qualité. Cela passe par tout un tas de choses dont nous parlerons ensuite et notamment les tests.
• Soyons honnêtes, à court terme, cela augmente les coûts et les délais : développer des tests en plus du code est consommateur, mettre en place une usine de développement prend du temps, configurer correctement un environnement de développement peut sembler futile…
• Par contre, à moyen et long terme, cela s’avère payant, les développeurs sont plus efficaces (intégration continue, IDE configuré), plus sereins (couvertures des tests).

Combien de projets en échecs pour un réussi ? combien de budgets dépassés pour un tenu ? Cela se produit encore trop souvent parce qu’on se borne à vouloir faire comme on a toujours fait, à savoir mal !

Je n’ai pas de chiffre précis pour comparer les deux cas cités ci-dessus mais simplement un retour d’expérience :

Je travaille pour le compte d’une grande banque française sur le développement d’un outil de provisionning d’habilitations. En 3 semaines, avec des tests unitaires (JUnit), des tests d’interface (Selenium), un serveur d’intégration continue (Hudson), on a mis en production une première version simple mais qui marchait.

Aujourd’hui, 6 mois et 1600 tests plus tard, on a à tout casser 5 bugs bloquants et tout au plus une dizaines de majeurs (en préprod) et aucun bug important sur la prod… Un nouveau développeur arrivé récemment a pu, grâce aux tests et sans souffrir, faire un gros refactoring au bout d’une semaine sur le projet. Le temps de correction d’un bug est inférieur à la demi journée, voire à l’heure… bref, on a misé sur la qualité et aujourd’hui, l’application est stable, évolutive, l’équipe est efficace et la MOA commence a comprendre l’intérêt d’être un peu patient.

Conclusion

Je ne suis pas entré dans les détails sur la qualité des développements, les différents types de test, les méthodologies de tests, les outils annexes pour faire de la qualité (métriques diverses)… et tout ce dont nous avons à disposition pour faire des logiciels de qualité. Je traiterai plus en détails de ces aspects dans un prochain article. Je voulais surtout mettre l’accent sur le fait que la productivité n’est pas incompatible avec la qualité, voire bien au contraire : faire du travail propre permet d’être efficace !

Encore une fois : faites l’expérience et prenez le temps de mesurer les gains de la mise en place de tests par rapport à une politique de debug intensif. Vous verrez que vous y gagnerez en qualité et en productivité…

Et surtout, n’hésitez pas à lire le livre blanc Octo