Chacun sa méthode, chacun son problème !

Souvent lorsque les gens me parlent des méthodologies Agiles, ils font rapidement référence à SCRUM ou Extrem Programming (XP). Mais, il en existe beaucoup plus que cela.

Chacune des méthodes adressent une problématique, chacun son problème. Par exemple, SCRUM adresse la capacité de la livraison d’un logiciel en développement. Je sais, je résume de manière très simpliste. Mais, mon propos n’est pas de parler de SCRUM en particulier.

Mais, il existe plusieurs tâches ou problèmes qu’on peut adresser avec les méthodologies Agiles. À la base des méthodologies Agiles, c’est le Manifeste Agile et aussi de bonnes pratiques de développement logiciels.

Il ne faut jamais chercher à prendre une implémentation des principes du Manifeste Agile comme un couteau suisse, mais comme une lame ou un outil de celui-ci. Si vous prenez soin de bien identifier le problème que vous voulez résoudre.

Mais trop souvent, les gens cherchent une méthode qui va solutionné leur problème, sans vraiment le connaître. Lorsque mon auto a problème, je demande à mon mécanicien de faire un diagnostique, pas juste changé la batterie ou l’huile de la voiture.

Si vous ne savez pas exactement ce qu’est votre problème, faites comme avec votre voiture, demandé l’aide d’un ou de plusieurs spécialistes qui vous aidera à choisir la bonne méthode.

Il me serait facile de vous faire une liste de problèmes typiques avec leur solution, leur méthode qui pourrait le résoudre. Mais, ça irait à ‘inverse de ma philosophie et à l’opposer des principes des méthodologies Agiles. À besoin, fait comme je le recommande dans cet article « Un chef et son buffet de services, un buffet de services agiles» inventer la vôtre !

Si vous me racontiez une petite histoire ?

C’est souvent comment, j’aborde mes séances d’ « User Storie » avec des usagers.
Au cours des prochaines lignes de ce billet, je vais essayer d’apporter mes lumières sur l’utilisation de cette méthodologie d’identifications de besoins et des fonctions de l’application des utilisateurs.
Beaucoup de gens plus traditionnels on peur de s’y impliquer trop à font ou encore ne savent pas comment le faire, sans embarqué dans dans une spirale de besoins. Ou encore pire, en utilisant un langage trop compliquer pour l’utilisateur.
L’utilisateur moyen comprend souvent mieux son son travail que le pense ! Pourquoi pas, de lui proposer une technique simple pour nous l’expliquer. Si on leur permet de nous parler, sans qu’ils sentent moins compétant ou inférieur à nous. Généralement, ils vont nous faire de belles surprises. Nous connaissons l’informatique, mais eux connaisse leur domaine. Notre logiciel doit s’adapter à leur besoin et aussi à leur domaine d’affaires. Laissons-les-nous en parler !
Les histoires utilisateurs (ou en anglais « User Stories ») permet de créer cet environnement facilitateur, et ce, sans l’utilisation d’outils complexes. Il est rare de trouver une personne qui est incapable de parler ce qu’il fait à tous les jours.
Qui ne sait pas dessiner grossièrement un écran juste pour donner un premier ébauche de ce quoi il pourrait ressembler. Mais, surtout prendre le temps d’écouter l’utilisateur sur ce qu’ils voudraient en faire.

Car, n’oublions pas, notre quête ultime dans cet exercice, c’est de livrer en fin de projet la meilleure application. La meilleure application qui correspond tant aux besoins de notre utilisateur. Mais, aussi selon contexte organisationnel (incluant sa capacité de payer aussi).
Trop souvent pour atteindre cet objectif, on utilisait un jargon trop technique; peut-être pour nous monter un peu trop savant ! Mais en restreignant notre langage à celui que tout le monde peut comprendre et surtout l’utilisateur. Il sera vite à l’aise de nous parle de toutes ses préoccupations. Il sera toujours temps d’écrire une belle documentation pour conserver ou officialiser ce besoin.
Nous en méthodologies Agiles, nous acceptons le changement. C’est vrai. Mais, plus rapidement ce changement arrive. Mais, aussi sa compréhension devient claire plus vite nous adapter dans le projet. Plus, nous aurons la capacité de l’adresser et d’y faire face. Plus auront la facilité d’atteindre notre objectif final.
Cette belle histoire que l’usager va nous raconter. Elle ne doit pas être laissée à tous les vents. Mais, accompagner tant dans son traitement que dans son discours. On peut bien raconter, les contes des mille et une nuits. Si cela n’apporte rien à la compréhension, cela ne sert à rien.
Il aussi intéressant, de permet à l’occasion de parler de sont travail d’une manière plus générale. Car, en racontant ces petits à côtés. À une oreille, bien à viser, on peut découvrir bien choses qui vont nous aider dans notre quête.
J’aime bien entendre raconter mon utilisateur ce qu’il fait en prenant son café en arrivant le matin. J’y ai découvert de vraies petites perles. Souvent même, sans que l’utilisateur se rendre compte de ce qu’il m’avait raconté, de l’importance de son histoire.

Raconter une histoire, c’est bien beau. Mais, comment faut-il le faire. Comme dit l’expression, nous avons deux oreilles et une bouche. C’est qu’il faut écoute 2 fois plus qu’on parle. Prendre des notes au besoin, des petits schémas, de petits dessins et l’utilisateur n’y voit pas d’inconvénient, enregistrer les conversations.
Il faut aussi, bien sûr, prendre des notes de ce que l’utilisateur nous explique. La manière le plus simplement, c’est par l’utilisation de grand Post-it ou d’un tableau. Si vous utiliser un tableau, d’apporter une caméra pour prendre une photo de ce qui a été écrit au tableau. C’est important de garder ces grands Post-it ou photos pour conserver une trace de ce qu’il a été discuté avec les utilisateurs.
Il est très conseillé de limiter à 4 ou 5 points de formes par fiche. On se croit toujours avoir une mémoire très supérieur à la réalité. Mais, il est facile de se rappeler de l’information comprise dans 4-5 items. Plus que ça, il sera difficile de combler l’information des points formes.
Et quand on dit, des points de forme. On ne dit pas de romans. Il faut se limiter à une ou deux phrases courtes. Une phrase d’actions et surtout affirmative. Nous voulons décrire ce qu’on veut faire et non l’inverse.
Restons simples, restons Agile tant notre approche que dans nos actes. Et faisons- le ensemble, en impliquant l’utilisateur, nous atteindrons notre objectif. De créer la meilleure application pour notre utilisateur. Et j’en suis sur, il en sera d’autant satisfait. Car, il se sentira impliqué dès le début et jusqu’à la fin.
Lors de ces séances d’ « user stories » vous ne devez pas diriger la conversation ou la rencontre. Mais, vous devez l’animer, idéalement nous en voulons toujours plus, avoir toute l’information d’un seule coup. Mais, parfois, il sera nécessaire, tant pour compréhension du système système ou domaine d’affaires. Ou parce que l’utilisateur avait plus d’information à nous donner.
Il sera toujours le temps, d’en refaire une autre pour compléter ou même améliorer la compréhension du besoin. Parler, s’assoir avec notre utilisateur, lui donner l’occasion de nous parler de son besoin, c’est aussi ça d’être Agile.
Avez-vous une petite histoire à me raconter ?

Bonne lecture à tous. L’équipe de Génération Agile !