L’ergonome AGILE

Posté par jc-QualityStreet le 7 juin 2007

Après le chef de projet Agile … l’Ergonome Agile

L’agilité véhicule pas mal d’idées reçues. Je me suis attaqué à l’une d’entre elle en soulignant la forte complémentarité entre Offshore et Méthodes Agiles. Pour autant, d’autres mythes circulent souvent à propos de ces méthodes:

• « Pas de documentation », (au contraire la doc. existe mais on va à l’essentiel, Juste ce qu’il faut)
• « Pas de discipline, pas de planning » (au contraire, les dates sont fixes -Time boxing-, le contenu des plannings est même plus précis puisque réactualisé à chaque itération, les jalons sont posés : la visibilité est un vrai point fort),
• « ERGONOMIE ET METHODES AGILES NE FONT PAS BON MENAGE »: là malheureusement, il y a du travail …

Pour avoir sa place dans des équipes Agile, l’Ergonome doit selon moi adapter sa démarche (plus de pragmatisme et de réactivité; d’ailleurs Dan Saffer, d’Adaptive Path, va dans ce sens), adapter ses outils (pour plus d’efficience), adapter ses livrables (en allant à l’essentiel mais toujours en fonction de ses destinataires) … et surtout convaincre de l’utilité de son rôle (soyez rassuré, tout cela, je le détaille trés précisément, profil et activités, dans mon Manifeste pour une Ergonomie Agile). Cela passe par la démonstration :

• Du recouvrement possible par l’ergonome d’activités parfois délaissées par les équipes de développement (du côté du besoin, des exigences, de la validation), preuve de sa polyvalence
• De sa forte expertise et de sa plus value sur toutes les problématiques d’Interface Utilisateur
• De son savoir faire dans le dialogue et la communication avec les utilisateurs au travers d’interviews, de réunions de validation, de tests utilisateurs ou d’ateliers de travail (fonctionnels ou de conception).

Biensûr des différences entre les deux approches existent, mais en contrepartie, l’ergonome peut bénéficier de leviers forts (des conditions trés favorables pas toujours présentes dans les cycles traditionnels) sur lesquels il va pouvoir asseoir son action: livraisons fréquentes, validation continue, coopération et implication forte des clients et utilisateurs tout au long du projet, accent mis sur la simplicité.

Ainsi l’ergonome a longtemps cherché (et cherche toujours, il n’a guère le choix) à intègrer une démarche de conception centrée Utilisateur (de type ISO 13407 ou “Usability Engineering Lifecycle” de Mayhew) à des cycles de développement logiciel traditionnels (cascade ou V).
Récemment et cette fois dans une perspective itérative et incrémentale, le RUP (instanciation la plus connue, la mieux documentée mais aussi peut être la plus lourde du Processus Unifié) a permis de démocratiser en ingenierie logicielle des termes comme UI Designer, Usability, User Testing, User Experience (en plugin svp).

Aujourd’hui, des groupes de discussion influents tel que « Agile usability » et des personnalités (Jeff Patton, Alain Desilets, Larry Constantine, Scott Ambler…) cherchent à aller plus loin; parallèlement les méthodes Agiles se font connaître en France:

le temps est donc venu pour l’Ergonome de devenir Agile.

Dévelopement Offshore : de l’itératif, du Timeboxing sinon rien ….

Posté par jc-QualityStreet le 25 avril 2007

Gérer des itérations en timeboxing (”la date de fin d’une itération est fixe, on ne la bouge pas ; en cas de difficultés, on peut jouer sur le contenu à réaliser en le reportant par exemple à l’itération suivante”) est le premier principe à respecter quand on s’engage dans le développement offshore, un contexte dans lequel les méthodes traditionnelles (cycle en V…) ont clairement montré leurs limites.
Vincent Massol, dans son livre blanc « Le Développement Offshore Agile » , nous explique pourquoi l’utilisation des méthodes agiles en Offshore est essentielle. A l’arrivée,

L’agilité diminue le risque projet dû à l’éloignement
L’agilité permet de réaliser des projets complexes en Offshore
L’agilité permet d’augmenter la productivité en soignant la motivation des équipes

