mars 2009Monthly :

in Ergonomie logicielle

En réaction à la Charte des droits des utilisateurs

Charte des droits des utilisateurs

  • L’utilisateur a toujours raison. S’il existe un problème avec l’utilisation du système, il provient du système, pas de l’utilisateur.
  • L’utilisateur a droit à la facilité lors de l’installation de logiciels et d’équipement informatique.
  • L’utilisateur a droit à des systèmes faisant exactement ce qu’ils sont censés faire.
  • L’utilisateur a droit à des instructions claires, simples et précises lui permettant de comprendre et d’utiliser un système assurant l’atteinte de ses objectifs.
  • L’utilisateur a droit au contrôle absolu du système, de même qu’à être capable d’obtenir l’attention du système sur demande.
  • L’utilisateur a le droit d’être informé par le système sur son état par rapport à la tâche qu’il effectue et par rapport au progrès accompli vers la complétion de la tâche, de façon claire, compréhensible et précise.
  • L’utilisateur a le droit d’être informé clairement quant aux spécifications requises pour utiliser pleinement tout système informatique.
  • L’utilisateur a le droit de connaître les limites des capacités du système.
  • L’utilisateur a le droit de communiquer avec les fournisseurs de technologies et de recevoir des réponses utiles et intelligentes à toutes ses questions.
  • L’utilisateur doit être le maître de la technologie, non l’inverse. Tout système doit être intuitif et naturel lors de son utilisation.

Ce n’est pas la première fois que je lis à propos de la “Charte des droits des utilisateurs” (A Computer User’s Manifesto traduit librement par Alain Robillard-Bastien). Initialement j’étais d’accord avec la charte et je tentais de la faire connaître à mes collègues. Maintenant, avec le recul apporté par une bonne année depuis ma précédente lecture, je dois avouer que je ne suis plus autant d’accord. Je pense même que certains éléments nuisent à l’adoption des pratiques d’utilisabilité par les équipes de développement.

D’abord, la charte parle de l’utilisateur. Pourtant “l’utilisateur” n’a pas de forme précise, “l’utilisateur” est malléable à la réalité désirée. Ainsi, au cours du développement d’un logiciel, l’équipe de développement pourrait s’imaginer que l’utilisateur est un expert du plus haut calibre et faire des choix de conception cohérent avec ceci. Ils respecteraient, en quelque sorte, la charte pour cet utilisateur, sans pour autant concevoir un système qui soit utilisable par l’ensemble des utilisateurs réellement ciblés. Ce qui manque à cette charte, c’est un préambule aidant les équipes à détailler qui sont les utilisateurs ciblés et à appliquer les concepts présentés avec discernement selon leur contexte.

Je comprends bien le fond des principes énoncés. Par contre, je pense qu’en mentionnant que l’utilisateur a toujours raison, l’auteur suppose que l’utilisateur comprend toujours ce qu’il fait, qu’il comprend toujours le système qu’il tente d’utiliser et qu’il n’est jamais distrait. Hors, pour avoir observé des utilisateurs dans l’utilisation de systèmes, j’ai pu constater qu’ils n’ont pas toujours raisons. Ils explorent parfois les possibilités offertes par le système, sans réellement comprendre ce qu’ils font. Je pense aussi que d’imaginer un utilisateur avec un contrôle absolu sur le système qu’il utilise n’est pas réellement souhaitable. Il y a généralement des limites sur le contrôle que l’utilisateur peut avoir sur le système. Ces limites sont mises en place pour empêcher l’utilisateur de se nuire à lui-même.

Enfin, je crois que les fondements de cette charte sont valides. Par contre, elle demande un peu de mise en contexte pour être bien comprise et ne pas effrayer les équipes de développement qui voudrait mettre en place des pratiques d’utilisabilité.

in Scrum

Quand la mêlée quotidienne sonne faux.

- Hier j’ai travaillé sur l’import/export et je vais continuer aujourd’hui. Je n’ai pas de difficultés…”

Entendez-vous les violons stridents qui annoncent un meurtre? Ils annoncent la mort de la mêlée quotidienne. Même si on a déjà posté sur ce sujet sur le blog de Pyxis, j’en rajoute une couche.

