Rubriques

Livres blancs :


IntroductionHaut de la page

Le Rational Unified Process (RUP) est un cadre de processus que Rational Software a perfectionné au fil des années, et qui est communément utilisé pour tout type de projets logiciels, petits ou grands. Un nombre croissant de processus "agiles", tels qu'eXtreme Programming (XP), SCRUM, Feature-Driven Development (FDD) et la méthodologie Crystal Clear, sont depuis quelque temps reconnus comme étant des méthodes efficaces en matière de construction de systèmes plus petits. (Voir www.agilealliance.org pour plus d'informations sur l'Alliance Agile.)

Les sections qui suivent ont pour objectif d'aider les équipes de projet à évaluer certaines des pratiques "agiles" tirées de l'une de ces méthodes afin de voir comment elles sont traitées par le processus de développement logiciel plus complet défini par RUP.

PrésentationHaut de la page

La communauté agile a fait la synthèse d'un certain nombre des "meilleures pratiques" qui s'appliquent particulièrement bien aux équipes de projet réduites et travaillant au même endroit. Bien que le RUP cible des équipes de projet de toute taille, il peut être appliqué avec succès à de petits projets. En général, les RUP et les processus de la communauté Agile partagent une vision similaire des principales meilleures pratiques nécessaires au développement d'un logiciel de qualité - par exemple, le fait d'utiliser le développement itératif ou celui de se focaliser sur les utilisateurs finaux.