D’ailleurs, l’utilisation de courtes itérations et le timeboxing, est une de ses 10 règles d’or permettant d’assurer le succès de projets de développement Offshore.
Itération, Timeboxing, il existe désormais un véritable consensus parmi les experts français du domaine (Développement Offshore) ; Eric O’Neill va lui aussi dans ce sens dans son livre « Conduite de projets informatiques offshore » :

Le processus itératif est primordial pour gérer efficacement un projet en Offshore. C’est le seul moyen de juger de l’avancement du projet et d’en tirer les conclusions pour améliorer les points faibles.

C’est pour lui l’une des clés de la gestion de projet.
En terme de méthodologie, les instantiations du Processus Unifié (notamment RUP ou AUP), simplifiées, réorganisées et réorientées pour s’adapter aux contextes offshore semblent faire l’unanimité parmi ces spécialistes.
Outre l’itératif, UP dans ce contexte bénéficie de réels points forts : “la gestion des exigences ” (sur la base d’une liste des exigences et de cas d’utilisation, ici les “User stories” ne sont pas forcément des plus adaptées), ” une documentation adaptée” (juste ce qu’il faut), “des build permanents“, un focus sur les tests (unitaires et autres en fonction des exigences) …
Si l’on ajoute des principes de gestion de projets plus agiles (un “scrum daily meeting”, deux trois fois par semaine, le “burndown chart”…), des moyens communication adéquats et l’intégration des activités et livrables de l’ergonome, on peut obtenir des résultats intéressants…
Dans tous les cas, vous pouvez aussi suivre les précieux de conseils de Martin Fowler, fondés sur l’expérience réussie de ThoughtWorks, acteur majeur de l’offshore, notamment entre Inde, USA et UK, et qui prône depuis quelques années l’adoption des principes agiles pour ce type de projets.

Développement Offshore: toujours plus agile…

Posté par jc-QualityStreet le 11 avril 2007

Certains ont choisi de mixer offshore et Méthodes Agiles avec succès…
Envisager le développement informatique Offshore (c’est à dire la sous-traitance d’un développement informatique dans un pays éloigné) ou passer d’un mode de développement “séquentiel” aux méthodes agiles, sont deux stratégies différentes répondant pourtant aux mêmes besoins de la part des entreprises:

• Baisser les coûts de développement
• Augmenter la flexibilité des équipes
• Réduire les délais de mise en marché
• Améliorer la qualité

On sépare souvent ces deux statégies argumentant qu’Offshore et Méthodes Agiles ne font pas bon ménage, que l’Offshore va à l’encontre des principes Agiles…
Depuis quelques années, certaines sociètés ont pourtant fait le pari de mixer les deux approches espèrant un cumul des bénéfices de chaque stratégie et donc un avantage concurrentiel évident. C’est ce que tend à démontrer ce rapport de Forrester, signé Stéphanie Moore et Liz Barnett…
Plus récemment, l’agilité est apparue comme une réponse aux échecs des premières tentatives Offshore opèrées par quelques éditeurs de logiciels et SSII, comme un remède aux problèmes de communication, au manque de visibilité sur l’état d’avancement du projet, aux dérapages budgétaires, ou encore aux livraisons non adéquates.
Mais tout n’est pas si facile et des adaptations sont nécessaires… encore une fois le Processus Unifié semble être un bon compromis, toujours avec notre dose de SCRUM et une forte implication de l’ergonomie tout au long du projet.

Méthodes Agiles : une comparaison

Posté par jc-QualityStreet le 4 avril 2007

Les méthodes agiles suscitent à l’heure actuelle beaucoup d’interêt.
Ce trés bon article de synthèse (en anglais) se propose de comparer les principales : dans une première partie vous retrouverez notamment XP, SCRUM et Lean Development Software, dont on parle pas mal en ce moment. Dans une seconde partie, Rod Coffin et Derek Lane décrivent entre autres l’Agile Unified Process de Scott Ambler, et proposent surtout en dernière page de l’article des tableaux comparant ces méthodes selon différents critères.
Dans le même registre, vous avez le livre de Craig Larman, ”Agile and iterative development : A Manager’s guide”, qui lui aussi fait le point (de manière plus détaillée évidemment) sur ces différentes méthodes.
En tout cas, vous connaissez mon avis sur ce sujet: UP, une dose de SCRUM et quelques pratiques XP… maintenant, il faut toujours rester à l’écoute.