Le problème avec l’intervention citée plus haut, c’est qu’elle n’a aucune valeur ajoutée; j’aurais pu obtenir la même information en regardant le tableau des tâches. Si vous tenez votre mêlée en face de votre tableau des tâches et de votre graphique d’avancement, et que les participants continuent de tenir de mêlées aussi insipides, vous gaspillez tous les jours 15 minutes de temps de travail. Au moins, vous aurez réduit à 15 minutes le massacre quotidien.

Quel est le contexte d’une mêlée? Ça ressemble un peu à un article de journal; je veux savoir ce qui a progressé depuis hier à propos des élections américaines. Si rien n’a changé, je ne tiens pas à le savoir. Dans le cadre d’une itération, en tant que membre impliqué, je veux savoir où nous en sommes et je veux partager avec mes coéquipiers mes contributions, mes observations et les risques que j’ai identifiés. Ce n’est pas moi le sujet de cette rencontre, mais notre engagement. En quoi ma journée a contribué au projet? En quoi j’ai affecté NOTRE itération? En quoi j’ai amélioré la qualité de NOTRE produit? Qu’est-ce qu’ON peut faire pour adresser un obstacle?

- Mais Mathieu, je n’ai rien fais sinon de modifier les scripts d’import pour tenir en compte les accents qui n’étaient pas supportés. C’est un travail qui n’était pas prévu et a été vite réglé. Maintenant je dois finir l’import.

Voilà!

Si vous avez de la difficulté à secouer vos troupes, changez la formulation de vos questions ou jetez-les par la fenêtre! Préférez une question qui s’adresse à tous le groupe sur la progression de votre itération.
in Sur le terrain

Vers une Administration Agile?


Hier matin, j’ai entendu le médiateur de la république française qui parlait de son rapport publié aujourd’hui, dans une émission de radio nationale sur le service public.

Voici un commentaire de ce rapport sur les Echos:
Déficits d’information, réponses aléatoires, sentiment d’arbitraire : dans son dernier rapport publié hier, le médiateur de la République, Jean-Paul Delevoye, ne ménage pas ses critiques vis-à-vis de l’administration. A l’heure de la RGPP (révision générale des politiques publiques) et de la modernisation des services publics, il semble que les effets positifs pour les usagers tardent à se concrétiser. Jean-Paul Delevoye a notamment insisté, hier, sur le manque d’attention porté aux réclamations des usagers : « Ce n’est pas une question de moyens, mais plutôt de culture. La gestion des réclamations est cruciale pour améliorer la qualité de service. Ce qu’ont très bien compris les entreprises privées, mais pas encore l’administration. »

D’après les propos que j’ai entendu, le médiateur de la république a reçu cette année 65 000 courriers des citoyens français. 65% concernent des demandes d’information, des réponses erronées ou contradictoires données par les administrations. Il s’interroge “Pourquoi de nos jours, à l’ère de l’information, c’est si difficile pour le citoyen de connaître ses droits?”. D’après lui, plus que jamais, les citoyens ont besoin de réponses, ont droit à l’information!

La journaliste de l’émission lui demande

“Et les fonctionnaires? Peuvent-ils être plus performants?”

Sa réponse est à peu près la suivante:

“Les employés de l’état sont les autres victimes du système en place; les lois sont trop compliquées, il n’y a pas assez de délégation, de droit à l’erreur; on ne fait pas appel à l’intelligence et au bon sens des agents, mais plutôt à leur capacité à suivre des procédures trop lourdes; il y règne la culture de la faute, et non pas celle de l’erreur; le législateur doit simplifier les textes. Ce qui compte c’est la qualité du service, la satisfaction des utilisateurs, et cela passe par changer la culture en place.”

Hum… voudrait-il faire du refactoring des lois existantes? Voudrait-il rendre le système moins hiérarchique? Laisser plus d’autonomie aux employés? Voudrait-il rendre “lean” notre administration? Houla… J’avoue que ce genre de discours, ça me fait du bien, même si ce n’est pas pour demain ;-)

in Agile, Nouvelles et événements

Esprit Agile à Marseille

