Introduction à Scrum Traduction de Fabrice AIMETTI 7 juin 2009 sur la base d’une première traduction de Claude Aubry

Introduction à Scrum Présenté par <vous> <date>

Nous sommes en train de perdre 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 entrer en conflit avec les objectifs de vitesse et flexibilité maximum. A l’inverse, une approche holistique comme au ‘rugby’ — où une équipe essaie d’avancer en restant unie, 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 se concentrer sur la livraison de la plus grande valeur métier dans le délai le plus court. Il nous permet de vérifier rapidement et régulièrement un logiciel qui fonctionne réellement (toutes les 2 à 4 semaines). Le métier définit les priorités. Les équipes s’organisent elles-mêmes pour déterminer la meilleure façon de produire les fonctionnalités les plus prioritaires. Toutes les 2 à 4 semaines, tout le monde peut voir réellement fonctionner un logiciel et décider soit de le livrer dans l’état, soit de continuer à l’enrichir sur le sprint suivant.

Origines de Scrum Jeff Sutherland Ken Schwaber Mike Beedle Premiers pas à Easel Corp en 1993 IDX et +500 pers. pratiquant Scrum Ken Schwaber ADM Scrum présenté à OOPSLA 96 avec Sutherland Auteur de trois livres sur Scrum Mike Beedle Scrum patterns à PLOPD4 Ken Schwaber et Mike Cohn Cofondateurs de Scrum Alliance en 2002, d’abord dans le cadre de l’Agile Alliance

Utilisateurs de Scrum : Microsoft Yahoo Google Electronic Arts Lockheed Martin Philips Siemens Nokia IBM 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 interne Développement contractuel Projets au forfait Applications financières Applications certifiées ISO 9001 Systèmes embarqués Systèmes fonctionnant 24h/24 7j/7 (99.999%) Le programme Joint Strike Fighter Développement de jeux vidéos Systèmes critiques pour la santé (FDA) Logiciel de contrôle satellite Sites Web Logiciels pour PDA Téléphonie mobile Infrastructure de réseaux Développeurs indépendants Quelques unes des plus grandes applications utilisées aujourd’hui

Caractéristiques Equipes auto-organisées Le produit s’enrichit par des suites de “sprints” d’au plus 1 mois Les exigences sont définies comme des éléments d’une liste appelée “product backlog” Pas de pratiques d’ingénierie prescrites Utilise des règles génériques permettant de créer un environnement agile pour produire un projet Un des “processus agiles”

Le Manifeste Agile – une déclaration de valeurs Processus et outils Individus et interactions plutôt que Documentation complète Un logiciel qui fonctionne plutôt que Négociation à partir d’un contrat Collaboration avec le client plutôt que Suivre un planning S’adapter au changement plutôt que Source: www.agilemanifesto.org

Niveau de bruit du projet Non 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 Pas maîtrisées Maîtrisées

Produit partiel potentiellement utilisable Scrum 24 heures Sprint 2-4 semaines Retours But du Sprint Produit partiel potentiellement utilisable Backlog du sprint Annulations Retours Papiers cadeaux Coupons Annulations Papiers cadeaux Coupons Backlog du Produit

Image disponible sur www.mountaingoatsoftware.com/scrum Vue d’ensemble Image disponible sur www.mountaingoatsoftware.com/scrum

Sprints Les projets Scrum progressent par une série de “sprints” Equivalent aux itérations en Extreme Programming La durée typique est de 2 à 4 semaines maxi Une durée constante apporte un meilleur rythme Le produit est conçu,codé et testé pendant le sprint

Cycle séquentiel vs. itératif par recouvrement Exigences Conception Code Test Plutôt que de faire totalement une seule chose à la fois ... 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.

Pas de changement durant le sprint Définissez la durée d’un sprint en fonction de la l’engagement que vous prenez de différer toute demande de changement au sprint suivant

Le framework Scrum Rôles Cérémonies Artefacts Product owner ScrumMaster Equipe Rôles Planification de Sprint Revue de Sprint Rétrospective de Sprint Scrum quotidien Cérémonies Backlog de produit Backlog de Sprint Burndown charts Artefacts

Scrum framework Rôles Cérémonies Artefacts Product owner ScrumMaster Equipe Rôles Planification de Sprint Revue de Sprint Rétrospective de Sprint Scrum quotidien Cérémonies Artefacts Backlog de Produit Backlog de Sprint Burndown charts

Product owner Définit les fonctionnalités du produit Décide la date et le contenu de la release Responsable du Retour sur Investissement Définit la priorité des fonctionnalités en fonction de leur valeur métier Ajuste les fonctionnalités et les priorités à chaque sprint, si nécessaire Accepte ou rejette les résultats

The ScrumMaster Représente le management du projet Responsable de l’application des valeurs et des pratiques de Scrum Résout les problèmes S’assure que l’équipe est complètement fonctionnelle et productive Facilité une coopération poussée entre tous les rôles et fonctions Protège l’équipe des interférences extérieures

L’équipe Typiquement 5 à 9 personnes Regroupant tous les rôles : Développeurs, testeurs, ergonomes, etc. De préférence à plein temps sur le projet Sauf exceptions (ex : administrateur BD) Les équipes sont auto-organisées Idéalement, pas d’étiquette mais rarement possible La composition de l’équipe ne peut changer qu’entre deux sprints

Scrum framework Rôles Cérémonies Artefacts Product owner ScrumMaster Equipe Rôles Planification de Sprint Revue de Sprint Rétrospective de Sprint Scrum quotidien Cérémonies Backlog de Produit Backlog de Sprint Burndown charts Artefacts

