La deuxième journée de la conférence Agile France 2010 commence par une Keynote d’Esther Derby. Il a fallut attendre une heure pour voir la première grosse présentation à ne pas louper : Satisfaire complètement son client avec le Problem Driven Development par Régis Medina. Cette visite guidée dans l’univers de Régis a été passionnante, je vous propose de suivre la session avec moi.
Quelques mots sur le speaker. Régis Medina est bien connu dans la communauté Agile Française. Coach Lean spécialisé dans l’accompagnement des équipes techniques, il découvre XP en 98, il a co-écrit avec d’autres auteurs le livre « Gestion de projet : eXtreme-Programming » paru chez Eyrolles. C’est un orateur passionnant, qui propose une vision où le Lean et l’Agile sont mis en parallèles. Et accessoirement c’est un utilisateur d’IDEA IntelliJ, donc je +1 avec plaisir.
Arrêtons-nous un instant sur ce que nous produisons. Parfois, nous suivons à la lettre ce que demande le client. Peu importe la méthode de développement, ou de gestion de projet. Lorsque l’on regarde quelques temps plus tard certains projets, certains apparaissent comme dangereux. Regardez cette théière utilisé par Régis pour illustrer son idée, fruit du travail de Donald A.Norman. Sur le plan du cahier des charges, l’ensemble des besoins sont développés. Simplement, cet objet est inutile. Et combien de projets ou d’outils inutiles avons-nous croisé dans notre carrière ?
Régis Medina pose la question suivante : « Comment faire des logiciels en mesure de satisfaire pleinement les clients ?« .
A priori, la réponse serait de prendre une bonne méthode de développement, et une bonne méthode de gestion de projet. Prenons le cycle en V, qui anime les soirées d’hiver et qui permet de se chauffer grâce aux tonnes de documentations produites…
Faire une spécification pour certains utilisateurs, c’est un peu découper le catalogue de la Redoute dans les pages Jouets. Certains utilisateurs, de peur de manquer, chargent à mort les spécifications fonctionnelles. Le fait de demander en amont aux clients, puis de spécifier de manière exhaustive leurs besoins, peut conduire parfois à une perte de temps, à un certain gâchis.
Les spécifications c’est fait. La conception ressemble ensuite à une équipe dans un sous-marin nucléaire. Impossible d’accéder à l’équipe de développement, c’est du cycle en V. Si tu veux leur parler, on te demandera d »écrire une spécification. Et de la donner aux développeurs avec une fourche.
Une fois le développement terminé tant bien que mal, souvent à l’arrache, vient le temps de la validation. Autant éteindre un feu avec un verre d’eau. Si la Validation se passe bien (ahahah) vous irez en production. Ne donnez pas votre vrai nom au gars qui fait la mise en prod. Il serait capable de venir vous casser la figure. Le déploiement… Régis utilise l’image d’une personne qui a peur.
Alors arrive l’Agile
Après avoir dépeint un tableau noir de la situation, Régis passe à la page « Agile ». Premier principe : nous allons écouter le client et délivrer des incréments de logiciels qui fonctionne, petit à petit. Cela permet de lisser l’inconnu et de s’assurer que le logiciel fonctionne.
Régis explique cependant, qu’en appliquant trop à la lettre les demandes des clients, vous risqueriez de développer une théière avec un manche mal placé. Le client ne sait pas toujours exprimer correctement ses besoins. Et faire de l’Agile, faire du Scrum, ne veut pas dire « ne pas prévoir à 2 ou 3 mois » ou « ne pas faire de l’Architecture ». C’est un anti-pattern de Scrum, que de croire que l’Architecture émerge magiquement du développement (ça c’est de moi).
Le Client n’est pas concepteur de logiciel. Pourquoi lui demander d’apprendre l’UML pour exprimer son besoin ? Si vous commenciez par écouter, et par apprendre le domaine du client… Je sens que Régis est aussi un fan de DDD comme moi.
Alors vient souvent la phrase « oui mais il faut un BON Product Owner« . Cette phrase est à mon avis un moyen élégant de dire « le client est un abruti, il en faut un plus intelligent« .
Je retourne la question : « Oui mais il faut une BONNE équipe capable d’écouter le client« .
Cela va mieux dans ce sens là non ?
Régis explique l’importance de définir le domaine du client, de cadrer les frontières de son problème. Il recommande de travailler par exploration, de découvrir le domaine, les mots du clients, à s’approprier le vocabulaire et la connaissance de celui-ci. C’est du DDD non monsieur Medina ?
Et bien il poste un nouvel acronyme : PDL pour Problem Driven Development.
Notre mission sera désormais de résoudre les problèmes des clients. Et de les résoudre complètement. Les tests vont piloter le développement. Nous, développeurs, sommes là pour comprendre, analyser et résoudre les problèmes du client.
Pour cela, Régis propose d’appliquer deux des principes du Lean :
– Plan Do Check Adjust
– Aller sur le terrain (Gemba)
Demandez à aller voir le client, l’utilisateur qui sera 8h par jour avec votre logiciel. Regardez comment le client utilise votre logiciel, ou comment il utilise un logiciel similaire. Listez les problèmes qu’il rencontre, et tirez-en des leçons pour vraiment écouter le client.
La voix du client
Prenons les 5 points suivants :
1. Donne moi exactement ce que je veux
2. Quand je le veux
3. Où je le veux
4. Soyez fiables
5. Ne me faîtes pas perdre mon temps, je n’ai pas envie d’apprendre
Le point 1 apporte la valeur. Les points 2 à 5 seront du gachis pour le client s’ils ne sont pas respectés. Les 2 points les plus importants : le 1 et le 5 : donnez moi exactement ce que je veux et ne me faîtes pas perdre mon temps, je n’ai pas envie d’apprendre à utiliser votre logiciel. Le meilleur exemple ? Pensez à l’iphone. Avec une ergonomie et une puissance importante, vous allez à l’essentiel. Si seulement nos bonnes vieilles applications de gestion pouvaient s’en inspirer…
Le meilleur service finalement, c’est celui que l’on ne voit plus. Régis nous demande de réflechir à tout ce qui est mis en oeuvre entre toi, lecteur qui lit cet article, et les byes stockés dans une base MySQL sur un serveur quelque part… sans parler d’électronique. Vous vous rendez compte du parcours de l’information ?
La démarche d’être très simple, très rapide et très efficace est aussi illustrée par Google. Lorsque vous arrivez, que vous tapez un mot, puis que vous partez sur une page de résultat, il s’écoule moins de 5 secondes… Quand on pense à tout ce qui se passe derrière, en amont, c’est assez impressionnant.
Régis propose donc de nous faire réfléchir aux meilleurs choix pour résoudre le plus efficacement possible le problème du client.
Regarder la performance
On ne peut améliorer que ce que l’on mesure. Il faut des indicateurs, afin de se rendre compte de ses progrès ou non. Que ce soit le nombre d’utilisateurs, le nombre d’appel sur la hotline, ou le taux de pertes de paquets réseaux, il faut des indicateurs.
Voir les problèmes
Un problème est l’écart entre l’indicateur et sa valeur actuelle. Gemba dans la démarche Lean, nous pousse à aller sur le terrain, pour comprendre ce qui cloche. Regardez l’utilisateur, la séquence d’utilisation, les stratégies d’évitement qu’il met en oeuvre pour résoudre un problème… c’est très intéressant. Comme dit Régis : « tant que l’on ne l’a pas vu… on ne l’a pas vu… c’est le problème ».
La courbe de connaissance entre vous, développeurs, et eux, les utilisateurs, est aussi très importante. Un développeur « sait » comment marche son logiciel, puisqu’il l’a codé. Quel est l’écart entre ce que sait le client et ce que vous savez ? Quel est la taille du problème (cf plus haut) ?
Inversement, les développeurs parfois ne connaissent pas le métier fonctionnel. Cela donne des perles, comme des objets financiers implémentés avec des getter/setter, alors que l’objet lui-même, dans la vraie vie, EST IMMUABLE ! Je m’égare…
Résoudre le problème
Résoudre c’est bien, mais il faut être proactif, et il faut penser en permanence à l’amélioraton du système. Pour cela, la technique du PDCA : Plan Do Check Adjust. Il faut voir les causes d’un problème, anticiper le résultat lorsque le souci sera corrigé, élaborer une contre-mesure en cas d’erreurs.
En tirer de bonnes leçons
Ecoutez les clients, et mettez en place des ateliers d’apprentissage afin que les développeurs s’approprient le domaine du client. Pour travailler, faites des ateliers de prototype, des interviews, des sessions de brainstorming avec le client. Lorsque vous développerez votre prochain site Web avec Play! Framework, ou votre application de gestion sérieuse avec Play! Framework, pensez aux écrans, à l’idée que pour résoudre un problème, il faut aller vite.
Imaginez Google ou l’interface de l’iphone développé par un gars qui n’aurait aucunes idées de votre besoin… ou qui ne chercherait pas à résoudre efficacement et rapidement vos problèmes…
Conclusion
En conclusion, Régis nous rappelle les principes de la démarche Lean, et de sa possible mise en place dans les équipes de développement logiciel. Avec de grands principes, qui placent le client au centre des préoccupations, j’ai bien accroché. J’aime aussi cette vision où le développeur et ses frameworks n’est plus le plus important. C’est vrai que parfois, nous donnons l’image de gosses qui bidouillent avec une boîte de « Petit chimiste », alors que l’on nous demande juste de faire une chose : résoudre les problèmes des clients simplement, le plus efficacement possible, et sans lui faire perdre son temps.
A méditer.
Merci à Régis, en espérant avoir retranscris l’esprit.
0 no like
Salut!
Aller vite pour résoudre un problème ?
Je ne sais pas…
Ca me fait penser à une histoire dans ‘Lean Manager’
Eric est un nouveau responsable de 2 lignes de production
La première a un problème et s’arrete
Il va voir et demande ‘pourquoi?’
Pendant ce temps, la 2 s’arrete aussi
Il se redresse pour aller la voir et son coordinateur lui attrape la manche et lui dit
‘il est plus important de savoir pourquoi la 1e ligne s’est arreté’
Pourquoi est-ce plus important ?
Curieux, Thierry