OpenUP: du Processus et de l’Agilité

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.

Manifeste pour une ERGONOMIE AGILE

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…

Lire la suite

Documentation Agile : Juste ce qu’il faut

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 …

Votre expert UP n’en est pas un …

Posté par jc-QualityStreet le 25 juillet 2007

• S’il décrit les phases du processus comme des phases séquentielles et insiste pour que la plupart des tâches soient effectuées avant le développement proprement dit
• S’il vous suggère des itérations de plus de 6 semaines
• S’il vous recommande de planifier une longue phase d’inception
• S’il vous recommande d’élargir le nombre de livrables plutôt que de les réduire
• S’il diffère sans cesse les tests … plus tard … rien ne presse
• S’il vous invite à produire toujours plus de diagrammes UML ….

Processus Unifié : 10 bonnes façons de se planter …

Posté par jc-QualityStreet le 18 juillet 2007

Adapter le Processus Unifié et basculer vers les méthodes Agiles ne se fait pas en un mois (c’était mon précédent billet); la démarche doit être rigoureuse, nécessite un vrai plan d’accompagnement du changement et passe par des jalons importants: Convaincre - Préparer et Planifier - Mettre en oeuvre - Evaluer, Raffiner et Améliorer.

Sinon, voici 10 bonnes façons d’échouer dans la mise en place du Processus Unfié :

1. Vous ne vous faites pas accompagner par un expert du Processus Unifié, et de ses différentes instanciations (RUP; AUP; Open UP …)
2. Vous adoptez trop d’éléments, votre process est trop lourd, et manque de souplesse
3. Vous faites une adoption Big Bang: on change tout et tout de suite, sans préparation, sans méthode et sans accompagnement !
4. Vous analysez vite fait votre processus de développement existant (type cascade) et croyez qu’UP s’y adapte parfaitement : y a presque rien à changer, vous dites-vous !
5. Au fond, vous n’adhérez pas : itérations, risques, intégration continue, c’est juste des concepts à la mode !
6. Vous pensez que ça prendra 3 mois et considérez votre Development case (la configuration du Processus Unifié à votre contexte) comme un aboutissement, une fin en soi !
7. Vous conservez des vieux noms de livrables, de vielles recettes au détriment de nouvelles techniques, de la nouvelle et bonne terminologie
8. Vous ne pouvez vous appuyer sur les bonnes personnes (niveau organisation) et des acteurs clés ne jouent pas le jeu
9. Vous ne disposez pas de chefs de projet formés et motivés
10. Vous continuez de faire des spécifications excessives avant de commencer le dév, de prévoir les tests à la fin, de fixer des plans détaillés de A à Z, modifier vos objectifs en cours d’itération, de bouger vos dates d’itération, vous faites les choses dans votre coin : bref vous n’avez rien compris !

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.