Cela fait quelque temps que je n’ai plus posté sur ce blog. J’étais alors sur la plateforme medium où vous pouvez retrouver certain de mes articles.
J’ai choisi de recommencer à poster des articles sur une plateforme dont j’ai la maitrise. Vous pouvez découvrir dès à présent mon nouveau blog à l’adresse lilobase.me.
Au plaisir de vous retrouver sur ce nouveau blog !
Vous venez d’améliorer ou définir un nouveau processus, vos équipes commencent à l’appliquer, l’énergie du début est là et tout le monde est motivé. Malheureusement deux semaines plus tard, le processus n’est plus que partiellement mis en œuvre. Un mois plus tard le voilà abandonné, retour à la case départ. Si cette situation, ô combien décourageante, vous semble familière, alors cet article va vous intéresser.
Très souvent la mise en place de processus est vécue comme une contrainte par les équipes. Il faut alors déployer beaucoup d’énergie pour un résultat qui s’avère souvent décevant. Pour résoudre cette problématique je vous propose de découvrir : L’amélioration continue pilotée par les KPI.
“KPI” est un acronyme signifiant “Key Performance Indicator” (indicateur clé de performance). Il s’agit d’une ou plusieurs métriques, agrégées et présentées graphiquement. Assemblée, elles permettent de construire des tableaux de bord d’aide à la décision. Par exemple un système e-commerce pourra avoir un graphique montrant l’évolution des ventes comme KPI.
Une KPI peut revêtir différente forme : loin d’être un simple nombre ou graphique, il peut s’agir de code couleur, de flèches de smiley. En bref, n’importe quel élément qui permet d’améliorer la compréhension de la métrique.
Nous pouvons distinguer deux type de KPI :
Il s’agit d’un changement de paradigme concernant la conduite du changement : au lieu de définir un processus, il s’agit de définir une vision pour construire les métriques associées ; et laisser les personnes définir elles mêmes le processus.
Ainsi l’effet contraignant lié à la notion de processus est supprimé, les personnes concernées deviennent actrices du changement garantissant un bien meilleur taux d’adoption.
Le processus devient émergent et auto-organisé. Il est guidé par les points de mesure mis en place. Cela a un côté stimulant pour les équipes qui vont chercher comment améliorer les métriques permettant de créer des habitudes plutôt que des processus. Les habitudes étant par définition quelque chose de bien plus puissant que n’importe quel processus. De plus elles participent à la création d’une culture d’entreprise.
Prenons un exemple, imaginons que vous souhaitez améliorer la qualité de la production logicielle dans vos équipes. Vous avez votre objectif (ou vision), vous pouvez alors définir quelques KPI qui mesurent l’aspect qualitatif d’un logiciel, par exemple :
Ces trois valeurs combinées pourront vous donner une métrique permettant de montrer la tendance concernant la qualité du code source produit. Et, avantage supplémentaires, elles peuvent être calculée automatiquement par un serveur d’intégration continue.
Vous devez être extrêmement transparent sur les KPI, à la fois sur leurs existences (ne créez pas de KPI “cachée”) ainsi que sur leurs mode de calcul. Enfin, permettez à l’ensemble des équipes d’y avoir accès en temps réel (si possible par un affichage public). Le fait de les présenter à l’ensemble de l’entreprise en temps réel via un affichage adéquat est un véritable moteur en terme de motivation car cela montre l’évolution et donne de la visibilité (et donc de l’importance) aux choses à améliorer.
Attention, les KPI ne doivent pas devenir une source de tension pour vos équipes, faites très attention à ce que cela reste une source d’émulation et non de pression. La façon de les présenter et l’usage que en sera fait sont des facteurs qui influencerons cette perception des KPI. Si les KPI sont mal perçues le risque est de les voir contournées. Par exemple si une KPI mesure le nombre de bug résolus il peut être tentant d’introduire volontairement des bugs dans un programme pour les corriger ensuite afin d’améliorer la métrique.
Évitez de lier les KPI à des objectifs chiffrés, préférez systématiquement l’affichage de tendance. Veillez à définir la direction plutôt que de définir des objectifs irréalistes.
Les KPI sont un facteur très important de feedback pour les équipes, vous devez régulièrement vous interroger avec elles sur les tendances qu’elles affichent. Si une KPI montre des signaux inquiétants, discutez avec l’équipe pour comprendre ce qui se passe et comment améliorer les choses. C’est un excellent outil pour identifier très rapidement des problématiques très concrètes. Les KPI vous permettent aussi de savoir quand féliciter une équipe. Cela s’avère être un très bon outil de management au quotidien.
Le choix des KPI crucial dans cette pratique. Les KPI sont en effet un support de la vision que vous souhaitez développer dans votre organisation. Pensez aux KPI comme des éléments de vigilances. Ne cherchez pas le comment, mais ce que vous souhaitez améliorer pour trouver les points de mesures correspondants.
Une KPI de bonne qualité rassemble trois qualités primordiales :
Pour résumer, les KPI doivent être simples et pragmatiques, sinon vous courrez le risque qu’elles ne soient pas mesurées et donc inutiles.
Vous devez restreindre au maximum le nombre de KPI mesurées à un instant donné. Un chiffre compris entre 10 et 15 KPI simultanées parait être un bon compromis. Avant d’introduire une nouvelle mesure essayer systématiquement d’en supprimer une existante. En effet, quand les habitudes amenées par une KPI sont totalement intégrées par les équipes, actualisez vos points de mesures au vue des problématiques actuelles. Avoir trop de KPI sature les tableaux de bords en noyant les signaux importants au milieu d’informations d’importances moindre.
Bien entendu il vous est possible d’avoir un tableaux de bord par département de votre organisation : les développeurs et le service marketing ayant chacun leurs KPI respectives. Cependant faites attention à ce que ces KPI soient alignées avec la vision de l’entreprise (et donc les objectifs).
Pour les KPI difficile à mesurer comme la qualité de communication au sein d’une équipe, vous pouvez utiliser des systèmes de sondages anonymes envoyés à intervalle régulier. Via ces sondages vous pouvez demander à vos équipes de donner une note sur un certain nombre de points (par exemple la qualité de la communication interne sur un événement particulier), les moyennes seront publiées publiquement comme KPI. Ces sondages doivent rester très rapides à remplir et être impérativement anonymes pour éviter les biais.
C’est une façon de modifier la façon dont le changement est perçu en définissant une vision et une direction plutôt qu’un processus.
L’amélioration continue dirigée par les KPI est un outil très puissant pouvant obtenir d’excellents résultats, à la condition de bien choisir des indicateurs pertinents, simples et en nombre limités.
One of the main questions I had when I started my career was « where I can put the business source code ?« .
In the famous MVC pattern, there is no mention about the business layer. Moreover, most of the framework does not speak about the business layer.
This presentation, created for a lightning talk in the software craftsman Meetup of Raleigh in july 2014. Aimed to give a simple and quick answer to this question.
The challenge of managing change
La deuxième loi de la thermodynamique, dans ses principes, énonce que la désorganisation d’un système fermé ne peut pas être diminuée, mais seulement rester inchangée ou augmenter. Une mesure de cette désorganisation est l’entropie. Cette loi semble aussi s’appliquer aux systèmes logiciels; quand un système est modifié, sa désorganisation, ou entropie, augmente systématiquement. Cela est connu sous le terme d’entropie logicielle.
Ivar Jacobson (traduit depuis l’anglais)
L’entropie logicielle est un principe intimement lié à la notion de dette technique. Commençons par définir celle-ci, il s’agit de l’ensemble des coûts cachés qui grèvent la rentabilité d’un logiciel :
Ces effets sont cumulatifs : l’ajout d’une fonctionnalité provoque un effet de bord, menant à une défaillance difficile à retrouver à cause de l’incohérence du programme…
Par ignorance, la dette technique est malheureusement rarement prise en compte.Mais aussi par le fait qu’évaluer la perte liée à la dette technique est un exercice complexe : les coûts sont liés à une perte de productivité et donc très difficiles à évaluer. Enfin corriger et prévenir la dette technique (améliorer le code source) est souvent considéré comme un investissement inutile car n’apportant aucune fonctionnalité supplémentaire, tout en pouvant ralentir le projet en consommant du temps de développement.
Pourtant, imaginons que vos développeurs passent 2 heures par semaine à chercher “comment faire” et à corriger des défaillances sur des logiciels existants. Multiplions ces heures par le nombre de semaines travaillées dans l’année (~44) nous obtenons 88 heures, soit 2,5 semaines de développements (journée de 7 heures). Pour une petite équipe de cinq personnes, la perte est de 3 mois hommes ! Avec l’hypothèse d’un coûts salarial de 4000€ mensuel, la perte se chiffre à 12 000€ par an ! Alors que nous avons une toute petite équipe et en sachant que le chiffre de deux heures par semaine est déjà très optimiste. Dans la majorité des cas vous pouvez le multiplier par 3 ou 4 (et appliquer le même multiplicateur sur vos pertes).
De l’autre coté le principe de l’entropie logicielle énonce que naturellement votre dette technique ne fait qu’augmenter avec la durée de vie de votre produit : l’ajout de fonctionnalités augmente la taille du code source et donc sa complexité. C’est pourquoi, sans contre-mesure concernant l’entropie logicielle, votre produit verra ses coûts de production et de maintenance augmenter mécaniquement jusqu’à atteindre un seuil où la rentabilité du logiciel sera remise en cause.
Si en France la terminologie consacrée parle “d’érosion de l’architecture logicielle”, la terminologie anglaise est plus parlante en utilisant le terme de “software rot” soit “niveau de pourriture” du logiciel.
L’entropie n’est cependant pas une fatalité grâce à un ensemble de bonnes pratiques d’ingénierie logicielle. Dans la suite de cette article nous allons nous intéresser à ces facteurs qui accélèrent ou au contraire ralentissent l’entropie d’un logiciel et donc sa tendance à générer de la dette technique. Enfin Les architectes, en tant que garant de la maintenabilité du logiciel sont très sensibles à cette notion (si ce n’est pas le cas, changez d’architecte), malheureusement trop souvent laissée de côté par les instances managériales.
Lutter contre l’entropie revient à lutter contre la nature même de l’évolution d’un projet logiciel, c’est pourquoi vous devez mobiliser vos développeurs pour les aider à combattre cette évolution.
La première mesure est psychologique, tout le monde a pû remarquer que si certaines habitations sont bien tenues, propres et rangées d’autres sont au contraire en désordre sale et où l’on n’y retrouve rien. Dans le logiciel c’est la même chose, vous pouvez avoir des développements propres et bien entretenus et à l’inverse des code sources complètement dégradés. Ainsi votre première ligne de défense contre l’entropie est vos développeurs : ils doivent y êtres sensibilisés et prendre soin de leurs développements.
Dans ce cadre, intéressant de parler de la théorie criminalistique de la vitre cassée (notamment mise en oeuvre à New York avec de très bon résultats), l’exemple donné est le suivant :
Imaginez un immeuble avec quelques fenêtres brisées. Si les fenêtres ne sont pas réparées, des vandales vont avoir tendance à briser les autres vitres. Et même pénétrer dans l’immeuble pour en faire un squat.
En effet, pensant que le bâtiment n’est plus occupé ni entretenu des vandales vont se sentir le droit d’en augmenter la dégradation. C’est un principe universel et je pense que toute personne a déjà fait l’expérience que le désordre amène toujours plus de désordre.
Le parallèle avec le milieu du développement n’est pas anodin. Un développeur travaillant sur un code source de mauvaise qualité se laissera aller sans faire d’effort pour améliorer la situation. Au contraire d’un développeur travaillant sur un code source d’excellente qualité : plus précautionneux, augmentera de lui même le niveau de son développement. Vous devez donc surveiller l’apparition de code de mauvaise qualité (vos “vitres cassées”) et le réparer au plus vite avant que la situation ne se dégrade. Il est à noter que travailler perpétuellement sur des codes de mauvaises qualités va gréver la motivation de vos développeurs diminuant d’autant leur productivité.
Pour aider à la détection de ces “vitres cassées” et transmettre cet état d’esprit au sein d’une équipe, les revues de code en groupe se placent comme des outils de choix. Il suffit d’être plus de deux personnes, de prendre un morceau de code source (si possible de l’un des participants) et le commenter collectivement pour proposer des améliorations (une revue de code doit aussi montrer des exemples d’implémentations de bonnes pratiques dans le code source). Attention, ces séance ne doivent pas être à charge pour le développeur dont le code est audité, les critiques doivent être constructives. La préparation de ces événements peut être réalisée par un architecte logiciel dans un but pédagogique, ou auto-organisées entre développeurs. Bénéficier du regard d’autrui sur un code source est l’une des meilleure façon de progresser.
De façon plus opérationnelle, la méthode de lutte contre l’entropie logicielle passe par du “refactoring”. C’est à dire améliorer constamment le code source en factorisant les processus similaires : la duplication de code étant l’un des facteurs accélérant le plus l’entropie logicielle. Afin de ne pas introduire de régressions fonctionnelles pendant cette étape, les tests unitaires sont indispensables. Si votre logiciel n’est pas testé, vous pouvez démarrer au fur et à mesure des travaux de refactoring en testant progressivement le code source. L’absence de test ne devant pas être une excuse pour ne pas exécuter ce type de travaux.
Supprimez aussi tout code inutile, un morceau de code source ne servant plus à rien doit être supprimé, le logiciel de gestion de version des sources gardant l’historique du code vous pourrez le récupérer à posteriori si nécessaire.
Enfin un dernier conseil pratique : dès qu’un bug est identifié, écrivez d’abord le test unitaire le provoquant puis corrigez le bug. De cette façon vous êtes certain qu’il ne se reproduira plus. C’est un bon moyen de démarrer une campagne de tests pour une application existante. Dîtes vous que non seulement vous remplacez la vitre, mais en plus vous installez un détecteur de bris de glace.
En terme d’architecture logicielle, la simplicité est votre meilleure alliée, un système simple est moins sujet à l’entropie et donc plus facilement maintenable. En découpant un logiciel en une série de composants indépendant vous transformez une application monolithique en un agrégat de modules simples travaillant de concert. Ces approches sont connues sous le terme d’Architecture Orientée Service.
L’entropie logicielle et la dette technique sont des sujets trop souvent ignorés et souvent mal acceptés : leurs réductions nécessitent une réflexion sur le long terme, qui n’est pas toujours en adéquation avec les besoins de mise sur le marché. Cette vision au long terme est cependant indispensable si votre business modèle repose sur le bon fonctionnement et la capacité d’évolution de systèmes logiciels.
Au niveau des outils, les serveurs d’intégrations continus pourront vous apporter une aide précieuse : en exécutant des tests par une analyse du code source, ces serveurs analysent la qualité du développement en temps réel, fournissant des retours de grande valeur aux développeurs pour savoir s’ils vont dans la bonne direction.
Enfin la mise en place d’une pratique rigoureuse de méthodes agiles d’architecture logicielle comme l’ “Emergent Design”, permet de construire des applications plus résistantes à l’entropie logicielle. Pour plus d’informations sur ce sujet, vous pouvez lire la série d’articles sur les architectures agiles.
Illustration issue de wikipedia
Si vous avez ce type de problématique, ma société : Ibsciss vous apporte un large panel de prestations sur ces sujets.
Arnaud LEMAIRE 