Posté par jc-QualityStreet le 13 octobre 2007
…pour estimer, planifier, piloter, évaluer, capitaliser …ou plus simplement pour rendre le boulot des autres plus facile et leur permettre d’atteindre leurs buts.
FACILITER, cela consiste à aider un groupe, une ou des personnes, à apprendre, explorer, trouver des solutions,atteindre un consensus….
Delphi, Metaplan, Planning Poker, Priority Poker, Scrum, Retrospective… ces quelques pratiques, aux noms exotiques, attestent de l’omniprésence de la dimension facilitation dans nos projets de développement informatiques, dimension qui prend davantage de relief dans une perspective agile.
La méthode Delphi (consultation d’experts soumis à des vagues successives de questionnement sur un sujet précis pour viser convergences et consensus) et son dérivé, le Planning Poker, pour l’estimation des User Stories en sont la plus belle illustration. Le modérateur y joue un rôle crucial (que je développerai dans un autre billet). Appliquer la technique d’estimation des points de cas d’utilisation nécessite aussi de faciliter les échanges entre analystes, architectes …
Définir d’une part le contenu (high level au départ puis affiné au fur et à mesure) des itérations (et release), et d’autre part la vélocité de ces dernières nécessite la collaboration active de différents acteurs. Faciliter les échanges de ces parties-prenantes, sur la base de l’analyse des risques par exemple (on parle de Pilotage par les risques) est souvent nécessaire. Le Priority Poker va dans ce sens.
- Faciliter pour suivre et piloter
Les réunions de début et de fin d’itération sont des exemples trés concrets. Le SCRUM en est le plus bel exemple, l’art de faciliter par excellence! Un scrum (« mêlée »), est une réunions d’équipe projet d’environ 15 min qui a lieu 2 à 3 fois par semaine et articulée autour de 3 questions : Qu’as tu fait depuis le dernier scrum ? Qu’est ce que tu dois faire ? Qu’est ce qui t’empêche de faire ton travail ? Le SCRUM est d’ailleurs selon moi l’outil de gestion de projet le plus performant.
- Faciliter pour évaluer et capitaliser
On pourrait parler des réunions de fin d’itération, fin de phases ou release, mais je pense davantage aux bilans de fin de projet et à la technique du METAPLAN. Cette technique consiste à réunir l’équipe projet et à échanger sans censure ni réglement de compte, sur 5 ou 6 thèmes (préparation individuelle de 10 minutes, lecture à tour de rôle et la présence indispensable d’un facilitateur pour noter le tout, cadrer les échanges et orienter les débats vers des points à améliorer, à capitaliser …)
Enfin, FACILITER, ça se joue au quotidien pour un Ergonome ou consultant Expérience Utilisateur quand il s’agit de conduire des Tests Utilisateurs (et croyez-moi on ressort fatigué d’une session de test d’1h bien menée !), d’organiser des ateliers de recueil et d’expression des besoins (use cases, user stories) et des ateliers de conception; la facilitation devient alors l’ingrédient essentiel de ces workshops ou ateliers de travail.
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:
- Recueillir et exprimer le besoin (Expression des besoins, Cahier des Charges, Vision …)
- Spécifier le besoin (Dossier de spécification, SRS, Use cases, User stories …)
- Gèrer et tracer les exigences (Backlog de produit, Liste des exigences, manuelle à base d’attributs ou sur des outils dédiés tels que DOORS, Requisite Pro, Caliber-RM …)
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:
- La capture est souvent incomplète, biaisée, mal maîtrisée.
- La spécification souvent confuse, inadéquate, incorrecte, incompréhensible pour ses destinataires.
- La gestion des exigences faite dans l’urgence voire absente, et de toute façon sous estimée.
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,
- de type Processus Unifié (”Unified Process”), le concept ou plutôt la discipline “Ingènierie des exigences” prend cette fois tout son sens puisque prévue, formalisée et cadrée, permanente et continue. Les acteurs chargés de ces activités vont donc suivre le projet du début à la fin, certes avec plus de spécification en 1ère partie du projet (80% des cas d’utilisation doivent être rédigés en fin d’Elaboration), et davantage de gestion des exigences dans la seconde partie.
- de type SCRUM, méthode Agile la plus populaire, le degré de formalisme sera diffèrent; le tout intégré à chaque Sprint. Un effort particulier sera fait en Sprint 0, l’ingenierie des exigences se jouera principalement au travers du Backlog de Sprint & User Stories dans une dynamique plus collaborative, toute aussi disciplinée mais moins formelle.
A bientôt pour plus de détails sur le Quoi et une idée du Comment.
Posté par jc-QualityStreet le 10 mai 2007
Google nous offre en version Bêta la nouvelle mouture de son application Google Analytics (outil de mesure et d’analyse d’audience Internet): mariage réussi entre complexité technologique, richesse des informations et des fonctionnalités et facilité d’utilisation.
L’interface est moins chargée que la précédente, le contenu mieux structuré, plus explicite, et plus facile d’accès; les graphiques impressionnants.
Les titres, données et informations importantes sont bien mises en avant.
Google propose surtout (et c’est trés appréciable) un tableau de bord configurable (flexibilité, efficacité et efficience) mais aussi un système d’envoi d’emails et des pages “sommaire” pour les rubriques principales contenant raccourcis, et liens transversaux vers les tâches et données principales.
Au programme également:
- des tableaux (listes) épurés, clairs avec de multiples possibilités d’affichage
- de nouvelles formes d’interaction (pour le choix des dates- bien repositionné d’ailleurs, des segments et segments croisés par exemple)
Exemple de calendrier :
Exemple de tableau de données :
Enfin la partie Aide n’a pas été négligée, tout comme l’accompagnement de l’utilisateur dans sa tâche et dans la transition entre ancienne et nouvelle interface.
Bref, une application web de haut niveau en version Bêta, donc optimisable!
MàJ: Un article (en anglais) pour découvrir tous les détails de cette nouvelle interface
