Scrum

Scrum est une infrastructure d'exécution de projets basée sur des valeurs et principes agiles. Il définit un jeu d'activités qui peuvent aider votre équipe à fournir plus rapidement plus de valeur ajoutée à vos clients. Ces activités donnent à vos clients la possibilité d'étudier, de guider et d'influencer le travail de votre équipe à mesure qu'il progresse. Cette approche ne consiste pas à définir toutes les étapes dès le début du projet. Au lieu de cela, votre équipe travaille par courtes itérations (appelées aussi sprints) et affine son plan à mesure qu'elle avance dans son travail. Pour plus d'informations sur les principes et valeurs agiles sur lesquels repose le Scrum, consultez Principes et valeurs agiles, par Jeff Sutherland.

MSF for Agile Software Development v5.0 est basé sur le Scrum. Par conséquent, votre équipe peut adopter le Scrum grâce aux outils intégrés à vos principales activités de développement.

Dans cette rubrique Préparer le projet Planifier le projet Planifier un sprint Exécuter un sprint Suivre le projet

Préparer le projet

Avant de démarrer votre projet, effectuez les tâches suivantes :

• établir l'analyse de cas ;

• réunir une équipe ;

• configurer l'infrastructure de l'équipe.

Pour établir une analyse de cas, identifiez le besoin et la justification de l'entreprise, définir la vision et obtenir un financement. « Crossing the Chasm », le livre de Geoffrey Moore, contient de bons conseils pour l'établissement de votre vision. Pour plus d'informations, consultez la ressource Web suivante : Crossing the Chasm (page éventuellement en anglais).

Une fois l'analyse de cas établie, vous devez réunir votre équipe, puis identifier le ScrumMaster et le propriétaire du produit. Pour plus d'informations, consultez Rôles.

Pour finir, votre équipe doit configurer son infrastructure de travail. Elle peut par exemple installer Visual Studio Team Foundation Server et Visual Studio Application Lifecycle Management (ALM), créer et, le cas échéant, personnaliser votre projet d'équipe, et configurer les pratiques d'ingénierie. Pour plus d'informations, consultez Prise en main de Visual Studio Application Lifecycle Management, Personnalisation de votre projet d'équipe et Pratiques d'ingénierie.

Planifier le projet

Dans un projet Scrum, l'équipe passe la majeure partie de son temps à développer un produit dans le cadre d'une série de sprints. Cependant, elle doit tout d'abord créer un plan global pour son projet. Ce plan est comme une feuille de route permettant de guider les décisions plus spécifiques que l'équipe devra prendre au cours du projet. À mesure que l'équipe implémente le plan, celui-ci évolue. Lorsque l'équipe aura terminé de planifier son projet, elle aura créé un journal des travaux en souffrance du produit et, si nécessaire, un plan de version.

Générer le journal des travaux en souffrance du produit

