Méthodologies. Agile. Scrum. Extreme programming. Beaucoup de méthodologies. « User stories » semble actuellement très vogue.

Quand j’étais développeur, je ne croyais pas aux méthodologies. Vous êtes un bon développeur ou vous ne l’êtes pas. Et si vous ne l’êtes pas, il n’existe aucune méthodologie qui puisse changer cela.

Spécifications

Un jour, un chef de projet m’a expliqué que je devais rédiger des spécifications avant de commencer à programmer. Pourquoi devrais-je perdre 2 ou 3 jours pour écrire des spécifications et attendre une semaine une validation par je ne sais qui, quand je pouvais accomplir le travail immédiatement?

Ok, je peux comprendre. Trop de fois je me suis rué sur le clavier avant même de penser à ce que je devais développer et à la fin de la journée, j’avais un tas de lignes de code que même moi je ne comprenais pas et pire encore, qui ne faisaient rien. Bugs, bugs, bugs. J’ai donc appris à prendre au moins 10 mn afin de penser, dessiner un croquis, voire même un algorithme.

C’était un temps où la méthodologie se limitait à la conception d’un algorithme. Après cela, est venue l’époque « entités – relations ». Structurer les données comme des entités et définir les relations entre elles. Une méthodologie française appelée Merise, très célèbre dans les années 80. Je l’appréciais parce que c’était un exercice intéressant, un peu comme un jeu, et se révélait vraiment utile pour concevoir la couche de données.

Le seul problème, c’est que vous commencez à avoir beaucoup de réunions et s’il vous plaît, pensez à prendre beaucoup de papier parce que nous allons passer quelques heures à discuter pour savoir si cette relation est bi-directionnelle ou non. Et vous savez que l’efficacité d’une réunion est généralement inversement proportionnelle au nombre de personnes autour de la table. Et si c’est une réunion de «user stories», même si vous avez juste 2 personnes autour de la table, mais que l’une est un développeur et l’autre un utilisateur, alors oubliez la méthodologie et revenez à quelques règles simples.

Les développeurs sont de Mars et les utilisateurs de Vénus

Les développeurs et les utilisateurs ne parlent pas la même langue, alors pourquoi perdre du temps à se raconter des « histoires »?

Le projet est en retard. Le chef de projet a une réunion le matin avec les utilisateurs qui lui content leurs dernières « histoires ». Puis il se met sur sa feuille de calcul ou son soft de gestion de projet pour re-programmer le planning. Puis il a une autre réunion afin de vendre le nouveau calendrier aux utilisateurs. Et puis une rencontre avec son patron pour lui parler du planning final. Encore plus de pression. Enfin, il va voir le développeur qui arrête tout ce qu’il faisait et développe rapidement un prototype afin qu’il y ait quelque chose à montrer lors de la prochaine réunion et que les utilisateurs puissent voir que toute l’équipe a commencé à travailler sur leurs «histoires». Peut-être que les utilisateurs seront contents. Le plus souvent, ils racontent une autre « histoire ». Ou disent que le chef de projet ne comprend rien parce qu’il est idiot.

La seule méthodologie que je connaisse, c’est «garbage in, garbage out». En tant que chef de projet, ma première priorité a toujours été de faire comprendre que je ne serais pas responsable de la poubelle en entrée. Donc:

1. Le développeur ne démarre pas quoi que ce soit avant que l’utilisateur dispose d’une «histoire».

2. L’utilisateur rédige son « histoire » et signe son « histoire ». Avec son propre sang, si possible.

Tout est critique

Les utilisateurs veulent tout et son contraire. J’ai eu une fois une réunion avec environ 20 commerciaux afin d’établir une liste de requirements. Après une paire d’heures assez productives, nous avions défini tout ce qu’ils attendaient pour leur application commerciale et je leur ai demandé de définir ce qui était critique à leurs yeux, ce qui était important et ce qui était simplement « nice to have ». Ils m’ont regardé comme si je leur demandais un rabais, et ils ont dit « tout est critique ». Donc je leur ai expliqué:

« Un client vous appelle au téléphone et vous souhaitez sa fiche client, avec ses ordres de vente, les données contractuelles, ses informations personnelles, et même ses hobbies, et vous voulez tout en moins d’1 seconde sur votre écran, n’est ce pas ? Et vous voulez être en mesure de mettre à jour ces informations aussi rapidement que possible pendant qu’il est au téléphone ? »

« Effectivement. Le client n’attend pas. »

« Vous voulez aussi pouvoir faire toutes sortes de requêtes sur toutes les données possibles pour identifier des ensembles de clients à cibler et générer des mailings à leur envoyer, n’est ce pas ? »

« Oui. »

