Peut-on vraiment montrer et livrer quelque chose au client à une telle fréquence ?

1) La réponse de l’expert Freddy Mallet, consultant spécialisé sur les méthodologies agiles.

Il n’existe pas de fréquence idéale mais disons que dans la pratique cette fréquence est

souvent égale ou inférieure à 1 mois. Avant de se poser la question de la faisabilité, posons-nous

la question du pourquoi montrer et livrer quelque chose au client à une telle fréquence ?

À vrai dire, comment faire autrement pour mesurer objectivement l’avancement d’un projet

de développement ?

La question peut paraître simpliste mais si, sur un projet de développement informatique, vous

avez 500 fonctionnalités (use cases, user stories, etc.) à implémenter et qu’au bout de 2 mois,

vous en avez toujours 500 à implémenter, comment faites-vous à la fin de ces deux mois pour

ré-évaluer objectivement votre charge et votre planning ? On peut toujours se rassurer en se

disant qu’on a fait un énorme travail d’architecture, de documentation et de formation mais la

vérité c’est qu’au bout de ces deux mois, on n’en sait pas plus sur notre capacité à délivrer les

fonctionnalités requises.

À l’inverse, si vous vous efforcez de délivrer des fonctionnalités à chaque fin d’itération, vous

allez très rapidement pouvoir évaluer objectivement votre niveau de productivité et affiner itération

après itération la charge et la date de fin sans grande possibilité de vous mentir à vous-même.

C’est également un bon moyen pour l’équipe de développement de rester focalisée sur son

objectif principal : délivrer des fonctionnalités ayant une valeur pour le client. Là encore, la

remarque peut paraître presque simpliste mais prenez un développeur au hasard dans votre

entreprise et posez-lui la question : « Quel est ton objectif principal ? » Les réponses serontelles

toutes orientées client ?

Enfin, c’est offrir au client la possibilité de confronter la représentation abstraite qu’il s’était faite

du produit avec la réalité. C’est mettre en oeuvre un principe de rétroaction sans lequel il ne

peut y avoir d’agilité business possible. Il existe une chimère assez répandue au sein des

services de développement informatique qui consiste à considérer que le client doit pouvoir

parfaitement exprimer et spécifier au pixel près son besoin pour les 8 à 12 mois à venir, et ce

de manière totalement abstraite. L’exercice est comparable en difficulté à imaginer et spécifier

dans un document Word toute la décoration d’une maison virtuelle sans assistance informatique.

Cette chimère donne lieu à des batailles ou à des tensions régulières entre maîtr ise

d’ouvrage et maîtrise d’oeuvre. Je joue moi-même le rôle du client dans le cadre du développement

d’un outil de contrôle de qualité logicielle (Sonar). Autant je sais exactement où je veux

aller, autant il m’est très difficile de spécifier mon besoin. Chaque période de test offerte à la fin

d’une itération me permet d’ajuster ma vision du produit. C’est aussi cela l’agilité.

Une fois la question du pourquoi levée, les problématiques réelles de mise en oeuvre qui

peuvent se poser portent essentiellement sur le niveau d’implication du client. Cependant, si

on arrive à expliciter auprès de ce même client les bénéfices qu’il peut retirer de cette démarche

itérative et incrémentale, il y a de grandes chances qu’il soit prêt à jouer le jeu.

2) La réponse de l’expert David Gageot, directeur technique chez Tech4Quant.

J’aime renverser cette question : comment penser que l’on peut être capable de livrer en une seule

fois une application ? Développer seulement quelques fonctionnalités à la fois permet un engagement

concret des utilisateurs. Le fait de leur montrer régulièrement l’application en cours de

croissance facilite leur feedback et leur permet de mieux creuser leurs propres besoins.