Le journal des travaux en souffrance du produit est une liste de récits utilisateur qui décrivent ce dont les utilisateurs ont besoin et ce qui est important pour eux. Les récits utilisateur sont classés par ordre de priorité en fonction de leur valeur commerciale et risque. L'équipe estime ces récits utilisateur dans des unités abstraites appelées points de récit.

	Créer des récits utilisateur : dans son livre « User Stories Applied », Mike Cohn définit les récits utilisateur comme décrivant les fonctionnalités utiles pour l'utilisateur ou l'acquéreur d'un système ou logiciel. Les récits utilisateur sont donc rédigés du point de vue de l'utilisateur final. Par exemple : « Étant déjà client, je souhaite trouver un repas que j'ai déjà commandé. » Pour plus d'informations, consultez Création d'un journal des travaux en souffrance du produit.
	Classer les récits utilisateur par ordre de priorité : le propriétaire du produit classe les récits utilisateur par ordre de priorité dans le journal des travaux en souffrance du produit en travaillant avec les clients pour savoir ce qui est important pour eux et en travaillant avec l'équipe pour connaître les risques et dépendances. Le propriétaire du produit spécifie des priorités en assignant un rang à chaque récit utilisateur pour indiquer l'ordre dans lequel l'équipe doit les implémenter. Le propriétaire du produit peut utiliser de nombreuses techniques pour analyser et comparer la valeur des récits utilisateur. Si votre équipe dispose déjà d'une méthode de classification par priorité qui fonctionne, vous devez utiliser cette méthode. Certaines techniques de classement par priorité sont étroitement associées à la communauté agile, telles que le modèle Kano de satisfaction des clients et la méthode des poids relatifs de Karl Wiegers. (Pour plus d'informations sur la méthode des poids relatifs, consultez la page suivante sur le Web : Chaque chose à sa place : classement des exigences par ordre de priorité (éventuellement en anglais).) D'autres techniques de classement par priorité, telles que la priorité en fonction du coût, la valeur actualisée nette, le délai de récupération et le taux de rendement interne sont bien établies à l'extérieur de la communauté agile. Ces techniques sont également légitimes et appropriées pour classer votre journal des travaux en souffrance du produit par ordre de priorité dans le cadre d'un projet Scrum. Pour plus d'informations, consultez « Part II: Estimating Size » de l'ouvrage identifié par la ressource Web suivante (page éventuellement en anglais) : Agile Estimation and Planning.
	Estimer les récits utilisateur : votre équipe estime de façon collaborative chaque récit utilisateur en points de récit. Dans son livre « Agile Estimation and Planning », Mike Cohn définit les points de récit comme étant des unités de mesure permettant d'exprimer la taille globale d'un récit utilisateur, d'une fonctionnalité ou d'un autre type de travail. Les points de récit sont des valeurs relatives qui ne se traduisent pas directement en un nombre spécifique d'heures. Au lieu de cela, les points de récit aident l'équipe à quantifier la taille générale du récit utilisateur. Ces estimations relatives sont moins précises ; elles nécessitent donc moins d'efforts et résistent mieux au temps qui passe. En estimant des points de récit, votre équipe fournit la taille générale des récits utilisateur dès le début et développe ultérieurement l'estimation plus détaillée des heures de travail, lorsque les membres de l'équipe sont sur le point d'implémenter les récits utilisateur.

Déterminer la rapidité de votre équipe

Avant de créer son plan de version et de planifier chaque sprint, votre équipe doit déterminer sa rapidité. Cette rapidité représente le nombre de points de récit qu'elle peut effectuer au cours d'un sprint.

Si votre équipe mesure sa rapidité en collectant les données qui indiquent combien de récits utilisateur elle effectue pendant une période donnée, vous devez utiliser ces données. Elles représentent la meilleure indication de la rapidité de l'équipe. Si vous ne disposez pas de ces données maintenant mais que vous commencez à exécuter votre projet avec Visual Studio ALM et MSF for Agile Software Development v5.0, les données seront rassemblées au cours du projet. Pour plus d'informations, consultez Rapport État de toutes les itérations.

Si aucune donnée d'historique n'est disponible, votre équipe peut réaliser une estimation approximative du nombre de points de récit qu'elle peut effectuer au cours du premier sprint. Consultez les récits utilisateur estimés en haut de la pile de priorité et faites une évaluation rapide du nombre de récits que l'équipe pourrait réaliser pendant un sprint. Ajoutez les points de récit de chaque récit utilisateur pour obtenir une estimation initiale. Après le premier sprint, vous pouvez utiliser les données d'historique pour déterminer la rapidité de l'équipe. Au cours des premiers sprints, vous devez vous attendre à des variations importantes tandis que votre équipe apprend à faire des estimations régulières. Après plusieurs sprints, la rapidité mesurée de votre équipe doit devenir plus stable. Une fois la rapidité mesurée stable, réévaluez le plan de version.

L'estimation de la rapidité de votre équipe fournit un point de départ que vous pouvez utiliser pour déterminer le nombre de récits utilisateur à implémenter dans un sprint, mais cette estimation ne représente pas la base de l'engagement de l'équipe. L'engagement de l'équipe doit reposer sur des estimations plus détaillées des tâches requises pour effectuer les récits utilisateur. Pour plus d'informations, consultez Planification de produit, classeur.

Établir le plan de version

Au cours de chaque sprint, votre équipe effectue un incrément du produit qui pourrait être livré. Bien que les récits utilisateur implémentés par votre équipe soient prêts à être livrés à la fin du sprint, ils peuvent ne pas offrir suffisamment de valeur commerciale pour justifier la publication réelle du produit. Planifiez vos versions en les assignant aux itérations :

• Identifiez des groupes de récits utilisateur qui, ensemble, fournissent suffisamment de valeur commerciale pour être livrés à vos clients.

• Déterminez au cours de quels sprints l'équipe doit s'attendre à effectuer ces groupes de récits utilisateur.

Lorsque votre équipe progresse, les récits utilisateur seront ajoutés au journal des travaux en souffrance du produit, et les récits utilisateur peuvent être supprimés. De plus, la priorité de certains récits utilisateur changera, et certains récits utilisateur peuvent être implémentés plus tôt ou plus tard que la date prévue. Le propriétaire du produit gère le plan de version et le journal des travaux en souffrance du produit tout au long du projet.

Pour plus d'informations, consultez Planification de produit, classeur.

Préparer le premier sprint

Un sprint est une itération de développement avec délai imparti, qui dure généralement entre une et quatre semaines et qui génère un incrément du produit que l'équipe pourrait livrer. Avant que l'équipe ne démarre le premier sprint, le propriétaire du produit prépare le journal des travaux en souffrance du produit. Les récits utilisateur dont la priorité est assez élevée pour figurer dans le premier sprint doivent être prêts à être implémentés. Le propriétaire du produit doit préparer le journal des travaux en souffrance du produit en effectuant les tâches suivantes :

• Diviser les récits utilisateur en récits plus petits.

• Fournir des détails à propos des récits utilisateur que l'équipe devra diviser en tâches.

Le propriétaire du produit sait qu'un récit utilisateur est trop grand lorsqu'il représente une quantité significative de la rapidité totale de l'équipe. Par exemple, un récit utilisateur comportant 15 points de récit est trop grand pour la réunion de planification de sprint si la rapidité de l'équipe est de 30 points de récit. En effet, l'équipe aurait besoin de la moitié du sprint uniquement pour effectuer ce récit utilisateur.

Votre équipe peut également rechercher les détails des récits utilisateur afin d'être en mesure de les diviser en tâches et d'estimer ces tâches. Par exemple, lorsque votre équipe examine le récit utilisateur « En tant que client, je souhaite être en mesure de rechercher un type de repas », elle peut poser des questions telles que :

• « Doit-il s'agir d'une recherche en texte libre ou cela peut-il être une sélection d'une liste de types disponibles ? »

• « Si plusieurs vendeurs fournissent un repas qui correspond à la recherche, comment les résultats doivent-ils être triés ? »

Pour plus d'informations, consultez Préparation du sprint suivant.

Planifier un sprint

Une fois que votre équipe a développé le journal des travaux en souffrance du produit et établi un plan de version, elle peut commencer à travailler sur les sprints. L'équipe démarre le sprint par une réunion de planification, au cours de laquelle elle s'engage à effectuer un ensemble de récits utilisateur du journal des travaux en souffrance du produit. Cet ensemble de récits utilisateur, avec les tâches correspondantes, constitue le journal des sprints en souffrance. Pour plus d'informations, consultez Comparaison des journaux des travaux en souffrance du produit et sprint.

Une fois le sprint commencé, les récits utilisateur du journal des sprints en souffrance ne changent pas. Par conséquent, le plan doit être assez détaillé pour que l'équipe puisse tenir son engagement avec confiance.

Pour plus d'informations, consultez Réunion de planification de sprint.

Choisir les récits utilisateur

Votre équipe choisit les récits utilisateur susceptibles d'être implémentés dans le sprint. Elle identifie les récits utilisateur qui possèdent la priorité plus élevée et dont les points de récit ne dépassent pas la rapidité estimée. Par exemple, les cinq récits utilisateur qui ont la priorité plus élevée comportent 8, 3, 7, 6 et 2 points de récit. Si votre équipe dispose d'une capacité de 25 points de récit par sprint, elle peut inclure les quatre premiers récits dans le journal des sprints en souffrance.

Pour plus d'informations, consultez Journal des itérations en souffrance, classeur.

Identifier les tâches

Votre équipe évalue chaque récit utilisateur pour déterminer ce qu'elle doit faire pour les implémenter. Elle divise les récits utilisateur en tâches afin de suffisamment comprendre ces récits pour pouvoir s'engager en toute confiance pour leur réalisation au cours du sprint.

Les équipes utilisant Scrum depuis longtemps peuvent prendre cet engagement sans avoir à diviser les récits utilisateur en tâches.

Estimer les tâches

Une fois les tâches identifiées, votre équipe estime la durée (en heures) de chaque tâche. Les équipes utilisent fréquemment la technique du planning poker pour estimer les tâches. Cette technique empêche les équipes d'essayer d'estimer la durée des tâches de façon trop précise.

S'engager pour les récits utilisateur

L'équipe utilise le classeur Journal des itérations en souffrance pour s'assurer qu'elle dispose de suffisamment d'heures de travail pour effectuer toutes les tâches. Si le sprint prévoit un travail supérieur aux disponibilités de l'équipe, les récits utilisateur à la priorité moins élevée doivent être supprimés jusqu'à ce que le travail corresponde à la capacité de l'équipe pour le sprint. Les plus petits récits qui ont une priorité moins élevée peuvent être échangés contre des récits plus importants qui ne correspondent pas au sprint.

L'équipe s'engage à effectuer les récits utilisateur qu'elle a dit qu'elle pouvait réaliser. Elle fait cet engagement en sachant bien que le propriétaire du produit n'essaiera pas de lui donner du travail en plus ou de modifier les priorités des récits utilisateur implémentés au cours du sprint.

Exécuter un sprint

Pendant un sprint, l'équipe effectue les tâches requises pour implémenter les récits utilisateur du journal des sprints en souffrance. Elle peut suivre sa progression et s'assurer qu'elle satisfait aux critères d'acceptation des clients et à ses propres critères pour aboutir à un logiciel fini avant la fin de chaque sprint.

Effectuer les récits utilisateur

Après avoir planifié le sprint, l'équipe dispose d'une liste de récits utilisateur qu'elle s'est engagée à effectuer au cours du sprint. Ces récits utilisateur ont été divisés en tâches. Chaque membre de l'équipe s'engage pour une tâche lorsque le sprint commence. Une fois cette tâche terminée, il met à jour son état et s'engage sur une autre tâche. De cette manière, l'équipe travaille à l'aide de la liste des tâches, en effectuant les récits utilisateur du journal des sprints en souffrance. Un membre de l'équipe peut indiquer les tâches qui ont été effectuées lors de l'archivage du code. Pour plus d'informations, consultez Associer des éléments de travail à des ensembles de modifications.

Pour plus d'informations sur l'assignation des tâches et la mise à jour de leur état, consultez Tâches (Agile).

Scrum repose sur la communication entre les personnes plus que sur des processus formels pour s'assurer que les dépendances sont comprises, que les compétences sont partagées et que les modifications apportées aux plans sont effectuées de manière efficace. Organisez chaque jour une courte réunion Scrum au cours de laquelle chaque membre de l'équipe décrit le travail qu'il a accompli le jour précédent, le travail qu'il projette d'effectuer ce jour, ainsi que tous les problèmes ou obstacles qui peuvent affecter les autres membres de l'équipe ou nécessiter leur aide. Pour plus d'informations, consultez Réunion de Scrum quotidienne.

Dans son livre « Extreme Programming Explained », Kent Beck explique qu'il revient nettement moins cher de corriger un bogue plus tôt plutôt que plus tard. À partir de cela, l'équipe doit comprendre ce qui est important pour votre client. Ainsi, peut-être le client préfère-t-il favoriser la qualité par rapport au nombre de fonctionnalités. Le propriétaire du produit doit connaître ce genre d'informations car les clients contrôlent le flux du travail de l'équipe.

Les logiciels produits par une équipe Scrum ne doivent pas comporter d'erreurs. Cependant, l'équipe rencontrera probablement des bogues au cours de ses projets. Traitez les bogues en sachant qu'il revient moins cher et qu'il est plus rapide de les résoudre à mesure qu'ils sont détectés plutôt que de les remettre à plus tard. Lorsque l'équipe rencontre des bogues, elle doit les corriger immédiatement. Si l'équipe ne peut pas corriger le bogue le jour même où elle l'a détecté, créez un élément de travail Bogue dans Visual Studio ALM et corrigez-le avant la fin du sprint.

Pour plus d'informations, consultez Bogue (Agile).

Effectuer le suivi de la progression d'un sprint

L'équipe peut suivre la progression du sprint pour s'assurer que le travail est bien effectué comme prévu et qu'il satisfait aux critères d'acceptation. Les équipes Scrum utilisent le plus souvent un rapport d'avancement pour suivre leur progression au cours d'un sprint. MSF for Agile Software Development v5.0 fournit un ensemble de rapports que les équipes peuvent utiliser pour suivre la progression d'un sprint.

Avancement et taux d'avancement, rapport (Agile)

Indicateurs de qualité de build, rapport

Progression du plan de test, rapport

Progression des récits, rapport (Agile)

Les équipes trouvent souvent qu'elles ont besoin plus ou moins de temps pour effectuer une tâche par rapport à ce qu'elles avaient estimé pendant la réunion de planification de sprint. Ce genre de variation est typique. Vous pouvez enregistrer ces informations en spécifiant le temps effectif que l'équipe a passé sur la tâche.

À mesure que le sprint progresse, l'équipe peut identifier du travail qu'elle n'avait pas prévu mais qui est nécessaire pour effectuer un récit utilisateur. Dans ce cas, créez une tâche, estimez-la puis déterminez si votre équipe peut l'effectuer dans les heures qui restent du sprint. Si l'équipe peut effectuer la tâche, continuez le sprint. Si elle ne peut pas effectuer la tâche au cours du sprint, rencontrez le propriétaire du produit pour discuter de la procédure à suivre. Le propriétaire du produit et votre équipe peuvent résoudre le problème en apportant les modifications suivantes :

• Réduire les critères d'acceptation du récit utilisateur afin que la tâche devienne inutile.

• Supprimer le récit utilisateur du journal des sprints en souffrance.

• Annuler le sprint.

Terminer le sprint

À mesure que la fin du sprint approche, vous devez vous assurer que votre équipe effectue tous les récits utilisateur ou spécifications. Par exemple, assurez-vous que les tests d'acceptation réussissent et que chaque récit utilisateur satisfait aux critères définis par l'équipe. Pour plus d'informations sur la définition d'un composant considéré comme terminé, consultez la page Web suivante (page éventuellement en anglais) : Mitch Lacey & Associates, Inc.

État des bogues, rapport

Tendances des bogues, rapport

Le dernier jour du sprint, l'équipe montre les récits utilisateur effectués au propriétaire de produit et parfois même aux clients. Le propriétaire du produit et les clients déterminent s'ils acceptent chaque récit utilisateur. Pour plus d'informations, consultez Réunion de révision sprint.

Après la révision du client, votre équipe organise une réunion de rétrospective. Pour plus d'informations, consultez Réunion de rétrospective.

Suivre le projet

À mesure que l'équipe travaille dans le cadre de sprints à la livraison d'incréments du projet, les clients développent une meilleure compréhension des besoins restants et des modifications doivent être envisagées dans l'environnement métier. Le propriétaire du produit travaille avec les clients pour comprendre ces modifications. Il gère le journal des travaux en souffrance du produit et le plan de version de façon à refléter ces modifications et à s'assurer que l'équipe dispose de ce dont elle a besoin au début de chaque sprint. L'équipe effectue le suivi de la progression du produit dans son ensemble pour s'assurer qu'elle avance correctement dans la réalisation du projet.

Préparer le sprint suivant

L'actualisation du journal des travaux en souffrance du produit a une relation directe avec la qualité et la réalisation globales du projet. Le journal des travaux en souffrance doit être régulièrement mis à jour, modifié et repensé de façon à toujours être prêt lorsque l'équipe est sur le point de démarrer un sprint.

Le propriétaire du produit prépare le journal des travaux en souffrance du produit pour le sprint suivant en effectuant les tâches suivantes :

• Mettre à jour les récits utilisateur et leurs priorités à mesure que les besoins des clients changent.

• Diviser les récits utilisateur susceptibles d'être implémentés au cours du sprint suivant.

Lorsque l'équipe termine un sprint, d'autres récits utilisateur s'approchent du haut du journal des travaux en souffrance du produit. Le propriétaire de votre produit doit analyser et diviser ces récits afin que votre équipe puisse les implémenter au cours du prochain sprint. (Pour plus d'informations, consultez la section Préparer le premier sprint plus haut dans cette rubrique.) Mike Cohn parle souvent de ce processus comme l'iceberg du journal des travaux en souffrance du produit. À mesure que l'équipe travaille sur un ensemble de fonctionnalités, l'iceberg fond et d'autres tâches arrivent à la surface. Dans ce processus, les détails supplémentaires émergent, juste assez et juste à temps.

