juin 2009Monthly :

in Ergonomie logicielle

Smells d’équipe qui n’intègre pas les pratiques d’utilisabilité;

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é
in Agile

Lecon apprise n°2 – Adapter la structure


Deuxième billet sur mes leçons apprises lors d’une expérience de 4 ans d’application de Scrum/XP chez un éditeur de logiciel à Grenoble. Avant, je veux clarifier le terme “structure”. Ce que je veux dire par “structure” c’est la cartographie de l’organisation en terme d’organigramme : la pyramide hiérarchique ou chaîne de commandement… on oppose souvent l’approche projet à cette structure pyramidale. En approche projet, on va travailler en mode transverse à de nombreux départements ou services.

Constat

En agile, les choses deviennent pire : on veut créer des équipes dédiées pluri-disciplinaires. De nouveaux rôles transverses apparaissent et on a du mal à les placer sur l’organigramme de l’organisation. A l’inverse des rôles existants se voient “dépouiller” de leurs activités du fait du changement de méthode. Dans notre cas, à l’époque, les chef de projets, responsables d’équipe et leaders techniques (architectes) ont eu beaucoup de difficultés à faire “leur trou” dans cette nouvelle façon de travailler. Le fait d’avoir conserver un grand moment une structure de l’entreprise inadaptée, cela a nuit au bon déroulement de la transition. Je n’ai jamais compris pourquoi cela semblait si compliqué de modifier la structure en place.

Pistes d’amélioration

  • Ne pas attendre pour introduire (valoriser) les nouveaux rôles dans la structure de l’organisation
  • Adapter ou supprimer la définition des rôles existants si ils sont obsolètes
  • S’appuyer sur une description processus/responsabilité plutôt que structure/autorité
  • Dans une approche processus, le rôle de ScrumMaster prend tout son sens : c’est le gardien ou le pilote du processus, à l’échelle d’un projet, d’une équipe
  • Maintenir un backlog de transition agile pour y consigner justement les adaptations de structure à conduire
  • Impliquer la RH le plus tôt possible dans la transition car le système de mesure de la performance individuel doit être adapté à cette nouvelle façon de travailler
in Agile, Ergonomie logicielle

Les pratiques d’utilisabilité, c’est Agile ?

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.

in Agile

Leçon apprise n°1 – Transition en douceur

Un mois déjà depuis mon dernier billet : je me ressaisis en entamant une série de 5 ou 6 billets sur les leçons que j’ai apprises durant ces dernières années d’accompagnement agile à Grenoble.

Leçon apprise n°1 – Transition en douceur

La transition vers l’agilité à laquelle j’avais assisté et dont j’étais aussi acteur, fut menée en mode “big-bang” : du jour au lendemain, tous les projets de l’entreprise furent gérés en Scrum. Le travail de préparation avait essentiellement porté sur des études de livres et la recherche de prestataires en formation et conseil agile. Nous avions organisé une grande réunion (ou plutôt une grande messe) pour expliquer les changements imminents et les raisons de ce changement. Je ne remets pas en cause ce que nous avions fait, mais je pense que nous manquions de maturité sur la gestion du changement à l’échelle de l’entreprise, et surtout sur les individus. Nous n’aimons pas changer quand quelqu’un décide à notre place, mais nous aimons changer si cette décision vient de nous… à méditer ;-)

J’aime l’image du lièvre et de la tortue : ne pas confondre vitesse et précipitation. Vouloir tout changer c’est bien mais savoir aider les autres à changer c’est mieux. La majorité des personnes veulent mieux faire, veulent s’améliorer et si elles vous paraissent hermétiques au changement, c’est que le problème ne vient pas forcément d’elles mais peut-être de de votre façon de leur parler et de les écouter.

Les bonnes pratique que je vois pour une transition en douceur sont les suivantes:

  • Impliquer un maximum de personne dans la décision de changer (et pas seulement le management et la direction)
  • Présenter ce changement “possible” à tout le monde (formation, ateliers…) avant de démarrer
  • Commencer avec UN projet pilote avec LES personnes qui souhaitent changer
  • Etre attentif aux arguments des personnes qui ne veulent pas changer et les entendre
  • Gérér formellement un “backlog” de transition en toute transparence en y agrégeant les idées de tous
  • Identifier une équipe en charge de ce “backlog”

Au final, on constate que pour démarrer, on a pas besoin d’avoir tout le monde d’accord : c’est une bonne nouvelle : une équipe motivée et un projet, ça suffit ;-)

in Scrum, Vie @ Pyxis

Une retrospective en image

Comme l’un des objectifs du Campus de Pyxis est d’améliorer les bonnes pratiques de développement logiciel tout en s’amusant. J’ai voulu faire une retrospective qui fait abstration du coté technique afin de valider, si le monde s’amuse sur le campus.

J’ai donc fais quelques recherches dedans le Internet et je suis tombé sur le blog The Agile Leap qui m’a inspiré l’activité que j’appel Retrospective en image.

Voici en gros l’activité

Préparation:

  1. Découper dans les revues différentes photos (essayer d’avoir autant d’image negative que positive)