Les paragraphes suivants expliquent comment appliquer certaines des "meilleures pratiques" identifiées dans la communauté agile à des projets RUP qui voudraient en bénéficier. Pour cela, nous nous axerons ici sur les pratiques proposées par la méthodologie eXtreme Programming (XP). (Pour plus d'informations sur XP, merci de visiter le site : http://www.extremeprogramming.org.)

Pratiques XPHaut de la page

XP compte quatre "activités" de base (l'écriture du code, le test, l'écoute et la conception), qui se rapprochent en fait plus des disciplines du RUP. Ces activités XP sont conduites au moyen d'un ensemble de pratiques qui nécessitent l'exécution d'activités supplémentaires, qui correspondent à certaines des autres disciplines du RUP. Les pratiques d'XP, selon Extreme Programming Explained, sont :

  • Le jeu de la planification : Déterminez rapidement la portée de la prochaine version en combinant les priorités métier et les estimations techniques. A mesure que la réalité prend le pas sur les prévisions, mettez le plan à jour.
  • Petites versions : Lancez rapidement la production d'un système simple, puis sortez de nouvelles versions sur des cycles très courts.
  • Métaphore : Pilotez tout le développement à l'aide d'un scénario simple et commun de la façon dont tout le système fonctionne.
  • Conception simple : Le système doit être à tout moment conçu aussi simplement que possible. Les complexités superflues sont supprimées dès qu'elles sont découvertes.
  • Test : Les programmeurs écrivent continuellement des tests unitaires, qui doivent fonctionner sans accroc pour que le développement puisse se poursuivre. Les clients écrivent des tests qui démontrent que les fonctionnalités sont terminées.
  • Réusinage : Les programmeurs restructurent le système sans en modifier le comportement afin de supprimer les doublons, d'améliorer la communication, de simplifier ou d'ajouter de la flexibilité.
  • Programmation par paire : Tout le code de production est écrit avec deux programmeurs pour une machine.
  • Propriété collective : N'importe qui peut modifier n'importe quel code à n'importe quel endroit du système et à tout moment.
  • Intégration continue : Intégrer et construire le système plusieurs fois par jour, à chaque fois qu'une tâche est accomplie.
  • Semaine de 40 heures : S'interdire de travailler plus de 40 heures par semaine. Ne jamais faire d'heures supplémentaires deux semaines d'affilée.
  • Client sur site : Inclure à l'équipe un véritable utilisateur, qui soit disponible à plein temps pour répondre à des questions.
  • Standards de code : Les programmeurs écrivent tout le code en se conformant aux règles qui mettent l'accent sur la communication par le biais du code.

Les activités conduites au titre de la pratique du "jeu de planification", par exemple, seront essentiellement mappées à la discipline de gestion de projet du RUP. Mais certaines rubriques du RUP, tels que la modélisation métier et le déploiement du logiciel mis sur le marché, sortent du cadre d'XP. L'obtention des exigences dépasse largement le cadre d'XP, étant donné que le client définit et fournit les exigences. Par ailleurs, du fait de la plus grande simplicité des projets auxquels il s'applique, XP peut gérer plus superficiellement des problèmes que le RUP couvre en détails dans la discipline de gestion de la configuration et des changements ainsi que dans la discipline d'environnement.

Pratiques XP compatibles avec le RUPHaut de la page

Dans les disciplines dans lesquelles XP et le RUP se chevauchent, les pratiques suivantes décrites dans XP pourraient être (et dans certains cas sont déjà) employées dans le RUP :

  • Le jeu de planification : Les conseils XP sur la planification peuvent être mis à profit pour atteindre, dans le cadre d'un projet de taille très réduite, un grand nombre des objectifs que l'on trouve dans la discipline de gestion de projet du RUP. Ces conseils sont particulièrement utiles à des projets à faible niveau de formalité, auxquels on ne demande pas de produire d'artefacts intermédiaires formels de gestion de projet.
  • Conception pilotée par le test et réusinage : Ce sont de bonnes techniques qui peuvent être appliquées dans la discipline d'implémentation du RUP. La pratique de test d'XP, qui nécessite que l'on ait recours à la conception pilotée par le test, est en particulier un excellent moyen de clarifier les exigences de manière détaillée. Comme nous le verrons dans la prochaine section, le réusinage peut toutefois ne pas s'adapter correctement à des systèmes plus grands.
  • Intégration continue : Le RUP gère cette pratique au moyen de constructions aux niveaux du sous-système et du système (au cours d'une itération). Les composants testés unitairement sont intégrés et testés dans le contexte du système émergent.
  • Client sur site : Parmi les activités du RUP, nombreuses sont celles qui tireraient grand bénéfice de compter un client au sein de l'équipe sur site, car cela présente l'avantage de réduire le nombre des livrables nécessaires - en particulier des documents. XP place la conversation au premier rang de ses moyens de communication préférés entre client et développeur, car celle-ci base son efficacité sur le suivi et la familiarité ; cependant, lorsqu'un système (même petit) doit subir une transition, la conversation ne suffit pas. Pour XP, cet élément peut être traité après coup, par exemple, dans des documents de conception à la fin d'un projet. Bien qu'il ne soit pas interdit de produire des documents ou d'autres artefacts, XP précise que vous ne devriez vous consacrer qu'à ceux dont vous avez vraiment besoin. Le RUP est également de ce avis, mais il va plus loin en décrivant ce dont vous pourriez avoir besoin lorsque le suivi et la familiarité ne sont pas idéaux.
  • Standards de code : Il y a dans le RUP des principes et conseils de programmation d'artefacts presque toujours considéré comme obligatoire (Du fait que la majorité des profils de risques d'un projet forment la ligne directrice de l'adaptation).
  • Semaine de 40 heures : A l'instar d'XP, le RUP suggère que les heures supplémentaires ne doivent pas avoir un caractère habituel. XP ne conseille pas pour autant de se limiter strictement à 40 heures, reconnaissant au temps de travail plusieurs niveaux de tolérance. Les ingénieurs logiciels sont connus pour faire de longues journées sans pour autant être mieux rétribués (mais simplement pour la satisfaction du travail accompli) et les responsables n'ont pas nécessairement besoin de mettre un terme arbitraire à cette habitude. Ce que ces derniers ne doivent en revanche jamais faire, c'est d'exploiter ou même d'imposer cette pratique. Ils doivent toujours tenir un compte précis du temps de travail réel, même s'ils ne paient pas les heures supplémentaires. Si le total des heures travaillées par quelqu'un semble élevé sur une longue période, il conviendra certainement d'y regarder de plus près ; ce sont toutefois des problèmes qu'il est possible de régler en temps réel, entre le responsable et l'individu concerné, en tenant compte du reste de l'équipe. Les quarante heures ne sont que l'expression d'un conseil, mais d'un conseil appuyé.
  • Programmation par paire : XP affirme que la programmation par paire participe à la qualité du code, et qu'une fois cette compétence acquise, celle-ci devient plus agréable à effectuer. Le RUP ne décrit pas les mécanismes de production de code de façon extrêmement détaillée, bien qu'il soit certainement envisageable d'utiliser la programmation par paire dans un processus RUP. Certaines informations sur ce type de programmation, de même que sur la conception pilotée par le test et le réusinage, sont désormais fournies avec le RUP, sous forme de livres blancs. Bien évidemment, il n'est obligatoire d'utiliser aucune de ces pratiques dans le RUP ; cependant, dans le cas d'une équipe ayant une culture de communication ouverte, nous nous risquerons à supposer que les bénéfices de la programmation par paire (en termes d'effet sur les coûts totaux d'un cycle de vie) seront difficiles à repérer. Dans une équipe qui fonctionne bien, les gens se rassembleront tout naturellement pour discuter et solutionner les problèmes, sans qu'il soit nécessaire de les y obliger.

La suggestion selon laquelle il faut s'assurer au niveau "micro" que les processus sont efficaces est souvent peu agréable à entendre et peut ne pas correspondre à certaines cultures d'entreprise. Le RUP ne défend donc pas l'idée d'une application stricte de la règle. Toutefois, dans certaines circonstances, le fait de travailler par paire (de même que certaines des autres pratiques d'équipe qu'XP encourage à adopter) est indéniablement avantageux, chaque membre de l'équipe pouvant aider l'autre à avancer ; par exemple :

  • dans les premiers jours de la formation d'une équipe, alors que les personnes font connaissance,
  • dans des équipes qui ne sont pas habituées à une nouvelle technologie quelconque,
  • dans des équipes composées à la fois de personnel expérimenté et de débitants.

Pratiques XP ne s'adaptant pas bienHaut de la page

Les pratiques XP suivantes ne s'adaptent pas bien aux systèmes plus importants (XP n'affirme d'ailleurs pas que ce soit le cas) ; on les utilisera donc dans le RUP en ayant toujours cette réserve à l'esprit.

  • Métaphore : Pour des systèmes complexes et plus grands, l'architecture comme métaphore n'est simplement pas suffisante. Le RUP propose un cadre descriptif nettement plus riche pour une architecture qui n'est pas seulement composée (comme Extreme Programming Explained la décrit) "de grandes zones et de connexions". Même dans la communauté XP, la métaphore a été plus récemment dépréciée. Ce n'est plus une pratique XP (jusqu'à ce qu'ils trouvent comment la décrire correctement ; une métaphore pourrait peut-être les y aider).
  • Propriété collective : C'est utile si les membres d'une équipe responsable d'un petit système ou d'un sous-système connaissent tout son code. Mais votre décision de donner ou non à tous la possibilité d'effectuer des changements à n'importe quel endroit devra dépendre de la complexité du code. Il sera souvent plus rapide (et plus sûr) de confier une réparation au membre (ou à la paire) qui travaille actuellement sur le segment de code concerné. La connaissance que l'on a d'un code, même le mieux écrit qui soit, et tout particulièrement s'il est algorithmiquement complexe, décroît rapidement avec le temps.
  • Réusinage : Dans un grand système, des réusinages fréquents ne peuvent pallier un déficit d'architecture. Extreme Programming Explained explique que "la stratégie de conception d'XP ressemble à un algorithme d'escalade. Vous obtenez une conception simple, que vous faites ensuite gagner en complexité, puis vous la simplifiez légèrement avant de la recomplexifier un peu. Le problème avec les algorithmes d'escalade est d'atteindre les optimaux locaux, où aucune modification légère ne peut améliorer la situation, alors qu'un changement important le peut". Dans le RUP, l'architecture fournit une vue et un accès à la "grande colline", afin de rendre exploitable un grand système complexe.
  • Petites versions : Le prix auquel un client peut accepter et déployer de nouvelles versions dépendra de plusieurs facteurs, notamment la taille du système, qui est généralement en corrélation avec l'impact commercial. Un cycle de deux mois peut s'avérer beaucoup trop court pour certains types de système, essentiellement à cause de la logistique du déploiement.

Pratique XP devant être traitée avec précautionsHaut de la page

Pour finir, voici une pratique XP qui, à première vue, semble potentiellement utilisable dans le RUP (Conception simple), mais qui requiert en fait de l'élaboration et de la précaution lorsqu'elle est appliquée de façon générale.

  • Conception simple
    XP est, dans une large mesure, axé sur les fonctionnalités : les témoignages des utilisateurs sont sélectionnés, décomposés en tâches puis implémentés. Selon Extreme Programming Explained, la bonne conception du logiciel à tout moment est celle qui exécute tous les tests, n'a aucune logique en doublon, prend en compte toutes les intentions importantes pour les programmeurs et a aussi peu de classes et de méthodes que possible. XP ne croit pas en l'ajout de tout élément non requis pour fournir au client une valeur commerciale.

    Il y a un problème, analogue à celui des optimisations locales, à traiter de ce que le RUP appelle les exigences "non-fonctionnelles". Ces exigences fournissent également de la valeur commerciale au client, mais elles sont plus difficiles à exprimer sous forme de témoignages. Certaines des conditions qu'XP appelle contraintes appartiennent à cette catégorie. Le RUP ne plaide pas non plus en faveur d'une conception qui vise à faire plus que ce qui est nécessaire, de quelque façon spéculative que ce soit, mais il favorise en revanche une conception réalisée avec un modèle architectural en tête (ce modèle étant l'une des clés pour satisfaire les exigences non-fonctionnelles).

    Aussi le RUP s'accorde-t-il avec XP pour affirmer que la "conception simple" doit impliquer l'exécution de tous les tests, mais en précisant que ces tests incluent ceux qui démontrent que le logiciel satisfera les exigences non-fonctionnelles. Là encore, cela ne devient un problème majeur qu'à mesure que la taille et la complexité du système augmentent, lorsque l'architecture est sans précédent ou bien encore lorsque les exigences non-fonctionnelles sont onéreuses. Par exemple, le besoin de trier les données (afin d'opérer dans un environnement réparti de façon hétérogène) semble complexifier le code à l'excès, mais il n'en est pas moins nécessaire tout au long du programme.

Mappage d'artefacts pour un petit projetHaut de la page

Lorsque l'on adapte le RUP à un petit projet et que l'on réduit les exigences en termes d'artefacts en conséquence, quelle comparaison peut-on en faire avec l'équivalent en artefacts d'un projet XP ? En observant l'../../../examples/devcase_sp/dc_index.htm -- This hyperlink in not present in this generated websiteexemple de plan de développement pour petits projets du RUP, on peut voir qu'un échantillon de configuration RUP a été configuré dans le but de produire moins d'artefacts (voir Tableau 1).

Artefacts XP
Témoignages
Documentation additionnelle tirée des conversations
Vision
Glossaire
Modèle de cas d'utilisation
Contraintes Spécifications supplémentaires
Tests d'acceptation et tests unitaires
Données d'essai et résultats de tests

../../../process/artifact/ar_tstpl.htm -- This hyperlink in not present in this generated websitePlan de test
../../../process/artifact/ar_tstcs.htm -- This hyperlink in not present in this generated websiteJeu d'essai../../../process/artifact/ar_tstste.htm -- This hyperlink in not present in this generated website
Suite de test
(incluant ../../../process/artifact/ar_tstsc.htm -- This hyperlink in not present in this generated website script de test, ../../../process/artifact/ar_tstdta.htm -- This hyperlink in not present in this generated websitedonnées d'essai)
../../../process/artifact/ar_tstlog.htm -- This hyperlink in not present in this generated websiteJournal de test
Sommaire d'évaluation de test

Logiciel (code) Modèle d'implémentation
Versions ../../../process/artifact/ar_prdct.htm -- This hyperlink in not present in this generated websiteProduit (Unité de déploiement)
../../../process/artifact/ar_rlsnt.htm -- This hyperlink in not present in this generated websiteNotes de version
Métaphore Document d'architecture logicielle
Conception (CRC, ébauche UML)
Tâches techniques et autres tâches
Documents de conception produits à la fin
Documentation de support
Modèle de conception
Standards de code ../../../process/artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated websitePrincipes et conseils spécifiques au projet
Espace de travail
Cadre de test et outils
../../../process/artifact/ar_devcs.htm -- This hyperlink in not present in this generated websitePlan de développement
../../../process/artifact/ar_tstenv.htm -- This hyperlink in not present in this generated websiteConfiguration de l'environnement de test
Plan de version
Plan d'itération
Evaluations de témoignages et estimations des tâches
Plan de développement logiciel
Plan d'itérations
Plan et budget globaux Cas métier
Liste des risques
Compte-rendus sur la progression
Carte de pointage pour charge quotidienne
Données de métrologie (incluant les ressources, la portée, la qualité et le temps)
Suivi des résultats
Compte-rendus et notes sur les réunions
Evaluation de l'état
Evaluation de l'itération
Enregistrement des révisions
Défauts (et données associées) Demandes de changement
Outils de gestion de code Référentiel de projets
../../../process/artifact/ar_wkspc.htm -- This hyperlink in not present in this generated websiteEspace de travail
Pointe (solution)

Prototypes
Prototype d'interface utilisateur
Démonstration du bien fondé de la conception architecturale

XP lui-même (ses recommandations et conseils)

../../../process/artifact/ar_tstidslst.htm -- This hyperlink in not present in this generated websiteListe d'idées de tests
../../../process/artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated websitePrincipes et conseils spécifiques au projet

[Non-inclus dans XP]

Modèle de données
../../../process/artifact/ar_eusm.htm -- This hyperlink in not present in this generated websiteMatériel d'aide à l'utilisateur final.

Tableau 1 : Mappage de XP à RUP d'artefacts destinés à un petit projet

Bien que la granularité des artefacts varie des deux côtés, en général, les artefacts du RUP destinés à de petits projets (du type de ceux qu'XP traiterait sans problème) se mappent fort bien à ceux d'un projet XP.

Notez que l'../../../examples/devcase_sp/dc_index.htm -- This hyperlink in not present in this generated websiteExemple de plan de développement pour petits projets inclue également quelques artefacts qui ne sont pas couverts par XP mais sont nécessaires sur de nombreux projets. On trouve parmi eux le modèle de données, ainsi que des artefacts associés au déploiement, tels que le ../../../process/artifact/ar_eusm.htm -- This hyperlink in not present in this generated websitematériel d'aide à l'utilisateur final.

ActivitésHaut de la page

Le RUP définit une activité comme une tâche réalisée par un rôle (soit en utilisant et transformant des artefacts d'entrée, soit en produisant de nouveaux artefacts de sortie modifiés. RUP va plus loin en énumérant ces activités et en les catégorisant selon ses disciplines. Celles-ci incluent : la modélisation métier, les exigences, l'analyse et la conception, le déploiement et la gestion de projets (entre autres).

Les activités sont liées au temps au travers des artefacts qu'elles produisent et consomment : une activité peut logiquement débuter lorsque ses entrées sont disponibles (et dans l'état de maturité approprié). Cela signifie que les paires d'activité producteur-consommateur peuvent se chevaucher dans le temps, dès lors que l'état de l'artefact le permet ; elles n'ont pas besoin d'être séquencées de façon rigide. Les activités ont vocation à donner des indications fortes de la manière dont un artefact doit être produit, et peuvent également servir d'aide à la planification pour le chef de projet.

Incorporées dans le RUP décrit en termes de cycle de vie, artefacts et autres activités, on trouve les "meilleures pratiques" : des principes de génie logiciel réputés pour la possibilité qu'ils offrent de produire des logiciels de qualité dans un temps et pour un budget prévisibles. Le RUP, au travers de ses activités (et de leurs artefacts associés), prend en charge et applique ces meilleures pratiques - qui sont des thèmes qui traversent le RUP dans son intégralité. Notez qu'XP utilise également la notion de "pratiques" mais, comme nous le verrons, celle-ci ne s'aligne pas exactement sur le concept de meilleure pratique que l'on retrouve dans le RUP.

XP offre une vision simple et attrayante du développement logiciel dans laquelle quatre activités de base (code, test, écoute et conception) sont habilitées et structurées selon certaines pratiques de prises en charge (abordées dans Extreme Programming Explained, Chapitre 9). En fait, comme on l'a fait remarquer plus haut, les activités d'XP sont, en matière de portée, plus proches des disciplines du RUP que de ses activités, et l'essentiel de ce qui se passera sur un projet XP (en plus de ses quatre activités de base) viendra de l'élaboration et de l'application de ses pratiques.

Les activités du RUP ont donc un équivalent XP, mais les "activités" d'XP ne sont pas formellement identifiées ou décrites comme telles. Par exemple, si vous examinez le chapitre 4, intitulé "Témoignages d'utilisateurs", dans Extreme Programming Installed, vous trouverez le titre "Définir les exigences avec des témoignages rédigés sur des cartes" et, tout au long du chapitre, un mélange de description de processus et d'indications sur ce que sont les témoignages d'utilisateurs d'une part, et sur la façon dont elles doivent être produites (et par qui) d'autre part. Et ainsi de suite : dans les différentes parties des Livres XP (sous des rubriques qui sont à la fois centrées sur les artefacts, et sur les activités) sont décrites à la fois les "éléments produits" et les "éléments effectués", à des niveaux variés de prescription et de détail.

Le niveau de prescription apparemment élevé du RUP résulte de son caractère complet et du plus grand formalisme qu'il observe dans le traitement des activités et de leurs entrées et sorties. XP ne manque pas de prescription mais, peut-être du fait de sa volonté de rester léger, le formalisme et le détail y sont simplement omis. Le manque de spécificité n'est ni une force ni une faiblesse, mais il ne faut pas prendre le manque d'informations détaillées dans XP pour de la simplicité. Le fait de ne pas avoir de détails peut satisfaire les développeurs les plus expérimentés mais, dans bien des cas, des détails en plus grand nombre sont d'un grand secours au nouveaux membres d'une équipe, ainsi qu'à ceux qui en sont encore à se familiariser avec l'approche de l'équipe en matière de développement logiciel.

Pour les activités, comme pour les artefacts, il est important de rester concentré sur ce que l'on cherche à accomplir. Réaliser une activité en aveugle n'est jamais une bonne pratique. Les activités et les principes et conseils associés sont faits pour être consultés lorsque l'on en a besoin pour atteindre un objectif, mais ne doivent pas servir d'excuse pour ne pas avoir à se faire une idée d'ensemble de ce que l'on cherche à faire. Cet état d'esprit est bien exprimé dans XP, et nous pensons qu'il devrait être adopté par chaque utilisateur du RUP.

RôlesHaut de la page

Dans le RUP, il est dit des activités qu'elles sont menées par des rôles (ou, plus précisément, par des individus ou des groupes jouant des rôles). Les rôles sont également responsables d'artefacts spécifiques ; le rôle responsable créera généralement l'artefact et s'assurera qu'un changement opéré par un autre rôle (si jamais il y est autorisé) ne casse pas l'artefact. Un individu ou un groupe de personnes peut jouer un seul ou plusieurs rôles. Un rôle n'a pas à être mappé à un seul poste ou à une seule"case" d'une organisation.

Extreme Programming Explained identifie sept rôles applicables à XP : programmeur, client, testeur, détecteur, formateur, consultant et grand patron ; puis décrit leur responsabilités ainsi que les compétences attendues des gens qui les joueront. Il est également fait référence à ces rôles dans certains des autres Livres XP. La différence dans le nombre de rôles entre XP et le RUP s'explique facilement :

  • XP ne couvre pas toutes les disciplines du RUP.
  • Les rôles XP sont plus comparables à des postes au sein d'une organisation (avec éventuellement des responsabilités multiples) qu'à des rôles RUP. Par exemple, le programmeur d'XP endosse en fait plusieurs rôles RUP (implémenteur, réviseur de code et intégrateur) qui supposent des compétences légèrement différentes.

Rôles XP et RUP sur un petit projetHaut de la page

Lorsque des rôles RUP sont mappés à un petit projet, le nombre de rôles de type XP auxquels ils correspondent est considérablement réduit, puisque le nombre de postes, ou dénominations de poste, est de 5. Le tableau 3 (extrait du RUP) présente ce mappage avec le rôle XP correspondant.

Rôle XP Exemple de membre d'une équipe sur un petit projet RUP Rôle RUP
Formateur
Consultant
Grand patron
Sally Slalom, Responsable en chef Chef de projet
../../../process/workers/wk_depm.htm -- This hyperlink in not present in this generated websiteResponsable du déploiement
Réviseur technique
Responsable de la configuration
Responsable du contrôle des changements
Client Partie prenante (voir Vision)
Réviseur de gestion
Réviseur technique (exigences)
Client
Grand patron
Détecteur
Tom Telemark, Ingénieur logiciel en chef Analyste système
Spécificateur d'exigences
Concepteur d'interface utilisateur
Architecte logiciel
Réviseur technique
Responsable de tests
../../../process/workers/wk_tstanl.htm -- This hyperlink in not present in this generated websiteAnalyste de tests

et dans une moindre mesure les rôles de développement.

Programmeur
Testeur

Susan Snow, Ingénieur logiciel

Henry Halfpipe, Ingénieur logiciel junior

Concepteur
Implémenteur
Réviseur technique
Intégrateur
../../../process/workers/wk_tstds.htm -- This hyperlink in not present in this generated websiteConcepteur de tests
../../../process/workers/wk_tstr.htm -- This hyperlink in not present in this generated websiteTesteur
../../../process/workers/wk_tchwr.htm -- This hyperlink in not present in this generated websiteRédacteur technique
Détecteur Patrick Powder, Adjoint administratif Responsable de la maintenance du site Web du projet, assiste le rôle de chef de projet pour les activités de planification/planning, et assiste le rôle de responsable du contrôle des changements pour le contrôle des changements apportés aux artefacts.  Peut aussi être amené à assister d'autres rôles si nécessaire.

Tableau 3 : Mapper les rôles XP aux rôles RUP sur un petit projet

Utiliser les pratiques XP avec le RUPHaut de la page

Le RUP est un cadre de processus à partir duquel des processus particuliers peuvent être configurés puis instanciés. Le RUP doit être configuré : c'est là une étape obligatoire définie dans le RUP lui-même. Au sens strict, nous devrions donc comparer XP à une version du RUP adaptée aux caractéristiques de projet qu'XP établit explicitement (et à celles qui peuvent en être déduites). Un tel processus RUP adapté pourrait contenir de nombreuses pratiques XP (telles que la programmation par paire, la conception pilotée par le test et le réusinage), mais il n'en serait pas pour autant identique à XP du fait de l'importance qu'accorde le RUP à l'architecture, à l'abstraction (dans la modélisation) et au risque, et à cause de sa structure temporelle (phases et itérations) différente.

XP est volontairement conçu pour implémenter un processus léger à de petits projets. Ce faisant, il contient également des descriptions (du moins dans les livres) qui ne sont pas complètement élaborées. Dans une implémentation XP, il y aura toujours des éléments à découvrir, à inventer ou à définir à la volée. Le RUP gérera des projets qui correspondent à la portée d'XP et la dépassent en terme d'échelle et de type.Comme le montre cette feuille de route, le RUP est ainsi tout à fait compatible avec la plupart des pratiques décrites dans la documentation XP.

Gardez à l'esprit que l'essence d'XP réside dans sa focalisation sur l'organisation, les personnes et la culture. C'est important dans tous les projets, et très certainement applicable à ceux qui utilisent le RUP. Les petits projets pourraient tirer un grand profit d'une utilisation conjointe de ces pratiques.

Références de processus AgileHaut de la page

  • eXtreme Programming (XP) (Voir http://www.extremeprogramming.org/more.html pour plus d'informations) :
    • Extreme Programming Explained : Embrace Change. Kent Beck explique les concepts et la philosophie de l'extreme programming. Ce livre enseigne le quoi et le pourquoi mais pas le comment.
    • Le réusinage améliore la conception du code existant. Martin Fowler écrit le premier ouvrage à faire autorité en matière de réusinage. Présenté sous forme de patterns. Il y a de nombreux exemples en Java. Ce livre vous enseigne comment et pourquoi réusiner.
    • Extreme Programming Installed. Par Ron Jeffries, Chet Hendrickson et Ann Anderson. Ce livre traite des pratiques XP spécifiques en plus grand détail que dans Extreme Programming Explained. Ce livre vous apprend à programmer dans l'esprit XP.
    • Planifier l'Extreme Programming. par Kent Beck et Martin Fowler. Ce livre expose les derniers points de vue sur la façon de planifier un logiciel dans un environnement de livraison rapide. Ce livre vous apprend à gérer un projet XP.
    • Extreme Programming Examined. par Giancarlo Succi et Michele Marchesi. Articles présentés au cours d'XP2000. Un recueil bien fait d'articles qui couvrent la plupart des sujets.
    • Extreme Programming in Practice. par Robert C. Martin et James W. Newkirk. Un véritable projet mené sous XP décrit dans les moindres détails.
    • Extreme Programming Explored. par William C. Wake. Basé sur le site Web renommé XPlorations. Des sujets spécifiques sont examinés en détail.
    • Extreme Programming Applied : Playing to Win. par Ken Auer et Roy Miller. Des expériences de pionniers de l'application d'XP. A paraître en septembre.
  • Pour des informations sur d'autres membres de l'Alliance Agile, voir http://www.agilealliance.org/home.



RUP (Rational Unified Process)   2003.06.15