Posté par jc-QualityStreet le 30 janvier 2008
Le débat sur les personas resurgit depuis quelques mois, pour preuve ce dernier billet d’Eric-Superfiction, celui de Mathieu Collet ou mes propres billets “Quelles données pour vos personas” ou “Personas : mon retour d’expérience”.
Jamais une technique de conception centrée utilisateur n’aura suscité de manière récurrente autant de polémique (notamment chez nos amis anglo-saxons), d’émotions et d’interrogations, car pour beaucoup d’acteurs, la construction des personas relève du mystère voire du mythe !
Rappelons au passage que les PERSONAS, tels qu’on les entend, datent de 1999 (et oui déjà !), plus exactement du livre “The Inmates Are Running the Asylum” , le best seller d’Alan Cooper, même si des concepts très proches (ancêtres des personas), notamment les Profil Utilisateurs et les Scénarios sont apparus dans les années 80.
Les personas nécessitent donc selon moi une démarche CONSTRUITE mais toujours AJUSTEE en fonction des objectifs que l’on se fixe, des bénéfices que l’on attend, de l’application à concevoir, des données disponibles et du temps dont on dispose (car oui on peut bel et bien envisager de vrais personas dans un timing serré, et dans le cadre des méthodes Agiles).
Seulement PRUDENCE ! comme toute technique, celle des personas peut vous amener droit dans le mur. Voilà donc quelques lignes décrivant les principales causes d’échec d’une approche “Personas”:
- Pas de soutien, pas de support de la part des décisionnaires (c’est banal)
- Personas non crédibles et pas construits avec rigueur (vous me suivez …)
- Personas mal communiqués
- Personas pas ou mal utilisés par les équipes
- Pas de construction progressive, exploratoire
- Absence de réflexion orientée BUT
Mon challenge en tant que consultant est de mettre en garde contre ces dérives potentielles, de les éviter et de faire comprendre à mes interlocuteurs que le temps qu’on va passer sur nos Personas (notamment préparation et création) va valoir le coup !!!
Croyez-moi, les bénéfices sont réels : j’ai donc pas mal d’arguments… qui viennent alimenter ma démarche.
Posté par jc-QualityStreet le 26 janvier 2008
Je vous parlais, il a y quelques temps de l’Information Radiator, criant symbole et représentation la plus concrète de l’Esprit Agile. Il donne de la visibilité à tous les acteurs en mettant le focus sur l’essentiel (on sait exactement où on en est et ce qu’on fait), suscite l’intérêt et provoque les échanges.
Et bien voilà une nouvelle preuve de l’intérêt et de l’efficacité du visuel, avec ce “job chart“, sorte de taskboard allégé, adapté à un nouveau contexte, la maison et les tâches domestiques, sujet ô combien sensible :), et à une nouvelle cible, la famille, dans le respect de celle-ci biensûr.
Peter Abilla, http://www.shmula.com/
Moi j’adore … ma femme trouve ça génial (évidemment) … seul problème nos enfants ne savent pas encore lire !. On attendra donc encore un peu avant de se lancer …
Plus sérieusement, Peter Abilla développe dans son article (en anglais) l’origine de sa démarche et les valeurs qu’ils cherchent à véhiculer : engagement, sens des responsabilités, valeur du travail, autonomie, esprit (d’équipe….non) de famille.
Il revient aussi sur les règles de fonctionnement, le positionnement dans un lieu stratégique, la cuisine ainsi que sur les multiples avantages de l’approche visuelle (feedback immédiat, information sur les tâches, visibilité…).
Les parents réfléchissent déjà à la façon d’améliorer le système (des modèles, toujours visuels, de “bon travail” avec par exemple un comparatif, toilettes propres / toilettes sales 
), et tous font même un point de suivi tous les soirs … nouveau concept le SCRUM familial !!
Bon, il faut dire que l’auteur est un expert reconnu du Lean Software Development, approche initiée par Mary and Tom Poppendieck, reprenant et adaptant au monde informatique, les principes ayant fait le succés de Toyota dans l’industrie automobile…
Posté par jc-QualityStreet le 17 janvier 2008
Je vous ai déjà parlé des personas au travers de mon retour d’expérience. Je vous les ai présenté comme un outil très performant notamment pour comprendre les utilisateurs et leurs buts, et pour guider les choix de conception.
Toutefois, une question revient régulièrement chez mes interlocuteurs: à partir de quelles sources, les personas se construisent-ils?
Ma réponse est sans ambiguïté : la construction des personas se fonde avant tout sur des données qualitatives issues de l’observation et d’entretiens réalisés auprès des utilisateurs (une bonne douzaine minimum, mais c’est évidemment très variable), en interne ou en externe (car de nombreuses et diverses sources externes sont disponibles et exploitables).
Alors, même si une approche quantitative (effectuée sur un très grand nombre d’utilisateurs à partir de questionnaires ou d’outils analytiques …) peut appuyer cette construction, crédibiliser l’approche vis à vis de certains ou valider certaines orientations, l’approche qualitative est la base, le minimum et ce qui va déterminer la suite des opérations. Évidemment, cela nécessite du temps, de l’énergie, de la technique.
On peut donc selon moi, dans une certaine mesure, se passer de données quantitatives, en revanche on ne pourra jamais faire sans, on a besoin obligatoirement des techniques qualitatives pour s’immerger dans l’univers des utilisateurs, et pour savoir:
- Quels sont leurs buts ?
- Quelles sont les tâches et activités associées, leur fréquence, leur durée, leur importance … les actions nécessaires pour atteindre leurs buts ?
- Qu’est ce qui déclenche leurs actions ?
- Comment les utilisateurs interagissent-ils les uns avec les autres, et avec les produits existants ?
- Qu’est ce qu’ils aiment et n’aiment pas ?
- Quel est l’environnement dans lequel ils évoluent ?
- Quels traits de personnalité ont-ils en commun ?
- Quels sont les influences ? les facteurs de décision ? les attentes ?
… en somme, tous ces éléments qui vont nous permettre de différencier et de construire efficacement vos personas. Bon au cas où vous ne l’auriez pas compris, les personas (les vrais), ça me plait …
Posté par jc-QualityStreet le 16 janvier 2008
Ce rapport Forrester d’août 2007 fait le point sur les processus Agiles; point nécessaire selon l’auteur Carey Schwaber puisque parmi les entreprises qui n’utilisent pas les méthodes Agiles, environ 1 sur 2 envisage de le faire !
Alors, au boulot …
Dans ce rapport en anglais, quelques rappels sur:
- ce qui fait un processus Agile (itératif, livraison à chaque itération, techniques spécifiques notamment le Test Driven Development, l’intégration continue, application des principes Lean notamment l’élimination des gaspillages ….)
- le niveau d’adoption de l’agilité
- les bénéfices attendus (délai de mise en marché, qualité, visibilité, vélocité, motivation des équipes …)
- mais aussi, sur ce qui est requis pour envisager sérieusement l’agilité : des équipes de taille raisonnables, plus de polyvalence (à l’instar de l’ergonome Agile), une nouvelle façon d’envisager la gestion de projet, l’automatisation…
Enfin, l’auteur insiste sur le fait que les méthodes Agiles peuvent s’appliquer dans tous les contextes de développement informatique, même si certains types de projets sont plus favorables pour “démarrer”. Dans cette optique, le rapport présente les possibilités s’offrant à une organisation qui souhaite adopter l’agilité: formations, coaching individuel, conseil par des consultants expérimentés en méthodes & process, développement agile externalisé.
Pour aller plus loin, je vous propose quelques conseils dans ce billet, “Adopter le Processus Unifié, Basculer vers les méthodes Agiles” et pour une vison claire, en français de ce que sont les méthodes Agiles, je vous renvoie à cet autre article “Méthodes Agiles: une belle définition“.
Commentaires:
Classé sous: Agile
Posté par jc-QualityStreet le 11 janvier 2008
Un anniversaire mais surtout:
- Le plaisir d’échanger et de partager
- Le plaisir de découvrir et de faire découvrir
Et aussi des rencontres (au fait à mercredi, Claude), des sollicitations, de futures collaborations, une vraie dynamique autour des thèmes qui me sont chers…
“Construire des projets autour d’individus motivés et garder l’esprit Agile”
Plus qu’une devise, une réalité à laquelle vous contribuez chers lecteurs.
Merci à vous qui me suivez dans ma démarche d’ouverture et dans ma vision transversale de la qualité informatique.
Et merci à ma petite famille de son soutien et de ses encouragements
Commentaires:
Classé sous: News
Posté par jc-QualityStreet le 10 janvier 2008
Pour ceux qui l’ignorent Alistair Cockburn est une vraie pointure, l’auteur de l’ouvrage de référence “Rédiger des cas d’utilisation efficaces” (la bible des use cases).
Soyons clair, Alistair Cockburn, dans son article, se déclare fermement contre les user stories, et défend avec force ce qu’il a toujours défendu : les cas d’utilisation (”use cases”).
Soyons clair, je trouve que son article manque d’objectivité mais qu’il a le mérite d’enrichir notre débat “use cases ou user stories” …
Alistair Cockburn considère qu’utiliser les user stories est source de trois gros problèmes :
- User stories ne donnent pas suffisamment de contexte
- User stories (et backlog) ne procurent pas à l’équipe un sentiment de complétude, d’achèvement
- User stories ne prévoient pas de mécanisme pour se projeter en avant, penser au travail à venir
Tout cela me semble très exagéré…
Rappelons tout de même que les user stories sont discutées (l’un des 3 C, “Conversation“), et estimées par l’équipe. Soulignons aussi qu’elles n’arrivent pas toutes seules et sont accompagnées de personas, storyboard, bref du travail de l’ergonome ce qui va faciliter grandement leur mise en contexte.
De plus, la grande force des méthodes agiles est de mesurer l’avancement du projet en fonctionnalités livrées (et non de documentation): le degré d’achèvement se révèle donc au final selon moi beaucoup plus concret.
Certes, l’art de se projeter en avant n’est pas inscrit dans user stories, et encore, car nous pourrions rappeler à Alistair, que les user stories envisagent d’entrée les éléments à tester en priorité (l’un des 3 C: Confirmation). Mais ce qui concerne le travail à venir se retrouve dans d’autres outils Agiles : le burndown chart, la backlog de produit, le radiateur d’informations, la pratique du SCRUM …
Alistair Cockburn revient ensuite sur l’intérêt du contenu des cas d’utilisation pour une équipe projet et pour un client: le résumé, le scénario principal, les extensions, le niveau de détail; des arguments qui tiennent la route et dont je suis convaincu pour certains contextes. Mais des éléments (hormis le niveau de détail de l’artefact) qu’on retrouve dans une approche agile bien menée qui se sert des user stories et qui intégre une démarche ergonomique de qualité.
Enfin, Alistair Cockburn nous propose quelques conseils pour ceux qui utilisent les cas d’utilisation (car tout n’est pas si simple au royaume des use cases). Des conseils exploitables et préconisés dans une perspective Agile :
- Avoir une démarche de construction progressive
- Décomposer les use cases (pourquoi pas en user stories: la réconciliation est là) pour faciliter leur mise en oeuvre. Un cas d’utilisation entier ne peut pas toujours être implémenté dans une courte itération de 2 ou 3 semaines
- Écrire de bons cas d’utilisation nécessite de réfléchir, d’analyser, de communiquer, d’analyser … bref nécessite un vrai travail de fond auquel il faut être préparé
Sur ces trois points, on est vraiment en phase ! D’ailleurs, ce sont les messages que j’essaie de faire passer quand il est question des cas d’utilisation et que j’évangélise sur le Processus Unifié et sur la mise en oeuvre des méthodes Agiles.
Personnellement, j’aime bien sa conclusion :
“I’m (not really) sorry if you don’t want to think – find a new profession”
La mienne sera moins polémique, (question de style) : dans certains contextes, les user stories, peuvent s’avérer beaucoup plus appropriées que les use cases. Et sur d’autres projets, on aura vraiment besoin d’une approche par cas d’utilisation.
En somme, “It depends…”: une vraie réponse d’ergonome ! Et vous, quel est votre point de vue ?
Commentaires:
Classé sous: Agile
