Posté par jc-Qualitystreet le 11 mars 2011
Activité # 2 du praticien Agile UX … (english readers can find on agile-ux.com an english version of this article)
(Voir l’activité 1 : Vision)
Le praticien Agile UX va créer les personas de manière collaborative …
Un PERSONA, c’est un utilisateur-type (le fameux archétype), une représentation fictive des utilisateurs cibles, qu’on peut utiliser pour fixer des priorités et guider nos décisions de conception d’interface.
Sophie, un Persona au format Sketchy!
Les Personas constituent d’un point de vue stratégique une composante essentielle de la Vision du Produit… tout simplement sa cible! A qui le produit s’adresse-t-il? Quels sont ses besoins de cette cible?
L’approche persona permet à l’équipe Agile de construire et de disposer, dans un format ultra engageant, d’une vision commune, des utilisateurs d’un service ou d’un produit. Les personas permettent de mettre l’accent et de comprendre ce que veulent les utilisateurs, leurs comportements, leurs besoins et attentes. Ils donnent du sens.
L’autre bénéfice des Personas pour l’Agilité est qu’ils peuvent facilement se lier aux User Stories, très populaires chez les équipes Agiles.
En somme, les personas sont un excellent moyen d’intégrer l’expérience utilisateur tout au long des projets de développement d’applications informatiques. C’est donc le rôle du praticien Agile UX d’en être le promoteur et d’initier leur création, en collaboration avec le Product Owner et l’Equipe.
Créer les Personas avec les équipes Agile
La démarche de construction des Personas doit démarrer au début du projet, avant de sprint 1. Le sprint 0 ou courte période d’exploration est un moment privilégié et très approprié pour créer les Personas. Toutefois, cette démarche de création nécessite la mobilisation de tous (Product Owner et Equipe) dans une approche résolument collaborative, facilitée par l’activité du praticien Agile UX.
Alors comment procéder ?
1 Préparer
- Organisez un ou deux workshops avec le Product Owner et les diverses parties-prenantes pour vous aligner sur l’approche et sur les objectifs à atteindre, identifier les sources de données, et déterminer les premières catégories de personnes à interviewer (les segments marketing ou rôles dans une application métier sont des points de départ assez fréquents)
- Sensibilisez l’équipe sur les Personas, la démarcheet ses bénéfices
- Collectez les données auprès des diverses sources préalablement identifiées, notamment en allant sur le terrain et en interviewant les utilisateurs.
2 Construire ensemble
- Analysez les données (faits) de manière collaborative en workshops et identifier les variables et patterns
- Créez des squelettes Personas
- Personnifiez et donnez naissance à vos personas, en travaillant les éléments de contexte, le storytelling selon un Template préétabli (formel ou non)
- Validez les résultats avec les principales partie-prenantes (voire sur le plan quantitatif)
Un Template Persona plus sophistiqué
3 Communiquer et Utiliser
- Placez les Personas sur le radiateur de l’information dans l’environnement de travail de l’équipe
- Liez les Personas aux User Stories
- Utilisez-les comme un outil de priorisation du backlog de produit et de conception des user stories (en tant qu’élément de conversation de celles-ci)
- Si nécessaire, montez un plan de communication sur les aspects marketing, vente ou encore formation: faites le buzz!
Personas Ericsson Life in 2020: Faites le Buzz!
Posté par jc-Qualitystreet le 4 mars 2011
Activité # 1 du praticien Agile UX …
Le praticien Agile UX aide à définir la vision du produit …
Agile ou non, la vision est essentielle
Au niveau de l’organisation, la vision permet d’apprécier et de croire en la société. Au quotidien, du point de l’équipe et du point de vue individuel, la vision c’est un bon moyen de donner du sens au travail que l’on fait (seule véritable source de motivation de l’homme au travail).
Un produit, une vision …
La Box Vision Qualitystreet affiche clairement ce qu'est Qualitystreet et son positionnement
A tout produit est nécessairement associée à une vision qui permettra de fixer les grandes orientations, donner du sens et de décrire ce qui est prévu pour le produit à court terme, moyen ou long terme.
Dans un contexte agile, parmi les 5 niveaux de planification utilisés, (Daily-> Sprint -> Release-> Roadmap -> Vision) du plus précis et détaillé (Daily) au plus “High Level”, la Vision est aussi le niveau le plus élevé.
Plus généralement, la Vision du produit et les Personas qui l’accompagnent constituent les fondements de l’expérience utilisateur du produit (couche stratégie, le socle des 5 éléments constituant l’Experience Utilisateur). Souvent courte et exprimée en termes d’objectifs, la vision est liée à un problème à résoudre.
Néanmoins pour être utile, efficace et fédérer des individus autour d’elle, la vision du produit doit être partagée avec l’équipe. En Scrum, ce travail de définition et de partage de la Vision fait partie des responsabilités du Product Owner, et ce travail doit être terminé avant que l’équipe commence à travailler son premier sprint (Sprint 1).
Ces activités de création, de partage et de portage de la Vision du produit sont d’énormes défis pour le Product Owner. Dans cet esprit, le praticien Agile UX a un rôle important à jouer pour l’aider dans cette tâche difficile:
- En tant que facilitateur des workshops permettant de définir et de partager la Vision,
- En tant que fournisseur d’éléments de “User Research” (formalisés pourquoi pas autour des Personas) pour alimenter le processus de réflexion menant à la définition de la Vision produit
Une nouvelle fois, la collaboration reste la clé et les techniques les plus efficaces pour définir et partager la vision sont avant tout COLLABORATIVES:
- avec l’équipe (PRODUCT VISION BOX et VISION STATEMENT, mes techniques préférées et un “must have” pour la seconde),
- ou dans une approche, plus UX (c’est la Voix du Client), une technique orientée innovation menée avec les clients et utilisateurs du produit (PRODUCT BOX).
N’hésitez pas à vous reporter à ce billet, la vision du produit, pour une description plus détaillée de ces trois techniques.
Exemples d’éléments de Vision Box:
Exemple de Vision “Agile” partagée:
Exemple de Vision Agile permettant de passer l'Elevator Pitch. la vision est affichée du début à la fin des développements là où l'équipe travaille
Posté par jc-Qualitystreet le 31 janvier 2011
Le Backlog de produit est cette liste de tous les éléments sources de valeur et nécessaires à l’équipe pour réaliser un produit. C’est le véritable fil rouge d’un projet Agile Scrum.
Vous qui suivez ce blog, vous connaissez peut être déjà les caractéristiques majeures (D.E.E.P.) d’un bon backlog ?
Mon Backlog est DEEP: c'est clair !
Malheureusement, on peut constater que parmi les équipes travaillant dans un mode Agile, encore peu de backlogs de produit répondent aujourd’hui à ces critères de qualité!
Étonnamment (ou pas), la question de l’outil permettant de gérer ce backlog suscite souvent plus d’intérêt… Outils dédiés, payants ou non, Excel, Google spreadsheet mais aussi Sharepoint, Jira voire même QualityCenter (si si je vous assure…)… quel outil choisir? Mais, c’est oublié assez vite, une autre caractéristique du Backlog de produit qui pour moi demeure essentielle: sa dimension physique.
Mon Backlog de produit est avant tout PHYSIQUE
Disposer d’une version physique (postits ou bristols sur un mur) du Backlog de produit, visible et accessible en permanence, est tout simplement indispensable. Accompagné de sa courbe, le BurnUp, c’est selon moi un élément clé du radiateur d’informations.
Backlog Physique: je vois où j'en suis; et là ON TOUCHE AU BUT !
Des bénéfices bien réels…
Le backlog de produit « physique » :
- offre aux yeux de tous (Equipe ou non) une vraie visibilité sur l’avancement du produit: ce qu’on fait, ce qu’on a fait et surtout le chemin restant à parcourir.
La vison du produit nous donne le cap ; le backlog de produit guide nos pas.
- est un signal fort de transparence (valeur forte de l’Agilité), mais aussi la marque d’une vraie volonté d’ouverture et de recherche de collaboration et de feedback
- permet aussi, en plus du produit partiel livré à chaque sprint, de DONNER DU SENS au travail de l’équipe. Proposer & afficher un but, une ambition est une source de motivation et d’engagement désormais reconnue. Le backlog de produit en tant que fil rouge du projet, vient concrétiser tout cela.
- Donne enfin la vue globale, cette “big picture” que CHAQUE MEMBRE DE L’EQUIPE ATTEND, et qu’aucun outil virtuel ne peut à ce jour remplacer.
L’esprit Agile et quelques prérequis
Le coût de création, notamment d’écriture, est un faux-problème (car l’ensemble prendra au final très peu de temps). Toutefois, l’efficacité du backlog de produit physique nécessite:
- Que celui-ci soit affiché, au sein du radiateur d’informations, là où l’Equipe travaille et donc évidemment pas très loin du Product Owner
- Que celui-ci soit partagé et qu’il devienne un élément de discussion entre l’Equipe et le Product Owner. Le backlog de produit physique doit devenir un véritable point de rencontre
- Que celui-ci soit «bichonné» et mis à jour en continu: laisser un backlog de produit à l’abandon dans un coin du mur n’est pas acceptable, c’est le signe que quelque ne va pas.
Trois conditions qui se travaillent au fil des sprints.
Vous l’aurez compris: le backlog de produit, moi j’en suis Fan !
Evidemment, les versions électroniques des backlog de produit restent INDISPENSABLES pour les équipes distribuées évoluant dans des contextes distants. Pourtant, y compris dans ces contextes, il faut savoir revenir à plus de simplicité, et redonner l’outil sa vraie place, c’est à dire « rendre les processus plus efficients et faciliter le travail des personnes ».
L’outil doit rester source de valeur, et ne doit pas ni devenir une contrainte ni une forme de gaspillage.
Posté par jc-Qualitystreet le 5 juin 2009
Product Owner c’est l’un des 3 rôles (avec le ScrumMaster et l’Equipe) proposé par Scrum; c’est aussi un vrai point de vigilance pour moi en tant que Coach Agile.
Le Product Owner est le responsable du produit, le représentant du client et des utilisateurs et donc à ce titre l’interlocuteur privilégié de l’Equipe.
Le rôle est essentiel; son importance est primordiale:
être Product Owner sur un projet Agile, c’est déjà pas mal de responsabilités (LA DECISION), c’est aussi:
- s’impliquer
- savoir communiquer
- savoir collaborer
- se rendre un minimum disponible
- disposer d’un certain savoir-faire…
Autant d’éléments, autant de risques que les choses dérapent…
Product Owner
Quant à l’activité du product Owner, même si son profil peut varier, elle est plutôt bien cadrée :
- Partager la Vision
- Définir et Alimenter un Backlog
- Fixer les priorités
- Décrire les fonctionnalités
- Ajuster les fonctionnalités et les priorités à chaque sprint
- Accepter ou rejeter les résultats (sur la base des critères d’acceptation)
Autant d’activités (et des registres différents), autant de risques que les choses ne dérapent… Backlog incomplet, exigences déconnectées de la réalité, de la valeur, Vision non partagée voire obscure, Absence de décision, Imprécision des critères d’acceptation, inéfficacité des échanges avec l’équipe, des ateliers de travail, manque de disponibilité et de présence à des RDV clés.
Seul, le Product Owner, peut il y arriver ? LA REPONSE EST NON!
mais il peut compter sur l’équipe me dire-vous?
OK mais pas suffisant…
Le Product Owner doit d’abord être accompagné.
Ensuite, même si le Product Owner doit parler d’une seul voix (vis à vis de l’équipe notamment, c’est un fondamental), constituer autour de lui une ”Team Product Owner” est trés souvent une pratique gagnante.
De ce point de vue, l’Ergonome est ce partenaire privilègié qui va appuyer le travail d’estimation et de priorisation du Product Owner, Il est aussi celui qui peut l’aider à clarifier et communiquer sa Vision, à recueillir et définir les besoins au travers de multiples ateliers de travail et d’une approche Personas. Associer trés vite Product Owner et testeurs est aussi un facteur clé de réussite
Mon Challenge :
- Faire adhérer aux valeurs Agiles
- Former à la pratique du SCRUM: les règles à respecter, le déroulé, l’attitude et les points de vigilance
- Définir précisément les rôles et responsabilités de chacun
- Diagnostiquer et dimensionner le rôle Product Owner sur le projet
- Construire le Team Product Owner si nécessaire
- Coacher le Product Owner sur 1 ou 2 sprints, avec un fort accompagnement en Sprint O
Mes autres Alertes:
