Posté par jc-QualityStreet le 11 septembre 2008
Itérer sur une proposition, recueillir le feedback, c’est trés bien …
(je dirais même c’est SUPER, assez tôt, c’est ce que préconise la Conception Centrée Utilisateur avec l’ISO 13407, c’est aussi une technique intégrèe par les méthodes Agiles ou le Lean Software Development),
… Mais, ce n’est pas faire du Développement Itératif, au sens Agile, au sens Ingenierie Logicielle, et ce n’est pas suffisant pour récolter un maximum de bénéfices…
WAIT! There is more to read… read on »
Posté par jc-QualityStreet le 3 avril 2008
C’est tout chaud, j’en sors tout juste…
Vous connaissez mon attachement à l’Agilité et au concept d’Open Space Technology; je ne pouvais donc pas manquer l’évènement organisé par Yannick Ameur, des praticiens de Paris (eXtreme Programming France).
Une trés bonne soirée passée parmi une trentaine de passionnés, autour de tableaux blancs, de bonnes pizzas (pour les 2ème sessions) et d’un bon café.
Côté logistique: démarrage à 19h (bon j’étais un peu en retard!) dans les locaux de nos amis de Valtech (dans le 8éme), 4 salles, 2 sessions de 45 min et une fin à 21h15 (c’est raisonnable !).
Les thèmes choisis et abordés (parmi ceux proposés):
- Quels ateliers en Sprint 0 ?
- Planning game
- FAIRE UNE RETROSPECTIVE
- Intégration continue
- Lean et Software development (allez voir mon dernier billet sur le sujet)
- Problem solving
- DEVELOPPEMENT IHM
- Quels engagements dans un contrat ? Sur quoi sait-on s’engager ?
Devinez donc les sessions auxquelles j’ai participé …
Bref une expèrience à renouveler, et que nous avons justement tous choisi de renouveler au minimum 1 fois par trimestre sur Paris, dans un lieu à définir à chaque fois, c’est un appel à contributions 
Merci à Yannick et à la prochaine fois…
Posté par jc-QualityStreet le 17 octobre 2007
Si vous n’étes toujours pas convaincu qu’OpenUP (”a lean Unified Process”) est un excellent compromis entre le RUP (instance la plus lourde du Processus Unifié) et les Méthodes Agiles, lisez cet article de Per Kroll, OpenUP In a Nutshell.
Peut-être vous incitera-t-il à télécharger OpenUP 1.0 (c’est gratuit), et à l’essayer au sein de votre organisation ! D’ailleurs pour cela, n’hésitez pas à consulter mes quelques conseils ou ceux de Claude Aubry.
Mais revenons à Per Kroll:
A couple of years ago, several colleagues and I started to think about how you could create a stripped-down version of the IBM® Rational Unified Process®, or RUP®, reflecting an agile approach to using RUP, while at the same time leverage all the good things we liked in other agile processes, such as Scrum and XP.
… sa démarche me plait d’autant plus, que c’est l’esprit qui m’anime depuis plus de 2 ans… je me sens donc moins seul :).
Per Kroll nous propose ainsi, dans son introduction, quelques rappels sur le développement itératif et incrémental, le cycle de vie du projet, le pilotage par les risques et la création de valeur ainsi que la “philosophie” Agile. Cela dit, on reste un peu sur sa faim côté pratiques SCRUM, XP et LEAN …
Sinon pour les inconditionnels, Per Kroll vous en parle directement dans cette video diffusée sur INfoQ.
Posté par jc-QualityStreet le 30 septembre 2007
Vous êtes nombreux à m’avoir sollicité sur cette question de l’Ergonome Agile :
en quoi consiste concrètement son travail dans des contextes UP, OpenUP, XP, SCRUM, DSDM ou Lean ?
Comment intégrer l’Expérience Utilisateur, le Design d’Interaction et le Graphisme dans un projet appliquant l’une de ces nouvelles méthodes, dites Agiles (car opposées aux cycles de développement traditionnels, en cascade ou V) ?
Tout d’abord, un constat : l’intégration d’une conception centrée utilisateur dans un contexte Agile n’est pas aisée, l’ergonome n’est pas attendu, et s’il ne parvient pas à prouver rapidement sa plus value, ou pire s’il retarde les équipes de dév. … on le sortira poliment du projet, c’est ça le Lean Thinking !!
Pourtant, croyez-moi les projets Agile ont un réel besoin d’ergonomie !!
L’ergonome Agile introduisait la nécessité pour nous autres Ergonomes ou Spécialistes de l’Interface Utilisateur, d’adapter notre démarche, nos outils et nos ivrables pour une collaboration plus efficace au sein d’équipes fonctionnant en mode itératif, incrémental. Cet article vous présente donc quelques pistes concrètes d’intégration de notre démarche mais n’hésitez pas à me contacter si vous voulez en savoir plus …
« … Le temps est donc venu pour l’ergonome de devenir Agile … », telle était donc ma précédente conclusion, mais quelles spécificités du profil de l’Ergonome Agile vont rendre sa collaboration plus efficace et surtout plus efficiente ? Quelles dimensions de son activité seront bénéfiques au projet, au client, aux utilisateurs finaux et en quoi son intervention donnera-t-elle satisfaction à l’équipe de développement ?
D’ABORD LE PROFIL DE L’ERGONOME AGILE
L’ergonome Agile possède…
WAIT! There is more to read… read on »
Posté par jc-QualityStreet le 3 septembre 2007
Plus qu’une simple tendance, le rapprochement des Méthodes Agiles et du CMMI (Capability Maturity Model Integration), ou plus exactement l’usage de pratiques de développement Agiles (qui ont le vent en poupe) dans une dynamique de processus guidée par le CMMI (version1.2 DEV d’aout 2006) est bel et bien réel.
Les exemples concernant XP et SCRUM (voir les études de Mickael Spayd, Mark Paulk, Hillel Glazer ou encore Jeffrey Dutton) se multiplient depuis quelques années.
Dernier exemple en date (trés bien documenté d’ailleurs), celui de Codice Software (un éditeur espagnol), “SCRUM Meets CMMi, Agility and discipline combined“, avec à la clé l’atteinte d’un niveau 2 de maturité et une vision trés pragmatique de la combinaison des deux approches (un vrai travail sur REQM, “Gestion des exigences”, des domaines complètement nouveaux et pas des plus simples dans un contexte Agile: PPQA, “Assurance Qualité Processus et Produit” et MA, “Mesure et Analyse”….).
Dans un contexte plus général, cette démarche de réconciliation Agile CMMI (c’est un bien grand mot !) est soutenue, et c’est trés positif, par des acteurs majeurs des deux “camps”, mais elle implique aussi, selon moi, à notre niveau, l’acceptation de certains prérequis:
- D’abord considèrer le CMMI tel qu’il est, à savoir, un modèle, un guide, et non pas un processus ou une méthode de développement.
- Se souvenir que le CMMI définit seulement le QUOI (par ses objectifs par exemple) et non pas le COMMENT, même si le modèle propose quelques pistes. Et c’est vrai que cette absence de COMMENT a laissé la part belle aux méthodes dites traditionnelles (cascade ou V) toujours bien ancrées.
- Ne pas oublier que seule l’atteinte des objectifs généraux (GG, liés à un niveau de maturité) et spécifiques (SG,liés à un domaine de processus) est requise lors d’une évaluation SCAMPI (méthodes standards d’évaluation). Les pratiques (GP, génériques liées à un niveau et SP, spécifiques liées à un domaine de processus) ne sont quant à elles pas obligatoires, et des alternatives (Agiles notamment) sont envisageables : c’est un bon point d’entrée.
- S’arracher des idées reçues concernant les deux Mondes … (vaste débat), rechercher l’ouverture, et d’un point de vue pratique, au quotidien, s’appuyer sur des leviers organisationnels exploitables.
David Anderson a su trouver les mots justes lors de l’Agile2005:
A key to achieving more agility with the CMMI is to realize that the practices are primarily advisory or indicative only. To meet a CMMI appraisal, an organization must demonstrate that the goals of a process area are being achieved. This is done by identifying evidence of practices. However, the practices need not be the ones described in the CMMI specification. The organization is free to propose alternatives practices and appropriate evidence. The appraisal team must then agree to whether this is appropriate to demonstrate the goal. This provides a process designer with a great deal of freedom.
En conclusion, si vous entendez les mots Agile et CMMI dans la même phrase, ne fuyez pas … soyez curieux … et dites OUI à la convergence.
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.
