La qualité est un voyage

pas une destination.

C’est par ces mots que se termine la conférence Qualité du code source et l’intégration continue des collaborateurs de Xebia. Il est bon de rappeler que la qualité ne peut pas être quelque chose qui s’enclenche en un geste, ni même qu’elle se termine.

Au cours de ma carrière, j’ai souvent été surpris par le peu de qualité fournie sur les projets, tant au niveau du code source que de la documentation. Et ne parlons pas des tests ou de l’intégration continue, concepts encore trop souvent inconnus chez certains éditeurs.

Mais instaurer la qualité sur un projet existant ou dans une société n’est pas chose aisée. Xebia le détaille d’ailleurs très bien sur les dernières diapositives de son exposé.

Pour ma part, je dirais que la plus grosse difficulté n’est pas sur la technique, puisque qu’après tout, si d’autres sociétés le font, tout le monde peut le faire, mais sur les individus et la motivation.

En effet, si les participants au changement ne connaissent pas ces pratiques, ils peuvent douter de leurs biens fondés, de la facilité de mise en place, des gains de productivité et qualité et de l’impact direct sur leur travail.

Imaginez, vous demandez à des développeurs, souvent en place depuis plusieurs années de :

  • changer leur façon de développer, cela pourrait laisser penser qu’ils ne savent pas développer,
  • écrire des tests unitaires et d’intégration, ce qui va leur demander plus de temps, et donc faire baisser leur productivité,
  • suivre leur projet sur un serveur d’intégration et corriger toute erreur en priorité si le cas se présente, ce qui signifie que corriger un serveur de build est plus important qu’une fonctionnalité métier,

Il est clair que si l’on évoque ces trois points, la qualité du code source et l’intégration continue ne semblent pas apporter de productivité aux développements, bien au contraire.

Mais lorsqu’on connait les 3 points suivants, les premiers commentaires semblent bien négligeables, face aux avantages accumulés :

  • Un développeur passe 80% de son temps à lire du code et 20% à en écrire, il a donc tout intérêt à avoir un code lisible et rapidement compréhensible, pour diminuer son temps de lecture et augmenter son temps d’écriture,
  • Les tests permettent d’être informé de la moindre régression dans le code et de modifier à loisirs et sans doute du code existant afin de l’améliorer,
  • Le serveur de build informe, en temps quasi-réel, de l’état du projet et des tests pour l’ensemble des acteurs du projet, afin de corriger une erreur au plus tôt et de ne pas attendre d’être en production pour corriger une faille passée au travers des tests métiers,

Pour une société qui ne maitrise aucun des points cités précédemment, les gains de productivité peuvent atteindre 300%, voire plus si le code est réellement catastrophique ou si l’intégration de nouveaux développeurs est importante. Vous me direz alors, 300%, c’est énorme. En fait à y réfléchir, ces 300% ne sont pas très important, c’est principalement la productivité de départ qui est très faible. Car bien souvent, si vous n’avez pas de qualité du source code ou d’intégration continue, vous empilez les bugs, vous multipliez les copier-coller de peur de modifier l’existant, vous passez votre temps à lire et vérifier une implémentation…

Mais rappelez-vous, pour mettre en place les bons process de développements, le plus important n’est pas la technique, c’est l’accompagnement au changement. Soyez sur d’avoir les bonnes personnes pour vous aider.

Scrum : De l’intérêt des méthodes agiles

Depuis l’année dernière je m’intéressais beaucoup aux méthodes dites agiles dans la gestion de projet, comme Scrum, par exemple.

J’ai l’occasion grâce à mon emploi actuel de m’initier à ces principes qui sont aux antipodes des méthodes dites traditionnelles de gestion de project que nous pouvons pratiquer en France et qui sont enseignées dans nos universités.

Il n’est pas simple pour un manager de passer de l’un à l’autre. Beaucoup de principes et concepts sont à revoir, réapprendre et le faire seul est une étape difficile. Heureusement pour moi, j’ai la chance d’être initié (sur la pratique tout au moins) par une collègue canadienne, devenue Scrum Master récemment.

Avec ces principes, vous ne devez plus penser long terme, mais court terme, et surtout retour sur investissement (ROI). Les premiers mois ont été plutôt difficiles. En effet, l’envie de faire des projets et des plannings restent forts. Surtout lorsque vous disposez de MS Project 2007 et que vous avez envie de faire « joujou » avec.

Et puis le temps passe, vous faites des réunions et des itérations (planning, développements, tests, bugs, démo et déploiments) et vous vous sentez tout à coup envahi par ces principes qui remettent en question tout ce que vous avez pu faire avant.

