Comment tester l'ergonomie ?

Tester l’ergonomie par programme peut sembler difficile : simuler les actions utilisateur s’apparente à de l’intelligence artificielle et la complexité du programme de test doit rester limitée. Par conséquent l’IHM est souvent peu testée alors qu’il s’agit de la partie visible de l’iceberg par l’utilisateur.
Dans les environnements web il existe de nombreux frameworks open source qui permettent de tester facilement l’ergonomie. Parmi eux j’ai pu essayer simple test pour le PHP et Canoo pour le html et les scripts (merci Christophe 🙂  ). En revanche en C++ il y a pénurie d’outils gratuits performants. Une façon de contourner le problème est d’utiliser des astuces d’architecture qui permettent de tester des sous-ensembles de façon simple. Par exemple en utilisant des interfaces et le design-pattern « subject/observer », on peut écrire un test simple qui permet de vérifier que si la donnée est à jour, l’objet responsable de l’affichage l’est aussi. Prenons l’exemple d’une application qui permet de régler et contrôler le volume d’une chaine hi-fi . Voici une proposition pour l’architecture du programme :

Tester l’ergonomie du programme consiste à instancier une donnée de test que l’on liera à l’objet StereoPanel. On pourra ainsi vérifier que les objet responsables de l’affichage et la donnée de test sont en phase.

  • Ce genre de test ne valide pas la fonctionnalité du point de vue utilisateur. En revanche il est facile à écrire et garanti que lorsque les données et les contrôles sont liés, si les uns sont à jour les autres le sont aussi.
  • On voit bien ici comment rendre testable le logiciel influe sur l’architecture.

SCRUM : peut-on réellement se passer de formation ?

J’ai voulu écrire cet article car l’idée m’était venue de ne pas suivre de formation pour appliquer Scrum et je pense qu’il est important d’aborder cette question.

D’une part j’observe souvent une certaine réticence à aller en formation : on se demande si l’on ne va pas perdre son temps dans une formation qui ne nous fera pas avancer. D’autre part  la tentation est grande de se lancer comme ca dans l’agilité : la méthode scrum est simple (elle tient dans un slide comme aiment à dire les agilistes).
Lorsque nous avons décidé de tester l’approche sur un projet pilote, je n’avais lu que des articles du web et assisté à quelques conférences. Nous avons alors mis en place les principes suivants :

  • Identification d’un jalon court terme : un salon
  • Equipe : 3 développeurs motivés pour l’expérience
  • Product owner identifié
  • Une réunion de suivi toute les semaines

Arrivée à la date du salon l’équipe a fourni une maquette d’ergonomie mais les promesses de la méthode n’étaient pas au rendez-vous :

  • présence d’un fort effet silo : chaque développeur travaillant dans sa spécialité
  • absence de métriques d’avancement
  • maquette non fonctionnelle

Après ce premier bilan, nous avons demandé à suivre une formation puis nous avons appliqué Scrum plus « à la lettre ». Cela ne nous a pas permis d’éviter tous les pièges classiques mais nous avons très vite mesuré les apports de l’approche Agile (cohésion de l’équipe, polyvalence des équipiers, mesure de l’avancement, etc…).

Pour conclure, je pense que :

  • Cette formation de 2 jours n’est absolument pas une perte de temps face à tous les obstacles qu’elle nous a permis de surmonter
  • Le changement vers l’agilité est difficile et basé sur l’expérimentation. J’ai vécu cette formation comme une réelle expérience qui permet de simuler plusieurs cas d’usage que l’on rencontre sur des projets réels.
  • Quand on lit un livre ou des articles, il n’est pas toujours évident de comprendre l’importance relative entre les différentes pratiques. L’expérience du formateur permet d’insister sur tel ou tel concept.
  • La qualité des interactions entre les membres de l’équipe augmente lorsque chacun a son propre sens critique : attention aux formations en interne qui ont tendance à unifier les points de vue.

Impact des méthodes agiles sur l'architecture

La question de l’impact des méthodes agiles sur l’architecture est une question qui revient souvent. Cet article n’a pas pour but de traiter tout le sujet mais d’aborder  les principaux changements qui sont venu avec ma pratique de l’agilité.

