2 Le cadre de Scrum Ce chapitre vous propose un aperçu du modèle Scrum en présentant d'abord les rôles, les activités et les artéfacts. Les chapitres suivants entreront dans les détails de chaque pratique, sans omettre de discuter en détail les principes sous-jacents. Vision générale Scrum ne constitue pas un processus standardisé qui vous demanderait de suivre passivement une série d'étapes successives en vous promettant d'aboutir à un produit de haute qualité censé ravir vos clients sans dépassement ni de budget, ni de délais. Scrum est un modèle pour vous aider à organiser des travaux et à en gérer le déroulement. Le modèle Scrum se fonde sur un jeu de valeurs, de principes et de pratiques qui deviennent une infrastructure sur laquelle votre organisation va pouvoir asseoir ses propres choix de pratiques d'ingénierie et sa manière personnelle de mettre en mouvement les pratiques Scrum. Le résultat sera un modèle Scrum qui vous sera propre. Pour vous faire une idée plus précise du concept, vous pouvez comparer le modèle Scrum au plancher et aux murs porteurs d'un bâtiment. Les valeurs, principes et pratiques Scrum sont les composants structurels que vous ne pouvez pas ignorer, ni modifier en profondeur sans risquer d'effondrer tout l'édifice. En revanche, vous avez toute liberté pour personnaliser les aménagements dans la structure Scrum, en déplaçant des cloisons et en ajoutant des équipements jusqu'à obtenir un processus qui vous convienne. Scrum est une approche étonnamment simple et orientée vers l'humain qui prône des valeurs telles que l'honnêteté, l'ouverture aux autres, le courage, le respect, la concentration, la confiance, la responsabilisation et la coopération. Le Chapitre 3 présente en détail les grands principes Scrum en liaison avec l'approche Agile ; les chapitres suivants montreront comment les pratiques s'articulent avec ces principes et valeurs. La pratique de Scrum se fonde sur des rôles, des activités, des artéfacts et les règles associées (voir Figure 2.1). La suite de ce chapitre présente les principaux points pratiques de Scrum.
16 Scrum - Management de projet Agile Product Owner Rôles Scrum Master Équipe de développement Sprint Planification de sprint Scrum quotidien Activités Exécution de sprint Pratiques Scrum Revue de sprint Rétrospective de sprint Grooming du Backlog de produit Backlog de produit Artéfacts Backlog de sprint Figure 2.1 Pratiques Scrum. aa Règles Décrites tout au long du livre Incrément de produit potentiellement livrable aa Les rôles Scrum Les efforts de développement en approche Scrum sont déployés par une ou plusieurs équipes Scrum. Chaque équipe comporte trois rôles Scrum : le Product Owner (propriétaire du produit), le ScrumMaster et l'équipe de développement (voir Figure 2.2). D'autres rôles peuvent s'y ajouter, mais le modèle Scrum ne rend que ces trois rôles incontournables.
Chapitre 2 Le cadre de Scrum 17 Product Owner Équipe scrum Scrum Master Figure 2.2 Les rôles Scrum. Équipe de développement Le Product Owner est responsable de ce qui doit être développé et dans quel ordre cela doit l'être. Le ScrumMaster se charge de guider l'équipe dans ses efforts de création en l'aidant à mettre en pratique son processus spécifique et à rester fidèle aux principes Scrum. Enfin, l'équipe de développement est responsable de la production et des modalités de livraison de ce qui a été demandé par le Product Owner. Si vous êtes manager, ne soyez pas étonné de ne pas voir ce rôle apparaître dans la Figure 2.2 ; les managers conservent néanmoins une fonction importante dans les processus basés Scrum (voyez à ce sujet le Chapitre 13). Le modèle Scrum se limite à définir les rôles qui lui sont spécifiques, et non tous les rôles qui peuvent et doivent être présents dans une organisation adoptant l'approche Scrum. Product Owner Le Product Owner est le point central du pilotage du produit. Il représente l'unique autorité pouvant décider quelles fonctions il faut réaliser et dans quel ordre. Le Product Owner est le garant de la vision globale de ce que l'équipe Scrum doit réaliser ; il se charge de communiquer cette vision à tous les autres participants. En conséquence, c'est le Product Owner qui est responsable du succès global de la solution à créer ou à maintenir. Note Dans ce livre, nous maintenons la parité hommes/femmes en représentant dans les figures un homme pour le rôle de Product Owner et une femme pour celui de ScrumMaster. Que l'objectif soit un produit destiné à un client ou une application interne, le Product Owner doit s'assurer que le travail produit offre le maximum de valeur ajoutée (et ce travail peut comprendre un aspect uniquement technique). Pour garantir que l'équipe produise rapidement ce qu'il attend, le Product Owner coopère activement avec le ScrumMaster et l'équipe de développement : il se tient disponible pour répondre au plus vite à toutes les questions. Le Chapitre 9 donne une description détaillée du rôle de Product Owner.
18 Scrum - Management de projet Agile ScrumMaster Le ScrumMaster est le gardien de l'esprit Scrum : il aide tous les membres à comprendre et adopter les valeurs Scrum, ses principes et ses usages. Il agit comme un entraîneur sportif ou un coach, en guidant le processus et en aidant l'équipe Scrum et d'autres membres de l'organisation à mettre en pratique de façon efficace l'approche Scrum spécifique à l'entreprise. Le ScrumMaster doit par ailleurs soutenir l'organisation dans l'important processus de changement dans le management que l'adoption de Scrum peut déclencher. En tant que facilitateur, le ScrumMaster aide l'équipe à résoudre les problèmes et à améliorer son utilisation de Scrum. Il doit aussi protéger l'équipe des interférences extérieures et devenir un meneur dans la suppression des obstacles qui menacent la productivité de l'équipe (lorsque les individus de l'équipe n'y parviennent plus de façon autonome). En revanche, le ScrumMaster ne détient aucune autorité sur l'équipe, ce en quoi ce rôle ne se confond pas avec le rôle classique de Project Manager ou Development Manager. Le ScrumMaster est un animateur, un facilitateur, pas un manager. Je rappelle les rôles de Manager fonctionnel et de Project Manager dans le Chapitre 13. Le Chapitre 10 détaille le rôle de ScrumMaster. Équipe de développement L'approche classique de développement logiciel réunit plusieurs profils : architecte, programmeur, testeur, administrateur de bases, concepteur d'interface IHM/GUI, etc. Scrum ne définit qu'un rôle collectif d'équipe de développement, qui constitue un regroupement polyvalent de ces différents types de compétences (conception, réalisation et test) indispensables pour aboutir au produit désiré. L'équipe de développement s'organise elle-même pour décider de la meilleure manière d'atteindre l'objectif défini par le Product Owner. Cette équipe réunit de cinq à neuf personnes ; elle doit disposer de toutes les compétences requises pour produire un logiciel fonctionnel et de qualité. Rien n'empêche d'appliquer Scrum à une équipe de plus grande taille, mais il est conseillé de constituer trois ou quatre équipes de moins de dix personnes plutôt qu'une seule grande équipe de, par exemple, 35. Le Chapitre 11 entre dans les détails du rôle de l'équipe de développement et le Chapitre 12 présente les techniques pour coordonner plusieurs équipes. Activités et artéfacts Scrum La Figure 2.3 donne une vue d'ensemble des activités et artéfacts principaux de Scrum avec leurs interactions.
Chapitre 2 Le cadre de Scrum 19 Backlog de produit Planification de sprint Backlog de sprint Scrum quotidien Exécution de sprint Grooming Incrément de produit potentiellement livrable Rétrospective de sprint Revue de sprint Figure 2.3 Vue globale du cadre Scrum. Passons ce schéma en revue en commençant par la gauche et en progressant dans le sens horaire. Le Product Owner détient la vision de ce qu'il veut voir produire (symbolisé par le gros cube). Ce projet pouvant être vaste, il est décomposé en plusieurs blocs fonctionnels par une activité appelée Grooming et ces blocs sont placés par priorités décroissantes dans la liste appelée Backlog de produit. La production d'un bloc fonctionnel correspond à une itération appelée sprint qui débute par la planification de sprint, englobe toute la séquence de développement (l'exécution de sprint) et se termine par les deux étapes de revue de sprint et de rétrospective de sprint. Dans le schéma, le sprint correspond à la grande boucle horizontale. Puisque le nombre d'éléments dans le Backlog de produit est en général bien supérieur à ce qu'il est possible de produire dans un cycle de sprint, l'équipe de développement doit sélectionner dans le Backlog de produit au début de chaque sprint un sous-ensemble d'objectifs. Cela correspond à l'activité de planification de sprint. Elle est montrée du côté gauche, juste à droite du cube du Backlog de produit. Je profite de l'occasion pour un bref aparté. En 2011, le livre de référence The Scrum Guide de Schwaber et Sutherland avait déclenché un débat passionné autour du terme approprié pour décrire le résultat de la planification de sprint : était-ce une estimation (forecast) ou bien un engagement (commitment)? Les partisans du terme "estimation" pensaient que même si l'équipe de développement faisait de son mieux pour estimer l'effort au départ, le fait de recueillir des informations pendant le déroulement des travaux rendait immanquablement cette estimation obsolète. Les mêmes redoutaient aussi qu'un engagement pousse l'équipe à rogner sur la qualité pour être certaine de tenir son engagement ou se montrer conservatrice en s'engageant moins loin vers le même but.
20 Scrum - Management de projet Agile Je pense que toutes les équipes de développement doivent établir des estimations de ce qu'elles pourront livrer pendant chaque sprint. Ceci dit, de nombreuses équipes tireraient profit de la transformation de cette estimation en un engagement. Les engagements matérialisent la relation de confiance entre le Product Owner et l'équipe de développement et au sein de cette équipe. Ils favorisent une planification et une prise de décision dans des délais raisonnables. Lors d'un projet avec plusieurs équipes de développement, les engagements aident à synchroniser la planification : une équipe peut prendre certaines décisions en s'appuyant sur ce à quoi une autre équipe s'est engagée. Au cours de ce livre, je privilégie le terme "engagement", mais j'utilise parfois le terme "estimation" quand il me semble plus pertinent dans son contexte. Pour renforcer sa confiance dans l'engagement pris collectivement par l'équipe de développement, ses membres construisent un second backlog lors de la phase de planification de sprint : c'est le Backlog de sprint qui décrit de façon détaillée les tâches lui permettant de concevoir, réaliser, intégrer et tester le sous-ensemble fonctionnel sélectionné dans le Backlog de produit pour le sprint considéré. Vient ensuite l'exécution de sprint proprement dite. L'équipe de développement réalise les tâches pour créer les fonctions prévues. Pendant l'exécution de sprint, une réunion quotidienne appelée scrum (mêlée) permet aux membres de l'équipe de garder le contrôle du flux de tâches. Ce scrum quotidien sert à synchroniser, inspecter et faire une planification adaptative. En fin d'exécution de sprint, l'équipe doit avoir abouti à un incrément fonctionnel livrable du produit qui incorpore une portion de la vision définie par le Product Owner. L'équipe Scrum clôture le sprint par deux activités successives d'inspection et adaptation. La première est la revue de sprint. Elle réunit les actionnaires/parties prenantes et l'équipe Scrum pour inspecter le produit résultant du sprint. La seconde réunion est la rétrospective de sprint. Elle s'intéresse au processus adopté pour réaliser le produit. Les conclusions de ces activités peuvent dégager des besoins d'adaptation qui pourront se propager jusqu'au Backlog de produit ou être incorporées dans le processus de développement standard de l'équipe. Après ces deux réunions, nous avons atteint la fin du cycle de sprint Scrum et pouvons en démarrer un autre. L'équipe de développement sélectionne les prochains éléments prioritaires du Backlog de produit pouvant être réalisés. Au bout d'un certain nombre de sprints, la vision définie par le Product Owner est concrétisée et la solution complète peut être diffusée. La suite de ce chapitre décrit en détail ces activités et artéfacts. Backlog de produit (carnet de production) Dans Scrum, vous réalisez toujours en premier les travaux offrant le plus de valeur. Le Product Owner recueille les avis du reste de l'équipe Scrum et des parties prenantes, mais il reste responsable de l'ordonnancement et de la gestion de la séquence du travail et de sa communication sous la forme d'une liste ordonnée qui correspond au Backlog de produit (voir Figure 2.4). Pour les développements de nouveaux produits, les éléments
Chapitre 2 Le cadre de Scrum 21 du Backlog de produit sont les fonctions requises pour concrétiser la vision produit du Product Owner. Pour les produits à faire évoluer, le Backlog de produit réunit des nouvelles fonctions, des changements de fonctions existantes, des correctifs, des améliorations techniques, etc. Fonction A Fonction B Fonction C Défaut 23 Refactor X Eléments très prioritaires Fonction D Fonction E Fonction F Eléments peu prioritaires Figure 2.4 Backlog de produit. Le Product Owner collabore avec les parties prenantes internes et externes pour collecter et définir les éléments du Backlog de produit, puis il classe ces éléments en ordre décroissant de valeur (avec comme critères la valeur résultante, le coût de production, la connaissance apportée et le risque). Le Backlog de produit est un document (artéfact) en évolution constante : des éléments sont ajoutés, supprimés, déplacés et révisés par le Product Owner en réaction aux changements du contexte économique ou suite aux nouvelles informations dont dispose l'équipe Scrum au sujet du produit visé (suite aux comptes-rendus de produit obtenus lors de chaque sprint). Les activités de création, d'estimation, de classement et de peaufinage des éléments du Backlog de produit sont regroupées sous le terme collectif de Grooming (voir Figure 2.5).