Notes Discussion – Agile et UCD

Accueil de Colas Nahaboo (Use Age)

Introduction de Teresa Colombi : présentation de l’association Use Age et de l’initiative Petits dej’ Use Age
Tour de Table des personnes présentes

Introduction de Teresa Colombi (Use Age) sur l’approche Agile et l’approche Ergonomie

Voir pdf

Retour d’expérience de Frank Wagner (IBM)

Scrum master & Agiliste
Travaille à IBM Sophia sur IBM Decision Management (anciennement ILOG JRules)
Derniere release du produit implémentait une nouvelle interface web

Objectif : Refonte de l’interface à destination d’utilisateurs métiers dits business users (banque, assurance).
7 mois au total : 9 sprints de deux semaines

Pour l’ensemble du produit 3 équipes impliquées sur 3 sites : Paris, Sophia, US -> 30 personnes
Equipes hétérogènes du point de vue des roles : dev, test, UX, resp. produits … La plupart travaillant sur un même lieu.
1 équipe en « Scrum », celle de Sophia

Développements incrémentaux pour créer un artefact.
User stories de bout en bout pour avoir chaque semaine un moyen de collaborer avec l’équipe.

Nouveautés pour cette équipe : application « Scrum », techno Web, UX designer dans l’équipe.
Nouvelle approche car avant le UX designer était impliqué après le travail des programmeurs.
Maintenant l’équipe travaille en amont avec le UX Designer qui intervient dès le début.

Le UX fournit des « low-fidelity » mock-ups qui servent de base au développement.
Entre la proposition UX et le developpement, beaucoup de questions …Exemple :

Highlight 1:

UX Designer propose une nouvelle façon de sélectionner un intervalle de date
Implémentation
Démonstration au client (entre 2 itérations)
Le client commente, la solution innovante doit être revue
Nous sommes capable de délivrer une solution plus en accord avec l’utilisateur.

Highlight 2 :

Un low-fi mock-up contenait un menu avec 2 actions
Le developpement avait découpé cela en 2 user-stories
Ils n’ont eu le temps d’implémenter qu’une user-storie
Du coup, le mock-up ne faisait plus sens. Nous avons perdu du temps à refaire des mockup « high fidelity ».

Designer et Developpeurs doivent plus travailler en binôme en amont pour par exemple identifier les composants technologiques à utiliser et ne pas « réinventer la roue ».
Avec SCRUM on s’occupe d’une seule fonctionnalité à la fois, et l’on est en contact avec le client bien avant la béta. C’est un point positif.

Questions & Points abordés lors de la discussion
Comment gérer un développement global avec des équipes non-agiles et 1 agile ?
Difficile de concilier les deux approches car les équipes non-agiles présentaient beaucoup de fonctionnalités non terminées.

Comment intégrer le temps de feedback client ?
Suggestion de faire des « medium-fidelity » mock-up » : maquettes plus fonctionnelles mais difficile de gérer le niveau médium sur des itérations de 15 jours.

Maquettes visuellement abouties versus maquettes fonctionnelles ?

Une maquette très aboutie visuellement permet de faire passer l’innovation mais en même temps les utilisateurs risquent de trop s’attacher aux détails de design.

Privilégier le test fonctionnel … laisser le design pour après ?
Dans les cas où le fournisseur est une start-up non connue, une présentation à des décideurs de visuels plus aboutis est important. L’aspect design apporte alors une certaine crédibilité.

Peut-être faudrait-il faire évoluer l’approche de développement pour intégrer ce niveau de médium ? …

Presentation slides : Low, Medium, High fidelity mockups (Teresa Colombi)

Low-fi : moche et non interactif
Medium-fi : moche et interactif (logiciel axure)
High-fi: design & intera

Retour d’expérience sur axure & agile

Incompatible pour des contraintes de temps et inadapté au contexte. Donc abandon d’axure. Nous utilisons un prototype quand il y a un besoin de réaliser des tests avec utilisateurs
Sert d’outil d’aide à la décision plus pour le product owner que pour l’utilisateur.

Autre retour :

Des maquettes statiques sont fournies par l’ergonome et validées en amont.
Difficulté de bien calibrer le sprint : conseil de partir sur 2 semaines car on peut réagir rapidement (corrections).
Grande difficulté pour caler l’organisation sur ce rythme. Equilibre fragile entre les interventions du product owner, l’ergonome, l’équipe de dev…

Bien préparer avant car une fois que le sprint est lancé, c’est un peu un marathon.
Si l’équipe souffre, c’est qu’il y a quelque chose qui ne va pas. Le « Scrum master » doit intervenir : anticiper et équilibrer est le role clé du scrum master

Occupation d’une équipe cross fonctionnelle en scrum ?

« L’agilité c’est mieux travailler avec les membres de l’équipe ».

Mesure de la vélocité des développeurs et identification des points de charges pour définir la charge du sprint. Dans le rythme de « Scrum » l’ergonome va faire partie de l’équipe et être agile aussi.
Il y a beaucoup de roles différents dans une même équipe qui sont tous censés avoir des taches définies et être occupés pendant 2 semaines. En fait certains sont a 10%, d’autres a 50%… etc
On observe que naturellement les personnes vont s’occuper utilement pour l’équipe. Par ex. les dev vont faire du test, prendre le temps de faire une revue de code non prévue, pour anticiper le prochain sprint… ou fournir des idées

