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.
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.
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.
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.
|