Le Texas Hold’em Poker est très à la mode, et je n’ai pas pu résister à la tentation de m’inscrire à PokerStars. J’étais tellement motivé de m’inscrire que j’ai passé par dessus le piège que m’a tendu PokerStars : “* – Optional fields”.
Les champs optionnels sont marqués d’un astérisque alors que le standard est plutôt de marquer ainsi les champs obligatoires. En respectant mes habitudes, j’ai d’abord rempli tous les champs marqués d’un astérisque. C’est seulement à l’affichage d’un message d’erreur me demandant d’inscrire une ville que j’ai réalisé qu’ils brisent le standard.
Auriez-vous fait la même erreur dans le même contexte?
Venez retrouver le Pyxis Snow Team durant le 24h Tremblant, encouragez-nous pendant nos descentes et profitez de votre visite pour assister à des spectacles. La programmation est incroyable et met en vedette entre autres : Jonas, Yann Perreau, Boom Desjardins, Izia, Dj Champion et ses G-Strings, Stefie Shock et Ariane Moffatt!
Il est encore temps de supporter l’équipe et par le fait même la Fondation Centre de cancérologie Charles-Bruneau en faisant un don au pyxis-tech.com/24h-tremblant.
Au plaisir de vous voir à Tremblant!
Le 24h Tremblant, cette année à sa 9e mouture, recueille plusieurs centaines de milliers de dollars pour les enfants malades ou défavorisés. En effet, la Fondation Centre de cancérologie Charles-Bruneau sera bénéficiaire de l’événement pour une 6e année.
Cette année le Pyxis Snow Team a décidé de participer à l’événement pour contribuer à amasser des fonds pour la recherche. L’équipe est composée de 6 Pyxissiens (Dominic Danis, Jean-François Proulx, Marie-Eve Trempe, Sami Dalouche, Tremeur Balbous et Yvon Frongillo), qui vont descendre les pistes de ski du Mont-Tremblant en relais pendant 24 heures les 12 et 13 décembre.
Soutenez notre équipe et la Fondation en faisant un don à http://pyxis-tech.com/24h-tremblant/. Venez aussi nous encourager durant cette fin de semaine du 12-13 décembre 2009. Vos cris et sourires nous motiverons dans nos descentes.
J’aime le magazine Wired, je le lis religieusement depuis 2005. Tous les articles ne génèrent pas le même niveau d’intérêt pour moi, certains sont lus distraitement. Par contre, certains autres se révèlent être inspirants. Comme celui de l’édition d’octobre 2009 à propos de Netflix.
On y décrit l’entreprise, sa croissance, son modèle d’affaires et son modèle de gestion.
A quiet, hands-off leader, he sets the tone and objectives and lets his employees figure out how to execute them. His main directive is that everyone act like an adult: Netflix has no vacation policy (take as much as you need, when you need it), pay is flexible (stock or cash, your choice), and though firings are unusually common, severance checks are unusually generous. Hastings is comfortable creating his own rules for how to run a business; you don’t see any management tomes in his office. In fact, he doesn’t even have an office. The CEO prefers to stroll around, a ThinkPad in hand, pitching camp in an empty conference room or huddling in an engineer’s cubicle to whiteboard some formula.
source: WIRED MAGAZINE: 17.10
Un modèle de gestion responsabilisant. Les employés sont des adultes et sont suffisamment responsables pour décider eux-mêmes comment mettre en œuvre les objectifs de l’entreprise et la faire avancer.
À Pyxis, nous construisons un modèle similaire et lorsque nous le décrivons, la réaction est parfois un regard quelque peu incrédule. “Ton patron ne te dit pas quoi faire!?!” Et bien non! Mon “patron” pyxissien ne me dit pas quoi faire, il m’encourage à prendre une décision réfléchie et de façon responsable.
Votre patron vous encourage-t-il à prendre des décisions ou bien est-il LE responsable ?
Durant le développement de logiciels, les équipes peuvent prétendre qu’ils appliquent des bonnes pratiques d’utilisabilité à leur projet. Par contre, il y a des odeurs, des habitudes, qui indiquent le contraire. Je vous énonce ici quelques-unes de ces odeurs que j’ai rencontrées.
Si vous reconnaissez certains comportements de votre équipe, n’ayez pas peur! Vous pouvez éliminer ces odeurs. Par la suite, vous verrez que rapidement vos utilisateurs seront plus satisfaits des logiciels que vous produisez.
Odeurs
- développer sans feedback des utilisateurs
- développer basé sur des design d’interfaces faites par des concepteurs graphiques
- développer une interface-utilisateur orientée développeur/debug
- rédiger de la documentation d’utilisation exhaustive
- accepter des excuses…
- …de la part des designers pour ne pas travailler de facon incrémentale
- …de la part du PO pour ne pas prendre les utilisateurs en considération
- …de l’équipe de développement pour négliger les pratiques d’utilisabilité
Réponse simple, oui!
En tant que tel, il n’y a pas de mécanismes dans les pratiques d’utilisabilité qui ne permettent pas de s’exécuter dans un contexte Agile. Comme ce sont des pratiques, le contexte d’application revient au choix de l’équipe.
Autant les pratiques d’utilisabilité que les méthodes Agiles font appel à des rétroactions fréquentes provenant des utilisateurs. Ceci permet de s’assurer que les interfaces respectent les critères d’utilisabilité, qu’elles permettent aux utilisateurs d’atteindre leurs objectifs et qu’elles répondent bien aux attentes énoncées par le PO. Ensuite, la conception et la validation des interfaces utilisateurs s’effectue de façon itérative et incrémentale. Cette approche contribue à augmenter l’efficacité et l’efficience des utilisateurs puisqu’elle intègre à chaque itération des considérations d’utilisabilité reflétant la réalité des utilisateurs visés par le logiciel.
Pour bien arriver à arrimer ces pratiques, il y a nécessité de faire un peu d’éducation à tous les participants du projet. Ceci afin que chacun voit et comprenne qu’il y a possiblité de travailler de façon itérative et incrémentale, et ce en ayant un rythme soutenu et soutenable.
Pour le PO
- voir de la valeur dans la conception de maquettes et l’exécution de tests d’utilisabilité
- associer de la valeur aux éléments d’expérience utilisateur
- ajouter les facteurs de risques concernant l’utilisabilité à la vision du projet
Pour l’équipe de développement
- intégrer les concepteurs d’interfaces/d’interactions/spécialiste en utilisabilité aux itérations
- questionner l’utilité du manuel d’utilisation du logiciel. Considérer qu’un manuel exhaustif ne peut pas remplacer une bonne interface utilisable
Pour les concepteurs d’interfaces/d’interactions/spécialiste en utilisabilité
- élaborer un squelette des interfaces-utilisateurs/navigation durant le sprint de démarrage (sprint 0)
- participer aux sprint plannings/retro pour conscientiser l’équipe aux problèmes qu’il anticipe ou pour évaluer le travail fait
- travailler de facon itérative et incrémentale
- intégrer l’équipe de développement à chaque itération
Bref, ce qu’il faut en comprendre c’est que tous ceux qui contribuent au projet doivent s’y commettre. Nous ne questionnons plus le fait que les développeurs sont des cochons du Scrum. Il faut maintenant voir les concepteurs d’interfaces/d’interactions/spécialiste en utilisabilité aussi comme des cochons qui se commettent au succès du projet.
Vous pouvez maintenant suivre nos activités sur Twitter à l’adresse twitter.com/pyxistech. Vous y trouverez des événements où venir nous rencontrer, l’ajout de nouvelles dates de cours à notre calendrier de cours des annonces à propos de nos produits et autres tweets sur des sujets d’intérêt pour Pyxis.
Hier soir, en lisant des articles sur l’utilisabilité, j’en ai trouvé un qui semblait initialement intéressant. Le titre m’a accroché; How Test-Driven Development Increases Overall Usability. Comme c’était la première fois que je voyais les deux sujets abordés dans un même article je n’ai pas pu m’empêcher de le lire.
Je vous laisse le temps d’aller le lire, revenez-moi après!
Suite à la lecture j’ai comme un sentiment de vide. J’ai l’impression qu’on n’aborde pas le thème d’utilisabilité et que l’article ne m’a pas livré ce qu’il me promettait. L’impression qu’on lance des concepts d’utilisabilité, sans pour autant décrire le lien avec TDD, et ce, seulement pour respecter le titre. Bref, je ne comprends toujours pas comment le TDD peut améliorer l’utilisabilité d’une application. Après la lecture, le comprenez-vous, vous?
En discutant avec des collègues à propos du développement de logiciels utilisables, je me suis rendu compte que le terme “logiciel utilisable” porte à confusion. Le fait de dire qu’un logiciel est utilisable n’implique pas nécessairement qu’il respecte des critères d’utilisabilité. Du moins, pas pour tout le monde. Pour moi, c’est ce que ça implique. Mais je baigne dans le domaine de l’ergonomie logicielle et pour moi un logiciel dit utilisable fait référence à son utilisabilité, selon le sens donné dans la norme ISO 9241, soit :
Degré selon lequel un produit peut être utilisé, par des utilisateurs identifiés, pour atteindre des buts définis avec efficacité, efficience et satisfaction, dans un contexte d’utilisation spécifié.
Lors de la discussion qui m’a inspiré ce billet, mes collègues comprenaient plutôt le terme comme étant simplement la possibilité de se servir, voire utiliser, un logiciel pour remplir une tâche. Ceci, en soi, n’est pas faux. Incomplet, mais pas faux! Le fait de pouvoir remplir une tâche avec un logiciel est un critère de base de l’utilisabilité. Qu’il soit intuitif, simple ou agréable à utiliser, si le logiciel ne permet pas à l’utilisateur d’arriver à ses fins, il n’est pas utile et encore moins utilisable.
Si je reprends la définition de la norme ISO, je distingue quelques éléments qui permettent d’établir des critères d’utilisabilité. En effet, on ne peut pas déclarer un logiciel comme utilisable seulement parce qu’un utilisateur atteint son objectif. Il est plutôt utile de voir cette définition de l’utilisabilité comme un ensemble de critères qu’on applique à un logiciel lors de l’évaluation de sa qualité ergonomique.