La démarche itérative induit deux nouvelles exigences : la testabilité et la robustesse au changement.

Architectures testables
La démarche itérative fait grandir l’effort de test de façon exponentielle. Pour ne pas tomber dans le travers qui consiste à ne plus tester et donc à diminuer la qualité du produit, le succès des méthodes agiles est fortement lié à une politique de tests automatiques.

L’impact sur l’architecture est le suivant :

  • Utilisation d’interfaces pour la communication entre les objets
  • Bien définir les rôles de chaque composant et les faire le plus petit possible
  • L’utilisation du Test Driven Developpement influe directement sur la testabilité de l’architecture tout en restant centrée sur le service qu’elle doit remplir. Vraiment une expérience intéressante qui nous fait poser les questions de manière différente.

Architectures robustes au changement

Une des valeurs du manifeste agile est « Responding to change over folowing a plan ». Il faut donc des architectures qui permettent de réagir favorablement à ces changements.

Voici quelques principes qui renforcent la réactivité au changement :

  • Utilisation des design pattern
  • Utilisation d’interfaces
  • Limiter  l’interdépendance des composants
  • Écrire des classes petites avec des rôles bien définis
  • J’enfonce peut être une porte ouverte mais : abolir le copier/coller (il n’y à pas pire que du code dupliqué quand on doit réagir au changement)
  • Faire du Refactoring dès que possible. Cette pratique est largement facilitée si elle est accompagnée d’une politique de test automatique.

Conclusion

Le sujet est vraiment vaste et je ferais certainement d’autres articles sur le sujet. Pour n’en retenir que deux points :

  • Choisir les architectures qui permettent d’aller vers la plus grande couverture de test (quand les contraintes de performances le permettent)
  • Vraiment séparer les rôles. Souvent on veut développer vite et on mélange tout (par exemple la manipulation des données avec le code de l’IHM)

Fiche de lecture : Scrum and XP from the Trenches

Contexte :

J’ai lu ce livre après plus d’un an de pratique de la méthode Scrum. Après avoir assisté à une conférence de l’auteur à l’Agile Tour 2009 de Grenoble, je me suis dis que sa lecture manquait à ma culture.

Attentes :

Ce livre est présenté comme un retour d’expérience sur les méthodes Scrum et XP. En lisant ce livre je voulais confronter nos pratiques avec celles de l’auteur et avoir de nouvelles idées quant à la mise en œuvre de Scrum.

Résultat :

Ce livre est étonnant par la richesse des sujets abordés par rapport à son nombre de pages. Le travail de synthèse de l’auteur est vraiment performant. Beaucoup de problématiques sont abordées parmi lesquelles :

  • Comment et pourquoi communiquer à toute l’entreprise
  • Favoriser la constitution d’équipes avec une approche fonctionnelle
  • Comment intégrer les testeurs
  • Comment gérer la lourdeur des réunions de planning
  • etc..

Ce que j’ai changé après avoir lu ce livre :

Jusqu’à présent je pratiquais le calendrier suivant :

Jeudi 09h30 – 11h : Démo
Jeudi 11h-12h : Rétrospective
Jeudi 14h – 17h : Sprint planning (avec une seule pause)

Autant dire qu’on avait du mal à boucler les réunions de planning. Le travail à fournir était très intense et l’équipe sortait fatiguée et peu satisfaite.

L’auteur fait deux propositions pour alléger cette réunion :

  • Laisser du temps entre la rétrospective et la réunion de planning.
  • Prioriser le travail à fournir lors de la réunion et commencer le sprint sans avoir le découpage en tâche complet

Je n’ai pas encore pu expérimenter la première proposition, mais la deuxième s’avère payante : le découpage en tâche se fait pendant le sprint. La visibilité sur le sprint est moins bonne mais l’équipe reste concentrée et efficace.

Conclusion :

Ce livre est à la hauteur de sa réputation. Vraiment très riche en enseignement. Par contre je pense qu’il faut connaître un peu le contenu de la méthode pour profiter pleinement du retour d’expérience.

Le livre est disponible gratuitement sur le site d’infoQ.

Illustration d'une organisation en "Silo" : l'effet Dalton

