Tâche: Accord sur la mission
Cette tâche aide à trouver le bon équilibre entre les ressources de test disponibles et les objectifs de l'itération.
Objet
L'objectif de cette tâche est de :
  • Négocier l'utilisation la plus efficace des ressources de test pour chaque itération
  • Se mettre d'accord sur un ensemble d'objectifs et de résultats attendus appropriés et envisageables pour l'itération
Relations
Etapes
Comprendre les objectifs de l'itération
Objectif :  Appréhender l'étendue et les objectifs du plan d'itération. 

Examinez le plan d'itération et identifiez son étendue et ses objectifs.

Il est conseillé de compléter cet examen par des discussions informelles avec le personnel chargé du projet (responsable de projet, architecte logiciel et décideur côté client) ; ces réunions permettent souvent d'expliciter certains points abordés dans le plan. La participation aux réunions de lancement d'itération permet également de rassembler des informations utiles.

Examiner les options de la portée de l'effort d'évaluation
Objectif :  Comprendre les attentes des parties prenantes afin de déterminer l'étendue de l'effort d'évaluation. 

La mission représente le principe qui guide l'effort de test pendant une période donnée. Les ressources de test sont généralement limitées ; par conséquent, l'objectif consiste à obtenir un équilibre entre les contraintes de ressources de test et les besoins de validation de la qualité induits par l'effort de développement d'applications.

Appréhender les attentes stratégiques de l'équipe de développement d'applications. Vous devez principalement recueillir les attentes du responsable de projet, de l'architecte logiciel et des analystes système.

Présenter les options aux parties prenantes
Objectif :  Obtenir un retour d'informations des parties prenantes sur les objectifs et l'étendue de l'effort de test. 

Il n'est pas très utile de traiter les objectifs et l'étendue en dehors du reste de l'équipe chargée du projet. RUP préconise d'octroyer la propriété de la qualité du produit à l'équipe, et à ce titre vous devez adjoindre les parties prenantes concernées issues du reste de l'équipe lorsque vous déterminez ce qu'il est important de tester. Vous devez considérer les membres de l'équipe qui remplissent les rôles suivants comme d'importantes parties prenantes : responsable de projet, architecte, analyste système, intégrateur.

Dans certains cas, la présentation doit être formelle, les parties prenantes agissant en tant que comité d'audit ; elle nécessite une longue préparation préalable. Dans d'autres cas, des déjeuners informels peuvent être adaptés, ou une entrevue avec chacune des parties prenantes. Chacune de ces approches présente des avantages et des inconvénients : choisissez simplement en fonction de vos besoins dans le contexte de l'environnement du projet actuel.

Formuler la déclaration de mission
Objectif :  Identifier clairement l'essence des tests pour l'itération en cours. 

Les déclarations de mission fournissent des éclaircissements utiles aux équipes, spécialement dans les situations dans lesquelles l'équipe a plusieurs choix possibles. Les équipes de test sans mission d'évaluation considèrent souvent qu'elles "effectuent simplement des tests" : cela n'apporte pas beaucoup d'éléments lorsque des choix difficiles doivent être faits en tenant compte de contraintes de temps ou de ressources. Une déclaration de mission distille l'essence de l'objectif de travail en cours et fournit un "mantra" permettant à l'équipe de se concentrer sur l'essentiel.

Formulez une déclaration de mission pouvant être utilisée par l'équipe de test. Elle ne doit pas être trop complexe, ni contenir trop d'idées conflictuelles : les meilleures déclarations de mission sont simples, brèves et dans la plupart des situations impliquant une prise de décision, elles facilitent le choix de l'option fait par l'équipe.

Voici quelques idées de déclarations de missions à adopter pour vos itérations :

  • identifier le plus grand nombre possible de bogues
  • détecter rapidement les problèmes importants
  • évaluer les risques qualité perçus
  • donner un avis en matière de risques projet
  • renseigner sur la qualité apparente
  • certifier une norme
  • vérifier une spécification (exigences, conception ou réclamations)
  • garantir la satisfaction des parties prenantes
  • remplir les mandats de processus

