Scrum (développement)

Scrum est un framework d’organisation de développement de produits complexes. Il est défini par ses créateurs comme un « cadre de travail permettant de répondre à des problèmes complexes et changeants tout en livrant de manière productive et créative des produits de la plus grande valeur possible ». Scrum est considéré comme une méthode agile.

La méthode s'appuie sur le découpage d'un projet en boîtes de temps, nommés « sprints ». Les sprints peuvent durer entre quelques heures et un mois (avec une préférence pour deux semaines). Chaque sprint commence par une estimation suivie d'une planification opérationnelle. Le sprint se termine par une démonstration de ce qui a été achevé et contribue à augmenter la valeur d'affaires du produit. Avant de démarrer un nouveau sprint, l'équipe réalise une rétrospective : elle analyse ce qui s'est passé durant ce sprint, afin de s'améliorer pour le prochain. L'adaptation et la réactivité de l'équipe de développement est facilitée par son auto-organisation.

La méthode Scrum ne couvre volontairement aucune technique d'ingénierie du logiciel. Pour l'utiliser afin de développer une application, il est nécessaire de la compléter avec des pratiques de qualité du logiciel. Par exemple, on pourra utiliser des pratiques issues de l'Extreme Programming, de la phase de Construction structurée de la méthode RAD, ou un ensemble de pratiques de qualité du logiciel émergent du vécu de l'équipe projet.

Historique

La métaphore de Scrum (mêlée du rugby) apparaît pour la première fois en 1986 dans une publication de Hirotaka Takeuchi et Ikujiro Nonaka intitulée The New New Product Development Game qui s'appliquait à l'époque au monde industriel. Ils y décrivent une nouvelle approche holistique qui augmenterait la vitesse et la flexibilité dans le développement de nouveaux produits. Dans celle-ci, les étapes de réalisation se chevauchent fortement et l'ensemble du processus est réalisé par une équipe aux compétences croisées à travers différentes phases. Ils ont comparé cette nouvelle approche au rugby à XV, où l'équipe essaye d'avancer unie, en faisant circuler la balle (« tries to go to the distance as a unit, passing the ball back and forth »). Cette référence reste étonnante, car si dans ces 12 pages le mot « rugby » apparaît et le mot « Scrum » est cité une fois, les concepts développés (ingénierie concourante, chevauchement de phases, spécialisation des acteurs) sont interdits dans Scrum.

En 1995, Ken Schwaber présente une courte communication décrivant les fondements de ce qui deviendra la méthode Scrum à l'OOPSLA, à Austin, aux États-Unis.

En 2001, Ken Schwaber fait équipe avec Mike Beedle pour décrire la méthode dans le livre Agile Software Development With Scrum.

En 2004, publication de Agile Software Management With Scrum de Ken Schwaber.

En 2011, Jeff Sutherland et Ken Schwaber décrivent les principes de la méthode dans le Scrum Guide.

Caractéristiques

Scrum est basé sur la conviction que le développement logiciel est une activité par nature non-déterministe et que l'ensemble des activités de réalisation d'un projet complexe ne peut être anticipé et planifié longtemps à l'avance, ce en quoi Scrum s'oppose aux démarches prédictives telles que le cycle en V. Pour répondre à cette imprédictibilité, Scrum propose un modèle de contrôle de processus basé sur l'empirisme (Voir « piliers de Scrum »), via l'adaptation continue aux conditions réelles de l'activité et une réaction rapide aux changements. L'analyse des conditions réelles d'activité et le plan d'amélioration continue qui en découle sont réalisés à intervalle de temps régulier, donnant lieu à un cycle de développement itératif.

La méthode Scrum a été conçue lors de projets de développement de logiciels. Elle peut aussi être utilisée par des équipes de maintenance. Dans le cas de très grands projets, les équipes se multiplient et on parle alors de Scrum de Scrums. La méthode Scrum peut théoriquement s'appliquer à n'importe quel contexte ou à un groupe de personnes qui travaillent ensemble pour atteindre un but commun comme planifier un mariage, gérer des projets de recherche scientifique, des écoles et même des églises comme le précise le site de l'un des co-créateurs Jeff Sutherland.

