Activités d'itération
Dans MSF for CMMI Process Improvement, vous planifiez un projet sous la forme d'une série d'itérations. Chaque itération dure en général de quatre à six semaines, pendant lesquelles l'équipe de développement implémente un ensemble spécifié de spécifications.
Au début d'une itération
La planification d'une itération a lieu au début ou avant le démarrage de celle-ci. Elle inclut les tâches suivantes :
Étudier les spécifications assignées à l'itération et les définir plus en détail.
Créer des éléments de travail Tâche pour le travail qui doit être effectué pour implémenter et tester chaque spécification. Lier les tâches aux éléments de travail Spécification à l'aide du type de lien parent.
Définir le champ Estimation d'origine de chaque tâche. Diviser les tâches dont les estimations de durée dépassent quelques jours.
Comparer les estimations avec le temps disponible pour l'itération. Si le total de l'estimation est trop long, simplifier certaines spécifications ou les différer aux itérations ultérieures.
Pour plus d'informations, consultez Planifier une itération (CMMI).
Pendant une itération
Exécution des tâches
Les membres de l'équipe effectuent leurs tâches, en enregistrant ces événements dans des éléments de travail. La réalisation d'une tâche peut inclure le contrôle du code de programme et d'autres artefacts. Les tâches ne doivent pas durer plus de quelques jours. Les plus grandes tâches sont fractionnées lors de la planification des itérations. Pour plus d’informations, consultez Journée d'un développeur ALM : écriture d'un nouveau code pour un récit utilisateur.
Si un membre de l'équipe rencontre un obstacle qui ne peut pas être résolu immédiatement, il doit créer un élément de travail Problème.
Tests
Des tests manuels ou automatiques doivent être développés, et les cas de test doivent être liés aux spécifications du produit. Une spécification de produit ne peut pas être considérée comme terminée tant que l'élément de travail n'est pas lié à des cas de test qui réussissent et démontrent qu'elle fonctionne.
Le travail de développement des tests doit être inclus dans les tâches liées à la spécification du produit.
Builds enchaînées et nocturnes
Le système de génération crée le produit à partir de mises à jour récemment archivées et exécute des tests automatisés. Vous pouvez demander à ce que les tests principaux s'exécutent de façon continue, et vous pouvez en définir une suite complète à exécuter toutes les nuits. Cette pratique permet de s'assurer que les bogues ne s'accumulent pas. Pour plus d'informations, consultez Configurer et gérer votre système de génération.
Réunion journalière debout
L'ensemble de l'équipe passe rapidement en revue la progression des tâches de l'itération. Les participants peuvent utiliser le tableau de tâches ou projeter le tableau de bord Progression sur un mur, le partager à l'aide d'Office Live Meeting, ou les deux à la fois.
Chaque membre de l'équipe raconte rapidement ses dernières avancées, le travail prévu pour la journée, ainsi que ses éventuels problèmes majeurs.
Le chef de projet ou le responsable d'équipe indique la progression de la résolution des problèmes. Pour plus d'informations, consultez Gérer les problèmes (CMMI).
Le nombre de bogues est examiné. Les bogues doivent avoir la priorité sur les nouveaux développements. Conservez le nombre de bogues le moins élevé possible pendant tout le projet. Si le nombre de bogues augmente, discutez des causes et de l'impact possible sur le travail de développement.
Le taux d'avancement est examiné.
Ajustement de la portée
Le graphique d'avancement peut indiquer que les tâches ne seront pas terminées d'ici la fin de l'itération. Dans ce cas, le chef de projet ou le responsable d'équipe lance une discussion à propos de la façon dont les spécifications peuvent être simplifiées afin que les tâches puissent être raccourcies. Pour plus d'informations, consultez Rapport sur le burndown et le taux de burndown.
Les spécifications et tests correspondants sont ajustés. Une nouvelle fonctionnalité de spécification est placée dans le plan de projet pour les fonctionnalités manquantes. Dans la révision de plan de projet qui a lieu vers la fin de l'itération, la fonctionnalité peut être assignée à une future itération ou supprimée.
Les demandes de modification et les risques ne sont pas pris en compte pendant une itération.
Triage
Certains membres de l'équipe (généralement pas l'équipe entière) se rencontrent régulièrement pour examiner les bogues. Chaque membre de l'équipe doit enregistrer un bogue lorsqu'il découvre une erreur. Au début, un bogue enregistré possède l'état Proposé, et l'objectif de la réunion de triage est de décider s'il faut le résoudre, le différer jusqu'à une itération ultérieure ou le rejeter.
Pour plus d'informations, consultez Faire le suivi des bogues.
À la fin d'une itération
Vérification
Les spécifications sont considérées comme étant terminées uniquement si les tests associés réussissent. Pour plus d'informations, consultez Vérifier des spécifications.
Rétrospective
L'amélioration des processus est un objectif CMMI important.
La rétrospective d'une itération indique ce qui s'est bien ou mal passé au cours de celle-ci et étudie les améliorations à apporter aux processus et outils utilisés par l'équipe. Une documentation significative sur les rétrospectives est disponible sur le Web.
Les membres de l'équipe ne doivent pas se faire de reproches les uns aux autres. Essayez d'améliorer le processus afin que les erreurs commises par les personnes aient le moins d'effets possible.
Lorsque vous modifiez votre processus, assurez-vous que l'équipe s'accorde sur les décisions suivantes :
Comment savoir qu'il s'agit d'une amélioration.
Quand faire l'évaluation.
Que faire ensuite.
Intégration
Si ce projet fait partie d'un programme plus vaste, chaque équipe effectue son travail dans une branche du système de contrôle de version. La branche principale (Main) est réservée à l'intégration du travail des équipes. À la fin d'une itération, l'équipe peut effectuer une intégration avec la branche principale. Pour plus d'informations, consultez Utiliser les branches pour isoler le risque dans le contrôle de version Team Foundation.
L'intégration se compose de deux étapes :
Une intégration en aval, pour fusionner le code le plus récent de la branche principale dans la branche de projet locale. Après la fusion, les tests automatiques et manuels sont exécutés. Ces tests peuvent révéler des erreurs. La priorité la plus élevée consiste à corriger ces erreurs.
Une intégration inverse. Le code de la branche locale est fusionné dans la branche principale. La build et la suite de tests complète de la branche principale s'exécutent. Les modifications sont inversées si des erreurs se produisent. L'introduction d'erreurs dans la branche principale est désapprouvée. Si aucune erreur ne se produit, l'intégration est considérée comme terminée.
Nous vous recommandons d'effectuer une intégration à la fin de chaque itération. Si vous la différez, la liste des bogues à résoudre après intégration en aval est plus longue. Si la résolution des bogues est longue, la branche principale comportera de nouvelles données et vous devrez exécuter une autre intégration en aval.
Préparation de l'itération suivante
Vers ou à la fin d'une itération, plusieurs activités de gestion de projet sont réalisées. Celles-ci incluent la révision des risques et du plan par rapport aux demandes de modification et à l'évolution des estimations de développement.
Pour plus d'informations, consultez Activités de projet.