Planification du Sprint Capacité de l’équipe Périmètre Analyser et évaluer le backlog du produit Définir le but du sprint But du Sprint Backlog de produit Conditions métier Planning Décider comment s’y prendre (conception) Créer la liste des tâches à partir des éléments du backlog du produit (user stories) Estimer les tâches en heures Produit actuel Backlog du Sprint Techno-logies

Planification du Sprint L’équipe sélectionne les éléments du backlog de produit qu’elle s’engage à finir Le backlog du sprint est créé : Les tâches sont identifiées et estimées (1 à 16 heures) Collectivement, pas uniquement par le ScrumMaster La conception de haut niveau est abordée En tant que touriste intéressé par la région, je souhaite voir les photos des hôtels. Coder la couche persistance (8 heures) Coder l‘IHM (4) Ecrire les test fixtures (4) Coder la classe foo (6) Màj des tests de performance (4)

Scrum quotidien Caractéristiques : Pas pour résoudre les problèmes : Tous les jours 15 minutes Debout Pas pour résoudre les problèmes : Tout le monde est invité Seul les membres de l’équipe, le ScrumMaster, le Product owner, peuvent parler Evite d’organiser d’autres réunions

Chacun répond à 3 questions Qu’as tu fais hier ? 1 Que vas-tu faire aujourd’hui ? 2 Es-tu bloqué par quelque chose? 3 Il ne s’agit pas de comptes-rendus au ScrumMaster Ce sont des engagements pris entre pairs

Revue de sprint L’équipe présente ce qu’elle a accompli durant le sprint En général sous la forme d’une démo des nouvelles fonctionnalités ou de l’architecture Informelle Préparation  2 heures Pas de slides Toute l’équipe participe Inviter le monde entier

Rétrospective de sprint Réfléchir régulièrement à ce qui marche et 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

Commencer / Arrêter / Continuer Toute l’équipe se réunit et discute sur qu’elle aimerait : Commencer à faire Arrêter de faire Juste une façon parmi d’autres de faire la rétrospective d’un sprint. Continuer à faire

Scrum framework Rôles Cérémonies Artefacts Product owner ScrumMaster Equipe Rôles Planification de Sprint Revue de Sprint Rétrospective de Sprint Scrum quotidien Cérémonies Backlog de Produit Backlog de Sprint Burndown charts Artefacts

Ceci est le backlog de produit Les exigences Une liste du travail souhaité sur le projet Exprimé idéalement de telle manière 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 au début de chaque nouveau sprint Ceci est le backlog de produit

Exemple d’un backlog de produit Elément de backlog Estimation Un invité peut faire une réservation 3 En tant qu’invité, je souhaite annuler ma réservation. 5 En tant qu’invité, je souhaite changer les dates d’une réservation. En tant qu’employé de l’hôtel, je souhaite afficher le revenu moyen de chaque chambre 8 Améliorer la gestion des exceptions ... 30 50

Le but du sprint Un bref énoncé de ce sur quoi le travail va essentiellement porter pendant le sprint Sciences de la vie Offrir les fonctionnalités nécessaires à l’étude génétique d’une population Base de données Faire tourner l’application sur SQL Server en plus d’Oracle. Services financiers Offrir davantage d’indicateurs techniques que l’entreprise ABC avec un flux de données diffusé en continu et en temps-réel.

Gérer le backlog de sprint Chacun s’engage sur un travail qu’il choisit lui-même Le travail n’est jamais assigné par un autre L’estimation du reste à faire est réactualisée tous les jours Chaque membre de l’équipe peut ajouter, supprimer ou changer un élément du backlog de sprint Le travail du sprint émerge progressivement Si le travail n’est pas clair, définir une tâche dans le backlog du sprint en estimant une grosse charge et la décomposez plus tard Affinez le reste à faire au fur et à mesure

Exemple d’un backlog de sprint 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 couche métier Ecrire l’aide en ligne Ecrire la classe foo

Un burndown chart de sprint Heures

Tâches Lun Mar Mer Jeu Ven Coder l’IHM 8 4 12 16 8 10 16 7 11 8 Coder couche métier 16 Tester couche métier 8 Ecrire l’aide en ligne 12 50 40 30 Hours 20 10 Mon Tue Wed Thu Fri

Scalabilité Une équipe comprend généralement 7 ± 2 personnes La scalabilité est obtenu avec plusieurs équipes Facteurs de scalabilité : Type d’application Taille de l’équipe Répartition géographique des équipes Durée du projet Scrum a été utilisé sur de nombreux projets de 500 personnes et plus

Scalabilité avec un Scrum de scrums

Scrum de scrums de scrums

Pour aller plus loin www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com scrumdevelopment@yahoogroups.com

Pistes de lecture Agile and Iterative Development: A Manager’s Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Software Development Ecosystems by Jim Highsmith Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber User Stories Applied for Agile Software Development by Mike Cohn Lots of weekly articles at www.scrumalliance.org

Notice Copyright Vous êtes libre : Selon les conditions suivantes : de Partager - reproduire, distribuer et communiquer ce support de Modifier - adapter ce support 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(s) auteur(s). Pour plus d’informations, voir : http://creativecommons.org/licenses/by/3.0/

Présentation de Mike Cohn Contact Présentation de Mike Cohn mike@mountaingoatsoftware.com www.mountaingoatsoftware.com (720) 890-6110 Vous pouvez supprimer ce slide (ou tout autre) mais vous devez citer les sources quelque part dans votre présentation. Utilisez le logo et le nom de l’entreprise (en bas à gauche par exemple) ou incorporez un slide quelque part pour dire qu’une portion (ou la totalité) de votre présentation provient de ces sources. Merci.