Posté par jc-QualityStreet le 23 octobre 2007
Une charte ergonomique est un référentiel qui définit les spécifications ergonomiques de conception (principes de navigation, présentation des informations, éléments d’interaction et de dialogue …) pour une application (ou plusieurs si elles relèvent de la même technologie, par exemple, l’ensemble des applications Web d’un Editeur).
On me demande presque toujours sur un projet nouveau, si je vais proposer un tel Guide d’ergonomie et surtout quand il sera disponible… comme si ce référentiel pouvait à lui seul garantir que l’interface sera « conviviale » 
Or, ce qui compte pour moi avant tout, c’est de déterminer quand cette charte sera la plus utile et la plus pertinente pour les équipes de développement, sa granularité, et tout simplement la valeur d’un tel référentiel sur mon projet.
En somme, je ne la propose pas systématiquement … une charte ergonomique, ce n’est pas une DEMARCHE ERGONOMIQUE !
Par ailleurs, j’opte de plus en plus pour une vision allégée de charte ergonomique, gérée en configuration, décrivant dans un premier temps la posture de l’application, son squelette, la forme générale de l’interface, et enrichie ensuite de manière incrémentale. J’utilise alors pour illustrations le contenu (Storyboard, Wireframes) des itérations sur lesquelles j’interviens.
Documentation, juste ce qu’il faut … rédiger des chartes d’une centaine de pages, certes visuelles mais pas toujours lues, comme j’ai pu le faire dans le passé, c’est bel et bien terminé ! certes c’est détaillé, c’est précis, “ça flatte l’ego” mais au bout du compte, le plus intéressant dans une charte ergonomique, c’est quand vos principes majeurs sont discutés, appliqués et quand 1 ou 2 développeurs motivés s’approprient votre référentiel, le décortiquent et le transforment tout ou partie en composants réutilisables.
C’est à ce moment là que les gains sont les plus forts : Ergonomie standard, juste et cohérente, Homogénéité des interfaces, Rapidité et Qualité des développements.
Bref, on élimine pas mal de zones d’incertitude !!
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 :
- La démarche de découverte et de construction progressive des cas d’utilisation: l’essentiel …
- La forte adéquation avec le développement itératif (dans l’estimation, la priorisation, la planification, le traitement)
- La complémentarité avec le travail de l’Ergonome
- La lisibilité, le formalisme des cas d’utilisation (élément clé de son efficacité et de son acceptation par les équipes)
- La gestion des modifications (pas si simple que ça!)
- Le lien fort avec les cas de tests et une approche de validation fonctionnelle (c’est l’idéal!)
… 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 20 septembre 2007
Bien plus qu’un livrable, le Plan de Projet (appelé aussi Plan de développement Logiciel), est un outil indispensable au Chef de Projet ou au ScrumMaster, nécessaire à la bonne marche de tout projet informatique (petit ou grand).
Disons qu’avec un Plan de Projet à peu près complet, correct, bien préparé, bien pensé et finalement compris par les équipes, le projet débute sous les meilleurs auspices…
Le Plan de Projet est donc sous la responsabilité du Chef de projet (personnage ô combien crucial mais j’y reviendrai …) ou du ScrumMaster (contextes Agile-CMMI), et rassemble en son sein toutes les informations utiles et nécessaires pour gérer le projet. Il est donc l’élément fédérateur du projet, la référence sur laquelle chacun va s’engager, et qui sera évidemment ensuite accessible par l’ensemble de l’équipe.
A ce titre, il doit être soigné même si son caractère formel/ informel et la densité de son contenu vont varier en fonction des contextes, je pense notamment aux contextes Agiles, et des tailles de projet.
Voici un modèle de Plan de Projet (structure type):
Bref, le Plan de Projet fait partie de ce “Juste ce qu’il faut” de documentation qu’on retrouve aussi bien dans du process plutôt lourd (RUP) que dans des versions beaucoup plus light du Processus Unifié, OpenUP par exemple, ou encore dans d’autres méthodes Agiles comme SCRUM.
Mais le Plan de Projet est aussi central dans un contexte CMMI, au cœur du domaine de processus de niveau 2, Planification de projet (PP), et essentiel pour d’autres domaines comme la Gestion des exigences (REQM) et la Gestion des risques (RSKM). Autrement dit, si vous avez un Plan de Projet (ainsi que la démarche et le contenu qui vont avec …), c’est aussi un bon point de départ du point de vue du SEI quant à la maturité de ce domaine de certains processus.
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 :
- A la Valeur du doc (ou de l’artefact) par rapport à l’Effort pour le produire et surtout le maintenir, sans perdre de vue que notre but, notre métier, c’est faire du soft, c’est concevoir des applications informatiques, ce n’est pas produire du papier !
- En termes de réponse à un besoin, de bénéfice pour le projet, de feedback …
- Et toujours en fonction de destinataires potentiels
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 …
