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 26 mars 2007
MàJ: Le comparatif sous forme de tableau synthétique dans ce billet Use Case vs User Story
Ou plutôt Cas d’utilisation (pratique Processus Unifié, UP), Récits d’utilisateur (pratique Extreme Programming, XP) ?… la question se pose car il s’agit de deux modes de représentation des exigences (fonctionnelles) utilisées dans le cadre des Méthodes Agiles.
J’ai toujours utilisé (moi même rédiger, former, et exploiter) les Cas d’utilisation (MàJ du 08/11/2007: des conseils de rédaction, un modèle et le lien avec UML dans ce billet Cas d’utilisation UML … oui mais… ).
Bien rédigés, ils complètent idéalement le travail que je peux produire pour les utilisateurs, concepteurs et développeurs sur un projet. Mais je réfléchis, comme pour SCRUM (cf. “UP et une dose de SCRUM”) à ce que je pourrais tirer des “User Stories“.
Soyons clairs, les “Use Cases” me semblent plus adaptés à la plupart des projets sur lesquels j’interviens (projets et problématiques métiers importants, taille de l’équipe moyenne, nécessité de formalisation, équipe sur deux sites et Offshore envisagé) mais pour certains projets (délais courts, “métier connu“, équipe réduite, client disponible), les “User stories”, plus concis, allant à l’essentiel et plus rapidement écrits pourraient s’avérer plus appropriés; j’ai déjà quelques idées…
Une “User story” est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l’utilisateur.
Exemples de “User stories”: “En tant qu’utilisateur, je peux réserver des chambres d’hôtel”, “En tant que recruteur, je peux déposer des offres d’emploi”.
Ron Jeffries utilise les 3 C pour la décrire:
- Card (l’histoire est courte et écrite sur une carte 8×13 cm)
- Conversation (les détails de l’histoire sont discutés)
- Confirmation (l’histoire est confirmée par des tests d’acceptation rédigés au même moment que celle-ci, au dos de la carte).
Un “Use case” modélise un sevice rendu par le système. Il représente un ensemble de séquences d’actions qu’un système ou toute autre entité peut accomplir en interagissant avec les acteurs du système.
Exemples d’intitulés de “Use cases”: “S’authentifier”, “Rechercher un livre”. Ces titres ne sont qu’une partie du “Use Case” qui comporte d’autres parties (Acteur, Résumé, Déclencheur, Scénario principal, Extensions…). Un “Use Case” est donc plus détaillé, et nécessite un travail approfondi d’analyse et de formalisation.
Alors pourquoi cette réflexion ? d’une part, comme je le disais, j’ai le sentiment que certains contextes se prêtent mieux aux “User Stories“, d’autre part “User stories” et “Use cases” se rejoignent sur beaucoup de points (pour les différences, consulter ce billet):
- “User Stories” et “Use Cases” formalisent les besoins utilisateurs et sont orientés “But”
- Ils font facilement l’objet d’ateliers de travail avec les utilisateurs pour les découvrir, les expliciter
- Ils vont être priorisés et vont ainsi guider les développements
- Ils mettent en avant les rôles, les différents profils d’utilisateurs
- Ils ne traitent que des exigences fonctionnelles (les aspects “non fonctionnels” sont décrits dans “les exigences non fonctionnelles” (contexte UP) et dans les “Constraints Cards” (contexte XP))
- Ils sont textuels et obéissent à des régles de construction trés précises (Travaux de Rachel Davis, ou critères “INVEST” pour les “User Stories”)
- Ils ne traitent pas des aspects interface et ergonomie (détails abordés dans les exigences d’ergonomie (contexte UP), livrables d’ergonomie, prototypes (contextes UP et XP))
- Ils peuvent être rédigés par les analystes (pour les UC c’est conseillé; pour les “User Stories“, c’est plutôt l’utilisateur ou un membre de l’équipe Client, composée de ceux qui vont s’assurer que le produit répond aux besoins des utilisateurs, c’est à dire Utilisateurs eux-mêmes, Directeur de produit, Analyste ou encore Ergonome)
- Ils ont chacun leur auteur et ouvrage de référence (Alistair Cockburn, “Rédiger des cas d’utilisation efficaces“, Mike Cohn, “User Stories Applied For Agile Software Development“).
Dans un prochain billet, j’aborderai les différences majeures entre “Use Cases” (Cas d’utilisation) et “User Stories”, ce qui me permettra de détailler davantage leur mode de construction et d’envisager l’impact de telle ou telle technique notamment en terme de Qualité Logiciel.
Posté par jc-QualityStreet le 19 mars 2007
D’ailleurs, je trouve le terme “user proxy” vraiment bien choisi…
Un “User proxy” (au sens XP, Extreme Programming) n’est pas un vrai utilisateur mais il est sur le projet pour aider à le représenter.
Les méthodes agiles et une démarche ergonomique (par exemple au travers de l’ISO 13407) cherchent à impliquer les utilisateurs au plus tôt et tout au long du processus de développement logiciel. Super ! mais on a pas toujours accès à ces derniers et on peut vite se retrouver face à un seul interlocuteur, le représentant des utilisateurs, ce fameux “User Proxy“.
Parfois, on aura de la chance (bon profil, bonne connaissance des tâches et besoins utilisateurs … même si dans tous les cas, les vrais utilisateurs sont toujours plus précieux que leurs représentants), parfois moins… une position délicate pour l’ergonome.
Mike Cohn nous propose dans son livre “User Stories Applied: For Agile Software Development” des solutions quand on doit collaborer avec des “user proxies” sans avoir aucun accès aux utilisateurs (car ça peut arriver):
- En prendre plusieurs (”User proxies”), si possible de profils différents,
- Confronter ce qu’ils nous donnent aux produits concurrents (discuter les fonctionnalités mises en avant…, étudier les guides utilisateur…),
- Mettre trés vite entre les mains des vrais utilisateurs une version, même non finalisée, pour ouvrir la discussion et susciter les feedbacks (interviews, tests …).
bref des conseils pertinents, transposables à beaucoup d’autres domaines, pas seulement logiciel.
Posté par jc-QualityStreet le 8 février 2007
Le Processus Unifié (UP) et SCRUM partagent une même démarche: itérative, incrémentale, pilotée par les risques, cadencée par le time boxing et par des livraisons fréquentes. Il s’agit de deux Méthodes Agiles, même si pour certaines instanciations d’UP il y a souvent débat et même si SCRUM possède incontestablement plus de légèreté et de dynamisme. Et c’est ce côté dynamique qui me semble trés pertinent.
On retrouve déjà dans le Processus Unifié pas mal d’éléments de SCRUM, mais dans une terminologie différente:
- Backlog produit = “Liste des exigences”, fonctionnelles ou non (ergonomiques, performance, sécurité …) (UP)
- Backlog de Sprint = “Plan d’itération” (UP)
- Produit partiel utilisable = “Prototype” en début de projet (phase d’Elaboration par exemple), ; “Produit” ensuite, (UP)
- Revue de Sprint = “Réunion de fin d’itération” (UP)
Au sein de nos équipes, le pilotage par les risques est très apprécié mais le concept d’itération est ce qui est le mieux perçu (malgré certaines difficultés dans la pratique), tout comme les livraisons intermédiaires. Toutefois l’itération en elle-même me semble manquer de pêche (ça démarre fort, ça se termine pas mal, mais au milieu il y a comme un peu de flottement…)
Le remède ? pourquoi pas ces techniques issues de SCRUM que le chef de projet (un chef de projet agile et pas un ScrumMaster) s’approprierait:
- Le scrum daily meeting (réunion d’équipe de 15 minutes maximum où chacun décrit où il en est…)
- Le burndown chart (graphique d’avancement, non figé, permettant de constater trés facilement le “reste à faire” sur un sprint)
- Les aides visuelles du SCRUM (par exemple, un grand tableau ou un mur distinguant les tâches en cours, celles non initiées et celles terminées, et des cartes pour chaque tâche à réaliser ; des cartes, un mur des choses que nous connaissons en Ergonomie des sites ou applications web)
- La communication sur certaines valeurs (esprit d’équipe, engagement, courage …)
J’attends de mettre ça en pratique sur mes prochains projets.
Pour le reste, le Processus Unifié correspond davantage à nos besoins notamment au niveau de la description et de l’enchainement des disciplines et activités, de la définition des rôles (trop succincte à mon goût dans SCRUM) et du focus sur la qualité.
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