Hier, mardi 17 mars, je me suis rendu à la soirée de lancement de la communauté agile sud-est à Marseille « Esprit Agile ». En tout 80 personnes étaient présentes dans l’amphi de l’Ecole Centrale Marseille : réunir tout ce monde sur le sujet, en soirée, c’est déjà un beau succès! Le programme s’est déroulé à bâton rompu et avec passion : introduction à l’agilité, description de Scrum, description de eXtreme Programming puis retour d’expérience ViaXoft, le tout ponctué d’applaudissements et de questions.

Environ 25% du public avait déjà « pratiqué » de l’agilité. La présentation d’eXtreme Programming m’a fait me rappeler que XP n’est pas « juste » un ensemble de pratiques d’ingénierie, comme on le présente généralement, mais bien une méthodologie à part entière, avec de fortes similitudes – il est vrai – avec Srum. Thierry a bien insisté sur les aspects humanistes de l’Agile, ça m’a plu! Le terme « Développement responsable », ça m’a bien plu aussi. Le retour d’expérience, quand à lui, m’a un peu frustré, time boxing oblige, j’aurai voulu en savoir plus: Eric Barthelemy de la société ViaXoft nous a présenté très humblement les choses qui ont bien marché, mais surtout les «difficultés» rencontrées et les « adaptations » effectuées durant leur mise en place agile pour le développement de leur produit interne.

Parmi les questions posées dans l’auditoire, on a senti une certaine tension lorsque la question des « aspects financiers » fut lancée : c’est un peu déconcertant de devoir justifier des bienfaits financiers d’une démarche, lorsqu’on a passé près d’une heure à expliquer que la principale motivation de cette démarche était justement d’augmenter la valeur ajoutée du produit réalisé… mais cette défiance est légitime tant on est formatés à suivre une méthode sans trop s’interroger sur son efficacité.

J’ai retrouvé Jean-Marie Daumas avec plaisir, on a bien échangé.. Ce fut super de rencontrer enfin Claude et Thierry, en chair et en os, autrement que par blogs interposés! Je fis aussi la connaissance de Karine Mazet, correspondante du French Scrum User Group dans la région PACA et ScrumMaster chez ViaXoft. Surprise pour moi, il y avait des agilistes praticiens venus de Montpellier pour cette soirée! Comme quoi, beaucoup de régions étaient présentes ce soir-là!

Pour conclure, souhaitons que l’Esprit Agile se diffuse le plus possible. Pour cela, on a besoin de bras, beaucoup de bras, pour faire du vent, pour agiter les consciences ;-)

in Scrum

Quel est le profil d’un bon ScrumMaster ?

Bien sûr, en premier lieu, un ScrumMaster est convaincu de la valeur de Scrum en tant que prisme à travers lequel il appréhende les évènements, les situations.

Scrum est très simple à décrire et très difficile à mettre en oeuvre.

Un bon ScrumMaster comprend en quoi Scrum est difficile. Défis humains, défis organisationnels, défis techniques. Lesquels seront les plus pénalisant pour le projet ? Cela dépendra des contextes. A chaque projet cela sera différent, plein de surprises, enrichissant.

Un bon ScrumMaster aide tout le monde à tirer le meilleur profit de Scrum. Au delà de sa connaissance pointue de Scrum, la forme de cette aide peut varier du tout au tout selon les contextes. Un bagage technique aidera-t-il à déceler une incompréhension entre deux membres d’équipe ? Peut être. Une attitude enjouée favorisera-t-elle la motivation pendant les mois d’hivers ? Peut être. Un naturel curieux permettra-t-il d’apprendre par hasard une information capitale à la machine à café ? Peut être. En se concentrant sur les aspirations personnelles des gens, un ScrumMaster aidera-t-il à favoriser le climat de confiance si chère à l’émergence d’une équipe auto-organisée ? Peut être. Peut être cette fois-ci. Sans doute pas à chaque fois.

Aspirer à ce que tout le monde tire le meilleur profit de Scrum c’est aussi reconnaître que Scrum ne se met pas en place en 1 jour. Patience. Gardons-nous de juger hâtivement un ScrumMaster en regardant “son” Scrum sans lui en parler. Il a sans doute lui aussi un backlog d’adoption, une stratégie incrémentale de mise en place des pilliers de Scrum, qui sont comme une petite musique dans sa tête :
- équipe auto-organisée
- backlog priorisé
- livraison d’incréments terminés à chaque fin d’itération
- processus empirique

in Agile

Approches Agiles dans les grandes entreprises

