avril 2009Monthly :

Kanban vs Scrum de Henrik Kniberg

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?

en réaction à How Test-Driven Development Increases Overall Usability

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?

Un logiciel utilisable, c’est plus que de pouvoir l’utiliser

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.

Une question de confiance

La confiance, mais c'est quoi au juste dans une équipe de développement logiciel? Ben, c'est pas très différent de celle d'une équipe de sportifs... Pour information, ce sujet a déjà été abordé dans les mêlées et à travers le livre de Patrick Lencioni "The Five Dysfunctions of a Team". Notre culture favorise-t-elle le développement de la confiance dans notre travail? J'ai envie de vous signaler ce podcast de Eric Mignot et Raphaël Pierquin sur Visual Talk Show. Le but de l'emission n'est pas de dévoiler le contenu du livre, loin de là, mais plutôt de vous donner envie de le lire! J'ai pris pas mal de plaisir à l'écouter pendant mon vol d'aujourd'hui Bordeaux-Toulouse. Ca m'a aussi donné envie de faire un BBQ ;-) Bravo les gars et merci pour votre témoignage!

L’utilisabilité et l’accessiblité de notre site internet sont plus importants que le référencement

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!

Les compétences techniques qu’un développeur devrait améliorer selon Justin James

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.

  1. : Connaître un langage majeur (ex: .NET, Java, PHP)
  2. : Connaître une technologie de client riche (RIAs)
  3. : Connaître le développement web
  4. : Connaître les services web
  5. : Avoir des compétences humaines (Soft skills)
  6. : Connaître les langages dynamiques
  7. : Connaître les méthodes Agile
  8. : Avoir de l’intérêt pour les domaines d’affaire
  9. : Avoir une bonne hygiène de développement
  10. : Connaître le développement embarqué (Mobile)

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.