Un principe fort des méthodes Agiles est la participation active du client. Cela permet de choisir plus finement les fonctionnalités réalisées à chaque incrément ou « boucle ». Le propriétaire du produit peut à tout moment compléter ou modifier la liste des fonctionnalités à produire pour les prochains sprints. Sans modifier le but du sprint en cours, celui-ci peut être affiné et faire l'objet d'une renégociation entre le propriétaire du produit et l'équipe de développement à la suite de nouvelles connaissances. Si le but du sprint devient obsolète, le propriétaire du produit a la capacité d'annuler un sprint en cours.

Chaque sprint constitue donc un incrément, facilitant le pilotage du projet. La notion d'itération couvre l'adaptabilité au quotidien. Cette adaptabilité est limitée par le but immuable d'un sprint.

Les trois piliers de Scrum

Scrum est un processus empirique : il se base sur l'expérience du terrain. Il s'appuie sur trois piliers.

Il suit également les principes des méthodes agiles.

La transparence

Scrum met l'accent sur le fait d'avoir un langage commun entre l'équipe et le management. Ce langage commun doit permettre à tout observateur d'obtenir rapidement une bonne compréhension du projet.

L'inspection

À intervalle régulier, Scrum propose de faire le point sur les différents artéfacts produits, afin de détecter toute variation indésirable.

Ces inspections ne doivent pas être faites trop fréquemment, ou par un inspecteur mal formé : cela nuirait à l'avancement du projet.

L'adaptation

Si une dérive est constatée pendant l'inspection, le processus doit alors être adapté. Scrum fournit des rituels, durant lesquels cette adaptation est possible. Il s'agit de la réunion de planification de sprint, de la mêlée quotidienne, de la revue de sprint ainsi que de la rétrospective de sprint.

Rôles, artefacts et événements

Le framework Scrum consiste en la définition des rôles projets, activités ou artefacts, et réunions ou événements. Ceux-ci sont décrits dans le Guide, rédigé par les créateurs de la méthode.

Rôles

Scrum définit trois rôles : le Propriétaire du produit (Product Owner), le Scrum Master et le Développeur. Il est à noter que le rôle de développeur couvre plusieurs métiers d'une organisation traditionnelle.

Propriétaire du produit

Le Propriétaire du produit (Product Owner) est le représentant des clients et des utilisateurs. Il est « responsable de maximiser la valeur du produit et du travail de l'équipe de développement ». Il s'agit d'« une personne et non d'un comité ». Il est seul à diriger l'activité de l'équipe de développement à qui il n'est « pas permis de suivre les instructions d'une autre personne. »

De ce fait, cet acteur se charge de différents rôles et responsabilités.

• Il explicite les éléments (Items) du Carnet du produit.
• C'est lui qui définit l'ordre dans lequel les fonctionnalités seront développées. Il prend les décisions importantes concernant l'orientation du projet.
• Il s'assure que le carnet du produit est visible et compris de l'équipe de développement.

C'est également lui qui, en accord avec l'équipe, fixe les objectifs d'un incrément (Sprint) au début de celui-ci. Si ces objectifs deviennent obsolètes pendant le sprint, il a alors la possibilité d'interrompre le sprint en cours.

Dans l'idéal, le propriétaire du produit travaille dans la même pièce que l'équipe. Il est important qu'il reste très disponible pour répondre aux questions de l'équipe et pour lui donner son avis sur divers aspects du logiciel.

Scrum Master

