Introduction à Scrum Présenté par <vous> <date> Traduction de Claude Aubry

Le rugby plutôt que la course de relais Hirotaka Takeuchi et Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, Janvier 1986. “… L’approche course de relais pour le développement de produits…peut être en conflit avec les objectifs de vitesse et de flexibilité maximum. A l’inverse, une approche holistique comme au rugby— quand une équipe essaie d’avancer en restant unie, en se passant le ballon de main en main— peut mieux servir les exigences de compétitivité d’aujourd’hui.” would be nice to include a quote from Wicked Problems here

Scrum en 100 mots Scrum est un processus agile qui permet de produire la plus grande valeur métier dans la durée la plus courte. Du logiciel qui fonctionne est produit à chaque sprint (toutes les 2 à 4 semaines). Le métier définit les priorités. L'équipe s'organise elle-même pour déterminer la meilleure façon de produire les exigences les plus prioritaires. A chaque fin de sprint, tout le monde peut voir fonctionner le produit courant et décider soit de le livrer dans l'état, soit de continuer à l'améliorer pendant un sprint supplémentaire.

Origines de Scrum Jeff Sutherland Ken Schwaber Mike Beedle Premiers pas à Easel Corp en 1993 IDX : 500 personnes pratiquant Scrum Ken Schwaber ADM Scrum présenté à OOPSLA 96 avec Sutherland Auteur des 3 livres sur Scrum Mike Beedle Scrum patterns à PLOPD4 Ken Schwaber et Mike Cohn Co-fondateurs de Scrum Alliance en 2002, d'abord dans le cadre de Agile Alliance

Utilisateurs de Scrum Microsoft Yahoo Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC Intuit Nielsen Media First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce

Utilisations de Scrum Logiciel commercial Développement de jeux vidéo Développement interne Développement contractuel Projets au forfait Applications financières Applications certifiées ISO 9001 Systèmes embarqués SI avec exigences de fiabilité 24x7 99.999% le Joint Strike Fighter(DoD)‏ Développement de jeux vidéo Systèmes critiques type FDA Logiciel de contrôle de satellite Sites Web Logiciels pour PDA Téléphonie mobile Infrastructure de réseaux Applications ISV Quelques-unes des plus grandes applications en utilisation

Caractéristiques de Scrum Equipe responsable, en auto-organisation Avancement du produit par une série de « sprints » d’un mois ou moins Exigences définies comme des éléments d’une liste appelée « backlog de produit » Pas de prescription de pratiques d’ingénierie Utilisation de règles génériques permettant de créer un environnement agile pour un projet Un des « processus agiles »

Manifeste Agile : valeurs Processus et outils Personnes et interactions > Documentation Logiciel qui fonctionne > Négociation à partir d'un contrat Collaboration avec le client > Suivi d'un plan Adaptation au changement > Source : www.agilemanifesto.org

Niveau de bruit du projet Loin d'être définies Anarchie Complexe Exigences Compliqué Source : Strategic Management and Organizational Dynamics par Ralph Stacey dans Agile Software Development with Scrum par Ken Schwaber et Mike Beedle. Simple Définies Technologie Maîtrisée Pas maîtrisée

Scrum 24 heures Sprint 2-4 semaines Retour But du sprint Produit partiel potentiellement livrable Liste des tâches Retour Annuler Emballage Coupons Annuler Emballage Coupons Backlog de produit

Image disponible à www.mountaingoatsoftware.com/scrum Tout Scrum Image disponible à www.mountaingoatsoftware.com/scrum

Sprints Les projets Scrum progressent par une série de sprints Equivalents aux itérations d'Extreme Programming La durée d’un sprint est de 2 à 4 semaines Une durée constante apporte un meilleur rythme Le produit (partiel) est conçu, codé et testé pendant le sprint

La séquence est différente Exigences Conception Code Test Plutôt que de faire toute une discipline d'un coup... ...Les équipes Scrum font un peu de tout tout le temps Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.

Stabilité pendant le sprint Changement Planifier la durée pour permettre de différer la prise en compte d’un changement jusqu’au prochain sprint