En effet, dans une démarche standard, vous avez l’étape de spécifications, pendant laquelle vous réfléchissez avec votre client ou votre MOA. Les idées sont souvent vagues, il est difficile de se faire une idée concrète du produit final, vous êtes seul ou dans une équipe réduite à son minimum. Pas de développeur. Ensuite vous attaquez les devs et tests et suivez avec fidélité les spécifications qui sont très souvent vagues et pour lesquelles vous devez retourner voir le client car vous avez besoin d’éclaircissements. Puis vient le jour du déploiement et des formations utilisateurs. Et comme bien souvent, à cette étape, l’équipe est à nouveau réduite et vous êtes le seul à recevoir les remerciements (ou les blâmes, cela dépend). Et puisqu’à cette date, vous quittez vous-même le projet, vous ne savez pas ce qui va réellement être utilisé et ce qui convient et ne convient pas. Grosso modo, quel est le travail réellement intéressant et qui apporte une réelle plus value au métier. Les manques sont considérables.

Dans l’autre cas, méthode Scrum, par exemple, vous êtes au contact direct du métier. L’équipe complète se forme très rapidement et les premiers développements apparaissent après la première ou deuxième itération (après un mois environ). Vous avez donc des retours client quasi immédiatement. Les choix de développement se font itération après itération, l’ensemble de l’équipe est impliqué et le client vous félicite (ou vous blâme) tous ensemble. Vous avez donc un retour instantané sur ce qui est « bien » et ce qui ne l’est pas, vous comprenez mieux le métier, plus rapidement. Le client a également une plus grande réactivité dans ses choix de développement, en choisissant d’annuler ou refaire un développement, si la première version qu’il a reçu n’apparait finalement pas convenir à ses besoins.

Si les principes de Scrum sont bien respectés, et si donc, l’équipe projet a suffisamment d’expérience dans ce domaine, les projets utilisant cette méthodologie sont plus à même de répondre aux besoins réels du métier.

Cependant il ne faut pas se leurrer. Cette méthodologie comporte des pièges que seules des personnes expérimentées sont à même d’éviter ou prévenir. Car la complexité projet ne disparait pas pour autant.

  • Premièrement le métier doit savoir de quoi il parle et doit se tenir à la disposition de l’équipe de développement tout au long du projet et pas uniquement sur le début comme dans un développement standard.
  • Deuxièmement, le chef de projet ou ScrumMaster, doit être conscient des limites de son équipe de développement et s’assure les conseils d’un senior en architecture/développement, histoire de ne pas revoir toute l’implémentation au moindre changement de conception.
  • Troisièmement, l’agilité ne concerne pas que la partie Scrum, mais toutes les phases de développement. eXtreme Programing pour un transfert de connaissance fluide, des tests et un serveur d’intégration continue, afin de pouvoir faire des modifications rapidement, facilement et sans crainte, un processus de déploiement simplifié, pour le répéter à chaque itération sans difficulté.

En suivant ces quelques principes, les projets suivant la méthodologie Scrum ont plus de chance d’aboutir et d’être à même de satisfaire le métier en fournissant des logiciels qui correspondent réellement à leurs attentes du moment (et pas à celles d’il y a 10 mois, déjà mises à l’oubli pour cause de crise, réorg ou perte de marché)

Le tableau suivant présente une comparaison des coûts de production des équipes de développement et la productivité du métier entre la méthodologie Scrum et les méthodes standards.

Comparaison des coûts de production et productivité entre Scrum et méthode standard

Comparaison des coûts de production et productivité entre Scrum et méthode standard

Dans le cas standard, on retrouve ce qui fait le principe d’un projet dit classique. Des coûts de production bas sur le début, lors des phases de spécifications, une intensification lors des développements et une baisse progressive sur la fin de projet lorsqu’il ne reste que la livraison, la correction des bugs et les formations utilisateurs. La productivité quant à elle ne débute qu’après la livraison et fournit son plein potentiel quelques mois après la livraison.

Pour Scrum, les coûts de production sont rapidement à leur maximum, puisque l’équipe intervient très rapidement sur le développement du produit. Ces coûts s’arrêtent d’ailleurs quasi immédiatement après la fin du projet, puisque l’application est livrée, les bugs sont déjà corrigés et les utilisateurs déjà formés. La productivité cependant débute juste quelques mois après les premiers développements. Cette productivité, timide sur le début, s’accélère rapidement puisque les fonctionnalités les plus importantes sont développées en priorité. Et la productivité est plus importante sur la fin, car elle correspond exactement à ce que demande le client au moment où il le demande (et non à ce que avait été défini dans les spécifications 10 mois avant, comme c’est le cas avec le méthode standard). Les gains de productivité sont d’ailleurs beaucoup moins important sur la fin de projet. C’est à ce moment que le client devra se demander s’il est légitime de poursuivre les développements, puisque ceux-ci n’apportent plus réellement de valeur ajoutée. On pourra alors stopper net le projet ou réorienter les développements vers d’autres objectifs.

Ce graphique montre tout le potentiel de Scrum.

Travailler plus, non, travailler mieux, oui !!!

Voila un refrain que l’on entend rarement.

Dans les métiers de l’informatique, qui sont en crise actuellement (sauf dans la petite bulle de Saskatoon, qui semble résister à tout), le refrain qui revient souvent c’est « travailler plus pour satisfaire nos clients », « soyez plus motivé, soyez plus investi ».

