Coaching Agile, Experience Utilisateur, Tests Logiciels et Ergonomie IHM
12 March 2010
Inscrivez-vous au Flux RSS
Posté par jc-QualityStreet le 16 février 2009
User Stories et Use Cases (cas d’utilisation) sont deux façons très populaires de capturer les besoins utilisateurs (exigences fonctionnelles).
Toutes deux sont orientées BUT, plutôt centrées Utilisateurs, sont découvertes au cours d’ateliers de travail et peuvent être admirablement combinées avec les activités Expérience Utilisateur (Personas, Storyboard, Wireframe …).. WAIT! There is more to read… read on »
Posté par jc-QualityStreet le 5 octobre 2007
N’oubliez pas qu’un cas d’utilisation est avant tout TEXTUEL, et n’associez donc pas aussi radicalement ce cas d’utilisation (Use Case) au diagramme UML: privilègiez plutôt la démarche.
En effet, se lancer dans la rédaction des cas d’utilisation, pour décrire un besoin fonctionnel (spécifications), c’est se lancer dans une véritable démarche d’analyse, progressive, parfois lente, parsemée d’ateliers de travail, d’entretiens …
C’est aussi adopter une vraie réflexion en termes d’utilisateurs (acteurs), de buts et de tâches.
Croyez-moi, c’est bien là l’essentiel.
Le diagramme des cas d’utilisation UML (« Use Case diagram ») est quant à lui trés précieux pour bénéficier d’une vue globale sur l’application; il permet de visualiser immédiatement les liens entre acteurs et cas d’utilisation, ou encore de délimiter explicitement les différents packages. « Modéliser graphiquement » est un principe du Processus Unifié (ceci dit toujours fonction des destinataires), donc le diagramme des Use Cases ne doit pas absolument pas être négligé !
Pour ma part, ce n’est pourtant pas le diagramme qui m’a séduit …
j’ai découvert les cas d’utilisation en 2000 quand j’étais consultant au Luxembourg et j’ai très rapidement perçu, en les construisant (et grâce à de bons mentors), la forte complémentarité à la fois avec la démarche Ergonomique (profil utilisateurs, réflexion sur les buts et scénarios, UCD …) et avec les activités, livrables de l’Ergonome ou Designer d’interaction (Personas, Storyboard, Diagramme de Tâches, Wireframes).
Le fait que les cas d’utilisation se focalisent seulement sur le Quoi (Fonctionnel et Métier) _c’est une règle d’or_, sans décrire les éléments d’interfaces (Ecrans et enchaînement), laissés aux spécialistes de l’IHM, est aussi un élément que j’ai beaucoup apprécié, selon moi un vrai point fort.
Modéle générique de cas d’utilisation
Donc, depuis tout ce temps, j’évangélise … en insistant principalement sur 6 points :
… Et je recommande toujours « Rédiger des cas d’utilisation efficaces », d’Alistair Cockburn, la référence que je conseille à tous ceux qui souhaitent s’attaquer à l’analyse système ou mètier.
Enfin, même si aujourd’hui je me retrouve davantage dans les User stories, je reste convaincu de la pertinence des cas d’utilisation dans pas mal de contextes … quand ils sont bien rédigés 
Posté par jc-QualityStreet le 28 août 2007
Agilité rime souvent avec Absence de documentation : voilà une idée reçue bien nuisible qui doit être combattue avec force … car mener un projet en utilisant les méthodes Agile (Agile UP, xxUP, XP, SCRUM…), n’a jamais signifié « ne produire aucune documentation ».
A l’origine de cette confusion ? Peut être une mauvaise interprétation de l’Agile Manifesto et de l’une de ses 4 valeurs « un logiciel fonctionnel plutôt qu’une documentation complète », ou plus simplement la facilité, un manque de volonté voire de compétences de certaines équipes de développement souvent soumises à un timing toujours plus serré …
Soyons clairs, privilégier l’application (ou un prototype) qui marche, plutôt que la documentation, à la fois pour mesurer l’avancement d’un projet et valider ce qu’on fait est un principe agile de base, indispensable et dont je suis entièrement convaincu (la documentation ne doit jamais servir d’indicateur de productivité). Mais aujourd’hui, peu de projets peuvent se passer d’une documentation (au sens large) précise et adaptée.
Ma position tient donc en quelques mots … « JUSTE CE QU’IL FAUT », en réfléchissant attentivement :
Car être agile c’est avant tout penser communication, feedback, réactivité et adaptation plutôt que lourdeur, lenteur et bureaucratie, et croyez-moi une telle approche nécessite même une grande discipline ! Etre agile, c’est donc documenter de façon intelligente, appropriée et précise son projet en s’appuyant sur ce dont on a réellement besoin et ce qui est attendu pour éviter un gaspillage de temps et d’argent.
L’expérience me montre que l’utilisation d’un certain nombre de documents est quasi obligatoire sur la plupart des projets (la Vision par exemple, et d’autres pour la gestion de projet, les spécifications, …), et que certains contextes nécessitent plus naturellement (sans imposer) un certain formalisme (je pense à l’Offshore ou encore au CMMI, Capability Maturity Model Integration …). D’ailleurs, à l’autre extrême (autre idée reçue), se référer aux bonnes pratiques du modèle CMMI ne signifie pas pour autant, excès de bureaucratie et documentation à outrance.
Tout est donc affaire de mesure … SCRUM (la méthode Agile la plus populaire du moment) ou encore la conduite efficace de projets agiles vont dans ce sens.
Le Processus Unifié (dans une version customisée et adaptée à l’entreprise) peut assurer un très bon compromis, en permettant de constituer rapidement un excellent référentiel de doc. et bonnes pratiques que le chef de projet devra de nouveau ajuster à chaque projet (par l’intermédiaire du Plan de projet, élément incontournable d’UP qu’on retrouve aussi dans les pratiques du processus PP (« Planification du Projet »), l’un des 7 processus de niveau 2 du CMMI 1.2).
Pour le reste, les qualités de l’auteur de la documentation feront la différence pour la rendre correcte, précise et pertinente mais aussi lisible, légère et acceptable : en effet rédiger des cas d’utilisation ou même des user stories ne s’improvise pas, tout comme décrire des « personas », faire des diagrammes UML, des grilles fonctionnelles, rédiger un guide utilisateur, définir un plan de projet ou encore maintenir un plan d’itération …
Posté par jc-Qualitystreet le 2 juillet 2007
… de la documentation (juste ce qu’il faut pour rester Agile) visant à rendre compte de l’adéquation de ce qui est livré avec ce qui est attendu, voulu par le Client et les Utilisateurs finaux;
… une documentation produite dans le cadre du Recueil & Expression, de la Spécification et de la Gestion du besoin, composantes principales de ce qu’on appelle « l’Ingénierie des exigences » (= la discipline « Requirements » du Processus Unifié);
… des exigences au cœur des projets, qu’elle soient fonctionnelles (ce que le système doit faire) ou non fonctionnelles (qualité du produit, principalement les attributs issus de la norme ISO 9126), présentes au travers de ces trois activités essentielles.
… et de nouveaux champs d’intervention pour l’Ergonome Agile comme je le décris dans le précédent billet de cette série: Spécifications, Exigences et Cahier des charges: Qui ? Quand ?
Recueillir & Exprimer les besoins
L’objectif est de fournir une vision claire du système à concevoir, d’offrir la définition et les limites du système, les fonctionnalités clés, les autres exigences et contraintes.
Les dénominations sont variées mais la structure de ces docs. est souvent similaire (le type d’application fera la différence):
Plan d’un Cahier Des Charges de Site Web
Plan de Vision Document (Wiegers)
L’entretien est la source d’informations principale mais d’autres techniques peuvent aussi être utilisées : questionnaires, focus group, observation, tests utilisateurs exploratoires, benchmarking, étude de la doc. (existant et concurrence), présentation de maquettes…
Le savoir-faire de l’ergonome dans la conduite de chacune de ces techniques est un véritable atout, notamment pour trier et organiser l’input des utilisateurs (« classifying the voice of the customer », selon Karl Wiegers ), discours qui peut prendre différentes formes : exigences Business, scénarios d’usage, règles de gestion, exigences fonctionnelles, attributs de qualité, contraintes, données, idées et solutions.
Ce premier tri nous servira à établir notre base d’exigences.
Spécifier les besoins
L’objectif est de détailler et de clarifier les besoins exprimés en analysant le fonctionnement du système de manière formelle et exploitable par les équipes de développement.
Encore une fois les formats se recoupent (IEEE, RUP, Volere …), et cherchent tous à intégrer en leur sein (partie Exigences fonctionnelles), les cas d’utilisation (”Use cases”) pour décrire la dimension fonctionnelle des applications.
Exemple SRS Volere
Exemple SRS IEEE 830
« Use cases et user stories », livrables d’ergonomie, diagrammes UML … sont de précieuses techniques pour spécifier les besoins.
Sur le plan fonctionnel, la construction progressive des Cas d’utilisation (« use cases »), (Acteur -> But -> Déclencheur et scénario nominal -> Extensions), l’un des principes du processus Unifié, ou l’utilisation des Histoires d’Utilisateurs (« user stories ») , le tout combiné aux spécifications IHM (Visio et les wireframes ; Une interface conviviale) sont désormais des standards, et des avancées majeures dans une vision toujours plus utilisateur et toujours plus orientée BUT.
L’ergonome est à ce stade INDISPENSABLE.
Gérer les exigences
Les objectifs de cette activité transversale sont de faciliter la reconnaissance et la compréhension du lien entre les exigences, de permettre leur priorisation, et surtout de tracer leur prise en charge dans le projet (tel composant est le fruit de tel UC, lui même issu de tel besoin, le tout testé dans tel cas de test); en somme, la vie d’une exigence aussi bien en amont qu’en aval de sa spécification.
Exemple d’une base d’exigences (RequisitePro)
Des outils spécialisés (Doors, Caliber-RM, Requisite Pro…) existent mais c’est surtout la prise de conscience de l’importance de cette activité qui est cruciale.
La gestion doit s’opérer de manière continue très tôt dans le projet : la base d’exigences qu’elle soit manuelle ou automatisée va servir de fil rouge au projet et de référence à l’ensemble des acteurs.
Lister & vérifier (selon ces huit critères : caractère correct, clair, sans ambiguïté, cohérent, complet, réaliste, pertinent, vérifiable et traçable), qualifier, valoriser & prioriser, suivre les exigences sont des tâches inhérentes à cette activité : il s’agit d’une grosse part du travail de l’analyste.
Pour terminer, quelques références sur le sujet:
Retrouvez d’autres références sur l’Ergonomie, le Processus Unifié et le Test Logiciel dans la rubrique “Quelques livres“.
Posté par jc-QualityStreet le 27 juin 2007
Plus j’interviens dans les projets de développement informatique (Logiciel, Application Web, Sites Internet, INTRANET, EXTRANET …), plus je m’aperçois du caractère essentiel mais complexe, de trois activités, qui bien menées, maximisent pourtant les chances de réussite des projets:
Evidemment, l’intensité, la répartition de ces activités va varier selon la taille et la nature du projet (Applications mètier, Sites Internet…), selon le contexte (Projet interne, R&D, Client, Appel d’offres), mais toutes trois se doivent d’être présentes et définies sur vos projets de conception…. D’ailleurs, dans un prochain billet, je détaillerai davantage le Quoi, et vous proposerai une réflexion sur le Comment.
Sans détours et sans vous rappeler les rapports CHAOS du Standish Group, je vous affirmerai pourtant que:
Sans détours, j’ajouterai même que le recueil, la spécification et la gestion du besoin, nécessitent au final une véritable expertise : maîtrise de diverses techniques souvent complémentaires (issues des Sciences Humaines), pas mal de rigueur et une bonne dose de formalisme :
bref, moins de blabla, moins d’artisanat, plus de professionnalisme et de méthode.
QUI
Vaste débat …et potentiellement pas mal de dérives…
L’Analyste, le Consultant, le Client : des acteurs récurrents … mais aussi l’Ergonome qui de par son savoir-faire, ses objectifs et sa démarche centrée utilisateur doit en effet être un acteur privilègié du recueil et de l’analyse du besoin. Souvenez-vous , un produit “ergonomique” est un produit utile (issu d’un besoin EXPRIME ou NON) et utilisable : la présence de l’ergonome à ce stade est donc plus que légitime.
QUAND
L’expression des besoins et autres Cahiers des charges sont quant à eux le fruit de l’activité de recueil, et servent souvent de déclencheurs pour la suite des opérations en mode itératif ou séquentiel.
Dans une perspective séquentielle (cascade ou V), l’enchaînement est simple et bien connu, et même si, comme le souligne fort justement Claude Aubry, le cycle de vie en V n’existe pas, les disciplines d’ingenierie (Spécification, Conception, Developpement, Intégration, Test) vont se dérouler dans un ordre trés précis avec la nécessaire validation de l’étape précédente pour passer à la suivante.
Les écueils de cette démarche sont nombreux : feedbacks et retours en arrière non prévus, corrections difficiles, pas de pilotage par les risques, manque de visibilité… Dans ce cadre, la gestion des exigences sera au mieux menée de manière transversale, servant de fil rouge à l’ensemble des acteurs et au projet; toutefois la plupart du temps la gestion des exigences ne sera pas envisagée ou sera traitée dans l’urgence.
Dans une perspective itérative,
A bientôt pour plus de détails sur le Quoi et une idée du Comment.
 |
|
"Construire des projets autour d'individus motivés et garder l'esprit Agile"
