Frédéric LeguédoisEst-il possible de développer sans bug ? D’atteindre un jour le « zéro bug » ? Nous pouvons percevoir ce scénario comme une illusion, voire une douce utopie. Et pourtant.
Lors de cet épisode de Scrum Life, Jean-Pierre Lambert interrogerait à juste titre la différence entre un bug et une évolution. Si de prime abord, nous pensons que les deux notions diffèrent fortement, la question mérite d’être posée.
L’urgence ne différencie pas le bug de l’évolution
Nous pouvons penser qu’un bug sera toujours plus urgent à corriger que développer une évolution. Certains bugs n’ont toutefois qu’une conséquence marginale sur l’utilisation d’un logiciel alors que certaines évolutions peuvent être primordiales, à un instant T, dans la vie d’un produit. Ainsi, une police de caractère erronée, apparaissant sur une seule page d’un site internet et ne s’affichant qu’une seule fois sur mille, constitue un bon exemple de bug insignifiant. Par conséquent, le caractère d’urgence ne différencie pas le bug de l’évolution.
La complexité ne différencie pas non plus le bug de l’évolution
La complexité technique ne constitue pas non plus un critère pertinent pour différencier les bugs des évolutions. En effet, certains bugs sont très complexes à corriger et d’autres très faciles à corriger. Et il en va de même pour les évolutions.
Quelle est donc la différence entre un bug et une évolution ?
Le bug est une différence entre la spécification – ce qu’a demandé le client – et le logiciel développé. Alors qu’une évolution est une différence entre le besoin des utilisateurs et la spécification. Exprimé de la sorte, l’écart entre les deux concepts apparaît plus tangible. Et pourtant, sur le terrain, les spécifications, comme tous les écrits, sont interprétables. D’où des discussions sans fin afin de déterminer s’il s’agit d’un bug ou d’une évolution.
Et qui sont tellement proches
Un bug, c’est quelque chose qui ne fonctionne pas comme on voudrait dans un logiciel et que nous allons spécifier, développer, tester et livrer.
Une évolution, c’est quelque chose qui ne fonctionne pas comme on voudrait dans un logiciel et que nous allons spécifier, développer, tester et livrer.
Pour être tout à fait explicites, un bug et une évolution sont, d’un point de vue opérationnel, exactement de la même nature. Ce n’est que la représentation que nous en avons qui nous fait les différencier, les classer dans des catégories (voire des sous-catégories) distinctes ; générant là une complexité qui pourrait bien se révéler hautement toxique pour notre efficience.
Vers le zéro bug ?
Une manière simple de supprimer les bugs est de ne plus considérer les spécifications comme LA vérité, mais comme une source d’inspiration. Et c’est à partir de cette dernière, après quelques itérations, qu’émergera la fonctionnalité. Celle qui sera qualifiée et qui deviendra donc notre référentiel. Et comme il n’existe aucune différence entre la fonctionnalité qualifiée et la fonctionnalité utilisée par les utilisateurs, tout ce qui sera découvert après la qualification sera automatiquement une évolution.
Une certaine maturité
Pour atteindre un tel fonctionnement, il faut assurément jouir d’une certaine maturité ; tant technique (environnement de qualification, tests automatiques de non-régression, déploiement automatisé…) que culturelle (recherche de solutions plus que de coupables…).
Enfin, eu égard au fait que la plus grande génératrice de bugs est la deadline, développer sans délai prédéfini, sans estimation, constitue aussi une voie avérée pour atteindre le zéro bug. « Une nouvelle utopie ! » nous direz-vous ? Nous vous invitons à le découvrir par vous-mêmes grâce à notre conférence et à notre formation sur le sujet.
