Comment améliorer la compréhension des besoins logiciels permet-elle d'économiser temps et argent ?
Lorsqu'un logiciel ou une application est construite, les phases de tests ou les utilisateurs remontent souvent des bugs... Ce qui augmente les coûts de développement. Retour d'expérience d'une major des télécoms qui a mis en place le concept de "3 amigos" afin de sécuriser la définition du besoin et son déploiement.
Nombreux sont les exemples où l'élaboration d'un produit produit un produit inadéquat. Un peu comme cette tournure de phrase, ce qui est élaboré n'est pas totalement inutilisable mais son dessein n'est pas tout à fait celui attendu. Si les moines bénédictins l'ont vécu lorsque du gaz s'est invité lors de la vinification, créant par la même le champagne… d'autres n'ont pas eu cette même et heureuse fin.
C'est malheureusement souvent le cas lors de développement logiciel ou lors d'optimisation de processus.
Les analyses sont menées par des business analystes, puis confiées au développement, puis testées et mises en production. Cependant, lorsque le donneur d'ordre utilise la nouvelle fonction en production, il s'aperçoit qu'elle ne répond pas à son souhait initial.
Cela provient du fait qu'à chaque étape de la chaine d'élaboration, un peu d'information se perd ou est sujette à interprétation... Et au final, les parties prenantes ne s'en rendent compte qu'à la fin du processus. Mais c'est déjà trop tard. Le mal est déjà fait et le coût de correction va venir grever les finances de l'entreprise.
Si bon nombre d'industrie n'avaient que faire du cout de rework auparavant, les récentes crises ont forcé les mastodontes à réfléchir aux moyens de minimiser les couts.
Issues de l'industrie et de la conception logicielle, les méthodologies Lean et agiles nous suggèrent de lever tout doute dès l'élaboration de la spécification. Que l on appelle cela "3 Amigos", "small kaizen", know your process", "shift left", le but de ces méthodes est de mettre en commun tous les maillons de la chaine, le plus tôt possible.
Je vais prendre un busines case bien réel pour illustrer cela : un des majors de la télécommunication nous a demandé d'intervenir car trop de défauts étaient remontés par les utilisateurs sur un des logiciels cœurs et demandait de nombreuses upgrades, et donc des releases, et donc du test... multipliant les coûts.
En étudiant le processus de développement, nous avons pu mettre au jour que, sur un besoin métier, les compréhensions des divers acteurs étaient différentes. Afin d'éliminer toute interprétation nous avons repensé la manière de développer et de spécifier, en introduisant dès le début de la définition du besoin, la conception des tests. Ainsi dès la phase de conception, les testeurs présentaient les divers scenarii destinés à valider le développement. A partir de ce moment, plus aucun doute ne subsistait sur la manière donc la "feature" devait fonctionner. Lorsque le test suggéré passait à côté de quelque chose, une des parties prenante (développeur ou représentant métier) le signifiait immédiatement lors de la réunion et le testeur intégrait les remarques au test afin d'être le plus représentatif possible du besoin.
Comme toute nouvelle méthode, des collaborateurs n'ont pas caché leur scepticisme face aux théories facilement applicables par des externes. Cependant, après deux features traitées selon ce nouveau processus, ces mêmes sceptiques étaient devenus les portes paroles de la méthode, avec parmi les bénéfices cités :
- Concentrer les opinions des divers métiers en amont du développement permet de lever tout doute et d'assurer la cohésion du besoin,
- Planifier les tests dès le début du développement permet de valider les compréhensions de tous les acteurs et de les aligner sur les besoins métier,
- Si les tests sont définis avec accord du métier et de l'IT et ceci dans le langage métier, ils peuvent être exécutés par n'importe qu'elle autre personne que le testeur lui-même. Ainsi, les UAT peuvent se reposer sur ces éléments et en diminuer la lourdeur sans en restreindre la valeur probante.
Afin de maximiser et partager les bénéfices de cette méthode, le challenge devient maintenant de ne pas alourdir le processus de conception par des meetings récurrents d'explication et de définition. En plus d'une réflexion stratégique sur la politique de développement, il est capital que le testeur soit extrêmement proactif dans l'élaboration du test et impliqué dans la compréhension du besoin. Et dans certains secteurs (banque, chimie, négoce...) avoir un testeur qui soit un expert métier est un atout indéniable.