Le développement Agile transforme le business

Posté par jc-QualityStreet le 29 juin 2007

CNN vient de lister les 50 personnes, produits ou tendances, qui révolutionnent le monde des Affaires (au sens large), et classe le mouvement Agile (oui oui nos fameuses méthodes Agiles) en 18ème position (le trio de Google et Steve Jobs occupant les 2 premières places) : le classement et la fiche de la 18ème place
L’itératif, l’incrémental mais aussi le respect des coûts et des délais sont mis en avant.

Un petit (tout petit) pas pour convaincre les décideurs de s’engager dans cette voie (ou du moins de la tester).

Spécifications, Exigences et Cahier des charges : Qui, Quand ?

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)

Évidemment, 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, la maîtrise de diverses techniques souvent complémentaires (issues des Sciences Humaines), et pas mal de rigueur…
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…

Dans un contexte agile, on parlerait de Product Owner. Plus largement, l’Analyste, le Consultant, le Client sont 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 (suffisamment ouverts) sont quant à eux le fruit de l’activité de recueil, et servent souvent de déclencheurs pour la suite des opérations en mode agile, itératif ou séquentiel.

Dans une perspective séquentielle (cascade ou V: le pire), l’enchaînement est simple et bien connu. 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.

Non ce qui marche, c’est l’AGILITE avec une bonne dose d’analyse, de test et d’expérience utilisateur.

Dans une perspective agile donc (l’idéal)

… 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 produit  & User Stories dans une dynamique plus collaborative, toute aussi disciplinée mais moins formelle. Le backlog de produit servira donc de fil rouge

Dans une perspective seulement 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.

A bientôt pour plus de détails sur le Quoi et une idée du Comment.

MIX 07: Ergonomie Design, les présentations

Posté par jc-QualityStreet le 22 juin 2007

Le Mix07 Paris vient tout juste de s’achever et les deux presentations de la session “Designer d’expériences interactives” sont déjà disponibles sur Slideshare:

• Ergonomie et Experience Utilisateur, Sophie-Laure Pilverdier (Steria)
• Evolutions du métier du Design Interactif, Benoit Drouillat (Designers interactifs)

Deux présentations originales, trés complémentaires qui mettent l’accent sur les individus, les savoir-faire, les nouvelles compétences (selon moi largement exploitables dans des contextes, UP et Agiles), le tout, dans un style plutôt dynamique.

Bon sans le son ni les commentaires des intervenants (je n’y étais pas), voici mes impressions !! … les visuels de Benoit Drouillat sont particulièrement bien réussis et les phrases clés captent instantanément l’attention : le concept d’évolution pour nos métiers me semble des plus pertinents.
L’axe des “Savoir-faire de l’Ergonome” proposé par Sophie-Laure Pilverdier est quant à lui trés efficace, les illustrations bien choisies, les messages clairs (les utilisateurs et leurs buts sont placés au centre des préoccupations__…). C’est trés pro, et ça me parle !

Ci-dessous la capture d’un slide assez réussi illustrant une activité souvent sous estimée, souvent bâclée et pourtant vitale pour la réussite de nos projets : la préparation et la conduite du changement.
Les deux exemples, Fickr (Yahoo Photos vers Flickr, dans un style incitatif) et Google Analytics (Ancienne version vers Nouvelle version, toutes deux encore disponibles jusqu’au 18 Juillet) sont trés bons et d’actualité.

Changement à envisager au plus tôt, dans un esprit Agile !

Votre feedback ? si vous y étiez.

Ergonomie, Tests Utilisateurs et Agilité

Posté par jc-QualityStreet le 19 juin 2007

Toujours dans la lignée de l’Ergonome Agile, le retour d’experience de Desirée Sy (d’Autodesk) sur la réalisation de tests utilisateurs dans des contextes agiles : « Adapting usability investigations for Agile User-Centered Design ».
Son « User Experience Group », habitué à travailler dans de le cadre cycles en cascade, a dû modifier son approche pour s’adapter à des cycles itératifs plus courts :

• Ajustement sur la façon de préparer et mener les tests Utilisateurs (temps, granularité, protocole, types de participants…)
• Ajustement sur le mode de présentation, de transmission et d’exploitation des résultats
• Ajustement sur la façon d’envisager le design des écrans : découpage en fonction des priorités, des risques, création progressive

Au final, des bénéfices constatés :

• Conception plus fluide, mieux réussie
• Réduction des biais dû à une mauvaise interprétation des feedbacks utilisateurs
• Mode de communication plus efficace avec les équipes
• Implémentation rapide des changements demandés suite aux tests: dans l’itération suivante et pas 2 ans plus tard !!
• Mise en place d’une démarche de tests utilisateurs tout au long du projet : pas seulement à la fin ni au début

MIX 07 et Design interactif

Posté par jc-QualityStreet le 14 juin 2007

Microsoft organise le 21 juin prochain, au Cirque d’Hiver (Paris) son MIX 07.
Au programme, des nouveautés évidemment, mais aussi un focus sur le Design interactif avec les interventions attendues de deux experts du domaine : Benoit Drouillat (WordAppeal et Designersinteractifs.com) et Sophie Pilverdier (User Experience & Human Computer Interaction Group, Steria); signe de la convergence entre une démarche davantage de type “créative” et une démarche plus axée “ergonomie”.
Ne pouvant me rendre à ce RDV, j’espère être en mesure de récuperer leurs présentations respectives; par ailleurs, pour ceux qui auront le plaisir de s’y rendre, n’hésitez à revenir sur QualityStreet pour me dire ce que vous en avez pensé.

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.