Instructions: Pratiques de personnalisation des processus
Ces instructions décrivent les valeurs recommandées pour la personnalisation de RUP.
Relations
Description principale

Généralités

Pendant que vous triez les produits, les tâches et les rôles dans le processus (RUP), vous pouvez être amené à vous poser les questions suivantes :

  • Ai-je besoin de cet élément ?
  • Comment dois-je trier tous ces éléments pour déterminer ceux dont j'ai besoin pour mon projet ?
  • N'est-il pas évident que le processus RUP ne sert que pour les gros projets ?

La personnalisation aborde toutes ces questions.

L'objectif d'un projet logiciel est de concevoir un produit. Un bon processus permet que le projet conçoive un produit répondant aux besoins de ses parties prenantes dans les temps et la limite du budget impartis. Pour plus d'informations, voir l'artefact :  Produit.

La clé d'un bon processus est de le personnaliser en le rendant aussi simple que possible, tout en retenant les principes clés.

Les instructions présentées ici doivent être prises en compte pour la personnalisation d'un processus. Des conseils plus détaillés sont fournis dans Concept : personnalisation de RUP.

Construction en premier lieu d'une infrastructure

Un problème souvent rencontré pour beaucoup de projets est que ceux-ci se concentrent souvent fortement sur une zone particulière au point qu'ils croulent sous les détails de cette zone avant de pouvoir être sûrs de savoir quels éléments "clés" sont impliqués dans tout le cycle de vie du processus qui vise à concevoir un produit de qualité.

Il vaut généralement mieux traiter rapidement tous les éléments clés d'un processus avant de se concentrer fortement sur une zone ayant un problème particulier.

Une fois l'infrastructure préfabriquée d'un processus logiciel de qualité mise en place, le projet peut effectivement se concentrer sur une zone précise qui a été identifiée comme un collaborateur essentiel aux problèmes. Cette sélection est basée sur l'identification des risques et la priorité donnée à ceux-ci, et sur la détermination de stratégies d'atténuation des risques identifiés.

N'insérez pas les tâches et les produits qui ne peuvent être clairement justifiés.

Un responsable de projet ou un responsable de processus consciencieux peut avoir une longue liste de besoins relatifs aux métriques, aux contrôles, aux rapports etc. qu'il serait bien d'avoir. Cependant, les tâches et les produits prennent du temps et coûtent chers. Certains de ces coûts, comme l'interaction quotidienne avec l'ensemble des outils de l'environnement, peuvent être ou ne pas être visibles, mais ils sont simplement réduits à une productivité moindre des tâches standard.  

Il vous faut différencier les besoins critiques d'un processus dans la liste des besoins et déterminer si les avantages dépassent le coût.

Protégez du processus vos développeurs de logiciel.

Vous disposez certainement de personnel hautement qualifié pour la conception, l'implémentation et l'exécution de tests. Ne leur faîtes pas perdre de temps à remplir toutes les semaines des formulaires, une documentation élargie ou à se débattre avec des outils difficiles à manier. Si ces tâches sont obligatoires, donnez-les à du personnel d'assistance qualifié.

Minimisez les produits intermédiaires formels

Le format des produits intermédiaires - ceux non destinés au produit final - n'est pas aussi important que la tâche et les réflexions nécessaires à leur production. Leur apparence ou les outils utilisés pour leur construction importent peu à partir du moment où ils remplissent leurs tâches. Comme le disait si bien Dwight D. Eisenhower, "Le plan n'est rien, tout est dans le planning."

Il y a un piège dans lequel il est facile de tomber : formaliser les produits beaucoup trop tôt.  Les premières versions des produits évoluent souvent rapidement puis restent floues, sous des représentations différentes, pendant quelques temps pendant que leurs implications sont explorées. Une documentation formelle peut entraver ce processus ; vous pouvez perdre beaucoup de temps à perfectionner un produit que l'on peut largement développer. Les diagrammes dessinés à la main et les descriptions simples dans les index sont souvent largement suffisants en début de projet. Pour certains projets, c'est parfois tout ce dont on a besoin.

Utilisation de formats pratiques

Un produit peut être personnalisé de manière à pouvoir être maintenu sous n'importe quelle forme. Par exemple, le document Vision peut être enregistré en tant que page Web, le planning de projet en tant que fichier de projet Microsoft et la liste des risques en tant que type d'exigence Rational RequisitePro.

Générez lorsque cela est possible

Certains projets passent beaucoup de temps à remplir des canevas de documents formels en coupant et collant manuellement des informations. Pensez plutôt à générer les documents requis à partir de la source, à l'aide d'outils tels que Rational SoDA, ou négociez un moyen plus simple de fournir les mêmes informations, en utilisant par exemple le diffuseur de publications Rational Rose pour générer un modèle de conception basé sur le Web.

Dans bon nombre de cas, vous pouvez aussi sauter un produit car l'information est implicitement présente dans l'environnement. Au lieu de générer la section de planification de la gestion des exigences qui liste tous les attributs des types d'exigences, vous voulez par exemple fournir uniquement le projet personnalisé Rational RequisitePro avec les types d'exigences applicables et la traçabilité, puis le parcourir avec les parties intéressées. Vous pouvez aussi fournir à ces parties une version en lecture seule des fichiers de projet Microsoft au lieu de reproduire des graphiques en un plan de développement logiciel distinct.

Utilisez le Web

Un produit utile est un produit qui communique des informations importantes.  Ces informations devraient être à portée de main de ceux qui ont en besoin. A ce propos, la technologie du Web est un mécanisme excellent. Si les exigences, la conception et l'implémentation sont disponibles sur le Web, vous n'avez pas besoin de générer de grands ensembles de documents papier qui deviennent vite obsolètes.

Utilisez des outils intégrés.

Sélectionnez des outils adaptés pour le projet et personnalisez le projet pour l'adapter aux outils. Les résultats escomptés sont d'avoir un processus et un ensemble d'outils faciles à utiliser.  Les outils intégrés sont généralement plus cohérents et fournissent des mesures et des rapports plus instructifs que les outils non intégrés.

Revue régulière du processus

Revoyez régulièrement le processus pour l'affiner et réduire sa complexité. Si votre personnel n'est pas convaincu qu'à chaque étape du processus vous obtenez une valeur ajoutée, il se peut alors que le processus ne fonctionne pas.

Procédez à la personnalisation tout en respectant les pratiques.

Le processus RUP encourage de recourir à la personnalisation. Cependant, cette dernière n'est pas une licence pour dériver complètement le processus.  Les éléments principaux du processus RUP sont intégrés dans ses pratiques. Gardez bien l'état d'esprit relatif à ces pratiques lorsque vous personnalisez les tâches et les produits pour répondre à vos besoins.