Maintenant que l'équipe est occupée par un sprint, le propriétaire du produit ne peut plus s'attendre à avoir le même niveau d'implication de l'équipe dans la maintenance du journal des travaux en souffrance du produit que celui fourni lors de la préparation du premier sprint. Pour aider le propriétaire du produit à préparer le journal des travaux en souffrance du produit avec un minimum d'interruption dans le sprint, l'équipe et le propriétaire du produit discutent des problèmes existants du journal des travaux en souffrance du produit au cours du sprint.

Effectuer le suivi de la progression de la version

À mesure que le projet avance de sprint en sprint, l'équipe effectue le suivi de la progression globale vers la version suivante. Elle effectue également le suivi de sa progression pour évaluer et améliorer sa rapidité. Lorsque l'équipe suit sa progression, elle doit essayer de répondre à des questions telles que :

• Travaillons-nous sur les récits utilisateur les plus appropriés ? Le journal des travaux en souffrance du produit est affiné avec de nouveaux récits utilisateur à mesure que le projet avance. Toutefois, si le nombre total de récits du journal ne diminue pas, bien que vous effectuiez des récits lors de chaque sprint, l'équipe doit en rechercher la cause. Les récits réalisés ne sont peut-être pas les récits appropriés. L'équipe doit avoir une vision et un objectif pour chaque version et s'assurer que les récits sont directement liés aux demandes du client.