À la Rétrospective:

  1. Étendre les différentes photos sur la table.
  2. Donner la directive suivante a l’équipe:

Vous avez 5 minutes pour choisir une photo qui represente selon vous le dernier sprint. Lorsque la photo a ete choisi, vous devez la coller sur le flip chart.

  1. Lorsque tout le monde a choisi une photo, ne passer aucun commentaire et demander a chaque personne d’expliquer leur choix.
  2. Lorsque tout le monde a répondu, faire un résumé de ce qui a été dis.
  3. Par la suite, dépendants des réponses, il suffit de voir les pistes de solutions pour règler les points negatifs

Retour d’expérience sur l’activité

Comme je veux respecter la confidentialité des retros, je vais simplement donner des constatations générique de l’activité.

En gros, ce fut très concluant puisque chaque membre de l’équipe a pu parler du dernier sprint sans aller dans le technique. Deplus, nous avons pu eclaircir ce qui a bien fonctionné et ce que nous devrions améliorer.

J’ai aussi remarqué qu’une image peut avoir différente représentation selon différente personne. En effet, j’avais choisi une photo qui selon moi était négative, mais un des membres a pris cette même photo et lorsqu’il la expliquer celle-ci avait une representation positive.

Ce que j’ai aimé apres la rétro c’est que le flip chart contenant toutes les images donnait une bonne vue d’ensemble du sprint.

Conclusion

Pour conclure, je vous invite a essayer cette rétrospective et me donner des commentaires. Aussi comme Trémeur Balbous me l’a dit, je vais réessayer cette activité de facon plus systematique (à chaque 4 sprint), Afin de mieux évaluer l’impact de cette activité.

in Scrum

Quand Scrum ne fait pas de sens.

Laissez moi vous raconter l’une de mes dernières interventions chez un client. Le mandat consistait à accompagner les gestionnaires de l’organisation dans leur exploration de l’agilité.

Lors des premiers jours on me présente l’organisation, le processus actuel, les contraintes spécifiques à leur industrie, les différents membres de l’équipe, bref le CONTEXTE organisationnel.
On discute de l’agilité, des valeurs, des principes, des pratiques et on se questionne sur l’impact de leur adoption.

L’une des questions à laquelle on souhaite répondre au plus tôt dans un mandat comme celui-ci c’est : ” Quels sont vos problèmes et pourquoi pensez-vous que l’agilité peut vous aider à les régler? “. Les réflexions autour de cette question sont intéressantes car on veut faire réaliser au client que l’agilité n’est pas un but, mais un moyen.

Question quiz : Vous êtes directeur IT et je vous offre les 4 objectifs suivants. Lequel choisissez-vous?

  1. Mettre en place le plus beau Scrum de l’Amérique
  2. Mettre en place le plus de pratique XP possible
  3. Être Agile
  4. Livrez rapidement du logiciel utile de qualité à mes clients

Alors?

Je reviens à mon histoire. Après les premiers jours de discussions et les formations d’usage on évalue plus sérieusement comment mettre en place Scrum et on établit un plan d’actions.

L’un des derniers ateliers sur le sujet est plutôt chaotique. Les gestionnaires et moi nous lançons des questions auxquelles nous avons de la difficulté à répondre. Pourquoi est-ce si difficile. Et si Scrum n’était pas le bon outil? Quel est le CONTEXTE déjà ?

  • Plusieurs projets à gérer en même temps de tous les types. Des petits, des gros, des banques de temps, des forfaits, …
  • Des feux à éteindre
  • Des ressources spécialisées qui appellent à un certain travail en séquence
  • Le travail à accomplir est habituellement prévisible.

Et rappelez moi quels sont les objectifs?

  • Augmenter la qualité (CQ constant)
  • Meilleur feedback client (plus incrémental)
  • Engagement et responsabilisation des équipiers
  • Travail d’équipe

Et Si Scrum ne faisait pas de sens?

En fait plusieurs pratiques de Scrum nous apparaissent essentielles :

  • Un leader business qui priorise (Product Owner)
  • Un leader de processus qui guide l’amélioration du processus(Scrum Master)
  • Une synchronisation quotidienne (daily Scrum)
  • Une rétrospective régulière (Sprint Review)
  • Plusieurs des pratiques XP nous semblent un must pour assurer la qualité.

Notre problème c’est l’itération. S’obliger à tout ” terminer ” à chaque fin de sprint cause des soucis. Hmmm…

On poursuit nos discussions…

Quel est le flow d’activité qui permet de livrer de la valeur à vos clients? Quel est la taille de vos livraisons? Combien de temps pour parcourir la chaîne des activités? Ou se trouve le gaspillage sur cette chaîne de travail?

Et si on s’organisait autour d’un Kanban avec du XP, un PO et son backlog, un daily scrum et une rétro à chaque mois pour ” inspecter et s’adapter “? Essayons…

Le point ici c’est que Scrum, XP, Kanban sont des outils. Ils ne devraient jamais nuire à l’objectif ultime qui est de livrer régulièrement du logiciel utile à nos clients.