Partager via


Organisation des spécifications dans un plan de produit

Une fois que vous avez suffisamment analysé les spécifications de votre client de façon à bien comprendre ce que le produit doit faire, vous devez élaborer un plan pour l'implémentation du produit. Ou, pour un produit existant, vous devez déterminer les fonctionnalités manquantes et créer un plan pour apporter des modifications. Cependant, les spécifications ne vous permettent pas d'aboutir automatiquement à un plan.

Cette rubrique présente une méthode d'obtention d'un plan, en démarrant à partir d'un ensemble de spécifications. Il s'agit juste d'une méthode parmi d'autres qui fonctionnent avec Visual Studio, et vous devez l'adapter à vos besoins.

Vous pouvez utiliser journal et journal de dossier pour définir et mapper des spécifications et des fonctionnalités.

Spécifications et fonctionnalités

Il existe deux genres de spécifications dans cette méthode : spécifications du client et fonctionnalités. Les spécifications du client sont celles que vous obtenez suite à l'analyse des souhaits du client pour le produit. Les fonctionnalités sont des éléments du plan de produit, qui correspondent à des petits sous-ensembles des spécifications du client. Chaque fonctionnalité peut inclure des spécifications du client provenant de différentes parties de l'expérience utilisateur et de différents domaines fonctionnels.

Spécifications du client

  • Les spécifications du client sont déterminées par la discussion avec les utilisateurs potentiels et d'autres parties prenantes.

  • Pour faciliter l'analyse de ces spécifications, vous créez en général des storyboards et des modèles, et vous décomposez les scénarios en de plus petites étapes, qui forment une arborescence. Vous pouvez lier des éléments de modélisation tels que les cas d'usage et les activités aux éléments de travail Scénario.

  • Il existe deux genres de spécifications du client :

    • Les scénarios, également appelés cas d'usage, représentent des séquences d'interactions entre les utilisateurs et le produit, dans la poursuite d'objectifs spécifiques. Un exemple de scénario peut avoir le titre « L'utilisateur achète un livre ».

    • Les impératifs de qualité de service incluent les performance, la sécurité, la facilité d'utilisation et d'autres critères.

  • Vous pouvez représenter ces spécifications comme des éléments de travail de type Spécification, le champ Type de spécification ayant la valeur Scénario ou Qualité de service. Pour plus d'informations, consultez Développement de spécifications.

  • Ces éléments de travail Spécification doivent être liés aux tests système afin de vous assurer que toutes les spécifications sont testées. Consultez Planifier des tests manuels à l'aide de Team Web Access.

  • Voir le journal des travaux ou utilisez la requête Spécification du client pour répertorier ces éléments de travail de spécification.

  • Utilisez le rapport Progression des spécifications, rapport (CMMI) pour vérifier quelles spécifications ont été satisfaites.

Fonctionnalités

  • Une fonctionnalité est un élément d'un plan de produit qui représente un groupe de tâches. Lors de la planification de produit, les représentants de l'équipe de développement et les parties prenantes assignent des fonctionnalités aux itérations. Pour plus d'informations, consultez Planification du projet (CMMI).

  • Entrez les fonctionnalités en tant qu'éléments de travail Spécification, le champ Type de spécification ayant la valeur Fonctionnalité.

  • Le titre de la fonctionnalité indique, dans les termes des utilisateurs, ce que les utilisateurs seront en mesure à faire avec le produit, qu'ils ne pouvaient pas faire dans les itérations précédentes. Pratiquement tous les éléments du plan fournissent une nouvelle valeur ajoutée aux utilisateurs.

    Par exemple, cette séquence de fonctionnalités peut former un plan d'implémentation :

    • « Un acheteur peut choisir un livre dans une liste et l'ajouter à une liste de souhaits. »

    • « La liste de livres contient les prix. Dans la liste de souhaits, le prix total est affiché. »

    • « Les vendeurs peuvent joindre des balises aux livres. Les acheteurs peuvent filtrer la liste de livres à l'aide des balises. »

    Remarquez qu'aucune fonctionnalité n'affecte qu'une seule étape de l'expérience utilisateur, et qu'aucune fonctionnalité n'implique qu'une seule partie de l'architecture de produit. Au lieu de cela, à mesure que les fonctionnalités sont implémentées, plusieurs fonctions sont à nouveau consultées et affectées d'une nouvelle valeur d'utilisateur.

  • Une fonctionnalité est assignée à une itération pendant la planification du produit. Toutes les tâches sous une fonctionnalité doivent être assignées à la même itération.

  • Une fonctionnalité décrit une réalisation partielle des spécifications du client. Il s'agit d'un sous-ensemble des spécifications du client, qui peut implémenter chaque spécification du client dans une certaine mesure.

  • Chaque fonctionnalité peut être liée à un ou plusieurs cas de test qui testent la partie des spécifications que la fonctionnalité représente. Ces cas de test constituent un sous-ensemble des tests système liés aux spécifications du client.

  • L'état de la fonctionnalité ne doit pas être marqué comme terminé jusqu'à ce que ses tests soient complètement définis et réussis.

  • Chaque fonctionnalité est un groupe de tâches de développement et de test. Elle représente la racine d'une arborescence de tâches. Les tâches de développement implémentent les spécifications partielles décrites par la fonctionnalité. Les tâches de test conçoivent et exécutent les cas de test appropriés.

  • Vous utilisez la requête Spécifications du produit pour répertorier les fonctionnalités.