Le Scrum Master est responsable de la compréhension, de l'adhésion et de la mise en œuvre de la méthode. C'est un « leader au service de l'équipe », il assiste chaque rôle de l'équipe Scrum dans son activité et promeut le changement des interactions entre les rôles dans le but de maximiser la valeur de ce que produit l'équipe. Son autorité s'exerce sur le processus de développement (définition de la durée des itérations, des modalités de tenues et de l'ordre du jour des réunions Scrum, etc), mais il ne dispose d'aucune autorité sur les autres membres de l'équipe Scrum.

Ce n'est pas un chef de projet, ni un développeur, ni un intermédiaire de communication avec les clients, ni une « nounou » de l'équipe de développement. Le rôle de Scrum Master ne peut pas être cumulé avec celui de propriétaire du produit. Les attributions du « chef de projet » présent dans d'autres approches sont distribuées dans les différents rôles de l'équipe Scrum. L'existence du rôle de chef de projet dans un contexte Scrum est le signe d'une « méconnaissance fondamentale de Scrum » est perçue comme contre-productive et menant à de « piètres résultats ».

En tant que facilitateur, il aide l'équipe à déterminer quelles interactions avec l’extérieur lui sont utiles, et lesquelles sont freinantes. Il aide alors à maximiser la valeur produite par l'équipe.

Parmi ses attributions :

• communiquer la vision et les objectifs à l'équipe ;
• apprendre au propriétaire du produit à rédiger les composantes du carnet de produit ;
• faciliter les rituels de Scrum ;
• coacher l'équipe de développement ;
• faciliter son intégration à l'entreprise, surtout si celle-ci n'est pas pleinement agile ;
• écarter les éléments pouvant perturber l'équipe ;
• aider l'adoption des méthodes agiles au niveau de l'entreprise ;
• travailler avec les autres Facilitateurs/animateurs pour coordonner plusieurs équipes, s'il y a lieu.

Équipe de développement

L'équipe de développement est constituée de 3 à 9 personnes et a pour responsabilité de livrer à chaque fin d'itération une nouvelle version de l'application enrichie de nouvelles fonctionnalités et respectant le niveau de qualité nécessaire pour être livré. L'équipe ne comporte pas de rôles prédéfinis, elle est « structurée et habilitée par l'entreprise à organiser et gérer son propre travail ».

Elle est auto-organisée et choisit la façon d'accomplir son travail, sans que ce soit imposé par une personne externe. Il n'y a pas non plus de notion de hiérarchie interne : toutes les décisions sont prises ensemble. Ce mode d'organisation a pour objectif d'augmenter l'efficacité de travail de l'équipe.

Elle est pluridisciplinaire et comporte toutes les compétences pour réaliser son projet, sans faire appel à des personnes externes à celle-ci.

L'objectif de l'équipe est de livrer le produit par petits incréments. Ainsi, à tout instant, il existe une version du produit « potentiellement utilisable » disponible.

L'équipe s'adresse directement au propriétaire du produit, et ne prend ses instructions que de lui. Son activité est issue du carnet de produit uniquement. Elle ne peut pas être multi-produit.

Événements

Toutes les activités (sprint, réunions de planning, revues, rétrospectives et mêlées) décrites dans le framework Scrum sont effectuées lors de boites de temps.

Le sprint

Le sprint est une période d'un mois au maximum, au bout de laquelle l'équipe délivre un incrément du produit, potentiellement livrable. Une fois la durée choisie, elle reste constante pendant toute la durée du développement. Un nouveau sprint démarre dès la fin du précédent.

Chaque sprint possède un but et on lui associe une liste d'éléments du carnet du produit (fonctionnalités) à réaliser.

Durant un sprint :

• l'objet du sprint ne peut être modifié ;
• la composition de l'équipe reste constante ;
• la qualité n'est pas négociable ;
• la liste d'éléments est sujette à négociations entre le propriétaire du produit et l'équipe de développement.

La limitation est d'un mois afin de limiter la complexité et donc les risques liés au sprint.

Si l'objet du sprint devient obsolète pendant celui-ci, le propriétaire du produit peut décider de l'annuler. Dans ce cas, les développements terminés sont revus par le propriétaire du produit, qui peut décider de les accepter. Les éléments du sprint n'étant pas acceptés sont ré-estimés et remis dans le carnet du produit. Un nouveau sprint démarre alors.

Mêlée quotidienne

La mêlée quotidienne (Daily Scrum) est une réunion de planification « juste à temps » et permet aux développeurs de faire un point de coordination sur les tâches en cours et sur les difficultés rencontrées. Cette réunion dure 15 minutes au maximum. Le Scrum Master s'assure que la réunion ait lieu à heure fixe, mais sa présence est facultative. Le propriétaire du produit n'est pas présent.

À tour de rôle, chaque membre aborde 3 sujets :

• ce qu'il a réalisé la veille,
• ce qu'il compte réaliser aujourd'hui pour atteindre l'objet du sprint,
• les obstacles qui empêchent l'équipe d'atteindre le but du sprint.

Si le besoin s'en fait sentir, des discussions sont alors menées librement après la clôture de la mêlée pour traiter des sujets levés en séance.

Cette réunion permet la synchronisation de l'équipe, l'évaluation de l'avancement vers l'objectif de l'itération, la collecte d'information nécessaire à l'auto-organisation. C'est le niveau quotidien des principes inspection et adaptation de Scrum.

Réunion de planification d'itération

Toute l'équipe Scrum est présente à cette réunion, qui ne doit pas durer plus de 8 heures pour un sprint d'un mois. Pour un sprint plus court, la durée est réduite proportionnellement. À l'issue de cette réunion, l'équipe a décidé des éléments du carnet du produit qu'elle traitera dans le cadre de la prochaine itération, et comment elle s'organisera pour y parvenir.

La réunion de planification d'itération (Sprint Planning Meeting) se passe en deux temps. Dans la première partie, l'équipe de développement cherche à prévoir ce qui sera développé durant le prochain sprint. À l'entrée de cette phase, l'équipe doit avoir à sa disposition :

• le carnet du produit priorisé,
• l'incrément réalisé à la dernière itération,
• ainsi que la capacité de production prévue pour la prochaine itération, dont l'estimation est la prérogative de l'équipe de développement uniquement.

L'équipe et le propriétaire du produit cherchent alors à déterminer le but du sprint.

Dans un second temps, l'équipe, aidée du propriétaire du produit, se focalise sur la manière dont ses membres atteindront le but du sprint, en découpant en activités d'une durée d'une journée au plus le travail à effectuer pendant les premiers jours du sprint.

Revue de sprint

À la fin du sprint, l'équipe Scrum et les parties-prenantes invitées se réunissent pour effectuer la revue de sprint, qui dure au maximum 4 heures. L'objectif de la revue de sprint est de valider l'incrément de produit qui a été réalisé pendant le sprint. L'équipe énonce les éléments du carnet de produit sélectionnés en début de sprint. L'équipe présente les éléments finis (complètement réalisés). Les éléments non finis (partiellement réalisés) ne sont pas présentés.

Une fois le bilan du sprint réalisé, l'équipe de développement et le propriétaire du produit mettent à jour le carnet du produit en fonction de ce qui a été réalisé (fini). Ils discutent avec les parties-prenantes de l'état courant du projet (budget, financement, conditions du marché), pour ajuster les éléments de carnet de produit et la planification selon les opportunités découvertes.

Rétrospective du sprint

La rétrospective du sprint est faite en interne à l'équipe Scrum (équipe de réalisation, propriétaire du produit et Scrum Master). Elle dure 3 heures pour un sprint d'un mois, et réduit selon la durée du sprint. Elle a pour but l'adaptation aux changements qui surviennent au cours du projet et l'amélioration continue du processus de réalisation.

L'objectif est d’inspecter l'itération précédente, afin de déterminer quels sont les éléments du processus de développement qui ont bien fonctionné et ceux qui sont à améliorer. L'équipe de développement déduit un plan d'actions d'amélioration qu'elle mettra en place lors de l'itération suivante.

Artéfacts

Carnet du produit (Product Backlog)

Le carnet de produit est « une liste ordonnée de tout ce qui pourrait être requis dans le produit et est l'unique source des besoins pour tous les changements à effectuer sur le produit ». C'est un document qui évolue constamment au cours de la vie du produit et n'est « jamais fini ».

Chaque élément du carnet représente une fonctionnalité, besoin, amélioration et correctif, auquel sont associés une description, une estimation de l'effort nécessaire à la réalisation de l'élément et une grandeur permettant d'ordonner les éléments entre eux. Le carnet de produit, son évolution et sa publication sont de la responsabilité du propriétaire du produit. Il peut changer à discrétion l'ordre des éléments, en ajouter, modifier le découpage en éléments, modifier leur description, ou supprimer des éléments qui n'ont pas encore été réalisés par l'équipe de développement. Les éléments en tête du carnet de produit sont destinés à être traités dans la prochaine itération et sont les plus finement décrits et estimés. Ils sont dits « prêts » dans la terminologie Scrum. Les éléments moins prioritaires peuvent être découpés plus grossièrement en attendant de devenir prioritaires et affinés à leur tour.

L'activité d'affinage du carnet de produit et de ses éléments est effectuée conjointement par le propriétaire du produit et par l'équipe de réalisation. C'est notamment elle seule qui a le mot final sur les estimations des éléments du carnet du produit.

Carnet de sprint (Sprint Backlog)

En début de sprint, un but est décidé. Pour atteindre cet objectif, l'équipe de développement choisit lors de la réunion de planification de sprint quels éléments du carnet de produit seront réalisés. Ces éléments sont alors groupés dans un carnet de sprint.

Chaque équipe met à jour régulièrement le carnet de sprint au cours de son activité, afin que celui-ci donne une vision la plus précise possible de ce que l'équipe prévoit de réaliser pour atteindre l'objectif du sprint. Le carnet de sprint est sous la responsabilité de l'équipe et elle est seule à pouvoir le modifier en cours d'itération.

Incrément de produit

L'incrément de produit est l'ensemble des éléments du carnet de produit finis pendant ce sprint, et aussi ceux finis pendant les sprint précédents. Les éléments sont finis lorsqu'ils remplissent la définition de fini. Cet incrément doit être utilisable, qu'il soit publié ou non.

Pratiques complémentaires

Scrum ne couvre volontairement pas tous les aspects de la gestion de projet, mais propose uniquement un ensemble minimal de règles favorisant le travail collectif. Il appartient à chaque organisation ou chaque équipe Scrum de définir les compléments à utiliser.

Référentiel de pratiques

Le site ScrumPLoP a pour objet de référencer les pratiques complémentaires aux règles de base décrites dans le Scrum Guide utilisées par la communauté des utilisateurs de Scrum. En 2014, le référentiel publie plus de 200 pratiques.

Les pratiques indiquées ci-dessous ne sont pas issues de ce référentiel.

Estimation et planification

Éléments de carnet de produit

Les éléments de carnet de produit sont souvent des récits utilisateur (User Stories) empruntées à Extreme Programming. Ces récits sont estimés en points relatifs, sans unité. L'équipe prend un élément représentatif et lui affecte un nombre de points arbitraire. Cela devient un référentiel pour estimer les autres items. Par exemple, un élément qui vaut 2 points représente une complexité double par rapport à un élément qui en vaut 1 (le point n'est pas une mesure de charge car il deviendrait arbitraire). Pour les valeurs, on utilise souvent les premières valeurs de la suite de Fibonacci (1,2,3,5,8,13), qui évitent les difficultés entre valeurs proches (8 et 9 par exemple).

