Planifier un projet (CMMI)
Le résultat souhaité de la planification d'un projet est un plan qui inclut une portée, une planification, un budget, un plan de gestion des risques, ainsi qu'un engagement et une approbation de la part de toutes les parties prenantes. Avec un plan de projet approuvé, vous pouvez passer à l'analyse, la conception, le développement, les tests et finalement la livraison.
Vous pouvez réduire les risques à l'aide d'une méthode de développement itératif. Les itérations vous permettent de faire la démonstration d'un produit partiellement fonctionnel à la fin de chaque itération, puis de réagir aux commentaires découlant de cette démonstration. Par conséquent, le plan constitue un objectif global, soumis à une révision et un affinage avant le démarrage de chaque itération.
Rassemblement et modélisation des spécifications
Cette activité consiste à discuter de ce que le système doit faire, avec les parties prenantes métier, les utilisateurs potentiels et les experts techniques. Il est important de comprendre le contexte professionnel. Si vous devez écrire une application pour des agents de police, il peut être utile de connaître leur jargon, leurs procédures et leurs règles.
Les modèles UML représentent un outil utile pour exprimer des relations complexes et réfléchir dessus. Vous pouvez les tracer dans Visual Studio et les lier à d'autres documents et à des éléments de travail Team Foundation. Pour plus d'informations, consultez Modéliser les besoins des utilisateurs.
Mettez à jour et affinez le modèle des spécifications tout au long du projet. À mesure que chaque itération approche, ajoutez plus de détails aux aspects du modèle pertinents pour cette itération. À partir du modèle, vous pouvez dériver des tests de vérification.
Pour plus d’informations, consultez Spécifications de développement et Développer des tests à partir d'un modèle.
Création de spécifications de produit incrémentielles
Les spécifications que vous avez recueillies auprès de vos clients ne sont pas directement utilisables pour la planification du développement incrémentiel. Par exemple, pour clarifier la procédure d'achat d'un utilisateur sur un site Web, vous pouvez avoir rédigé une série détaillée d'étapes : le client parcourt le catalogue, ajoute un élément à son panier, accède à ce panier, fournit son adresse et paie ; l'entrepôt planifie la livraison ; etc. Ces étapes, ou un diagramme d'activités équivalent, ne constituent pas des spécifications incrémentielles.
En effet, le premier incrément de votre système peut ne mettre qu'un seul élément en vente, livrer à une seule adresse et effectuer uniquement une transaction de test avec le service de paiement. Le deuxième incrément peut fournir un catalogue qui se compose d'une liste simple. Les incréments ultérieurs peuvent ajouter l'option de papier-cadeau pour l'achat ou de demande de catalogues fournis par différents fournisseurs. Certains incréments peuvent porter sur la qualité de service, telle que la capacité à gérer 1 000 clients au lieu d'un seul.
En d'autres termes, les premiers incréments doivent traiter les principaux cas d'usage de bout en bout et progressivement ajouter des fonctionnalités.
Si vous travaillez sur un produit existant, le principe reste le même, mais vous démarrez à partir de fonctionnalités existantes. Si vous êtes peu familier avec sa conception interne, le coût des mises à jour peut être difficile à estimer. Il vaut mieux prévoir large pour les premières modifications.
Pour plus d'informations, consultez Spécifications de développement.
Saisie et modification des spécifications de produit
Enregistrez les spécifications de produit incrémentielles en tant qu'éléments de travail Spécification dans Team Foundation et définissez le type de spécification sur Fonctionnalité. Créez des journaux des spécifications en utilisant TWA ou Team Explorer. Si vous avez plusieurs éléments de travail que vous souhaitez créer en même temps, utilisez Excel.
Estimation des spécifications de produit
L'équipe de développement doit estimer le travail requis pour développer chaque spécification de produit. Cette estimation doit être entrée en heures, dans le champ Estimation d'origine de l'élément de travail.
Au début du projet, seule une estimation approximative est nécessaire.
Divisez les grandes spécifications de produit en des spécifications plus petites. Dans l'idéal, chaque spécification de produit ne doit durer que quelques jours du temps de développement.
Assignation des spécifications de produit aux itérations
Les représentants des parties prenantes métier et l'équipe de développement doivent travailler ensemble pour assigner les spécifications de produit aux itérations. En règle générale, ceci se fait dans le cadre d'une réunion, où vous partagez ou projetez la vue Office Excel de la requête Spécifications du produit.
L'assignation est effectuée à l'aide des informations suivantes :
La priorité de la spécification. Consultez les remarques de la sous-section suivante.
Le coût estimé. En fonction du nombre de membres de l'équipe et de la longueur de l'itération, chaque itération dispose d'un nombre fixe d'heures disponibles pour le développement. En outre, un nombre significatif de ces heures est utilisé pour la planification des itérations et d'autres tâches qui n'impliquent pas directement le développement.
Les dépendances entre les spécifications du produit. Dans une série incrémentielle de spécifications, les spécifications les plus simples doivent être traitées avant les améliorations liées au même domaine.
Vous pouvez définir la spécification dans un élément de travail en fournissant diverses informations, comme indiqué dans les illustrations suivantes :
.png "Formulaire d'élément de travail Spécification")
Indications relatives à la définition de priorités
De nombreux modèles détaillés existent pour la définition de priorités. Nous étudierons certains d'entre eux lorsque nous aborderons la planification des itérations. Pour le moment, au niveau du projet, nous incluons certaines indications qui peuvent être utiles pour la gestion des risques et l'optimisation de la valeur ajoutée.
Donner la priorité à des scénarios de bout en bout minimes.
L'objectif est d'aboutir à un scénario de bout en bout simple aussi tôt dans le projet que possible. Vous ajoutez ensuite plus de fonctionnalités aux différentes parties du scénario. Cette pratique permet de s'assurer que les principales fonctions de la plateforme et les principales idées des spécifications sont rapidement mises en œuvre.
Par contre, ne divisez pas la planification en fonction de l'architecture. Une planification qui termine la base de données, la logique métier, puis l'interface utilisateur, nécessitera probablement un important travail d'intégration des différentes les parties à la fin du processus. De la même manière, un fractionnement horizontal tel que {composant de ventes ; composant d'entrepôt ; composant de paiement} n'est pas recommandé. Il aboutirait probablement un système parfait pour vendre sur le Web mais serait beaucoup trop long pour que l'entreprise puisse espérer obtenir de d'argent de la part de ses clients. Des composants complets peuvent être planifiés pour les itérations ultérieures uniquement s'il s'agit de modules complémentaires facultatifs.
Donner la priorité au risque technique.
Si un scénario inclut un élément techniquement risqué, développez-le au début de la planification. Anticiper les risques. Si un élément ne peut pas être accompli, il vaut mieux le savoir dès le début du projet afin de pouvoir l'annuler ou le remplacer par une autre approche. Donnez donc la priorité aux spécifications techniquement risquées dans les premières itérations.
Donner la priorité à la réduction des incertitudes.
Les parties prenantes métier ne sont pas toujours sûres de toutes leurs spécifications. Il est difficile de prévoir quel comportement du produit fonctionnera le mieux dans le contexte professionnel. Donnez la priorité au travail susceptible de réduire les incertitudes. Pour ce faire, vous pouvez développer une version plus simple du scénario que les utilisateurs peuvent expérimenter. Différez le scénario complet à une itération ultérieure, au cours de laquelle les résultats de ces expériences peuvent être pris en considération.
Donner la priorité aux spécifications les plus importantes.
Si possible, essayez d'établir une fonction opportunité-coût de retard pour chaque scénario. Utilisez ces éléments pour déterminer les spécifications susceptibles de générer plus de valeur plus rapidement aux clients. Donnez la priorité à ces spécifications dans les premières itérations. Cela peut vous donner la possibilité de présenter rapidement un produit partiel.
Regrouper les scénarios communs à plusieurs personas.
Si vous possédez des scénarios utiles pour deux personas ou plus, regroupez-les. Classez-les en fonction du nombre de personas qui nécessitent le scénario. Donnez la priorité aux scénarios qui s'appliquent à un plus grand nombre de personas dans les premières itérations.
Classer les personas.
Les personas représentent des segments de marché ou des groupes d'utilisateurs. Les responsables marketing et les chefs d'entreprise doivent être capables d'articuler la priorité de ces segments ou groupes en fonction de l'utilisation prévue ou de la valeur du segment. Si les segments ou groupes d'utilisateurs peuvent être classés par ordre de priorité, indiquez ceci en répertoriant les personas de chaque segment dans l'ordre. Identifiez les scénarios des personas les plus importantes et donnez-leur la priorité au cours des premières itérations de la planification.
En règle générale, il convient de donner la priorité à la réduction des risques en raison de la possibilité d'échec. Il convient de donner la priorité aux fonctionnalités communes car elles sont susceptibles d'être requises et peu susceptibles de changer. Il convient de donner la priorité aux spécifications les plus importantes. Il convient de permettre la présentation rapide du produit à un sous-ensemble de personas en donnant la priorité à tous les scénarios requis pour satisfaire les besoins des personas.
Planification des tests
L'estimation du travail lié à chaque spécification doit inclure l'effort requis pour tester la spécification, que ce soit manuellement ou en créant un test automatisé.
Avant d'être considérée comme terminée, chaque spécification de produit doit être liée à un ensemble d'éléments de travail de cas de test qui indiquent si elle a été satisfaite, et les tests doivent réussir.
Lorsque vous créez ou révisez des spécifications de produit, le plan de test correspondant doit être mis à jour.
Révision des spécifications de produit
Reprenez cette activité avant chaque itération afin d'étudier les spécifications nouvelles et révisées, les priorités révisées et les estimations révisées. Il y a plus de révisions dans les premières itérations.
Après les premières itérations, les membres de l'équipe de développement sont plus assurés quant aux estimations. Ils doivent parcourir les estimations de l'itération suivante (voire des deux suivantes) et modifier les champs Estimation d'origine des spécifications assignées à ces itérations.