Recherche de fonctionnalités

La séparation de spécifications en des fonctionnalités incrémentielles est une tâche créative qui doit impliquer des développeurs, des analystes et les parties prenantes. Une fonctionnalité définit une partie des fonctionnalités du produit qui peuvent raisonnablement être implémentées de façon séparée par rapport aux fonctions environnantes. Par conséquent, un ensemble exploitable de définitions de fonctionnalités et l'ordre d'un plan dépendent en partie de l'architecture du système.

Pour cette raison, la planification et la conception initiale du produit doivent fonctionner en parallèle, en particulier dans l'itération 0 où l'ensemble du plan est tracé.

Décomposition du scénario

Pour faciliter l'organisation des spécifications en fonctionnalités, il peut être utile de décomposer les scénarios en de plus petites étapes.

Les storyboards sont souvent utilisés pour cette activité. Un storyboard est une suite d'images qui illustrent le scénario. Les diagrammes d'activités UML sont utiles pour indiquer d'autres chemins d'accès, et les diagrammes de séquence UML peuvent vous aider à discuter des interactions entre plusieurs acteurs. Une fois que vous avez utilisé ces outils pour analyser un scénario, vous pouvez entrer les scénarios décomposés dans Team Explorer. Cela vous permet de lier des cas de test aux scénarios et de cette façon de vérifier que les spécifications ont été satisfaites. Pour plus d’informations, consultez Diagrammes d'activités UML : instructions et Diagrammes de séquence UML : indications.

Fonctionnalités - spécifications accomplies dans chaque itération

Une fonctionnalité est une spécification qui résume ce que les utilisateurs peuvent faire à la fin de chaque itération. Vous pouvez créer plusieurs fonctionnalités pour chaque itération. Entrez-les en tant qu'éléments de travail Spécification, en affectant au Type de spécification la valeur Fonctionnalité.

Utilisez vos assignations de scénarios aux éléments de travail pour vous aider à définir les fonctionnalités. Le plan de fonctionnalités de l'exemple suivant est dérivé des assignations de scénarios aux itérations de la section précédente :

  • Itération 1

    • Le client choisit des éléments dans un menu, les ajoute à une commande et indique une adresse de livraison.
  • Itération 2

    • Les clients commencent par afficher une liste de restaurants, puis en choisissent un.

    • Lorsque le client met fin à une commande, celle-ci s'affiche à l'écran du restaurant choisi.

    • Le prix des éléments et le prix total sont indiqués sur la commande.

  • Itération 3

    • Le restaurant marque la commande comme « Terminée » lorsque le repas préparé a été expédié. Le repas est enregistré dans le restaurant.

    • Chaque restaurant peut entrer et mettre à jour son menu.

    • Le client peut parcourir le menu de chaque restaurant avant d'en choisir un.

  • Itération 4

    • Le client entre ses informations de paiement à la fin de la commande. La carte du client est débitée lorsque le restaurant marque la commande comme Terminée.

    • Le restaurant est payé pour les commandes marquées comme étant terminées.

  • Itération 5

    • Les restaurants peuvent définir leur zone de livraison. Le client entre son code postal au début de la session. Le site Web affiche uniquement les restaurants qui peuvent livrer de façon locale.

Scénarios partiellement implémentés

La décomposition des scénarios en petites d'étapes vous permet de séparer certaines étapes qui peuvent être implémentées avant d'autres, implémentés ultérieurement.

Mais vous pouvez parfois séparer d'autres aspects des scénarios. Dans cet exemple, l'équipe peut implémenter une version de base de l'expérience utilisateur dans les premières itérations, puis l'améliorer ultérieurement. Vous pouvez donc ajouter la fonctionnalité suivante :

  • Itération 6 - Le restaurant peut choisir le modèle de couleurs et la police de son menu, ainsi que télécharger son propre logo et ses propres photos de plats.

Ce type de fonctionnalité ne découle pas directement de la décomposition en étapes, mais il découle généralement des discussions relatives aux storyboards. Les fonctionnalités liées à l'expérience utilisateur sont de bonnes candidates pour les itérations ultérieures.

Entrée et inspection de fonctionnalités

