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 …
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.
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.
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.
Posté par jc-QualityStreet le 3 février 2007
“Le processus unifié est un processus de développement logiciel, c’est-à-dire qu’il regroupe les activités à mener pour transformer les besoins d’un utilisateur en système logiciel” (Jacobson, Booch, Rumbaugh 1999)
Il est le fruit des meilleures pratiques de l’ingénierie logicielle: des approches éprouvées pour développer et maintenir des logiciels de qualité.
Pourquoi passer au Processus Unifié ?
Le processus Unifié est en mesure de répondre directement ou indirectement à à ces problématiques, n’hésitez donc pas à en lire un peu plus !
- Vous explosez vos budgets
- Vous dérapez sur les délais ce qui retarde la mise en marché de vos produits
- Vos clients ne sont pas satisfaits de la qualité de vos produits
- Vos produits ne font pas, au final, ce qu’il sont censés faire, sans compter les bugs !
- Vous ne parvenez pas à gèrer le moindre changement demandé en cours de projet
- Vous manquez de visibilité sur vos projets, d’ailleurs vous avez commencé du développement Offshore et c’est encore pire!
- Vos équipes de développement ne savent pas ce qu’elles ont à faire ou ne semblent guère motivées
- Vous perdez du temps à refaire sans cesse les mêmes choses
- Vous n’avez rien à communiquer à vos clients, dailleurs vos clients vous ne les revoyez qu’à la fin !
- Vous avez besoin d’un “cadre” que les autres méthodes Agiles (XP ou SCRUM) ne peuvent vous proposer …
Son origine
Le terme “Unifié” est trés approprié puisqu’il s’agit de la fusion des travaux d’Ivar Jacobson, Grady Booch (au départ chez Objectory) et de James Rumbaugh, enrichie de nombreux apports issus d’UML (développé en parallèle) et du produit commercial RUP, sorti en 1998 et toujours mis à jour par IBM (aprés le rachat de Rational qui avait lui même acheté Objectory en 1995).
D’autres ont permis de peaufiner le processus, notamment Walker Royce et Philippe Kruchten pour la planification et la gestion de projet.
Ses principes
Le Processus Unifié (UP) est piloté par les cas d’utilisation (eux même guidés par les risques) centré sur l’architecture, itératif et incrémental.
Le projet sera donc mené selon les besoins et les exigences (fonctionnelles et non fonctionnelles) : points d’entrée sur lesquels l’analyse des risques va principalement s’exercer pour organiser les plans d’itération, et pour moi en tant qu’ergonome c’est important.
Les risques majeurs (souvent liés à l’architecture) seront traités en premier lieu dans le but de les lever au plus tôt: gestion et pilotage par les risques, de vrais points forts pour la méthode.
Le Processus Unifié est opposé au cycle de vie en cascade (ou séquentiel) trop figé et rigide, et se lit selon deux axes: vertical (enchainement de disciplines et d’activités au sein d’une itération) et horizontal (enchainement dynamique sur l’axe temporel de phases et d’itérations). On va donc par exemple, tester à chaque itération sans attendre la fin du projet…
Il définit donc 4 phases :
- Inception (courte pour estimer, planifier, partager une même vison du problème, et engager les hostilités),
- Elaboration (architecture définie, risques majeurs levés, exigences trés avancées, programmation largement engagée)
- Construction (plus d’itérations mais plus courtes; développement de toutes les fonctionnalités, doc incluse)
- Transition (préparation du lancement, tests beta, formation des utilisateurs, optimisation …).
Mais le Processus Unifié permet aussi et surtout de définir des disciplines, des activités, des rôles et des livrables: en cela il est beaucoup plus complet que la plupart des autres méthodes agiles (XP ou SCRUM) qui n’abordent pas ou trés peu ces questions.
Autre avantage, le Processus Unifié est customisable que ce soit à partir de sa forme la plus répandue et la mieux documentée, le RUP, ou à partir des autres instanciations qui ont été faites ces dernières années :
Les évolutions récentes cherchant à être plus légères, plus agiles.
Bref, à vous de l’adapter à votre contexte (organisation, types de projet…) pour qu’il réponde efficacement à vos besoins.
Ses six bonnes pratiques
L’application de ces principes ne peut vous assurer à 100 % de la réussite de votre projet; disons simplement qu’elle y contribuera fortement.
- Iterations courtes de 3 à 6 semaines avec les principes du Timeboxing (on ne bouge pas les dates, on ajuste le contenu des itérations) et du pilotage par les risques
- Développements centrés sur l’architecture (et orientés sur les risques majeurs) avec le principe de la réutilisation des composants
- Focus sur la qualité (tester tôt et souvent, niveau unitaire, intégration, système) avec les principes de la validation et de l’intégration continues
- Modélisation graphique (UML, digrammes, grilles …) avec le principe de l’utilisation du visuel pour communiquer
- Gestion des exigences (organisation, traçabilité, évolution des exigences)
- Contrôle du changement (anticipation, gestion des demandes) avec le principe du réajustement (feedback, adaptation)
Son adaptation, sa customisation
Avant tout être “Agile” (c’est un état d’esprit), faire simple en ne retenant que le strict nécessaire; voici ma démarche:
- S’attaquer aux processus
- Mettre en avant les bonnes pratiques
- Identifier de manière pragmatique ce qui se passe sur les projets en termes de rôles, activités et disciplines. Ce fut notamment pour moi l’occasion d’officialiser certains rôles (dont l’ergonome…)
- Etablir une première mouture et l’appliquer sur 2 ou 3 projets pilotes
- Conduire le changement et généraliser
- Capitaliser et faire évoluer de nouveau
Les pre-requis pour mener à bien ce type de mission :
- bonne connaissance de l’organisation,
- vue globale sur les projets de l’entreprise et sur les activités des différents acteurs,
- bonne connaissance du RUP (bien documenté c’est une bonne référence),
- ouverture sur les différentes instanciations et les autres méthodes agiles (XP, SCRUM)
Les erreurs malheureusement souvent commises
Elles sont le signe d’une mauvaise interprétation du Processus Unifié:
- Decrire les phases d’UP comme les phases du mode séquentiel. L’inception n’est pas que l’analyse des besoins, la transition n’est pas une phase de test. La construction, ce n’est pas que du code ! Toutes ces disciplines peuvent avoir lieu en même temps dans une itération (comme l’indique le schéma).
- Commencer d’entrée par un planning ultra détaillé pour les 12 mois à venir
- Planifier des itérations trop longues (une itération dure entre 2 et 6 semaines : le but est d’être réactif)
- Décaler les dates d’itération à sa guise sans respecter le Timeboxing
- Ne pas tester dans une itération ce qu’on a produit
- Oublier que le but de la phase d’Elaboration n’est pas de produire un prototype jetable mais une architecture viable
- Analyser toutes les exigences avant de commencer à programmer
- Se dire qu’il faut absolument utiliser tous les livrables potentiellement utilisables
Pour aller plus loin…
- The Unified Software development process, Jacobson, Booch, Rumbaugh, 1999
- The Rational Unified Process, An Introduction, Philippe Kruchten, 2000
- Agile and iterative development : A Manager’s guide, Craig Larman, 2003
- Rational Unified Process Version 2003.06.01.06
