Gestion de projet

Vous pouvez utiliser la section Gestion de projets du guide MSF for CMMI Process Improvement afin de mieux comprendre comment gérer, planifier et coordonner le développement et la maintenance de produits logiciels. Pour plus d'informations concernant CMMI, consultez Informations générales sur CMMI.

Le regroupement Gestion de projets de domaines de processus du CMMI inclut la planification de projet, le suivi et le contrôle de projet, la gestion des accords avec les fournisseurs, la gestion de projet intégrée, la gestion des risques et la gestion de projet quantitative. Tous ces éléments, sauf la gestion de projet quantitative, font partie des niveaux 2 ou 3 du modèle. La gestion de projet quantitative est une activité de niveau 4 du modèle qui indique comment les organisations à maturité élevée utilisent des données quantitatives, statistiquement défendables et objectives pour prendre des décisions de gestion et mener leurs projets jusqu'à un résultat réussi et prévisible.

Les activités de gestion de projet ont des coûts peu élevés sur les activités d'ingénierie à valeur ajoutée. Ces activités sont nécessaires et importantes pour gérer les risques, coordonner les efforts d'ingénierie et définir correctement les attentes des clients. Toutefois, vous devez réduire l'effort consacré à ces activités. « Peu et souvent » constitue un bon slogan. De plus petits lots réduisent complexité et coûts de coordination. Lorsque vous définissez et adaptez votre définition de processus, vous ne devez pas oublier que vos activités de gestion de projet doivent être aussi limitées que possible tout en satisfaisant le profil de risque de votre projet.

Développement itératif

Team Foundation et le modèle de processus MSF for CMMI prennent en charge le travail itératif. Le développement itératif gère les risques en fournissant un logiciel démontrable et testé à des intervalles définis tout au long du projet.

Le planning du projet est organisé en une série d'itérations qui durent en général de quatre à six semaines. Chaque itération se termine par une démonstration du logiciel testé et utilisable. Pour planifier des sprints, voir ici.

• Le plan de projet indique quelles spécifications de fonctionnalités seront développées dans chaque itération. Le plan de projet est développé dans l'itération 0 et révisé au début de chaque itération. Pour créer et afficher le plan de projet, consultez Créer le backlog.

• Chaque plan d'itération indique les tâches qui seront effectuées pendant cette itération. La plupart des tâches représentent le travail de développement et de test requis pour accomplir les spécifications de fonctionnalités planifiées pour cette itération. Le plan d'itération peut être affiché via la page du journal des travaux en souffrance (backlog) des sprints.

Le travail itératif ne gère pas les risques automatiquement. Pour limiter les risques, vous devez organiser le plan de projet en incréments. Les premières itérations doivent présenter une version minimale des comportements les plus importants du produit. Les itérations suivantes permettent d'ajouter des fonctionnalités.

En revanche, il serait beaucoup moins utile de planifier toute la partie ventes d'un site Web d'achats lors du premier tiers du projet, tout le système d'entreposage dans le deuxième tiers et tout le système de paiement dans le troisième. Cette planification risquerait de produire un site Web de ventes attractif et riche en fonctionnalités mais qui n'a pas les moyens de gagner de l'argent auprès de ses clients. Elle est itérative sans être incrémentielle.

Le développement incrémentiel présente les avantages suivants :

• Il répond aux véritables spécifications. Les parties prenantes ont la possibilité d'essayer le produit, ce qui entraîne toujours des améliorations de leurs spécifications.

• Il s'adapte à l'architecture. Il permet à l'équipe de développement de découvrir et de résoudre les éventuelles difficultés qui se produisent avec la plateforme ou des améliorations potentielles à leur conception.

• Il garantit les résultats. Les parties prenantes savent que, même si les ressources du projet ont déjà bien été utilisées, les dépenses à ce jour n'ont pas été gaspillées. La même chose est vraie si les estimations de développement s'avèrent avoir été optimistes et que vous devez supprimer les fonctionnalités les moins importantes.

Pour plus d'informations sur l'expression des spécifications sous une forme appropriée pour le développement incrémentiel, consultez Développement de spécifications.

Cycles plus grands et plus petits

Le projet et l'itération ne sont pas les seuls aspects cycliques du développement de logiciel. Par exemple, dans une itération, les membres de l'équipe effectuent des tâches et archivent du code. Le système de génération crée le produit sur une base continue ou nocturne. L'équipe effectue une brève révision quotidienne de la progression des tâches d'itération.

Grands projets

Un projet dans lequel une équipe travaille via une série d'itérations peut faire partie d'un plus grand projet ou programme. Dans le cadre d'un grand projet, plusieurs équipes travaillent en parallèle. Chaque équipe se compose en général de quatre à 16 personnes.

Ouvrez une branche de contrôle de version séparée pour chaque équipe. Chaque équipe doit s'intégrer à la branche principale à la fin de chaque itération. Pour plus d'informations, consultez Utiliser les branches pour isoler le risque dans le contrôle de version Team Foundation.

Réservez la branche principale à l'intégration et aux tests. L'ordinateur de build doit exécuter un ensemble complet de tests après une intégration.

Assignez une zone à chaque équipe afin que ses éléments de travail puissent être séparés facilement des autres. Pour plus d'informations, consultez Ajouter et modifier des chemins de zone et d'itération.

Les équipes peuvent partager une série d'intégrations, mais ce n'est pas toujours nécessaire. Si les équipes ne synchronisent pas les intégrations, chaque équipe doit avoir son propre préfixe pour ses noms d'itération.

Dans cette section

Cycle du projet : démarrez le projet, rassemblez les spécifications, créez un plan de projet, divisez-le en itérations et fournissez des versions. Gérez les risques et les modifications apportées au plan.	Activités de projet
Cycle de l'itération : révisez et mettez à jour les spécifications, planifiez les tâches d'implémentation des spécifications et gérez les problèmes à mesure qu'ils se posent.	Activités d'itération

Voir aussi

Concepts

Modèle de processus CMMI pour Visual Studio ALM