Le cadre Scrum Rôles Cérémonial Artefacts Product Owner ScrumMaster Equipe Rôles Planification du sprint Revue du sprint Rétrospective Scrum quotidien Cérémonial Backlog de produit Liste des tâches Burndowns Artefacts

Le cadre Scrum Rôles Rôles Cérémonial Artefacts Product owner ScrumMaster Team Rôles Product Owner ScrumMaster Equipe Rôles Planification du sprint Revue du sprint Rétrospective Scrum quotidien Cérémonial Artefacts Backlog de produit Liste des tâches Burndowns

Product Owner Définit les fonctionnalités du produit Choisit la date et le contenu de la release Responsable du retour sur investissement Définit les priorités dans le backlog en fonction de la valeur « métier » Ajuste les fonctionnalités et les priorités à chaque sprint si nécessaire Accepte ou rejette les résultats

ScrumMaster Représente le management du projet Responsable de faire appliquer par l’équipe les valeurs et les pratiques de Scrum Élimine les obstacles S'assure que l'équipe est complètement fonctionnelle et productive Facilite une coopération poussée entre tous les rôles et fonctions Protège l'équipe des interférences extérieures

Equipe Scrum De 5 à 10 personnes Regroupant tous les rôles Architecte, concepteur, développeur, spécialiste IHM, testeur, etc. A plein temps sur le projet, de préférence Exceptions possibles (administrateur, …)‏ L’équipe s’organise par elle-même La composition de l’équipe ne doit pas changer pendant un Sprint

Le cadre Scrum Rôles Cérémonial Artifacts Product Owner ScrumMaster Equipe Rôles Planification du sprint Revue du sprint Rétrospective Scrum quotidien Cérémonial Backlog de produit Liste des tâches Burndowns Artifacts

Planification du sprint Capacité de l'équipe Périmètre Analyser et évaluer le backlog de produit Définir le but du sprint But du sprint Backlog de produit Conditions métier Plan Décider comment s'y prendre (conception)‏ Créer la liste des tâches à partir des éléments du backlog de produit Estimer les tâches en heures Produit actuel Liste des tâches Technos

Planification du sprint L'équipe choisit, à partir du backlog de produit, les éléments qu'elle s'engage à finir. La liste des tâches est créée Les tâches sont identifiées et estimées (1-16 heures)‏ Collectivement, pas seulement par le ScrumMaster La conception de haut niveau est abordée En tant que touriste potentiel dans la région, je veux voir les photos des hôtels Coder la couche de persistance (8 heures)‏ Coder l'IHM (4)‏ Ecrire les test fixtures (4)‏ Coder la classe foo (6)‏ Maj les tests de performance (4)‏

Scrum quotidien Paramètres Pas fait pour résoudre les problèmes Tous les jours 15 minutes Debout Pas fait pour résoudre les problèmes Tout le monde est invité Seuls les membres de l'équipe peuvent parler Permet d'éviter l'organisation d'autres réunions

Chacun répond à 3 questions Qu'as-tu fait hier ? 1 Que vas-tu faire aujourd'hui ? 2 Y a t-il un obstacle qui te freine ? 3 Il ne s'agit pas de compte-rendus au ScrumMaster Ce sont des engagements devant des pairs

Revue de sprint L'équipe présente ce qu'elle a fait pendant le sprint Se fait avec une démo des nouvelles fonctionnalités ou de l'architecture Informel Préparation < 2h Pas de slides Toute l'équipe participe On invite du monde

Rétrospective du sprint Réfléchir régulièrement à ce qui marche et ce qui ne marche pas Dure en général de 15 à 30 minutes Fait à la fin de chaque sprint Toute l'équipe participe ScrumMaster Product Owner Equipe Eventuellement clients et autres intervenants

Retour sur les pratiques Toute l'équipe collecte du feedback et discute sur ce qu'elle aimerait : Commencer à faire Arrêter de faire Juste une façon parmi d'autres de faire une rétrospective. Continuer à faire

Scrum framework Rôles Cérémonial Artefacts Product Owner ScrumMaster Equipe Rôles Planification de sprint Revue de sprint Rétrospective Scrum quotidien Cérémonial Backlog de produit Liste des tâches Burndowns Artefacts

