Votre département logiciel est-il efficace ?

Par Eric Pinet | 15 May, 2018

Votre département logiciel est-il efficace ?

Lorsque les administrateurs tentent de mesurer l’efficacité d’un département de conception logiciel, l’exercice peut donner des résultats assez surprenants. C’est alors que l’on voit arriver les métriques qui font sourire les concepteurs expérimentés tels que : la quantité de bogues résolue ou la quantité de lignes de code produites. 🤦

À ce moment, nous sommes en droit de nous poser la question suivante : mais qu’est-ce que l’on cherche vraiment à optimiser en suivant ces métriques ? 🤔

Selon moi, l’élément le plus important en conception logicielle est de minimiser le temps nécessaire afin de mettre en marché une nouvelle fonctionnalité ou une correction. Ce que l’on appelle le « Time to market ». Comment réduire au maximum ce délai ? Voilà ce qu’il faut réussir à faire.

Pour y arriver, que devons-nous suivre comme métriques ? Je vous donne un petit indice : certainement pas la quantité de lignes de code produites. Selon moi, voici ce sur quoi les équipes devraient être mesuré :

Stabilité de la branche « master »

Suivre la stabilité de la branche « master » permet de vérifier la capacité de l’entreprise à déployer lorsque c’est nécessaire. Si la branche principale est instable, démarrer de nouvelles fonctionnalités ou tenter de corriger un bogue est impossible. Il est également impossible de déployer de nouvelles versions. Les concepteurs ne peuvent pas intégrer leur nouveau développement dans la branche principale. Autrement dit, votre organisation en paralysée.

Il est donc facile de comprendre pourquoi une entreprise désire suivre cette métrique. C’est une manière de s’assure que l’entreprise reste réactive et prête à livrer rapidement en cas de besoin que se soit pour produire une correction ou s’adapter à une nouvelle réglementation.

Mesure: Pourcentage de temps ou la branche “master” est stable dans les derniers 7 jours

Exemple d’objectif: Une stabilité supérieur à 98%

Quelques méthodes pour s’améliorer

Les entreprises qui réussissent le mieux au niveau de la stabilité sont celles qui possèdent une bonne base de tests automatisés offrant une excellente couverture du code.

Plusieurs organisations vont utiliser le « Feature Flag » pour activer ou désactiver des fonctionnalités qui ne sont pas encore complétées ou stabilisées. Visiter le site: https://featureflags.io/ pour plus de détails et d’outils sur le « Feature Flag ». Certaines entreprises vont même permettre d’activer ou désactiver les fonctionnalités par client ou région de manière à rendre les nouvelles fonctionnalités disponibles graduellement pour éviter de déstabiliser l’ensemble des clients.

Temps de déploiement

Après avoir fait le code, les revues de codes et les tests, l’application ou le module à prêt à être déployé en préproduction ou en production. Le temps nécessaire pour ce déploiement est important pour limiter les attentes inutiles. L’objectif est de rendre l’application le plus rapidement possible disponible aux clients pour obtenir le meilleur retour sur investissement.

Un des clients de votre application est votre propre « Product Owner » qui désire obtenir rapidement des prototypes pour valider des idées ou opportunités. Le temps de déploiement peut également devenir critique lorsqu’il devient nécessaire de sortir une correction rapidement pour corriger un bogue majeur.

Mesure: Temps nécessaire en minutes pour déployer l’application après avoir demandé une compilation

Exemple d’objectif: Inférieur à 5 minutes

Quelques méthodes pour s’améliorer

Pour obtenir de bons résultats pour votre temps de déploiement vous vous devez d’automatiser le processus. L’arrivée des outils permettant « l’Infrastructure as code » tels que Terraform offre la possibilité de déployer simplement et de manière automatisée dans le cloud. De plus, la plupart de ces outils permettent également de faire des « Rolling Update » pour éviter les « Downtime ».

Si votre application n’est pas distribuée dans le cloud, l’utilisation des technologies de conteneurs tels que Docker permettent de grandement simplifier vos déploiements.

Lorsque votre application contient peu de bogues, que votre méthode de recouvrement est efficace, que vous avez un bon système de surveillance et une utilisation efficace des « Feature Flag » vos clients peuvent remplacer votre équipe d’assurance qualité peu à peu. Vous n’aurez plus peur de déployer votre application immédiatement à vos clients.

Fréquence de déploiement

La fréquence de déploiement de votre application démontre la rapidité de votre organisation à produire de la valeur. C’est cette fréquence que vos clients perçoivent et jugent. C’est par là que vous pourrez démontrer votre agilité.

Lorsque vous aurez optimisé les deux autres métriques soit la stabilité ainsi que votre temps de déploiement votre équipe sera encouragée à faire des déploiements fréquents, car ils seront simples et rapides. En d’autres termes, votre équipe sera encouragée à livrer de la valeur rapidement !

Mesure: Nombre de déploiements réalisées dans une semaine

Exemple d’objectif: 32 par semaine

Quelques méthodes pour s’améliorer

Pour être en mesure de livrer fréquemment il faut évidemment avoir automatisé au maximum son processus. Mais ce n’est pas tout, il faut également penser à découper le travail en petites tâches simples. Il faut minimiser le temps ou les « Pull Request » restent ouvertes. Idéalement, il faut tenter de fermer une « Pull Request » en 24 heures.

L’utilisation des « Feature Flag » vient également permettre de livrer rapidement en s’assurant de ne pas rendre disponible des fonctionnalités incomplètes ou instables à l’ensemble des clients.

comments powered by Disqus