C’est une belle phrase mais qui sonne souvent comme un non-sens lorsqu’on la vit de l’intérieur.

Employés, employeurs, arrêtez de dire n’importe quoi.

Au premier, chers développeurs, je dirais :

« Affûtez votre outil » ou comme le disait Abraham Lincoln « If I had six hours to chop down a tree, I’d spend the first four hours sharpening the axe. » Littéralement « Si j’avais six heures pour couper un arbre, je passerais les 4 premières heures à affûter ma hache. »

Ce qui veut dire, Messieurs, Mesdames les développeurs, réfléchissez avant de faire afin d’être plus efficace. Restez au fait des technologies, prenez le temps d’étudier les outils qui peuvent vous rendre plus efficaces, expérimentez et appliquez, en un mot, Osez !!! Vous aurez besoin de moins de temps pour la même charge de travail.

Bien sûr certains vont me répondre, mais nous n’avons pas le temps de réfléchir ou d’étudier ou d’expérimenter. En clair,  « Je n’ai pas le temps d’affûter ma hache, il faut que je coupe cet arbre. » Ben voyons !

Lorsque vous créez votre environnement de travail, prenez le temps de le configurer afin d’être le plus efficace, même si cela doit vous prendre une heure, deux heures ou huit heures. Si grâce à cette configuration, vous êtes capable de gagner 10 ou 20 minutes par jour, vous verrez que l’investissement est très vite rentable.

Il en est de même pour vos développements. J’ai l’exemple d’un développeur qui s’est « amusé » à écrire son parser pour un format de fichier XML fait maison. Alors qu’il existe des outils qui vous permettent de générer le code afin de parser automatiquement votre fichier. Dans le deuxième cas, le code est optimisé, rapide à mettre en place ou à mettre à jour. Dans le premier cas, il faut le temps de l’écrire, de le tester, le remettre à jour manuellement. Mais voila, le développeur n’avait pas le temps d’étudier l’outil. Dommage.

Au second, chers employeurs, je dirais :

Arrêtez de rogner sur des coûts, qui certes font baisser vos dépenses, mais font baisser également votre production. Alors, oui, vous pouvez compenser en faisant travailler plus vos employés, mais si ceux-ci pouvaient l’être sans toujours avoir à travailler plus.

Pour cela, quelques règles simples et rapidement rentables :

  • Fournissez un second écran voire un troisième écran à vos employés : une étude de Microsoft montre que la productivité augmente de 9 à 50%. Coût de l’opération : 200€, pour un ingénieur avec un coût de 1000 euros par mois et une productivité accrue de 15%, l’investissement est rentable en seulement un mois et demi, et vous gagnez 15% de productivité sans travailler plus. Ce qui signifie sur une journée de huit heures, une bonne heure et demie de gagnée, (mon employeur actuel l’a bien compris, j’ai eu un second écran dès le premier jour et tout le monde en a un, même la secrétaire)
  • Fournissez un espace de travail suffisamment grand. Je vois des managers expliquer qu’ils ont réussi à faire rentrer un développeur dans moins d’un mètre carré et qu’ils peuvent ainsi économiser 5000 euros par an en frais de structure. Super, mais le développeur n’a pas les moyens de poser son clavier et un cahier sur son bureau. Perte de productivité, facilement 15%, si ce n’est 25%. Par rapport au coût sur la marge totale, ça fait une belle différence et pour le salarié également. Permettez au moins à vos collaborateurs de respirer et de poser plus de 2 feuilles sur leur bureau. Fournissez leur également de quoi ranger leurs affaires, un placard, des tiroirs et pas dans la pièce d’à côté, s’il vous plaît,
  • Fournissez les outils qui augmentent la productivité. Imprimante, téléphone, logiciels et matériels de qualité. Je me rappelle avoir vu une fois, une imprimante, type imprimante personnel basique pour 80 personnes, à un autre étage dans un autre local, fermé à clé. Tout de suite, vous découragez vos développeurs d’imprimer, belle économie de papier et d’encre. Mais belle perte de productivité également. J’en ai vu d’autres qui préféraient des outils Open Source gratuits plutôt que l’investissement dans un logiciel performant mais payant. J’ai un bel exemple avec MS Project. Je passais mes vendredis entiers à essayer de mettre à jour mon super logiciel gratuit afin d’avoir des dates de fin pour mon projet, alors que la même chose était possible avec MS Project en moins d’une heure. Coût du logiciel : 1000 euros, gain de productivité : +20%. Rentabilité garantie. Je suis fan de logiciels libres, mais il faut également savoir réfléchir.

Alors à toutes ces règles simples, vous me répondrez, oui, mais moi qui vends des hommes, ça me coûte. Un développeur qui travaille plus, ça ne me coûte pas plus cher, il est payé le même prix. Et en temps de crise, il le fait même sans qu’on lui demande.

Et je ne peux que répondre :

Super !!! Logique implacable.

%d blogueurs aiment cette page :