« Eh bien, vous pouvez obtenir toutes les données pour 1 client en 1 seconde, ou vous pouvez obtenir 1 donnée pour tous vos clients en un temps très rapide, mais vous ne pouvez pas avoir toutes les données de tous les clients en 1 seconde. »

Je leur ai expliqué que pour obtenir un type d’information le plus rapidement possible, les développeurs indexent les données, mais que plus on utilisait d’indexs et plus on ralentissait l’ensemble du système. Comme je pensais que la requête pour obtenir la fiche client était la plus critique, je me suis engagé à leur fournir cette fonctionnalité avec le temps de réponse le plus rapide possible. Puis, je leur ai dit que, même si la possibilité d’effectuer toutes sortes de requêtes complexes sur toutes les données possibles était important, ce n’était pas quelque chose qu’ils feraient tous les jours, mais plutôt une fois par mois ou par trimestre. Donc si ce traitement était lent, une fois par mois, ils pouvaient aller prendre un café en attendant les résultats. Et ils ont été d’accord.

Les commerciaux peuvent parfois être exigeants, mais au moins, ils comprennent le concept de négociation.

Donc, quelles que soient les « histoires » des utilisateurs, l’important est que:

3. L’utilisateur définit les priorités.

4. Vous vous engagez sur ce qui est critique, faites du mieux possible sur ce qui est important, le « nice to have » attendra la prochaine version.

Je veux la lune

Un autre projet consistait en la création d’ un site web de jardinage. Ce fut un projet difficile avec un calendrier trop serré, une équipe de projet insuffisante, et beaucoup de pression. Et les utilisateurs ne savaient pas ce qu’ils voulaient, avec des exigences en constante évolution. Jusqu’à ce qu’un jour le responsable du site a demandé qu’on lui développe une section sur « la lune et son influence sur les plantes ».

Je pensais que c’était complètement irresponsable de demander un tel truc alors qu’on avait beaucoup plus important à faire, mais comme il était le grand patron, il savait que je ne pouvais pas refuser. J’ai demandé au plus jeune développeur dans l’équipe de faire rapidement un prototype, et de ne pas perdre trop de temps là-dessus. Il a rapidement conçu une section avec 2 ou 3 pages que l’utilisateur pouvait mettre à jour, modifier le texte, mettre quelques liens, etc. Et il a placé une image de lune au sommet de chaque page.

J’ai fait une présentation au grand patron et ses assistants, sur mon propre écran, et même s’il n’y avait pas tout ce qu’il avait demandé, il a bien aimé. Mais à ce moment, il a fait quelque chose de simplement stupide: il a indiqué le coin supérieur droit de l’écran et il a dit « Je veux la lune ici ». J’ai appelé le jeune programmeur qui était à l’autre bout de la salle et tout le monde pouvait voir, alors qu’il s’approchait à pas mesurés de mon bureau, qu’il était las des caprices des utilisateurs.

Le grand patron a réitéré sa demande: « Est-il possible avoir la lune ici ? »

Le jeune développeur s’est penché sur mon écran et a regardé attentivement l’endroit indiqué comme s’il réfléchissait profondément à la question, et répondit simplement « Non ». Puis il retourna à sa place en traversant toute la salle stupéfaite. Le grand patron était tellement surpris qu’il a juste regardé l’écran et dit « Bon. Je suppose que c’est assez bien comme c’est là. »

Après cela, nous n’avons plus eu aucun problème. Plus aucune évolution de spécifications. J’ai parfois invité le programmeur en réunion du projet avec le comité de pilotage, et il s’asseyait à ma droite, le regard fermé sans rien dire, de sorte que tout le monde puisse se rappeler que « c’était assez bien comme cela. » J’appelais ce jeune développeur mon ‘Kill Bill’.

La leçon ici est : tout ce que l’utilisateur dit avoir besoin n’est pas forcément nécessaire. Le problème n’est de ne pas comprendre les requirements, mais de produire une application qui réponde aux besoins de l’entreprise. Le développeur peut modifier les requirements tant que l’utilisateur ne prouve pas que ce soit absolument nécessaire. Cela suppose certes une bonne connaissance métier de l’équipe de projet.

 

J’ai beaucoup d’histoires sur les utilisateurs et vous en avez probablement aussi quelques unes. Quelle que soit la méthodologie utilisée, il existe certains fondamentaux de type « Keep it simple » à retenir.

Le travail d’un développeur est de produire en temps et en heure une application qui soit de qualité, avec des outils de développement qui boguent, des bases de données au temps de réponse imprévisible, avec des librairies pas toujours opérationnelles, et des langages mystérieux et complexes.

Les développeurs ont déjà suffisamment de problèmes sans leur demander de comprendre des « user stories ».

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.