User stories, Use cases : les différences

Posté par jc-QualityStreet le 30 mars 2007

MàJ: Un bon récap et le TABLEAU SYNTHETIQUE DES DIFFERENCES dans ce billet Use Case vs User Story

“User stories” (c’est à dire “Récits d’utilisateurs” ou plutôt “Histoires d’utilisateur“ comme le suggère Claude Aubry) et “Use cases” (”Cas d’utilisation”) ont des similitudes (mon précédent billet, “Use cases, User Stories ? “) mais aussi de réelles différences qui, en fonction de notre contexte, vont nous permettre d’opter pour l’une ou l’autre de ces deux techniques de spécification des exigences fonctionnelles:

• “User stories” et “Use cases” n’ont pas la même portée, n’ont pas le même niveau de détail. Une “User story” s’écrit en une courte phrase (Rôle -> But) alors que le “Use case” est beaucoup plus riche en informations. Il possede un Titre (le but), est liè à un Acteur, propose un Résumé, et surtout, décrit un Déclencheur, un Scénario nominal (séquence d’actions de 3 à 9 étapes), les Variations à ce scénario nominal (à toutes les étapes), ainsi que tous les Cas d’erreur et leur mode gestion. Il peut décrire aussi les règles metiers et les données.
• Une “User story” propose donc uniquement un but, pas une séquence d’actions.
• Une “User story” correspond souvent et seulement à l’un des scénarios (nominal ou alternatif) du “Use case”.
• Une “User story” ne nécessite pas un travail d’analyse aussi poussé que le “Use case” (spécification mais aussi gestion, une activité trop souvent sous estimée).
• Les “User stories” émergent plus rapidement (en 1 ou 2 ateliers de travail).
• Les “User stories” se lisent plus facilement d’autant que les “Use cases” sont souvent mal écrits ou mal présentés.
• Les “User stories” sont rédigées (en principe) sur des cartes: leur durée de vie est limitée et elles n’ont pas pour vocation à être conservées (contrairement aux “Use cases”). Or, ce besoin de traçabilité peut être réel.
• Les “User stories” reposent sur un mode oral, collaboratif, de proximité : elles sont discutées (Customer / Developer) et tout n’est pas rédigé (contrairement aux “Use cases”). Or ce besoin de formalisme peut lui aussi être réel (gros projets, équipe importante, offshore…).
• Les “User stories” contiennent d’entrée des tests d’acceptation (rédigés au dos de la carte); les “Use cases” sont une base solide et efficace pour les tests fonctionnels mais ceux-ci sont réalisés plus tard et ailleurs.
• Une “User story” doit être implémentée et testée en une itération. Un “Use case” peut être traité sur plusieurs itérations (scénario nominal sur une, scénarios alternatifs sur une autre) en fonction des risques à lever.
• “Use cases” ou “User stories” : le choix va impacter le mode d’estimation et de planification du projet (”Technique des points de cas d’utilisation” / “Points d’histoire d’utilisateur et vélocité d’une itération”).
• Les relations entre “User stories” ne sont pas toujours évidentes; le problème est moindre pour les “Use cases” grâce notamment au diagramme de cas d’utilisation (qui accompagne les “Use cases”), et aux notions de package, inclusion, extension.
• Enfin, les “User stories” sont issues de l’univers “Extreme programming” alors que les “Use Cases” sont intimement liés au “Processus Unifié“. L’usage de telle ou telle technique sera donc aussi fonction de la méthode de développement utilisée: UP, RUP, XP, SCRUM…

Use cases, User stories ?

Posté par jc-QualityStreet le 26 mars 2007

MàJ: Le comparatif sous forme de tableau synthétique dans ce billet Use Case vs User Story

Ou plutôt Cas d’utilisation (pratique Processus Unifié, UP), Récits d’utilisateur (pratique Extreme Programming, XP) ?… la question se pose car il s’agit de deux modes de représentation des exigences (fonctionnelles) utilisées dans le cadre des Méthodes Agiles.