• Avons-nous un retard technique ? Certaines équipes considèrent les récits utilisateur comme étant terminés même quand il reste à effectuer du travail de résolution de bogues. Ces équipes prennent un retard technique qu'elles doivent payer ultérieurement, généralement à un prix plus élevé.

Visual Studio ALM fournit plusieurs rapports pour aider votre équipe à suivre sa progression sur de nombreux sprints.

Rapport État de toutes les itérations

Aperçu des récits, rapport (Agile)

Progression des récits, rapport (Agile)

Vous pouvez créer des rapports personnalisés et des requêtes d'élément de travail pour faciliter le suivi de la progression. Pour plus d'informations, consultez Création, personnalisation et gestion de rapports pour Visual Studio ALM et Recherche de bogues, de tâches et d'autres éléments de travail.

Terminer la version

Si votre équipe n'accumule pas de retard technique, elle peut diffuser le produit une fois qu'elle a terminé les sprints de cette version, sans travail supplémentaire. L'équipe et le propriétaire du produit organisent des réunions de rétrospective et de révision client pour examiner la version dans son ensemble.

Toutefois, le retard technique est un problème sérieux que les équipes ne peuvent pas écarter facilement. Si votre équipe, comme de nombreuses autres équipes, accumule toujours un retard technique, vous devez passer du temps à faire le travail en attente pour terminer les récits utilisateur avant de diffuser le produit. Au cours de la réunion de rétrospective de la version, votre équipe doit envisager ce qu'elle doit faire au cours des prochains sprints pour éviter de prendre encore plus de retard.

Voir aussi

Concepts

Pratiques d'ingénierie

Choisir un modèle de processus

Planification et suivi de projets

Autres ressources

MSF for Agile Software Development v5.0