L'intérêt de cette démarche est d'avoir une idée du travail requis pour réaliser chaque fonctionnalité sans pour autant lui donner une valeur en jours que le propriétaire du produit serait tenté de considérer comme définitivement acquise. En revanche, on utilise la vélocité pour planifier le projet à l'échelle macroscopique de façon fiable et précise.

Calcul de vélocité

Une fois que tous les éléments de carnet de produit ont été estimés, on attribue un certain nombre d'éléments à réaliser aux sprints successifs. Ainsi, une fois un sprint terminé, on sait combien de points ont été réalisés et on définit alors la vélocité de l'équipe, c'est-à-dire le nombre de points qu'elle peut réaliser en un sprint.

En partant de cette vélocité et du total de points à réaliser, on peut déterminer le nombre de sprints qui seront nécessaires pour terminer le projet (ou la release en cours). L'intérêt est d'avoir une vision de plus en plus fiable (retours d'expérience de sprint en sprint) de la date d'aboutissement du projet, tout en permettant d'aménager les éléments de carnet du produit en cours de route.

Éléments de carnet de sprint

Les éléments de carnet de sprint sont généralement exprimés en heures et ne doivent pas dépasser 2 journées de travail, sinon il convient de les décomposer en plusieurs éléments. Par abus de langage, on emploie le terme de tâches, les concepts étant très proches.

Lancement du projet

Scrum présuppose que le carnet de produit est déjà défini au début du projet. Une approche possible pour constituer ce carnet est de réaliser une phase de lancement. Cette phase de lancement s'articule autour de deux axes de réflexion : l'étude d'opportunité et l'expression initiale des besoins.

L'étude d'opportunité est très variable d'un projet à l'autre, tout dépend du contexte de l'entreprise, de la nature du projet (sous-traitance ou interne), etc. Chaque entreprise a sa propre politique sur cette activité.

L'expression initiale des besoins n'est pas un élément défini dans Scrum, et n'est pas une activité de contractualisation d'un cahier des charges. L'esprit d'une telle activité dans les méthodes Agiles est de définir d'une part le cadre du projet (pour que l'équipe s'imprègne du contexte métier) et d'autre part une première analyse globale des besoins. L'objectif est d'identifier un maximum de fonctionnalités que le logiciel devra implémenter, en se limitant à un niveau de précision assez grossier. On peut par exemple utiliser une approche par raffinages successifs, en partant des secteurs métier concernés par l'application, puis en identifiant les activités métier, qu'on décompose en tâches métier qui correspondent à des fonctionnalités que l'on doit/peut ou non implémenter dans le logiciel final.

L'objectif pour Scrum est de produire la première version du carnet de produit.

Vue globale

Vue synthétique du processus Scrum

Vue synthétique du processus Scrum

Qualité de l'environnement de travail

Un concept fort de Scrum est la qualité de l'environnement de travail de l'équipe. Cela inclut :

• pas de changements imposés pendant un sprint ;
• toute l'équipe dans une même pièce ;
• un tableau blanc et/ou en liège ;
• un bon outil de suivi du projet ;
• prévenir des interventions extérieures (téléphone, irruption dans la pièce, etc.) ;
• tout ce qui peut rendre l'équipe plus sereine et efficace.

Définition de prêt

La définition de « prêt » définit les conditions nécessaires pour considérer qu'un élément du carnet de produit est considéré comme suffisamment décrit pour entrer dans un Sprint. Elle a pour but la compréhension commune de ce qu'est un élément spécifié.
De la spécification d'un élément pourra découler sa propre définition de « terminé », c'est-à-dire les critères à remplir pour que le propriétaire de produit les accepte.

Elle est le pendant de la « définition de terminé » pour la sortie d'un élément du carnet de produit.

Risques de la méthodologie

On peut en citer trois risques, mais il en existe bien d'autres :

• Flaccid Scrum ;
• un Scrum Master directif ;
• la communication constructive laisse la place aux reproches.

« Flaccid Scrum »

Le terme « Flaccid Scrum » est utilisé par Martin Fowler en 2009 pour identifier une pratique erronée de Scrum dans laquelle la qualité logicielle est négligée et le produit développé accumule de la dette technique. Fowler indique que même si Scrum ne décrit pas quelles pratiques techniques mettre en place, la méthode n'encourage pas l'absence de telles pratiques et que les « Scrummers » de premier plan ont toujours insisté sur l'utilisation de pratiques techniques efficaces. La négligence de l'aspect technique de l'activité de développement et l'augmentation de la dette technique qui en résulte sont des signes d'une mauvaise utilisation de Scrum.

Fowler mentionne que les pratiques techniques de l'extreme programming constituent un bon point de départ pour les équipes Scrum et valent mieux que l'absence de pratiques.

En 2014 Fowler considère que le problème persiste et encourage les utilisateurs de Scrum et des méthodes agiles en général de prendre garde à l'utilisation de pratiques techniques efficaces.

Un Scrum Master directif

Il n'est pas rare que le Scrum Master soit un chef de projet déguisé ou officiel, et qu'il applique un contrôle trop strict sur les membres de son équipe.

Même si l'on demande aux membres de l'équipe de s'impliquer et d'être coresponsables du projet, en réalité ils ne le sont pas. Le Scrum Master, qui est dans ce cas-là le chef de projet, a le dernier mot pour tout et peut effectuer des choix arbitraires, ce qui peut frustrer les membres de l'équipe. En outre, il n'endosse plus les responsabilités du Scrum Master : être le protecteur de l'équipe, objectif, garde-fou, garant de la méthodologie appliquée, etc.

Les bénéfices de l'agilité disparaissent, et l'on voit apparaître une défiance de la part de l'équipe vis-à-vis du Scrum Master, des conflits à l'intérieur même de l'équipe, des non-dits, du désengagement, l'oubli des bonnes pratiques. L'une des conséquences est une baisse de la qualité, élément pourtant non négociable dans un projet agile : « Un logiciel qui fonctionne ».

La communication constructive laisse la place aux reproches

La surexposition dans Scrum prend sa source dans les différentes réunions d'équipe telles que la quotidienne matinale, censée informer et apporter des solutions aux problèmes de la veille.
Sur certains projets, ces réunions se transforment en blâme des membres n'ayant pas réussi à mener à bien leurs tâches de la veille.
Les conséquences dans ce cas peuvent prendre la forme de discussions houleuses ou de conflits plus ou moins durables entre membres de l'équipe. On constate aussi parfois à l'inverse une manière différente d'appréhender la réunion quotidienne : non-dit ou propos vagues en ce qui concerne les problèmes rencontrés. Ainsi, les réunions peuvent se passer de façon plus courtoise mais un risque de ne plus chercher le support de l'équipe en cas de difficulté pourrait apparaître. Ce qui va à l'encontre même des principes de Scrum.

À l'inverse, sur les projets cycle en V, on dispose d'un effet de lissage, qui permet de compenser un jour ce qu'on a moins bien fait la veille.
En outre, les difficultés rencontrées un jour par un membre de l'équipe ne sont pas mises en avant aux yeux de tous. Le membre en question peut trouver une solution seul le lendemain ou demander de l'aide auprès de collègues. En clair, il a le choix de choisir sa solution et de ne pas être potentiellement rabaissé par les autres membres de l'équipe.

Documentation de projet

Hormis les carnets de produit et d'itération, Scrum n'impose aucune documentation particulière. Scrum fait partie des méthodes agiles et le principe indiquant que « Les logiciels opérationnels » sont à privilégier par rapport à « une documentation exhaustive » est applicable.

L'application des principes de Scrum suggère qu'une documentation, comme tout élément du processus de développement, ne doit émerger uniquement parce que l'équipe pense qu'elle augmente la valeur du produit ou l'efficacité de l'activité de l'équipe Scrum. La pertinence de l'effort de maintenance de la documentation doit être périodiquement réévaluée par l'équipe lors des rétrospectives d'itération.

En tous cas, Scrum ne décourage pas l'utilisation d'une documentation que l'équipe juge pertinente.

Voici quelques exemples de documents utiles et dans quels cas :

• diagramme métier (processus, objets, etc.), associé au carnet de produit : uniquement si la logique métier du client qui concerne l'application est vraiment complexe. Dans ce cas, l'équipe devrait produire ce document avec lui ;
• diagramme de séquence, associé à un item du carnet du produit : uniquement si la fonctionnalité aura une utilisation complexe, tant au niveau métier qu'applicatif ;
• diagramme d'architecture du logiciel (classes, modules, composants, etc.), pour le projet : indispensable pour avoir toujours sous les yeux une vue de l'architecture et s'assurer ainsi qu'elle est de qualité ;
• les manuels utilisateur, à chaque sprint : les manuels sont produits à chaque sprint et pas en fin de projet. Utiliser des vidéos de démonstration commentées est une solution efficace ;
• une base de connaissance pour le support client.

Outils

Hormis pour le maintien des carnets de produit et d'itération, il n'y a pas d'éléments de processus décrit dans la documentation de référence qui requière l'utilisation d'un outil particulier. Dans « Agile Project Management with Scrum », Ken Schwaber donne l'exemple de carnets de produit et d'itération maintenus dans un tableur, qui permet aussi le calcul des burndown charts. Il est à noter que les burndown charts ne sont cités dans le Scrum Guide qu'à titre d'exemple et ne sont pas une pratique requise.

Glossaire

Propriétaire du produit (Product Owner)

Personne ayant la responsabilité de produire et de maintenir à jour le carnet de produit. C'est lui qui détermine les priorités et qui prend les décisions d'orientation du projet.

Chef de mêlée (Scrum Master)

Membre de l'équipe dont l'objectif principal est de la protéger des perturbations extérieures. Il est complètement transparent pour la communication entre l'équipe et les clients et n'a aucun pouvoir hiérarchique sur l'équipe. C'est en revanche un facilitateur pour les problèmes non techniques de l'équipe.

Carnet de produit (Product Backlog)

Liste des fonctionnalités qui devront être mises en œuvre par le logiciel.

Définition de fini (Definition of Done ou DoD)

L'ensemble des conditions nécessaires pour considérer qu'un élément de carnet de produit est livrable. Sa définition varie selon les équipes, mais elle doit être la même pour tous les membres d'une équipe Scrum.

Carnet de sprint (Sprint Backlog)

Liste des tâches à accomplir pendant un sprint. Elles correspondent à la réalisation des éléments de carnet de produit affectés au sprint.

Mêlée quotidienne (Daily Scrum)

Réunion quotidienne de 15 minutes qui a pour but de faire le point sur ce qui a été fait depuis la dernière mêlée, ce qu'il est prévu de faire jusqu'à la prochaine et quels sont les obstacles rencontrés durant le travail.

Sprint

Nom d'une itération dans Scrum. Cette itération dure 30 jours calendaires en théorie, mais en pratique entre 2 et 4 semaines. Pendant une itération, l'équipe doit développer la liste d'éléments du carnet de produit qui a été définie au début du sprint.

Graphique d'avancement (Burndown Chart)

Graphique qui représente l'évolution du reste à faire total de jour en jour (pour les sprints) ou de sprint en sprint (pour les releases).

Voir aussi

Articles connexes

• Méthode agile
• Kanban, autre méthode moins restrictive
• Cycle de développement
• Extreme programming

Liens externes

• (en) Site officiel

Bibliographie

• (en) Agile Software Development with Scrum, Ken Schwaber, Mike Beedle (Prentice Hall, 21 octobre 2001) (ISBN 978-0130676344)
• (en) Agile Software Management with Scrum, Ken Schwaber (Microsoft Press, 10 mars 2004) (ISBN 978-0735619937)
• (en) The Power of Scrum, Jeff Sutherland, Rini van Solingen, Eelco Rustenberg (Kindle Edition, 10 novembre 2011) (ASIN 978-0735619937)
• (fr) SCRUM : Le guide pratique de la méthode agile la plus populaire, Claude Aubry (Dunod, 10 février 2010) (ISBN 978-2100540181)