J’ai toujours utilisé (moi même rédiger, former, et exploiter) les Cas d’utilisation (MàJ du 08/11/2007: des conseils de rédaction, un modèle et le lien avec UML dans ce billet Cas d’utilisation UML … oui mais… ).

Bien rédigés, ils complètent idéalement le travail que je peux produire pour les utilisateurs, concepteurs et développeurs sur un projet. Mais je réfléchis, comme pour SCRUM (cf. “UP et une dose de SCRUM”) à ce que je pourrais tirer des “User Stories“.
Soyons clairs, les “Use Cases” me semblent plus adaptés à la plupart des projets sur lesquels j’interviens (projets et problématiques métiers importants, taille de l’équipe moyenne, nécessité de formalisation, équipe sur deux sites et Offshore envisagé) mais pour certains projets (délais courts, “métier connu“, équipe réduite, client disponible), les “User stories”, plus concis, allant à l’essentiel et plus rapidement écrits pourraient s’avérer plus appropriés; j’ai déjà quelques idées…

Une “User story” est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l’utilisateur.

Exemples de “User stories”: “En tant qu’utilisateur, je peux réserver des chambres d’hôtel”, “En tant que recruteur, je peux déposer des offres d’emploi”.
Ron Jeffries utilise les 3 C pour la décrire:

• Card (l’histoire est courte et écrite sur une carte 8×13 cm)
• Conversation (les détails de l’histoire sont discutés)
• Confirmation (l’histoire est confirmée par des tests d’acceptation rédigés au même moment que celle-ci, au dos de la carte).

Un “Use case” modélise un sevice rendu par le système. Il représente un ensemble de séquences d’actions qu’un système ou toute autre entité peut accomplir en interagissant avec les acteurs du système.

Exemples d’intitulés de “Use cases”: “S’authentifier”, “Rechercher un livre”. Ces titres ne sont qu’une partie du “Use Case” qui comporte d’autres parties (Acteur, Résumé, Déclencheur, Scénario principal, Extensions…). Un “Use Case” est donc plus détaillé, et nécessite un travail approfondi d’analyse et de formalisation.

Alors pourquoi cette réflexion ? d’une part, comme je le disais, j’ai le sentiment que certains contextes se prêtent mieux aux “User Stories“, d’autre part “User stories” et “Use cases” se rejoignent sur beaucoup de points (pour les différences, consulter ce billet):

• “User Stories” et “Use Cases” formalisent les besoins utilisateurs et sont orientés “But”
• Ils font facilement l’objet d’ateliers de travail avec les utilisateurs pour les découvrir, les expliciter
• Ils vont être priorisés et vont ainsi guider les développements
• Ils mettent en avant les rôles, les différents profils d’utilisateurs
• Ils ne traitent que des exigences fonctionnelles (les aspects “non fonctionnels” sont décrits dans “les exigences non fonctionnelles” (contexte UP) et dans les “Constraints Cards” (contexte XP))
• Ils sont textuels et obéissent à des régles de construction trés précises (Travaux de Rachel Davis, ou critères “INVEST” pour les “User Stories”)
• Ils ne traitent pas des aspects interface et ergonomie (détails abordés dans les exigences d’ergonomie (contexte UP), livrables d’ergonomie, prototypes (contextes UP et XP))
• Ils peuvent être rédigés par les analystes (pour les UC c’est conseillé; pour les “User Stories“, c’est plutôt l’utilisateur ou un membre de l’équipe Client, composée de ceux qui vont s’assurer que le produit répond aux besoins des utilisateurs, c’est à dire Utilisateurs eux-mêmes, Directeur de produit, Analyste ou encore Ergonome)
• Ils ont chacun leur auteur et ouvrage de référence (Alistair Cockburn, “Rédiger des cas d’utilisation efficaces“, Mike Cohn, “User Stories Applied For Agile Software Development“).

Dans un prochain billet, j’aborderai les différences majeures entre “Use Cases” (Cas d’utilisation) et “User Stories”, ce qui me permettra de détailler davantage leur mode de construction et d’envisager l’impact de telle ou telle technique notamment en terme de Qualité Logiciel.