Gestion de projet agile

Mettez en place des habitudes plutôt que des processus : l’amélioration continue pilotée par les KPI

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, qu’est ce ?

“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 :

  • Les KPI d’état qui affichent les informations à un instant donné.
  • Les KPI de tendance qui affichent la progression dans le temps d’une métrique afin de montrer l’évolution.

L’amélioration continue pilotée par les 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 :

  • la quantité de code dupliquée dans l’application
  • le pourcentage de code qui est testé
  • la complexité du code source.

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.

Les facteurs de réussite d’une approche pilotée par les KPI

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.

Comment définir une bonne KPI ?

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 :

  • elle est concrète, c’est à dire qu’elle mesure quelque chose d’effectif
  • elle est facilement compréhensible, elle doit être intuitive à comprendre.
  • elle est accessibles, ce qui implique qu’elle ne doit pas difficile à calculer.

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.

Conclusion

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.

Architecture logicielle

How to organize a business layer ?

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.

Architecture logicielle

L’entropie logicielle, pourquoi la dette technique ne fait qu’augmenter ?

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)

Entropie logicielle et dette technique

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 :

  • Le coût lié à la perte de productivité des développeurs face à un code source incohérent, inutilement complexe ou de mauvaise qualité : perte de temps pour comprendre le fonctionnement du programme et rechercher de l’information.
  • Le coût lié à la correction de bugs : perte de temps pour corriger des dysfonctionnements (si cela touche un utilisateur final, il y a en plus une perte d’image pour le logiciel).
  • Le coût de modification du code source : le logicielle devient de plus en plus difficile à modifier sans effet de bord (défaillances en cascades sur d’autre partie du 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

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.

Conclusion

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.

Git

Ce que j’aurais aimé savoir quand j’ai commencé GIT

Vous n’êtes pas très à l’aise avec cet outil et l’on vous demande de l’utiliser sur un projet ? Pas d’inquiétude, je vous ai préparé un article récapitulatif sur tout ce que j’aurais aimé savoir quand j’ai commencé à utiliser git.

Et si vous connaissez déjà très bien git, lisez quand même, peut être y apprendrez vous des choses. Surtout n’hésitez pas à donner le lien à vos développeurs qui arrivent dans l’univers de git, vous leurs ferez gagner de précieuses heures de recherche.

Git, les premiers pas

Si vous ne vous sentez vraiment pas à l’aise avec git, je vous conseille cette première prise de contact en démarrant avec try git, excellent tutoriel interactif d’environ 15 minutes.

Pour approfondir et consolider les acquis allez lire le tutoriel sur le site d’Atlassian, profitez-en pour découvrir les différents workflow inhérent à l’usage de l’outil.

Si vous avez encore des doutes vous pouvez suivre le tutoriel git immersion, qui devrait faire taire vos dernières craintes.

Si vous allez être amené à travailler sur la plate forme github, vous pouvez lire ce guide de démarrage très bien pensé : Hello World, your first github project.

Imprimez-vous un rappel des principales commandes de git : Git Cheat Sheet, si vous avez besoin de visualiser graphiquement le workflow de travail sous git utilisez cette cheat sheet intéractive pour git.

Git un peu plus loin

Notez l’adresse d’une excellente (et exhaustive) documentation de git : git-scm, et notamment le chapitre Getting started.

Préparez votre ligne de commande à avoir un prompt git qui déchire et ayez une configuration aux petits oignons.

Tapez git config --global help.autocorrect 1 dans votre terminal pour vous corriger automatiquement les commandes git que vous auriez mal tapée (le matin, au réveil, tout le monde à du mal).

Commencez à utiliser un workflow git, git branching model est l’un des plus connus. Vous pouvez aussi regarder le workflow github.

Apprenez à garder un historique propre et faites la différence entre un merge et un rebase.

Vous démarrer un projet, récupérez un gitignore configuré pour votre framework.

Si vous travaillez avec github, apprenez toutes les astuces et fonctions cachées de la plateforme.

Si après toutes ces lectures vous n’êtes toujours pas sûr de vous, Christophe Porteneuve propose d’excellente formation git.

Ce que vous voulez savoir mais vous ne le savez pas encore

Voici une liste de commandes que j’aurais aimé connaître quand j’ai commencé à utiliser git :

  • Vous avez fait une erreur sur votre dernier commit (mauvais message ou oublie de fichier) : git --amend vous permet de merger le dernier commit avec votre stagging courant et de modifier le message du commit.
  • Vous souhaitez ajouter l’ensemble des modifications et des nouveaux fichiers au stagging : git add --all
  • Vous avez ajouté un fichier dans le stagging mais en fait vous ne le vouliez pas (vous avez encore fait un gros git add –all) : get reset HEAD (ou pour juste un/des fichier(s) : git reset HEAD filenames)
  • Vous souhaitez annuler les modifications que vous avez fait sur un fichier : git checkout filename
  • Vous voulez revenir à la branche où vous étiez précédemment : git checkout -
  • Vous souhaitez connaitre quelles sont les branches déjà fusionnées avec votre branche courante : git branch --merged (et le contraire --no-merged).
  • Vous voulez lister les différences entre votre dépôt local et un dépôt distant : git fetch puis git diff master origin/master (pour la branche master sur le remote origin).
  • Vous voulez avoir un git status un peu plus joli : git status -sb
  • Vous souhaitez donner un nom à votre stash : git stash save "message"
  • Vous souhaitez nettoyer un fichier : git stripspace < README.md va supprimer tout les espaces inutiles.
  • Vous souhaitez naviguer dans le dépôt et son historique git instaweb vous lance une interface web.
  • Vous souhaitez vous connecter à plus d'un serveur distant : git remote add upstream https://url.torepo.com/reponame.git ajoute le dépot reponame en tant que serveur remote (nommé dans notre cas upstream), il devient possible de faire des git pull upstream ou git push upstream.

Si vous pensez que j’ai oublié une commande git intéressante, n’hésitez pas à l’indiquer en commentaire !