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.
Je suis en mandat avec une équipe de développement qui ne peut d’emblée adopter toutes les pratiques de Scrum. Le domaine d’affaire de l’application est si complexe qu’il est difficile pour le PO de présenter à l’équipe l’équivalent de quelques semaines de travail. Pour le moment, nous avons décidé de contourner le problème sans se priver des valeurs d’amélioration et de collaboration de l’Agilité en adoptant la méthode Kanban. Isabelle Therrien m’a référé un très bon article de Henrik Kniberg à propos du Kanban versus Scrum. C’est la meilleure vulgarisation de la méthode que j’ai lu à ce jour. Contrairement à d’autres articles, il explique bien le Kanban comme une méthode Agile à part entière, et pas seulement une adaptation de Scrum.
L’article explique notamment que: – Scrum est dirigé par l’engagement et les boîtes de temps alors que le Kanban est dirigé par un flux tendu et le périmètre. – Kanban permet la ré-introduction de spécialités impossibles à diffuser au sein d’une équipe pluri-disciplinaire – Kanban permet au PO de planifier les items à développer à l’unité alors que Scrum permet la planification d’items en lot
Attention! Kanban est moins restrictif que le Scrum. Il faut prendre garde de respecter l’esprit Agile.
Avez-vous des mises en garde ou des opinions à propos de Kanban?
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?
La liste des builds et le résultat :
Vais peut être changer de mobile moi...
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.
Parfois, certains choix sont difficiles. Plutôt, certains choix nous confirment nos priorités.
Dans l’amélioration du site internet de Pyxis, il y a des choix à faire; prioriser l’utilisabilité et l’accessibilité du site ou prioriser le référencement et le marketing web. De façon générale, je pense que les deux vont très bien de paire. Mais, il arrive des moments où un choix s’impose. Pour moi, le choix est clair. L’utilisabilité et accessibilité ont priorité. Je trouve plus utile que les visiteurs du site internet de Pyxis comprennent le contenu, qu’ils ne se perdent pas dans la navigation et que le contenu soit accessible à tous les visiteurs que de faire quelques pirouettes pour avoir un meilleur référencement.
Comme exemple, dernièrement on me suggérait de modifier les attributs alt des images des pages pour y ajouter des keywords ayant un lien à la page en cours. Ceci pourrait aider le référencement. Pourrait, certes, mais à quel prix? Pour moi le prix de diminuer l’accessibilité de notre site internet ne vaut pas le léger avantage que pourrait ajouter la modification aux attributs alt. L’utilité de cet attribut est de présenter un texte alternatif pour les situations où l’image en question ne peut être affichée. Le texte alternatif devient, dans ces situations, le contenu et c’est pour cette raison qu’il doit être significatif.
Alors, en suivant la suggestion faite, l’image de notre logo d’entreprise aurait eu comme texte alternatif “Pyxis Technologies agile accompagnement formation développement logiciel “. Pour moi cette suggestion ne fait pas de sens et je préfère conserver le texte alternatif pour notre logo comme étant “Pyxis Technologies”.
Un choix qui semblait initialement difficile est devenu par la suite plutôt simple. Il faut respecter ses priorités!
Un petit outil fort intéressant pour permettre de suivre le “mood” de l’équipe. Ça s’appelle un Niko-Niko Calendar.
À Chaque jour on y indique l’état d’esprit de l’équipe. Bel input pour une rétrospective !
Laissez moi savoir si vous décidez de l’utiliser ou si vous avez d’autres outils similaires à me suggérer.
J’aime bien cet article qui liste les compétences passe-partout que les développeurs devraient chercher à améliorer. Voici la liste des thèmes, lire l’article pour le détail.
Les temps changent; il me semble qu’à mes débuts, la liste aurait aussi inclus des connaissances du SQL avec un SGBD, et au moins un langage script (utile entre autres pour faire des scripts de build et des batchs).
Dans tout les cas, je vois d’un bon œil d’avoir une liste d’axes de compétences avec laquelle je peux me mesurer dans mon processus d’amélioration continue.