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 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…
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
Posté par jc-QualityStreet le 12 janvier 2007
Doit-on considèrer le RUP (et plus globalement le Processus Unifié, UP, c’est souvent le débat) comme une méthode agile ? Les points de vue de Kroll, Ambler et Jacobson. Rien que ça !!
Pour ma part, je partage l’avis de Per Kroll :
“So, use a light version of RUP correctly, and it is agile. Way to many use a way too heavy version of RUP, without following the (agile) spirit of RUP…”
Pour l’avoir appliqué il ya quelques années (le RUP) et pour l’avoir adapté chez mon employeur (UP), il me semble aussi que c’est certes une question de mesure mais aussi et avant tout une question d’état d’esprit.
On peut être agile en appliquant UP comme on peut ne pas l’être… d’où la nécessite de bien étudier son contexte, de faire un point sur ses pratiques et ses besoins, d’accompagner le changement en douceur. Ne prendre que ce qu’il faut et appliquer les bons principes… d’autant qu’UP est trés clairement en accord avec les 12 principes de l’Agile Manifesto !