Ceci est le backlog de produit Les exigences Une liste de tout ce qui va entraîner du travail pour l'équipe Exprimé de telle façon que chaque élément apporte de la valeur aux utilisateurs ou clients du produit Les priorités sont définies par le Product Owner Les priorités sont revues à chaque sprint Ceci est le backlog de produit

Un backlog de produit Elément de backlog Estimation Un invité peut faire une réservation 3 En tant qu'invité, j'annule une réservation 5 En tant qu'invité, je change les dates d'une réservation. En tant qu'employé de l'hôtel, je produis les rapports de revenu par chambre 8 Améliorer la gestion des exceptions ... 30 50

Le but du sprint Un bref énoncé de sur quoi va porter l'essentiel du travail pendant le sprint Sciences de la vie Offrir les fonctions pour les études génétiques. Application BD Faire tourner l'application sur une base MySQL en plus d'Oracle. Services financiers Offrir plus d'indicateurs que le produit ABC sur les données de streaming .

Vie de la liste des tâches Chacun s'engage sur du travail qu'il choisit Le travail n'est jamais attribué par un autre L'estimation du reste à faire est ajustée tous les jours N'importe qui peut ajouter, supprimer ou changer la liste des tâches Le travail du sprint émerge progressivement Si un travail n'est pas clair, définir une tâche avec plus de temps et la décomposer après Mise à jour du travail restant quand il est mieux connu

Une liste des tâches Tâches Lun Mar Mer Jeu Ven Coder l'IHM Tracer les erreurs 8 10 16 8 16 12 4 12 16 8 4 11 8 8 Coder couche métier Tester l'intégration Ecrire l'aide en ligne Ecrire la classe foo

Un burndown de sprint Heures

Tâches Lun Mar Mer Jeu Ven Coder l'IHM 8 4 12 16 8 10 16 7 11 8 Coder la persistance 16 Tester l'intégration BD 8 Ecrire l'aide en ligne 12 50 40 30 Heures 20 10 Lun Mar Mer Jeu Ven

Scrum à grande échelle Une équipe typique c'est 7 ± 2 personnes Le changement d'échelle se fait par la collaboration de plusieurs équipes Facteurs dans la scalabilité Type d'application Taille de l'équipe Répartition géographique des équipes Durée du projet Scrum a été utilisé pour de nombreux projets de plus de 500 personnes

Scalabilité avec un scrum de scrums

Scrum de scrums de scrums

Où se renseigner ? www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com scrumdevelopment@yahoogroups.com En français le groupe des utilisateurs de Scrum : www.frenchsug.org http://fr.groups.yahoo.com/group/frenchsug

Quoi lire d'autre ? Agile and Iterative Development: A Manager’s Guide de Craig Larman Agile Estimating and Planning de Mike Cohn Agile Retrospectives d'Esther Derby et Diana Larsen Agile Software Development Ecosystems de Jim Highsmith Scrum and the Enterprise par Ken Schwaber User Stories Applied for Agile Software Development de Mike Cohn Des articles toutes les semaines à www.scrumalliance.org

Copyright notice Vous êtes libre de : Selon les conditions suivantes : Reproduire, distribuer et communiquer cette création au public Modifier cette création Selon les conditions suivantes : Paternité. Vous devez citer le nom de l'auteur original de la manière indiquée par l'auteur de l'oeuvre ou le titulaire des droits qui vous confère cette autorisation (mais pas d'une manière qui suggérerait qu'ils vous soutiennent ou approuvent votre utilisation de l'oeuvre). Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur ou des auteurs. Pour plus d'infos voir : http://creativecommons.org/licenses/by/3.0/

Information et contact Présentation de Mike Cohn mike@mountaingoatsoftware.com www.mountaingoatsoftware.com (720) 890-6110 Vous pouvez modifier cette présentation mais vous devez citer les sources (auteur et traducteur) quelque part dans votre présentation. Par exemple incorporez une diapositive au début pour dire que votre présentation provient de ces sources. Merci de faire pour le mieux. Traduction de Claude Aubry claude@aubryconseil.com 06 60 646 946 www.aubryconseil.com