[agile conference] – Problem Driven Development

A l’Agile Conférence, Régis Medina a animé une session sur le thème du Problem Driven Development et la satisfaction complète du client. Surfant sur la vague du TDD, BDD et autres Driven Development, le terme Problem Driven Development (inventé par Régis) désigne une nouvelle approche du développement logiciel qui tourne autour du problème client à résoudre et non plus des fonctionnalités à produire.

Les méthodes agiles ont certes le mérite de placer le client au centre du projet avec une équipe prête à s’adapter à ses besoins. Cependant cette flexibilité peut amener les équipes à tourner en rond ou alors à ajouter des fonctionnalités jusqu’à obtenir une application difficile d’emploi pour les utilisateurs finaux.

Comment s’y prendre alors pour obtenir un logiciel avec une vraie valeur client ? Comment arbitrer efficacement le choix des fonctionnalités ? Comment organiser l’interface utilisateur pour qu’elle reste facile d’accès et d’emploi au fil des itérations ?

Régis Medina au travers de sa démarche de résolutions de problèmes du Lean montre comment répondre à ces questions.

Satisfaction du client ?

La satisfaction complète du client n’est pas une chose aisée à obtenir. Les méthodes de projet « classiques » ont pour principal défaut d’obtenir une application en décalage avec les besoins de l’utilisateur, car ceux ont évolué depuis la phase de spécifications. Concernant les méthodes agiles, certes ce décalage est fortement réduit, mais au final, même si le client obtient scrupuleusement toutes les fonctionnalités qu’il veut, cela ne signifie pas pour autant qu’il en soit complètement satisfait.

Les méthodes agiles ne sont pas suffisantes. En effet, dans de nombreux cas, si on écoute et qu’on ajoute rapidement des fonctionnalités désirées par le client au fil des itérations, on obtient rapidement une usine à gaz difficile d’emploi pour l’utilisateur final.

Le problème est la formulation des besoins, le manque de recul et la manque de connaissances sur les possibilités informatiques. Mais direz-vous, cela n’arriverait pas avec un bon Product Owner ? Cependant, lorsque le domaine est peu cadré et de nature exploratoire, une approche par la résolution des problèmes empruntée à Lean, baptisée Problem Driven Development est plus adaptée.

2 principes du Lean

Le PDCA : Plan Do Check Act

C’est un cycle perpétuel d’actions d’amélioration continue : Planifier, Réaliser, Vérifier et Corriger.

+ le Gemba.

Littéralement ce terme désigne le terrain, là où la valeur est ajoutée. Le principe qui en découle, le « genshi genbutsu » consiste à aller à la source et sur le terrain pour « capter » la réalité du terrain.

Application de ces 2 principes

Partant de ces deux principes, le Problem Driven Development consiste non plus à répondre aux besoins du client par le développement de fonctionnalités mais à s’attaquer aux problèmes du client et à les résoudre par le cycle suivant.

Voir le client, l’utilisateur final

La voix du client se résume en ces 5 points :

  1. Donnez-moi exactement ce que je veux
  2. Quand je veux
  3. Où je veux
  4. Soyez fiables
  5. Ne me faîtes pas perdre mon temps (performances, prise en main du logiciel…)

Le premier point désigne la valeur client. Mais les 4 autres points, souvent négligés, sont les gaspillages contre lesquels il va falloir lutter afin de satisfaire pleinement le client. Si le client n’a pas l’application disponible quand il veut, où il veut ou qu’elle n’est pas fiable il ne pourra être satisfait. Afin de satisfaire le dernier point, il faudra chercher à réduire le Lead Time d’utilisation, le temps nécessaire d’utilisation de bout en bout de l’action utilisateur.

Régis donna en exemple le cas de Google, qui cherche à minimiser le temps sur lequel l’utilisateur reste sur le moteur de recherche pour aller au plus vite sur la page résultat qu’il voulait. Google va même plus loin dans la réduction du Lead Time en corrigeant par exemple les fautes de frappe de l’utilisateur et en suggérant une nouvelle recherche, le tout dans le but de faire perdre le moins de temps possible à l’utilisateur.

Voir les performances

Afin de voir les performances, il faut absolument déterminer des indicateurs. Cela peut être des indicateurs de volume, de qualité, de lead time. Le tout est de pouvoir comparer la valeur actuelle avec une valeur cible, ce qui donnera les problèmes à résoudre.

Voir les problèmes

Cette étape consiste non seulement à déterminer les problèmes vus précédemment par comparaison des mesures des indicateurs avec les valeurs cibles mais surtout à appliquer le « genshi genbutsu », à aller voir sur le terrain l’utilisateur final utiliser l’application et découvrir ses problèmes. Cette pratique est souvent source de surprises.

Régis donna un exemple personnel d’une interface avec une liste d’éléments, où l’utilisateur ne savait pas comment ajouter un élément à la liste, malgré la présence du texte juste en dessous du cadre de la liste.

L’équipe est souvent victime de ce qu’on appelle la malédiction de la connaissance, c’est-à-dire qu’elle connait trop bien son application pour détecter ce genre de problème. A cela s’ajoute à l’opposé, la malédiction de l’ignorance, le fait de ne pas connaître suffisamment le métier du client. C’est contre ces opposés que l’équipe devra lutter pour résoudre les problèmes du client.

Résoudre les problèmes

Ensuite, une fois les problèmes déterminés, l’équipe va pouvoir s’attaquer à la résolution des problèmes. Cela peut également être judicieux de réaliser des prototypes. Pour l’exemple donné de Régis sur la liste d’éléments, la contre-mesure adoptée a été de mettre un dernier élément fictif dans la liste « Ajouter… ».

Tirer les bonnes leçons

Enfin cette dernière étape consiste à vérifier la résolution des problèmes, notamment en comparant les indicateurs avant les corrections réalisées.

Avis personnel

J’ai particulièrement apprécié cette session, car elle m’a fait découvrir des principes du Lean Management, qui apportent une nouvelle vision au développement logiciel. La réalité du terrain sur lequel Régis a bien insisté me semble également essentiel, ayant déjà fait l’expérience moi-même d’aller voir comment mes utilisateurs utilisent l’application. Je rajouterais toutefois qu’il faut faire attention lors de cette phase Gemba, car l’observation du problème peut l’altérer. En effet, pour l’exemple donné sur la liste d’éléments, si lors de l’observation, on informe l’utilisateur que pour ajouter un élément il faut cliquer en-dessous de la liste, il pourra être déstabilisé par la contre-mesure qui place l’ajout d’éléments en fin de liste. La contre-mesure peut se voir ainsi biaisé par l’observation et être contre productive. La malédiction de la connaissance de l’application peut alors potentiellement s’appliquer à l’utilisateur observé !

Conclusion

En conclusion, le Problem Driven Development apporte une nouvelle vision du développement logiciel qui s’adapte bien aux situations d’un cadre exploratoire, le tout dans le but d’obtenir une satisfaction complète du client.

Cette approche ne se concentre plus sur les features, les fonctionnalités, mais sur les problèmes du client à résoudre. En outre, au travers du cycle d’amélioration continue PDCA, il faut considérer chaque évolution, non plus comme une solution qui a une connotation définitive, mais comme une contre-mesure au problème.

Nombre de vue : 306

AJOUTER UN COMMENTAIRE