Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

GUIDE DE DÉMARRAGE SCRUM Faire le bon produit au bon moment et au meilleur coût

GUIDE DE DÉMARRAGE SCRUM Faire le bon produit au bon moment et au meilleur coût FLORENT LOTHON Formateur & Coach Agile https://agiliste.fr Cet ebook est sous licence Creative Commons - Usage non commercial. En clair, cela signifie que vous êtes libre d'utiliser et diffuser son contenu aux seules conditions suivantes : ● Citer l’auteur avec un lien vers son site. ● Ne pas modifier le contenu sans autorisation préalable de sa part. ● Ne pas commercialiser le contenu. GUIDE DE DÉMARRAGE SCRUM Page 2/19 SOMMAIRE Introduction Au sujet de Scrum Utilisation de Scrum Pré requis recommandés Les Rôles en bref Vision du produit et product backlog Estimations des exigences Démarrage Réunion de planification de sprint Phase 1 : Le « Quoi » Phase 2 : Le « Comment » Sprint (2 à 4 semaines) Mêlée quotidienne ou « stand-up meeting » Graphique d’avancement (Burndown Chart) Revue de Sprint Rétrospective de sprint Projet Scrum et MOA Le rôle du consultant métier Rôle du Product Owner Renfort du Product Owner Les pièges à éviter Scrum est simple mais difficile Gestion du changement Plusieurs équipes de développement Scrum Annexes Caractéristiques d’une User Story Quid des spécifications ? Envie d’aller plus loin ? A propos de l’auteur GUIDE DE DÉMARRAGE SCRUM Page 3/19 Introduction La méthode Scrum (« Scrum » signifie « Mêlée » en anglais), ou plus exactement le cadre méthodologique Scrum est de loin la méthode Agile la plus utilisée dans le monde. Expérimentée en 1993, elle bénéficie aujourd’hui de nombreux retours d’expérience. Les conférences, communautés, formations, blogs, outils et ouvrages à son sujet ne manquent pas. L’objectif de cet article est de vous aider à vous lancer dans la mise en oeuvre de Scrum. Il décrit le processus associé, ses étapes, réunions, rôles, etc. Dès que les limites de cet article seront atteintes, la lecture du Guide Scrum (20 pages, gratuit, complet et traduit en français) puis du livre « Scrum et XP depuis les tranchées » (160 pages, également gratuit, complet et traduit en français) est recommandée. Pour une meilleure compréhension de cet article, il est préférable d’avoir assimilé les principes Agile. Au besoin, je vous invite à lire la fiche pratique « Introduction aux méthodes Agile ». Au sujet de Scrum Parler d’une « méthode » concernant Scrum n’est pas ce qu’il y a de plus approprié. Scrum ne se considère pas comme une méthode mais comme un cadre méthodologique. Une méthode dit généralement « comment » faire les choses. Scrum ne dit pas comment réussir son logiciel, comment surmonter les obstacles, comment développer, comment spécifier, etc. Il se contente d’offrir un cadre de gestion de projet Agile (et c’est déjà beaucoup) : des rôles, un rythme itératif, des réunions précises et limitées dans le temps, des artefacts (product backlog, sprint backlog, graphique d’avancement) et des règles du jeu. Au sein de ce cadre méthodologique de gestion de projet, les acteurs ajustent empiriquement, au fil des itérations, leur propre méthode en fonction de leur contexte. On peut qualifier Scrum de simple, pragmatique, transparent et empirique. Scrum ne couvrant que les aspects de gestion de projet, c’est souvent la méthode eXtreme Programming (XP) qui vient compléter le vide laissé en matière de pratiques de développement. XP apporte ainsi les pratiques de programmation en binôme, de développement piloté par les tests (TDD ou Test Driven Development), intégration continue, etc. Ces dernières jouent un rôle capital pour relever le défi du développement incrémental. Le mouvement Software Craftsmanship est également là pour répondre à ces enjeux techniques. NB : Sachez que eXtreme Programming couvre également efficacement les aspects de gestion de projet, faisant d’elle l’une des méthodes Agile les plus complète qui existe. GUIDE DE DÉMARRAGE SCRUM Page 4/19 Utilisation de Scrum Processus Scrum (source des icônes des personnages : Mike Cohn) Pré requis recommandés ● Un grand mur libre et dégagé dans l’espace de travail de l’équipe. ● Blocs de post-it et marqueurs. ● L’ouvrage « Scrum et XP depuis les tranchées ». ● Jeu de cartes ou logiciel de Planning Poker. Les Rôles en bref Scrum définit seulement 3 rôles : ● Le Product Owner qui porte la vision du produit à réaliser et travaille en interaction avec l’équipe de développement. Il s’agit généralement d’un expert du domaine métier du projet. ● L'Équipe de Développement qui est chargée de transformer les besoins exprimés par le Product Owner en fonctionnalités utilisables. Elle est pluridisciplinaire et peut donc encapsuler d’autres rôles tels que développeur, architecte logiciel, DBA, analyste fonctionnel, graphiste/ergonome, ingénieur système. GUIDE DE DÉMARRAGE SCRUM Page 5/19 ● Le Scrum Master qui doit maîtriser Scrum et s’assurer que ce dernier est correctement appliqué. Il a donc un rôle de coach à la fois auprès du Product Owner et auprès de l’équipe de développement. Il doit donc faire preuve de pédagogie. Il est également chargé de s’assurer que l’équipe de développement est pleinement productive. Généralement le candidat tout trouvé au rôle de Scrum Master est le chef de projet. Celui ci devra cependant renoncer au style de management « commander et contrôler » pour adopter un mode de management participatif. Vision du produit et product backlog La première étape consiste à formaliser la vision du produit (logiciel) que l’on souhaite réaliser. Cette vision décrit les principaux objectifs, jalons, utilisateurs visés. Elle contribuera à guider et fédérer les acteurs du projet. La suite consiste à établir la liste des exigences fonctionnelles et non fonctionnelles du produit. Chaque exigence est ensuite estimée par l’équipe de développement avec la technique de Planning Poker. A la lueur des estimations, la liste ainsi complétée est ordonnancée. Les exigences seront converties en fonctionnalités utilisables selon cet ordonnancement. Le principe étant de convertir en premier les exigences qui apportent le plus de valeur ajoutée (ou ROI) au commanditaire. Il s’agit donc de faire remonter les exigences fonctionnelles de la plus haute valeur ajoutée (ou dont le ROI est le plus élevé) en haut de la liste. Cette liste est appelée le Product Backlog. Le Product Backlog servira à piloter l’équipe de développement et pourra évoluer tout au long du projet. Le changement est non seulement autorisé mais encouragé afin de pouvoir éliminer les idées de départ qui s’avéreront mauvaises et de prendre en compte les nouvelles idées qui arriveront en cours de route. Cette activité de construction du Product Backlog est collaborative, elle implique le Product Owner et l’équipe de développement. ET DANS LE CAS D'UN APPEL D'OFFRE ? Vous répondez à un appel d’offre pour la réalisation du logiciel de votre client ? Vous ne pouvez pas construire le Product Backlog avec lui ? Dans ce cas, vous pouvez partir du cahier des charges, extraire de ce dernier les exigences, les estimer (idéalement avec 3 membres de l’Equipe de Développement pressentie) et initialiser ainsi le Product Backlog. Vous pouvez également aller plus loin en proposant un premier ordonnancement. Pondérer chaque exigence d’une valeur ajoutée n’est pas toujours évident pour une équipe métier (MOA) novice. Différentes techniques s’offrent à vous. Le fameux Planning Poker (voir paragraphe ci dessous) peut s’avérer utile pour déterminer collectivement les pondérations en « points » de valeur ajoutée. On peut également utiliser des échelles de valeur plus ou moins fine (exemple : « faible », « moyenne », « haute » ou encore les tailles de tee-shirt : XS, S, M, L, XL, XXL). Estimations des exigences L’ensemble des fonctionnalités de la liste doivent être estimées par l’équipe de développement afin de permettre les futurs engagements de cette dernière. Impliquant plusieurs développeurs, le Planning Poker permet de mettre à profit les expériences de chacun et de parvenir rapidement à une estimation optimale et objective. Avant ou pendant les estimations, le Product Owner pourra être sollicité afin de répondre aux questions de l’équipe de développement. A ce stade, le besoin pourra être approfondi, mais sans aller trop loin GUIDE DE DÉMARRAGE SCRUM Page 6/19 (il s’agit simplement d’estimer le coût de chaque exigence). La conception détaillée se fera pendant les itérations (sprints). Lien pour en savoir plus sur le Planning Poker Démarrage Vous pouvez commencer par déterminer ensemble (équipe de développement et product owner) la durée des itérations ou Sprints (4 semaines maximum). Cette durée devra être la même pour l’ensemble des sprints afin de maintenir un rythme régulier propice aux automatismes et pouvoir construire des indicateurs de pilotage fiables. Un projet démarre généralement par les travaux préparatoires du projet tels que la construction du product backlog et de la vision du produit, initiation des acteurs à Scrum (sur un projet de développement logiciel, on peut étendre à la préparation des environnements, mise en place de l’intégration continue, définition de l’architecture générale du projet, etc.). Inutile de le faire durer trop longtemps cette phase, souvenez vous (cf. article « introduction aux méthodes Agile »), l’idée est de se lancer sans élaborer au préalable un plan et une architecture millimétrés qui risqueraient de nous enfermer, de nous frustrer, voire de nous coûter cher à courts et longs termes. L’architecture doit être souple et émerger au fil uploads/Management/ guide-de-demarrage-scrum.pdf