{"id":164,"date":"2012-03-04T20:50:59","date_gmt":"2012-03-04T19:50:59","guid":{"rendered":"http:\/\/dev.qualilogy.com\/fr\/?p=164"},"modified":"2013-01-05T09:05:21","modified_gmt":"2013-01-05T08:05:21","slug":"histoires-dutilisateurs-2","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/histoires-dutilisateurs-2\/","title":{"rendered":"Histoires d’utilisateurs"},"content":{"rendered":"

M\u00e9thodologies. Agile. Scrum. Extreme programming. Beaucoup de m\u00e9thodologies. \u00ab User stories \u00bb semble actuellement tr\u00e8s vogue.<\/p>\n

Quand j’\u00e9tais d\u00e9veloppeur, je ne croyais pas aux m\u00e9thodologies. Vous \u00eates un bon d\u00e9veloppeur ou vous ne l’\u00eates pas. Et si vous ne l’\u00eates pas, il n’existe aucune m\u00e9thodologie qui puisse changer cela.<\/p>\n

<\/p>\n

\"\"<\/a>Sp\u00e9cifications<\/strong><\/h3>\n

Un jour, un chef de projet m’a expliqu\u00e9 que je devais r\u00e9diger des sp\u00e9cifications avant de commencer \u00e0 programmer. Pourquoi devrais-je perdre 2 ou 3 jours pour \u00e9crire des sp\u00e9cifications et attendre une semaine une validation par je ne sais qui, quand je pouvais accomplir le travail imm\u00e9diatement?<\/p>\n

Ok, je peux comprendre. Trop de fois je me suis ru\u00e9 sur le clavier avant m\u00eame de penser \u00e0 ce que je devais d\u00e9velopper et \u00e0 la fin de la journ\u00e9e, j’avais un tas de lignes de code que m\u00eame moi je ne comprenais pas et pire encore, qui ne faisaient rien. Bugs, bugs, bugs. J’ai donc appris \u00e0 prendre au moins 10 mn afin de penser, dessiner un croquis, voire m\u00eame un algorithme.<\/p>\n

C\u2019\u00e9tait un temps o\u00f9 la m\u00e9thodologie se limitait \u00e0 la conception d’un algorithme. Apr\u00e8s cela, est venue l\u2019\u00e9poque \u00ab entit\u00e9s \u2013 relations \u00bb. Structurer les donn\u00e9es comme des entit\u00e9s et d\u00e9finir les relations entre elles. Une m\u00e9thodologie fran\u00e7aise appel\u00e9e Merise, tr\u00e8s c\u00e9l\u00e8bre dans les ann\u00e9es 80. Je l\u2019appr\u00e9ciais parce que c’\u00e9tait un exercice int\u00e9ressant, un peu comme un jeu, et se r\u00e9v\u00e9lait vraiment utile pour concevoir la couche de donn\u00e9es.<\/p>\n

Le seul probl\u00e8me, c’est que vous commencez \u00e0 avoir beaucoup de r\u00e9unions et s’il vous pla\u00eet, pensez \u00e0 prendre beaucoup de papier parce que nous allons passer quelques heures \u00e0 discuter pour savoir si cette relation est bi-directionnelle ou non. Et vous savez que l\u2019efficacit\u00e9 d\u2019une r\u00e9union est g\u00e9n\u00e9ralement inversement proportionnelle au nombre de personnes autour de la table. Et si c\u2019est une r\u00e9union de \u00abuser stories\u00bb, m\u00eame si vous avez juste 2 personnes autour de la table, mais que l’une est un d\u00e9veloppeur et l’autre un utilisateur, alors oubliez la m\u00e9thodologie et revenez \u00e0 quelques r\u00e8gles simples.<\/p>\n

Les d\u00e9veloppeurs sont de Mars et les utilisateurs de V\u00e9nus<\/strong><\/h3>\n

Les d\u00e9veloppeurs et les utilisateurs ne parlent pas la m\u00eame langue, alors pourquoi perdre du temps \u00e0 se raconter des \u00ab histoires \u00bb?<\/p>\n

Le projet est en retard. Le chef de projet a une r\u00e9union le matin avec les utilisateurs qui lui content leurs derni\u00e8res \u00ab histoires \u00bb. 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\u00e9union 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\u00e9veloppeur qui arr\u00eate tout ce qu’il faisait et d\u00e9veloppe rapidement un prototype afin qu’il y ait quelque chose \u00e0 montrer lors de la prochaine r\u00e9union et que les utilisateurs puissent voir que toute l’\u00e9quipe a commenc\u00e9 \u00e0 travailler sur leurs \u00abhistoires\u00bb. Peut-\u00eatre que les utilisateurs seront contents. Le plus souvent, ils racontent une autre \u00ab histoire \u00bb. Ou disent que le chef de projet ne comprend rien parce qu’il est idiot.<\/p>\n

La seule m\u00e9thodologie que je connaisse, c’est \u00abgarbage in, garbage out\u00bb. En tant que chef de projet, ma premi\u00e8re priorit\u00e9 a toujours \u00e9t\u00e9 de faire comprendre que je ne serais pas responsable de la poubelle en entr\u00e9e. Donc:<\/p>\n

1. Le d\u00e9veloppeur ne d\u00e9marre pas quoi que ce soit avant que l’utilisateur dispose d’une \u00abhistoire\u00bb.<\/p>\n

2. L’utilisateur r\u00e9dige son \u00ab histoire \u00bb et signe son \u00ab histoire \u00bb. Avec son propre sang, si possible.<\/p>\n

Tout est critique<\/strong><\/h3>\n

Les utilisateurs veulent tout et son contraire. J\u2019ai eu une fois une r\u00e9union avec environ 20 commerciaux afin d\u2019\u00e9tablir une liste de requirements. Apr\u00e8s une paire d’heures assez productives, nous avions d\u00e9fini tout ce qu’ils attendaient pour leur application commerciale et je leur ai demand\u00e9 de d\u00e9finir ce qui \u00e9tait critique \u00e0 leurs yeux, ce qui \u00e9tait important et ce qui \u00e9tait simplement \u00ab nice to have \u00bb. Ils m’ont regard\u00e9 comme si je leur demandais un rabais, et ils ont dit \u00ab tout est critique \u00bb. Donc je leur ai expliqu\u00e9:<\/p>\n

\u00ab Un client vous appelle au t\u00e9l\u00e9phone et vous souhaitez sa fiche client, avec ses ordres de vente, les donn\u00e9es contractuelles, ses informations personnelles, et m\u00eame ses hobbies, et vous voulez tout en moins d\u20191 seconde sur votre \u00e9cran, n\u2019est ce pas ? Et vous voulez \u00eatre en mesure de mettre \u00e0 jour ces informations aussi rapidement que possible pendant qu’il est au t\u00e9l\u00e9phone ? \u00bb<\/p>\n

\u00ab Effectivement. Le client n’attend pas. \u00bb<\/p>\n

\u00ab Vous voulez aussi pouvoir faire toutes sortes de requ\u00eates sur toutes les donn\u00e9es possibles pour identifier des ensembles de clients \u00e0 cibler et g\u00e9n\u00e9rer des mailings \u00e0 leur envoyer, n\u2019est ce pas ? \u00bb<\/p>\n

\u00ab Oui. \u00bb<\/p>\n

\u00ab Eh bien, vous pouvez obtenir toutes les donn\u00e9es pour 1 client en 1 seconde, ou vous pouvez obtenir 1 donn\u00e9e pour tous vos clients en un temps tr\u00e8s rapide, mais vous ne pouvez pas avoir toutes les donn\u00e9es de tous les clients en 1 seconde. \u00bb<\/p>\n

Je leur ai expliqu\u00e9 que pour obtenir un type d’information le plus rapidement possible, les d\u00e9veloppeurs indexent les donn\u00e9es, mais que plus on utilisait d\u2019indexs et plus on ralentissait l’ensemble du syst\u00e8me. Comme je pensais que la requ\u00eate pour obtenir la fiche client \u00e9tait la plus critique, je me suis engag\u00e9 \u00e0 leur fournir cette fonctionnalit\u00e9 avec le temps de r\u00e9ponse le plus rapide possible. Puis, je leur ai dit que, m\u00eame si la possibilit\u00e9 d’effectuer toutes sortes de requ\u00eates complexes sur toutes les donn\u00e9es possibles \u00e9tait important, ce n’\u00e9tait pas quelque chose qu’ils feraient tous les jours, mais plut\u00f4t une fois par mois ou par trimestre. Donc si ce traitement \u00e9tait lent, une fois par mois, ils pouvaient aller prendre un caf\u00e9 en attendant les r\u00e9sultats. Et ils ont \u00e9t\u00e9 d’accord.<\/p>\n

Les commerciaux peuvent parfois \u00eatre exigeants, mais au moins, ils comprennent le concept de n\u00e9gociation.<\/p>\n

Donc, quelles que soient les \u00ab histoires \u00bb des utilisateurs, l’important est que:<\/p>\n

3. L’utilisateur d\u00e9finit les priorit\u00e9s.<\/p>\n

4. Vous vous engagez sur ce qui est critique, faites du mieux possible sur ce qui est important, le \u00ab nice to have \u00bb attendra la prochaine version.<\/p>\n

Je veux la lune<\/strong><\/h3>\n

Un autre projet consistait en la cr\u00e9ation d\u2019 un site web de jardinage. Ce fut un projet difficile avec un calendrier trop serr\u00e9, une \u00e9quipe de projet insuffisante, et beaucoup de pression. Et les utilisateurs ne savaient pas ce qu’ils voulaient, avec des exigences en constante \u00e9volution. Jusqu’\u00e0 ce qu’un jour le responsable du site a demand\u00e9 qu\u2019on lui d\u00e9veloppe une section sur \u00ab la lune et son influence sur les plantes \u00bb.<\/p>\n

Je pensais que c’\u00e9tait compl\u00e8tement irresponsable de demander un tel truc alors qu\u2019on avait beaucoup plus important \u00e0 faire, mais comme il \u00e9tait le grand patron, il savait que je ne pouvais pas refuser. J’ai demand\u00e9 au plus jeune d\u00e9veloppeur dans l’\u00e9quipe de faire rapidement un prototype, et de ne pas perdre trop de temps l\u00e0-dessus. Il a rapidement con\u00e7u une section avec 2 ou 3 pages que l’utilisateur pouvait mettre \u00e0 jour, modifier le texte, mettre quelques liens, etc. Et il a plac\u00e9 une image de lune au sommet de chaque page.<\/p>\n

J\u2019ai fait une pr\u00e9sentation au grand patron et ses assistants, sur mon propre \u00e9cran, et m\u00eame s’il n’y avait pas tout ce qu’il avait demand\u00e9, il a bien aim\u00e9. Mais \u00e0 ce moment, il a fait quelque chose de simplement stupide: il a indiqu\u00e9 le coin sup\u00e9rieur droit de l’\u00e9cran et il a dit \u00ab Je veux la lune ici \u00bb. J’ai appel\u00e9 le jeune programmeur qui \u00e9tait \u00e0 l’autre bout de la salle et tout le monde pouvait voir, alors qu’il s\u2019approchait \u00e0 pas mesur\u00e9s de mon bureau, qu’il \u00e9tait las des caprices des utilisateurs.<\/p>\n

Le grand patron a r\u00e9it\u00e9r\u00e9 sa demande: \u00ab Est-il possible avoir la lune ici ? \u00bb<\/p>\n

Le jeune d\u00e9veloppeur s’est pench\u00e9 sur mon \u00e9cran et a regard\u00e9 attentivement l’endroit indiqu\u00e9 comme s\u2019il r\u00e9fl\u00e9chissait profond\u00e9ment \u00e0 la question, et r\u00e9pondit simplement \u00ab Non \u00bb. Puis il retourna \u00e0 sa place en traversant toute la salle stup\u00e9faite. Le grand patron \u00e9tait tellement surpris qu’il a juste regard\u00e9 l’\u00e9cran et dit \u00ab Bon. Je suppose que c’est assez bien comme c\u2019est l\u00e0. \u00bb<\/p>\n

Apr\u00e8s cela, nous n’avons plus eu aucun probl\u00e8me. Plus aucune \u00e9volution de sp\u00e9cifications. J’ai parfois invit\u00e9 le programmeur en r\u00e9union du projet avec le comit\u00e9 de pilotage, et il s’asseyait \u00e0 ma droite, le regard ferm\u00e9 sans rien dire, de sorte que tout le monde puisse se rappeler que \u00ab c\u2019\u00e9tait assez bien comme cela. \u00bb J’appelais ce jeune d\u00e9veloppeur mon ‘Kill Bill’.<\/p>\n

La le\u00e7on ici est : tout ce que l’utilisateur dit avoir besoin n’est pas forc\u00e9ment n\u00e9cessaire. Le probl\u00e8me n\u2019est de ne pas comprendre les requirements, mais de produire une application qui r\u00e9ponde aux besoins de l’entreprise. Le d\u00e9veloppeur peut modifier les requirements tant que l’utilisateur ne prouve pas que ce soit absolument n\u00e9cessaire. Cela suppose certes une bonne connaissance m\u00e9tier de l\u2019\u00e9quipe de projet.<\/p>\n

 <\/p>\n

J’ai beaucoup d’histoires sur les utilisateurs et vous en avez probablement aussi quelques unes. Quelle que soit la m\u00e9thodologie utilis\u00e9e, il existe certains fondamentaux de type \u00ab\u00a0Keep it simple\u00a0\u00bb \u00e0 retenir.<\/p>\n

Le travail d’un d\u00e9veloppeur est de produire en temps et en heure une application qui soit de qualit\u00e9, avec des outils de d\u00e9veloppement qui boguent, des bases de donn\u00e9es au temps de r\u00e9ponse impr\u00e9visible, avec des librairies pas toujours op\u00e9rationnelles, et des langages myst\u00e9rieux et complexes.<\/p>\n

Les d\u00e9veloppeurs ont d\u00e9j\u00e0 suffisamment de probl\u00e8mes sans leur demander de comprendre des \u00ab user stories \u00bb.<\/p>\n","protected":false},"excerpt":{"rendered":"

M\u00e9thodologies. Agile. Scrum. Extreme programming. Beaucoup de m\u00e9thodologies. \u00ab User stories \u00bb semble actuellement tr\u00e8s vogue. Quand j’\u00e9tais d\u00e9veloppeur, je ne croyais pas aux m\u00e9thodologies. Vous \u00eates un bon d\u00e9veloppeur ou vous ne l’\u00eates pas. Et si vous ne l’\u00eates pas, il n’existe aucune m\u00e9thodologie qui puisse changer cela.<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[],"class_list":["post-164","post","type-post","status-publish","format-standard","hentry","category-qa"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/164"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=164"}],"version-history":[{"count":2,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/164\/revisions"}],"predecessor-version":[{"id":187,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/164\/revisions\/187"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=164"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=164"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=164"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}