J’ai beaucoup aimé la présentation à propos du travail d’équipe de Henrik Kniberg lors de sa présentation « What’s Agile? » à l’agile tour 2009 de Grenoble :

L’esprit d’équipe ce n’est pas :

  • un travail en silo : où une à plusieurs personnes sont responsables de la production d’un sous ensemble de produit
  • un ensemble de personnes dans un open space : qui vont dans des directions différentes

Mais :

  • un ensemble d’individus qui poussent dans la même direction en même temps.

Pour illustrer la problématique du travail en silo voici une petite histoire que j’ai vue maintes fois.

Les personnages sont : Joe & William. Ils travaillent tous les deux à l’élaboration d’un même produit. Joe est responsable du module IHM et William de la partie « moteur métier ». Joe et William intègrent régulièrement leur travail sur le produit.

Un jour Joe découvre un bug! Il remue ciel et terre pour identifier le problème. Ouf, cela ne concerne pas son module d’IHM. Par professionnalisme, Joe continue d’investiguer et cible que le problème vient du module dont s’occupe William, il va même jusqu’à diagnostiquer précisément le problème et trouver une solution.

Joe va alors se confronter à plusieurs sources de perte de temps :

  • Ce n’est pas Joe qui est responsable du module « moteur métier ». Il ne peut donc pas corriger le problème lui même.
  • William est le seul à avoir une vision de l’ensemble du module.
  • Joe doit convaincre William que le problème est dans son module.
  • Joe doit expliquer à William la solution qu’il a trouvée.
  • William doit comprendre la solution que Joe a trouvée.
  • etc…

Bref je suis souvent témoin de cette pratique. Je suis déçu par tout ce temps et cette énergie gâchés. Pour moi, une organisation en silo favorise la culture de la faute et les réflexes qui vont avec au détriment de l’efficacité. L’individu est frustré car il n’a que la vision des silos qui l’entourent.

La responsabilité collective et le partage de compétences ont souvent mauvaise presse quant à l’efficacité; mais je reste persuadé que le temps et l’énergie dépensés dans la collaboration sont payants à moyen voire à court terme. Par contre le changement de culture nécessaire est parfois douloureux.

Retour d’expérience : histoire de la fonction PIPO…

On me demande souvent si les méthodes agiles sont plus performantes que les approches traditionnelles. C’est difficile de répondre à cette question mais je raconte souvent l’histoire suivante :

On avait deux produits A et B. Le produit A avait été jugé plus prioritaire que le produit B. Une partie des fonctions de A étaient réutilisables dans B.

En montant l’équipe Scrum sur le produit A, nous avions réalisé un « product charter » qui affichait les principaux jalons du produit dont le premier était un salon à Las Vegas. Les priorités des items du backlog étaient évaluées en fonction de ce salon.

A la 4ème itération, le product owner arrive en réunion de sprint planning et fait remonter la priorité d’un item qui était tout en bas du backlog pour qu’on le traite dans l’itération suivante. J’appelle cet item « la fonction PIPO » pour la suite de l’histoire 🙂.

Voici l’échange entre l’équipe et le product owner ce jour là :

Équipe : Tiens !? Pourquoi cet item remonte ? Il n’a pourtant rien à voir avec notre jalon n°1.

Product Owner : j’ai croisé « chef » qui m’a dit de vous faire implémenter cet item qui est très important pour une affaire basée sur le produit B.

Equipe : Le produit B ? Mais personne ne travaille sur ce projet. L’affaire est vraiment importante ?

Product Owner : Oui, la date est même antérieure à notre salon à Las Vegas.

En fait l’affaire du produit B était plus prioritaire que le produit A. Nous avons basculé toute l’équipe sur le produit B pour nous donner toutes les chances de réussir. Le produit B nécessitait beaucoup de travail d’intégration pour être livrable. On a eu juste assez d’itérations pour livrer le produit à l’heure et remporter l’affaire… sans la fonction PIPO !!!

Si nous n’avions pas été organisé en Scrum, nous aurions parallélisé les développements, développé la fonction PIPO et su que beaucoup plus tard qu’il fallait un gros effort pour produire le produit B. Je pense que ce jour là, cette façon de travailler a sauvé l’affaire.