« Le mode agile crée cette dynamique d’équipe et chasse l’individualisme. »
Le mot SCRUM vient du Rugby. La notion d’équipe qui dialogue, heureux de travailler ensemble.

« Quand on est individualisé, on ne se sent pas concerné par le projet. Dans une équipe Agile, il y a une cohésion qui se crée.
Les équipes montent en compétences : il y a des équipes qui doublent leur vélocité en 6 mois… par exemple. C’est comme une plante. »

Est-ce que ce rythme est soutenable ?

Métaphore de l’autoroute : Un seuil où tout se passe bien. S’il arrive des temps morts, on peut toujours trouver une tâche à réaliser en amont pour anticiper les sprints suivants.

Scrum adaptée pour tous les stakeholders ?

Coté IT, passage à l’agile est évident.
Coté Product Owner, le passage est plus compliqué. Habitude d’avoir des spécifications lourdes et détaillées. Faire comprendre qu’on va découper ça en tranche, c’est dur. Il faut travailler avec le client pour définir ces incréments.
Rythme très utile dans le Web design car personne ne sait ce qui va marcher.
Difficulté de faire comprendre qu’une Version 1 et un sprint ce n’est pas la même chose. Il faut apprendre des retours clients. Faire comprendre que l’on va produire des petits bouts pour faire évoluer l’ensemble

Agile est plus orienté pour le développement.

Est-ce que coté Marketing il y a des approches « agiles » ?

Les approches en « V » coté marketing ont montré leur inadaptation au Web. Avec le Web le besoin d’avoir une vision produit et de la séquencer en étapes est cruciale.
Par contre il n’existe pas de process equivalent à scrum seulement des méthodologies plus ou moins publiées par ex. Lean process
Mettre en place des moyens pour collecter les feedback?

Comment faire pour avoir de l’agilité en amont ?
Evolutions du côté des clients. Ils acceptent maintenant que toutes les fonctionnalités ne seront pas implémentées.
« Lean start up » pour accompagner les start up.
En demo on peut inviter toutes les personnes intéressées par le projet. Du coup on arrive à avoir des retours users sans froisser les marketers.

Comment allier l’ergonomie & scrum ?

Designer et ergonomes sont souvent confondus dans les méthodes Agiles. Tout ergonome n’est pas forcement un deigner. Une équipe Agile inclut plus souvent un Designer UX

Les retours utilisateurs entre itérations risquent d’être « galvaudés » .
L’approche ergonomique est d’assurer que le feedback utilisateur est correctement interprété parce que l’approche de recueil de feedback est maitrisé.

Il reste des approches à créer pour définir comment dans un temps court apporter un feedback de valeur et en rendre compte

A-t-on besoin de mettre l’ergonome dans les sprint ?

N’est-ce pas une trame de fond de travail entre l’ergonome et le product owner ?

Raison d’avoir un ergonome dans l’equipe scrum est la même que d’avoir le testeur : réparer dès qu’on trouve un defect.

Après l’ergonome peut avoir des interventions plus exploratoires qui demandent plus de temps mais qui au final sont complémentaires.
On peut parler alors de:

Ergonomie de conception – plus en amont et long terme avec le product owner
Ergonomie d’amelioration – dans scrum

Role et fonctionnement d’une équipe scrum

En agile on ne sait pas comment les équipes doivent fonctionner ensembles à priori. Ca marche dans un cas pas dans l’autre, l’essentiel c’est d’analyser et d’adapter. Quelque fois c’est une question de personne, quelque fois de role… Si on essaye pas, on le sait pas.
Mieux vaut ne pas définir les roles de chacun trop strictement car après les personnes ne vont pas en sortir. Mieux vaut identifier les responsabilités des personnes.

Est-ce que finalement ce n’est pas revenir a l’esprit start-up ?

Retour d’expérience sur la partie test (QA)

L’automatisation des tests est la priorité. Le « testeur » va chercher à definir des tests limites qui vont aider le dev. Ces petits A/R se font dans la journée.
Dès qu’il y a une modification de la spec, le dev et le test définissent ensemble les choses qui seront testées.
Chaque commit d’un developpeur reteste automatiquement l’ensemble de la release.
A la fin de chaque iteration, ce qui a été produit peut être mis en production. Donc automatiser les tests fonctionnels sur un projet agile est pratiquement obligatoire pour en garantir la qualité. Sinon c’est un risque.

Les tests unitaires sontt une aide énorme pour les développeurs.

Existe-t-il de bonnes formations ?

Institut Agile : Intervention de plus en plus fréquente dans les écoles d’ingenieur.

Est-ce que toutes les entreprises sont prêtes à être agiles ?

Beaucoup d’entreprises affichent le fait de passer en Agile.
Ce n’est pas seulement une approche de gestion de projet, c’est aussi une approche de management que la société doit avoir.

Quand on travaille à un dev de produit agile, certains clients de ces produits ne sont pas dans cette culture agile.
Mais il existe toujours, des early-adopters,ou des personnes qui sont plus proches de cette culture. On peut alors choisir de commencer à travailler avec ceux la.