Créez des éléments de travail avec le type Spécification et affectez au champ Type de spécification la valeur Fonctionnalité. Affectez au titre de la fonctionnalité la description courte.

Liaison de fonctionnalités aux spécifications

Vous pouvez lier des fonctionnalités aux spécifications comme suit :

  • Liez les éléments de travail Fonctionnalité aux spécifications de scénarios de nœud terminal de leurs itérations. Vous devez les lier à l'aide de liens Éléments connexes car les scénarios de nœud terminal ont déjà des parents.

  • Liez les éléments de travail Cas de test aux scénarios et aux impératifs de qualité de service qu'ils testent. Liez des fonctionnalités au sous-ensemble des cas de test qui doivent réussir lorsque la fonctionnalité a été développée. De cette manière, les cas de test jouent le rôle de lien entre fonctionnalités et spécifications du client.

Fonctionnalités de qualité de service

Les impératifs de qualité de service sont généralement très présents en matière de conception de logiciels. Par exemple, les spécifications de sécurité ne sont généralement pas liées à une tâche de développement spécifique.

Néanmoins, pour chaque impératif de qualité de service, vous devez créer un élément de travail Fonctionnalité dont les enfants testent principalement les tâches qui vérifient qu'un critère de qualité de service est satisfait. Ces éléments de travail sont appelés fonctionnalités de qualité de service.

Certaines fonctionnalités de qualité de service peuvent posséder des tâches de développement. Par exemple, au cours de l'une des premières itérations, vous pouvez implémenter une version du système pouvant gérer quelques utilisateurs uniquement, comme preuve de concept. Pour une itération ultérieure, vous pouvez ajouter une fonctionnalité qui spécifie la capacité cible telle qu'énoncée dans les spécifications du client.

Planification de produit

Avant le début de chaque itération, organisez une réunion pour étudier le plan de produit. La première réunion de planification de produit crée le plan, et les réunions suivantes le révisent en fonction des premières itérations. Pour plus d'informations, consultez Planification du projet (CMMI).

Lors d'une révision de plan de produit, discutez des fonctionnalités avec les parties prenantes métier et soyez prêt à modifier leur ordre de priorité et à les changer d'itérations. La réunion doit inclure les parties prenantes métier et des représentants de l'équipe de développement.

Ceux-ci discutent de l'ordre dans lequel les fonctionnalités seront développées. Pour cela, ils projettent ou partagent sur leurs écrans l'affichage Office Excel de la requête Spécifications du produit, puis classent les fonctionnalités par itération.

Une autre technique consiste à classer les fonctionnalités dans un ordre spécifique, puis à réfléchir au nombre de fonctionnalités qui peuvent être effectuées dans chaque itération. Par exemple, les développeurs peuvent discuter si « Le client peut afficher les prix » doit être déplacé de l'itération 2 à l'itération 3, sans le changer de place dans l'ordre établi. Pour placer les éléments dans un ordre spécifique, ajoutez une colonne supplémentaire nommée Classement à la feuille de calcul et insérez des entiers qui indiquent cet ordre. Classez la feuille de calcul en fonction de cette colonne. Les classements ne sont pas stockés dans Team Foundation Server, mais vous pouvez enregistrer la feuille de calcul. Lorsque vous rouvrez la feuille de calcul, cliquez sur une cellule du tableau d'éléments de travail, puis cliquez sur Actualiser sous l'onglet Équipe.

La planification du produit tient compte des priorités des fonctionnalités et des coûts de développement. Les priorités viennent des parties prenantes métier, avec certaines recommandations en matière de risques de la part des développeurs. Les estimations de coûts viennent des développeurs. Pour avoir une idée exacte des coûts, l'équipe de développement doit avoir déjà travaillé sur l'architecture du produit et peut avoir besoin de l'expérience des premières itérations. Pour cette raison, les estimations de coûts doivent être affinées à chaque révision du plan de produit.

Planification d'itérations

Après la révision du plan de produit, planifiez l'itération. Le plan de produit détermine les fonctionnalités qui seront fournies à la fin de l'itération. Le plan d'itération détermine le travail que l'équipe met en œuvre pour implémenter et tester les fonctionnalités.

Les activités suivantes font partie de la planification des itérations :

  • Créer des tâches de développement et de test, et les lier sous la forme d'enfants aux spécifications de fonctionnalités.

  • Créer des cas de test pour les aspects des spécifications du client qui seront développées dans chaque fonctionnalité. Les cas de test doivent être liés aux spécifications du client afin que vous puissiez surveiller l'état d'avancement des spécifications.

Vous pouvez également lier des cas de test aux fonctionnalités afin d'effectuer le suivi de la correspondance entre fonctionnalités et spécifications. La fonctionnalité ne doit pas être marquée comme terminée tant que les cas de test liés n'ont pas réussi.

Pour plus d'informations, consultez Planification d'une itération (CMMI).