Ce blog est agile !

L’objectif de ce blog étant de publier des réflexions et retours d’expériences sur la mise en place des méthodes agiles, j’ai envie d’essayer de mettre en place certaines pratiques dans la gestion de ce blog.

Voici ce que je mets en place :

  • Les utilisateurs du blog sont modélisés sur une page dédiée « Profils des utilisateurs« . Je choisis une page plutôt qu’un article car elle pourrait évoluer au cours du temps
  • Le backlog est accessible et mis à jour régulièrement ici

Plus tard  je voudrais :

  • Définir un modèle de valeur métier qui permettra de gérer les priorités des articles à publier
  • Mesurer un retour sur investissement fictif basé sur le nombre de commentaires postés sur les articles
  • Délivrer des articles toutes les semaines

En appliquant ces méthodes j’espère atteindre deux objectifs :

  • Augmenter la satisfaction utilisateur en publiant des articles pertinents
  • Donner un exemple pratique

Petite déception : un des gains qu’offre l’agilité réside dans le travail d’équipe et la communication. Comme je commence tout seul, une partie de la méthode ne peut être exploitée. Cela dit je suis prêt à faire un blog collaboratif  (faites moi part de votre envie participer dans la page feedback et suggestions).

Fiche de lecture "User stories applied" de Mike Cohn

Contexte :
J’ai lu ce livre juste après la formation de 2 jours sur SCRUM dispensée par ObjetDirect et Alexandre Boutin.
A l’époque nous étions en pleine mise en place de la méthode et notamment l’écriture des stories du backlog.

Ce que je voulais trouver en lisant ce livre :
Mon attente était d’améliorer notre façon de travailler avec les user stories. J’avais surtout un problème de granularité : j’avais du mal à dire si une histoire était suffisamment petite ou trop vague.
Je cherchais un certain formalisme pour mieux gérer le backlog.

Les réponses apportées par le livre :
Ce livre aborde les problèmes de façon très concrète. J’y ai trouvé la résolution de plusieurs problématiques que j’avais déjà rencontrées et mal résolues. Par exemple : comment découper une story en plusieurs pour qu’elles rentrent dans une itération.

Il explique pourquoi favoriser une découpe verticale plutôt qu’en couches.

Le travail pour se rapprocher de l’attente utilisateur est abordé : quand on n’a pas un utilisateur final sous la main, on fait avec ceux qu’on a. L’auteur balaye les différents corps de métier et analyse les travers de chacun.

D’autre part la lecture de ce livre permet de comprendre la philosophie des user stories : l’histoire utilisateur formalise la discussion entre l’équipe de développement et l’équipe des utilisateurs.

Le livre finit par un exemple d’application que je n’ai pas lu mais toute la première partie est vraiment très riche. Après avoir lu ce livre ma façon de travailler dans l’élaboration du backlog a vraiment changé.

Je recommande vivement la lecture de ce livre à tous ceux qui veulent jouer un rôle dans l’élaboration des histoires utilisateurs.

Bonjour tout le monde !

Je suis tombé dans l’agilité au séminaire Agile Tour 2008 de Grenoble. J’ai assisté à 4 conférences qui m’ont laissées bouche-bée devant la différence de méthode entre les « agilistes » et mon approche traditionnelle en Cycle V. Après quelques mois d’incubation j’ai enfin pu mettre en place la méthode SCRUM sur un projet. Enthousiaste, au bout de 6 mois d’expérimentation, la direction a décidé d’étendre la méthode à plusieurs équipes. Il me semble intéressant de partager mes retours d’expériences/réflexions dans ce blog.

Les sujets que j’aborderais seront entre autre :

  • quels sont les obstacles que j’ai rencontré dans la mise en place des méthodes agiles?
  • les différents liens et livres qui traitent de l’agilité
  • quels outils pour quelles métriques?
  • Qu’est-ce que l’agilité?
  • Le design itératif
  • Travail avec le marketing
  • Mise en place des méthodes eXtrem Programing
  • etc…

N’hésitez pas à me faire part de vos questions/suggestions/remarques pour alimenter ce blog.