Quels sont les enjeux rencontrés par les grandes organisations lors d’une transition vers les approches agiles? Comment convaincre les organisations? La transition est-elle toujours possible?

Voici le témoignage de François Beauregard sur Visual Studio Talk Show, président de Pyxis Technologies qui nous livre sa vision actuelle des choses après plusieurs années de pratiques.

Le podcast est ici. Bonne écoute!

in Développement logiciel

Les Dojos de Développement (Coding Dojo)

L’amélioration continue est un concept clé des pratiques agiles. Les livres, les blogues et les formations sont de bonnes façons de se perfectionner. La tenue de dojos est une autre façon ludique et motivante de partager et se perfectionner sur le développement logiciel.

Les Dojos

Si je veux apprendre le Judo, je vais m’inscrire au dojo du coin et y passer une heure par semaine pendant deux ans, au bout de quoi j’aurai peut-être envie de pratiquer plus assidûment.

Si je veux apprendre la programmation objet, mon employeur va me trouver une formation de trois jours à Java dans le catalogue 2004.

Cherchez l’erreur.

Laurent Bossavit

Se donner des périodes pour pratiquer la programmation nous éveille à de nouvelles techniques et nous fait découvrir de nouveaux langages sans amputer sur nos mandats professionnelles. De le faire en groupe nous encourage et nous aide à nous défaire de nos pratiques routinières.

Références

Statégies

  • Recommencer à zéro: on ne cherche pas vraiment à résoudre un problème, mais plutôt à pratiquer. Les problèmes rencontrés dans un cas simple réalisable en une heure seront similaires à ceux que l’on rencontre dans la réalisation de plus gros projets.
  • Prévoir une courte pause au milieu de l’atelier pour inspecter et ajuster l’exercice en cas de besoin. On pourra y définir de nouvelles règles ou s’entendre sur la ligne directrice de conception.

Foire aux questions

  • Où peut-on trouver des exemples de défis?

Un défi populaire dans la communauté, c’est le fameux pointage du jeu de quilles . Le catalogue du site Coding Dojo  est une bonne source d’inspiration. Pragmatic Dave propose également d’autres katas .

Le défi se doit de rester simple et réalisable dans un court laps de temps. Écrire un convertisseur de chiffres romains est un bon exemple de défi raisonnable.

  • Quel est le but du dojo si ce n’est pas la résolution du défi?

Le but est de se perfectionner dans une discipline du développement logiciel. On peut perfectionner une pratique comme le TDD ou l’orienté-objet, un langage comme Ruby, ou encore l’utilisation d’un framework comme Rails.

  • A quel moment on doit changer le binôme au commandes d’un randori?

Une boîte de temps est sûrement la technique la plus simple (ex. entre 5 et 7 minutes). On aussi peut utiliser le cycle normal du TDD; chaque binôme est responsable de faire passer un nouveau test.

Le Coding Dojo de Pittsburg a une autre approche; tous les participants binôment simultanément sur le défi et l’atelier se termine par une rétrospective de groupe.

in Agile, Management

Adoption de l’agilité et changement culturel

Dans l’interview récente que j’ai donné au VSTS je parle du changement culturel nécessaire pour adopter l’agilité. Je parle également de mon parcours des sept dernières années et du moment où je cherchais à convaincre des bienfaits d’utiliser une approche Agile. Après un certain temps j’ai décidé pour préserver mon énergie (et ma santé mentale!) de me rendre disponible sans chercher à convaincre. Il semble que Tom Poppendieck m’encourage à attendre!

The constraints on when agile approaches can be used are primarily organizational and cultural, not project types. Some organizations and some contexts are incompatible with agile/lean thinking. When these organizations eventually come up against a strong competitive threat, they will fail to meet it unless they change their values and mindsets. Lean/Agile is at it’s foundation, the fourth industrial paradigm, the first being Craft Production, Factory Production with machine tooling, Automation and Taylorism. These come along every hundred years or so and take a few decades to work through. Each paradigm includes the preceding one and makes it dramatically more productive. There is no need to sell agile except to organizations that want to survive long term. If they don’t see the threat/opportunity they cannot succeed with agile or lean nor can they sustain economic viability in the long run.

Tom Poppendiek the guy behind “Lean Software Development”

Vous en pensez quoi ?