En examinant cette liste, vous pouvez constater que de nombreuses missions sont mutuellement exclusives. Par exemple, si ma mission est de "détecter rapidement les problèmes importants", je ne serai sans doute pas capable de "vérifier une spécification" : Pour mener à bien une mission, il faut souvent en refuser d'autres et adopter une approche de test différente.

Les équipes de test qui tentent de satisfaire un trop grand nombre de missions d'évaluation rencontrent fréquemment des situations de conflit dans leur travail. Il est également recommandé de choisir ou de reconsidérer votre mission d'évaluation dans chaque itération : il est naturel que la mission évolue dans la durée en fonction du contexte de travail.

Identifier les résultats attendus de test
Objectif :  Spécifier la valeur à retirer de l'effort de test. 

Certains produits sont des résultats importants pour une ou plusieurs parties prenantes : d'autres produits représentent des parties nécessaires de l'effort de test et bien qu'ils sont importants pour l'équipe de test, ils présentent peu d'intérêt pour ces mêmes parties prenantes.

Indiquez approximativement le nombre minimal d'éléments livrables pour l'effort de test. Ne dressez pas la liste de tous les produits, mais indiquez uniquement ceux qui présentent un intérêt direct et tangible pour les parties prenantes et ceux qui serviront à mesurer l'efficacité de l'effort de test. Vous pouvez modifier la liste initiale pour vous adapter aux besoins manifestés par les parties prenantes, mais vous devez dans ce cas veiller à ce que les éléments livrables restent utiles et facilement gérables.

Obtenir l'accord des parties prenantes
Objectif :  Négocier avec toutes les parties prenantes pour obtenir un accord sur la mission la plus adaptée à l'itération. 

Comme pour l'étape précédente Présenter les options aux parties prenantes, vous devez obtenir l'accord de ces parties prenantes sur l'adaptation de la mission d'évaluation et du support associé à l'itération.

Là aussi, indiquez approximativement la façon dont vous envisagez de présenter la mission et d'obtenir les accords requis. Choisissez celle qui répond le mieux à vos besoins dans le contexte de l'environnement de projet actuel.

Evaluer et vérifier vos résultats
Objectif :  Vérifier que la tâche a été correctement réalisée et que les produits qui en résultent sont acceptables. 

Maintenant que vous avez achevé le travail, il serait utile de vérifier que ce travail a suffisamment de valeur et que vous n'avez pas simplement consommé de grandes quantités de papier. Vous devez évaluer si votre travail est d'une qualité correcte et qu'il est assez complet pour être utile aux membres de l'équipe qui en feront un usage ultérieur comme entrée pour leur propre travail. Si possible, utilisez les listes de contrôle fournies dans RUP pour vérifier que la qualité et l'exhaustivité sont "satisfaisantes".

Faites en sorte que les personnes qui effectuent les tâches en aval, et qui se basent sur votre travail comme entrée, prennent part à la revue de votre travail intermédiaire. Effectuez cette revue pendant que vous avez encore du temps disponible pour prendre les mesures qui répondent à leurs préoccupations. Vous devez également évaluer votre travail par rapport aux produits d'entrée clés pour vous assurer que vous les avez précisément et suffisamment représentés. Il peut être utile que l'auteur du produit d'entrée revoie votre travail sur cette base.

Essayez de vous rappeler que le RUP est un processus de livraison itératif et que dans de nombreux cas, les produits évoluent au fil du temps. A ce titre, il n'est généralement pas nécessaire - et c'est même souvent contre-productif - de former complètement un produit qui ne sera que partiellement utilisé ou ne sera pas du tout utilisé dans l'immédiat. Ceci parce qu'il y a une grande probabilité pour que la situation qui entoure le produit change - et que les hypothèses émises lors de la création du produit s'avèrent incorrectes - avant même l'utilisation du produit, occasionnant ainsi une perte d'efforts et une coûteuse reprise. Evitez également le piège consistant à utiliser trop de cycles pour la présentation au détriment de la valeur du contenu. Dans les environnements de projet où la présentation a une importance et une valeur économique en tant que résultat d'un projet, vous pouvez envisager d'utiliser une ressource administrative pour réaliser les tâches de présentation.



Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable