Traduction de la dernière version du guide officiel de Scrum                                         (Version Juillet 2011...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)                        ...
Prochain SlideShare
Chargement dans…5
×

Traduction de la dernière version du guide officiel de Scrum (Version Juillet 2011)

1 962 vues

Publié le

Titre original : « The Scrum Guide. The definitive Guide to Scrum : The Rules of the Game”. Le guide officiel en anglais est disponible à l’adresse : www.scrum.org. Des traductions officielles dans d’autres langues y compris
en français sont également disponibles à la même adresse.

Publié dans : Technologie
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 962
Sur SlideShare
0
Issues des intégrations
0
Intégrations
42
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Traduction de la dernière version du guide officiel de Scrum (Version Juillet 2011)

  1. 1. Traduction de la dernière version du guide officiel de Scrum (Version Juillet 2011) Le guide définitif de Scrum : Les règles du jeu Par les pères fondateurs de Scrum Ken Schwaber et Jeff Sutherland Traduit de l’anglais et commenté par Mahfoud Amiour mamiour@softenia-solutions.com www.softenia-solutions.com (Traduction non officielle1, V1.0 -Avril 2012)1 Titre original : « The Scrum Guide. The definitive Guide to Scrum : The Rules of the Game”. Le guide officiel enanglais est disponible à l’adresse : www.scrum.org. Des traductions officielles dans d’autres langues y comprisen français sont également disponibles à la même adresse.
  2. 2. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comTables des matiè resObjectif du guide Scrum .......................................................................................................................... 3Vue d’ensemble de Scrum ....................................................................................................................... 3Le Framework Scrum .............................................................................................................................. 3La théorie Scrum ..................................................................................................................................... 4 La transparence ................................................................................................................................... 4 L’adaptation......................................................................................................................................... 4Scrum ....................................................................................................................................................... 5 L’équipe Scrum .................................................................................................................................... 5 Le Product Owner ............................................................................................................................ 5 L’équipe de développement............................................................................................................ 6 Le Scrum Master .............................................................................................................................. 7 Les événements Scrum........................................................................................................................ 8 Le Sprint ........................................................................................................................................... 8 Réunion de planification de Sprint .................................................................................................. 9 Mêlée Quotidienne ....................................................................................................................... 11 Revue de Sprint ............................................................................................................................. 12 Rétrospective de Sprint ................................................................................................................ 13 Les artefacts Scrum ........................................................................................................................... 13 Backlog de produit......................................................................................................................... 14 Backlog de Sprint ........................................................................................................................... 15 L’incrément.................................................................................................................................... 16 Définition de Fini ........................................................................................................................... 16Conclusion ............................................................................................................................................. 17Remerciements ..................................................................................................................................... 18 Les personnes .................................................................................................................................... 18 Historique .......................................................................................................................................... 18Traduction non officielle -Version 1.0 Avril 2012 Page 2
  3. 3. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comObjectif du guide ScrumScrum est un framework dédié au développement et à la maintenance de produits complexes. Ceguide présente la définition de Scrum. La définition inclut les rôles, les événements, les artefacts etles règles qui les lient. Le guide est écrit et fourni par Ken Schwaber et Jeff Sutherland, les créateurset développeurs de Scrum.Vue d’ensemble de ScrumScrum(n) : Un framework au sein duquel on peut adresser des problèmes complexes et changeants,tout en livrant de manière productive et créative des produits ayant la plus haute valeur ajoutéepossible. Scrum est : • Léger • Simple à comprendre • Extrêmement difficile à maitriserScrum est un framework utilisé dans la gestion de projets de développements complexes depuis ledébut des années 1990. Ce n’est pas un processus ni un technique de construction de produits ; Ils’agit plutôt d’un cadre dans lequel vous pouvez utiliser différents processus et techniques2.Scrum vous aide à rendre visible l’efficacité relative de vos pratiques de gestion et dedéveloppement, afin que vous puissiez les améliorer.Le Framework ScrumLe framework se compose d’équipes Scrum et leurs rôles, d’événements, d’artefacts et de règles.Chacun de ces éléments répond à un objectif bien précis. Il est par conséquent indispensable àl’utilisation et au succès de Scrum.Les stratégies spécifiques pour l’utilisation du framework Scrum varient et sont décrites ailleurs.Les règles de Scrum définissent et régissent les liens et les interactions entre les événements, lesrôles et les artefacts. Elles seront décrites tout au long de ce guide.2 Scrum ne prescrit pas de pratiques d’ingénierie logicielle par exemple. En général, on utilise des pratiquesprovenant de l’eXtreme Programming comme l’intégration continue, le développement dirigé par les tests(TDD, etc.).Traduction non officielle -Version 1.0 Avril 2012 Page 3
  4. 4. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comLa théorie ScrumScrum est basé sur la théorie de contrôle des processus empiriques : L’empirisme. La théorie del’empirisme considère que la connaissance vient de l’expérience. De ce fait, elle favorise la prise dedécision en se basant sur ce qui est connu.Scrum emploie également une approche itérative et incrémentale pour améliorer la prédictibilité etle contrôle des risques.Le contrôle des processus empiriques est fondé sur trois piliers : La transparence, l’inspection etl’adaptation.La transparenceLes aspects significatifs du processus doivent être visibles aux acteurs responsables du résultat. Latransparence nécessite que ces aspects soient définis via un standard commun à fin de permettreaux observateurs d’avoir une compréhension commune de ce qu’ils sont en train d’observer.Par exemple : • Tous les participants doivent partager un langage commun représentant le processus • Ceux qui effectuent le travail et ceux qui le valident doivent partager une définition commune de « Fini3»Afin de détecter les écarts indésirables, les utilisateurs de Scrum doivent régulièrement inspecterles artefacts du framework et l’état d’avancement vers un objectif fixé. Cependant, la fréquencede l’inspection ne doit pas être trop élevée pour ne pas gêner l’équipe dans son travail. D’autrepart, les inspections les plus bénéfiques sont celles menées par des inspecteurs qualifiés sur le lieude travail de l’équipe.L’adaptationSi l’inspection d’un processus détecte des déviations qui dépassent les limites tolérables, rendant leproduit inacceptable, le processus ou le matériel en cours d’inspection doit être ajusté. Cetajustement doit être effectué le plus tôt possible pour éviter l’aggravation de la situation.Scrum prescrit quatre opportunités formelles pour l’inspection et l’adaptation. Ces opportunités,décrites dans la section « Les événements Scrum » de ce document, sont : • La Réunion de planification de Sprint ; • La Mêlée quotidienne ; • La Réunion de revue de Sprint ; • La Rétrospective de Sprint.3 La définition de « Fini » fait partie des artefacts de Scrum. Elle sera présentée dans la section « Définition deFini ».Traduction non officielle -Version 1.0 Avril 2012 Page 4
  5. 5. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comScrumScrum est un framework structuré destiné à supporter le développement de produits complexes. Leframework se compose des éléments suivants : Une équipe Scrum et ses rôles, des événements, desartefacts et des règles. Chaque élément répond à un besoin spécifique le rendant indispensable àl’utilisation et au succès de Scrum.L’équipe ScrumL’équipe Scrum comprend les rôles suivants : le Product Owner, l’équipe de développement et leScrum Master.Les équipes Scrum sont auto organisées et multidisciplinaires4. L’auto-organisation signifie que lafaçon de travailler de l’équipe n’est pas dictée de l’extérieur. C’est à l’équipe de choisir la meilleurefaçon pour accomplir son travail et atteindre ses objectifs. La multidisciplinarité veut dire quel’équipe possède toutes les compétences nécessaires à l’exécution de son travail, sans dépendre del’extérieur5. Ce modèle d’équipe a été conçu dans le but d’optimiser la flexibilité, la créativité et laproductivité.L’équipe Scrum effectue des livraisons de produits de façon itérative et incrémentale, maximisantainsi les opportunités de feedback. Ces livraisons incrémentales de produits « Finis » permettentd’avoir en permanence une version du produit potentiellement utilisable6.Le Product OwnerLe Product Owner a la responsabilité de maximiser la valeur ajoutée du produit et du travail del’équipe de développement. La façon pour y parvenir dépend des organisations, des équipes Scrumet des individus.Le Product Owner est également l’unique responsable de la gestion du Backlog du produit. Cettegestion consiste à : • Décrire de manière claire les éléments du Backlog ; • Ordonner les éléments de façon à mieux accomplir les objectifs et les missions7 ; • Garantir la valeur du travail effectué par l’équipe de développement ; • S’assurer de la visibilité du Backlog, de sa transparence et de sa clarté pour tous ; • Garantir que le Backlog montre bien sur quoi l’équipe Scrum travaille prochainement ; • S’assurer de la bonne compréhension des éléments du Backlog par l’équipe de développement et avec le niveau de détail adéquat.Le Product Owner peut effectuer lui-même les tâches ci-dessus. Il peut également les déléguer àl’équipe de développement. Cependant, il demeure toujours le seul responsable du Backlog duproduit.4 Note du traducteur : C’est une équipe transverse.5 Note du traducteur : L’équipe possède des compétences en développement, tests, analyse fonctionnelle,bases de donnes, etc.6 Note du traducteur : Cela veut dire que l’on peut déployer l’incrément en production.7 Note du Traducteur : Il s’agit de prioriser les éléments afin de commencer par la réalisation de ceux qui ont leplus de valeur pour le client.Traduction non officielle -Version 1.0 Avril 2012 Page 5
  6. 6. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comLe Product Owner est une personne physique et non un comité. Il peut néanmoins représenter lesdésirs d’un comité via le Backlog du produit. Dans tous les cas, ceux qui désirent changer le Backlogdu produit (Modifier les priorités par exemple) doivent toujours passer par le Product Owner.Afin que le Product Owner puisse réussir dans son rôle, l’organisation doit respecter ses décisions.Ces dernières sont toujours visibles à travers le contenu et l’ordre du Backlog du produit. En dehorsdu Product Owner, personne n’est autorisé à imposer à l’équipe de développement de travailler surdes éléments qui ne font pas partie du Backlog. De son côté, l’équipe de développement n’est pasautorisée à accepter les demandes ne provenant pas du Product Owner.L’équipe de développementL’équipe de développement se compose de professionnels qui travaillent pour livrer un incrément« Fini » et potentiellement livrable en production à la l’issue de chaque Sprint. Seuls les membres del’équipe de développement réalisent l’incrément.L’équipe de développement est habilitée par l’entreprise à organiser et à gérer elle-même sontravail. La synergie qui résulte de cette auto organisation permet à l’équipe d’optimiser son efficacitéet son efficience globale8.Les caractéristiques de l’équipe de développement sont les suivantes : • L’auto-organisation. Personne (Pas même le Scrum Master) ne peut dicter à l’équipe la façon de procéder pour transformer le Backlog du produit en un incrément ; • La multidisciplinarité. L’équipe possède toutes les compétences nécessaires à la création des incréments9 ; • Pas de titre individuel autre que celui de développeur. Scrum ne reconnait pas de titres au sein de l’équipe de développement. Seul le titre de développeur est reconnu aux membres de l’équipe indépendamment du travail qu’ils effectuent10. Il n’y a pas d’exception à cette règle ; • Les membres de l’équipe peuvent être spécialisés dans certains domaines et avoir des compétences spécifiques11. Cependant, la responsabilité appartient collectivement à l’équipe de développement. • L’équipe de développement ne contient pas de sous équipes dédiées à des domaines spécifiques comme les tests ou l’analyse métier.Taille de l’équipe de développementLa taille optimale de l’équipe de développement est à la fois assez petite pour que l’équipe resteagile, et suffisamment grande pour qu’elle soit capable de produire des résultats significatifs. Une8 Note du traducteur : Lefficience est la qualité dun rendement permettant de réaliser un objectif avecloptimisation des moyens engagés (Source Wikipedia).9 Note du traducteur : L’équipe inclut des compétences en développement, test, analyse fonctionnelle, base dedonnées, etc. selon les besoins du projet.10 Note du Traducteur : Chaque membre de l’équipe est appelé développeur.11 Note du Traducteur : C’est ce que l’on appelle les « profils en T ». Un membre de l’équipe peut par exempleêtre expert en développement Java (Compétence centrale) et avoir des connaissances plus ou moinsimportances en tests, bases de données, etc. Ces compétences « secondaires » lui permettent de prendre destâches autres que du développement Java ; Comme participer aux tests par exemple.Traduction non officielle -Version 1.0 Avril 2012 Page 6
  7. 7. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comtaille de moins de trois membres réduirait les interactions et mènerait à des gains en productivitémoins importants. Une équipe de petite taille risque également de manquer de certainescompétences nécessaires au projet, ce qui peut l’empêcher d’atteindre l’objectif du Sprint.Inversement, avoir plus de neuf personnes dans une équipe exige beaucoup d’effort decoordination. En effet, les équipes de développement de grande taille génèrent trop de complexitépour être gérées par un processus empirique comme Scrum. Le Product Owner et le Scrum Masterne sont pas inclus dans le comptage de la taille de l’équipe, sauf s’ils contribuent à la réalisation deséléments du Backlog du produit12.Le Scrum MasterLe Scrum Master garantit la bonne compréhension et l’application de Scrum en s’assurant quel’équipe Scrum adhère à la théorie, aux pratiques et aux règles du framework. Le Scrum Master estun leader13 au service de l’équipe Scrum.Le Scrum Master apporte son assistance également aux personnes de l’organisation ne faisant paspartie de l’équipe Scrum. Il les aide à comprendre les interactions utiles avec l’équipe Scrum etcelles qui ne le sont pas14. Le Scrum Master apporte son aide pour changer ces interactions de façonà maximiser la valeur créée par l’équipe Scrum.Services rendus au Product OwnerLes services rendus par le Scrum Master au Product Owner incluent : • Trouver les techniques efficaces pour gérer le Backlog du produit ; • Communiquer la vision, les objectifs et les éléments de Backlog du produit à l’équipe de développement ; • Apprendre à l’équipe Scrum (Product Owner et équipe de développement) comment élaborer des éléments de Backlog clairs et concis ; • Comprendre la planification à long terme dans un environnement empirique ; • Comprendre et appliquer l’agilité ; • Faciliter la tenue des évènements Scrum.Services rends à l’équipe de développementLes services rendus par le Scrum Master à l’équipe de développement incluent : • Coacher l’équipe dans l’auto-organisation et la multidisciplinarité ; • Conduire l’équipe et lui apprendre comment créer des produits à forte valeur ajoutée ; • Eliminer les obstacles qui empêchent l’équipe d’avancer ; • Faciliter la tenue des événements Scrum ;12 Il existe des équipes où le Scrum Master effectue également des tâches de développement par exemple.Dans ce cas, il compte aussi comme un membre de l’équipe de développement.13 Note du traducteur : Servant-leader en anglais. Cela signifie que le Scrum Master n’a pas de pouvoirhiérarchique sur l’équipe ; Ce n’est pas lui qui assignent les tâches par exemple.14 Certaines réunions ne concernent que les membres de l’équipe Scrum comme par exemple les mêléesquotidiennes (présentées plus loin dans ce guide). Il est inutile que des personnes externes à l’équipe Scrum yparticipent. En revanche, il est utile (voire indispensable) que ces personnes puissent participer à la réunion derevue des résultats à la fin de chaque Sprint.Traduction non officielle -Version 1.0 Avril 2012 Page 7
  8. 8. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.com • Coacher l’équipe dans les organisations qui n’ont pas encore adopté Scrum.Services rendus à l’organisationLes services rendus par le Scrum Master à l’organisation incluent : • Conduire et coacher l’organisation dans son adoption de Scrum ; • Planifier les implantations de Scrum ; • Aider les employés et les parties prenantes à comprendre et appliquer Scrum et le développement empirique (Transparence, Inspection et adaptation) ; • Provoquer le changement permettant d’accroitre la productivité de l’équipe Scrum ; • Collaborer avec les autres Scrum Master de l’organisation pour rendre l’application de Scrum plus efficace.Les événements ScrumScrum prescrit des événements dans l’objectif de créer de la régularité dans le projet et deminimiser le recours à d’autres réunions non définis dans le Framework. Chaque événement a unedurée maximale appelée « Time-box ». Imposer une durée maximale aux événements permet deconsacrer une quantité de temps appropriée au processus de planification sans autoriser degaspillage.En dehors du Sprint lui-même, qui est le conteneur de tous les événements de Scrum, chaqueévénement constitue une opportunité formelle pour inspecter et adapter quelque chose. Cesévénements sont conçus spécifiquement pour offrir la transparence critique et l’inspection. Omettrel’un d’eux conduira à une diminution de la transparence et à des occasions d’inspection etd’adaptation manquées.Le SprintLe Sprint est au cœur du framework Scrum. C’est un time-box d’un mois ou moins durant lequel oncrée un incrément « Fini » utilisable et potentiellement livrable à la production. Les Sprints ont desdurées constantes tout au long de l’effort de développement. Un nouveau Sprint commenceimmédiatement après la fin du précédent.Les sprints sont constitués d’une réunion de planification de Sprint, de mêlées quotidiennes, dutravail de réalisation15, d’une revue de Sprint et d’une rétrospective de Sprint.Pendant le Sprint : • Les changements pouvant compromettre l’objectif du Sprint ne sont pas permis • La composition de l’équipe de développement ne doit pas changer • Les objectifs de qualité ne doivent pas diminuer • Le périmètre peut être renégocié entre le Product Owner et l’équipe de développement suite à des connaissances nouvelles acquises durant le Sprint.15 Note du traducteur : Il s’agit des tâches nécessaires à la réalisation des fonctionnalités : Conception, codage,tests, documentation, etc.Traduction non officielle -Version 1.0 Avril 2012 Page 8
  9. 9. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comChaque Sprint peut être considéré comme un projet de moins d’un mois d’horizon. Comme toutprojet, les Sprints sont utilisés pour accomplir un travail. A ce titre, chaque Sprint possède unedéfinition de ce qu’il faut construire, une conception et un plan flexible permettant de réaliser cetteconception, le travail à faire, et le produit résultant.Les Sprints sont limités à un mois calendaire. Si l’horizon d’un Sprint est très lointain (plus d’un mois),la définition du produit en cours de construction peut changer, la complexité peut accroitre et lerisque peut augmenter. Un horizon de moins d’un mois est plus approprié : Il améliore laprédictibilité en permettant d’inspecter et d’adapter le planning au minimum une fois tous lesmois ; Le coût des risques est également limité à un mois calendaire.Abandonner un SprintUn Sprint peut être abandonné avant son terme. Seul le Product Owner est habilité à prendre unetelle décision, même s’il peut le faire à la demande des parties prenantes, de l’équipe dedéveloppement ou du Scrum Master.Le Sprint peut être abandonné si son objectif devient obsolète. Cela peut arriver lorsque l’entreprisechange d’orientation ou si les conditions du marché et de la technologie évoluent. En général, unSprint doit être abandonné s’il perd son sens compte tenu des nouvelles circonstances. Mais, vue lacourte durée des Sprints, l’abandon d’un Sprint représente rarement de l’intérêt16.Lorsqu’un Sprint est abandonné, chaque élément « Fini » est examiné. Si une partie du travail estpotentiellement livrable en production, le Product Owner peut décider de l’accepter et l’intégrer auproduit. Les éléments incomplets sont ré-estimé et remis dans le Backlog du produit. La ré-estimation des éléments et une activité régulière dans Scrum car le travail effectué sur les élémentsse déprécie rapidement.L’abandon d’un Sprint est consommateur de ressources. Tout le monde doit se regrouper dans unenouvelle réunion de planification et redémarrer un nouveau Sprint. Les abandons sont souventtraumatisants pour l’équipe Scrum et ils sont rares.Réunion de planification de SprintLe travail à réaliser durant le Sprint est planifié pendant la réunion de planification du Sprint. Le planqui résulte de la réunion est établi collectivement par l’ensemble de l’équipe Scrum.La réunion a une durée maximale de huit heures pour un Sprint d’un mois. Ce time-box estproportionnel à la durée du Sprint. Par exemple, pour un Sprint de deux semaines la durée maximalede la réunion de planification est de quatre heures.La réunion de planification du Sprint se compose en deux parties. Chaque partie possède un time-box égal à la moitié du time-box global. Les deux parties doivent répondre respectivement aux deuxquestions suivantes : • Le Quoi : Que doit-on livrer dans le Sprint? • Le Comment : Comment doit-on procéder pour accomplir le travail nécessaire?16 Note du traducteur : On peut aller jusqu’au bout du Sprint et finir les choses proprement, notamment si peude jours nous séparent de la fin du Sprint.Traduction non officielle -Version 1.0 Avril 2012 Page 9
  10. 10. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.com Première partie(Le Quoi) : Qu’est ce qui va être fait pendant ce Sprint?Dans la première partie de la réunion, l’équipe de développement cherche à établir une prévisionde la fonctionnalité qui sera livrée à l’issue du Sprint. Le Product Owner commence par lui présenterles éléments ordonnés du Backlog du produit17. Ensemble, ils discutent les éléments afin decomprendre le travail à effectuer pendant le Sprint18.Les prérequis de la première partie de la réunion sont le Backlog du produit, le dernier incrément, lacapacité de l’équipe de développement durant le Sprint et sa performance passée19.Il appartient exclusivement à l’équipe de développement de décider du nombre d’éléments àréaliser dans le Sprint. En effet, seule l’équipe (connaissant ses capacités) est en mesure d’évaluerce qu’elle peut accomplir durant le Sprint qui vient.Après avoir établi une prévision de la fonctionnalité à livrer, l’équipe Scrum définit un But pour leSprint. Ce but représente l’objectif que l’on cherche à atteindre à travers la réalisation deséléments sélectionnés du Backlog du produit. Il permet d’orienter l’équipe et lui montrer l’intérêt del’incrément qu’elle est en train de construire20.Deuxième partie (Le Comment) : Comment le travail sélectionné va être effectué ?Dans cette partie de la réunion l’équipe de développement détermine comment procéder pourréaliser la fonctionnalité sélectionnée pour le Sprint. L’ensemble formé par les éléments choisis duBacklog et le plan de réalisation de ces éléments est appelé Backlog de Sprint21.L’équipe de développement commence souvent par concevoir le système22 et identifier le travailnécessaire pour transformer les éléments sélectionnés en un incrément. Les unités de travailidentifiées peuvent avoir des tailles ou des durées variées. Cependant, Il faut identifiersuffisamment de travail durant cette réunion, de façon à permettre à l’équipe de développementd’estimer ce qu’elle est en mesure de livrer à la fin du Sprint. Avant la fin de la réunion, le travailprévu pour les premiers jours du Sprint est décomposé en unités (tâches) d’une journée ou moins.L’équipe de développement s’auto-organise pour prendre en charge le travail qu’elle consigne dans17 Note du traducteur : Il les présente dans l’ordre de priorité.18 Note du traducteur : Afin de se focaliser sur la planification et minimiser le nombre de fonctionnalités àexpliquer, je préconise d’expliquer les fonctionnalités en dehors de la réunion de planification : Soit lors de laphase de préparation du projet (en début du projet), soit lors des réunions de préparation du Backlog duproduit.19 Note du traducteur : Il s’agit de la vélocité estimé de l’équipe. Cette information permet à l’équipe dedéveloppement de déterminer combien d’éléments elle peut sélectionner pour le Sprint.20 Note du traducteur : Exemple de Buts : Implémenter la recherche avancée, Internationaliser l’application,etc. Avoir un but peut aussi être une source de motivation supplémentaire pour l’équipe.21 Note du traducteur : C’est un artefact officiel de Scrum. Il sera détaillé plus loin dans ce document.22 Note du traducteur : Il ne s’agit pas ici d’une conception technique détaillée mais d’une discussion et d’uneébauche de la solution technique dans laquelle toute l’équipe de développement participe. On parle deconception participative.Traduction non officielle -Version 1.0 Avril 2012 Page 10
  11. 11. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comle Backlog du Sprint23. La prise en charge du travail par les membres de l’équipe peut se fairependant la réunion de planification et tout au long du Sprint selon les besoins.Le Product Owner peut participer à la deuxième partie de la réunion afin de préciser les élémentssélectionnés du Backlog du produit et d’aider l’équipe de développement à trouver des compromissi nécessaire. Si au cours de la réunion l’équipe se rend compte qu’elle a sélectionné trop d’élémentsou à l’inverse très peu de choses à faire, elle négocie avec le Product Owner un nouveau périmètredu Sprint24.Si l’équipe de développement le juge utile, elle peut également inviter d’autres personnes à laréunion. C’est le cas par exemple si elle veut se faire conseiller sur certains aspects techniques oufonctionnels.Avant la fin de la réunion de planification du Sprint, l’équipe de développement doit être en mesured’expliquer au Product Owner et au Scrum Master comment elle compte procéder pour atteindre lebut du Sprint en tant qu’équipe auto-organisée.But de SprintLe But du Sprint offre à l’équipe de développement une certaine flexibilité par rapport à lafonctionnalité à réaliser durant le Sprint.L’équipe de développement garde ce but à l’esprit durant toute la durée du Sprint. Pour l’atteindre,elle implémente de la fonctionnalité et de la technique. Si le travail s’avère différent de de ce qui aété prévu, l’équipe de développement peut consulter le Product Owner afin de négocier unnouveau périmètre pour le Sprint.Le but du Sprint peut être considéré comme un jalon intermédiaire dans la roadmap du produit.Mêlée QuotidienneLa mêlée quotidienne est un événement d’une durée maximale de 15 minutes. Il permet à l’équipede développement de synchroniser ses activités et de définir un plan pour les prochaines 24 heures.La mêlée consiste à examiner les tâches accomplies depuis la réunion précédente et de prévoir lestâches à faire avant la suivante.La mêlée quotidienne a lieu chaque jour, à la même heure et au même endroit. Pendant la réunion,chaque membre de l’équipe de développement explique trois points : • Qu’est-ce qu’il a fait depuis la dernière mêlée ? • Qu’est-ce qu’il va faire avant la prochaine mêlée ? • Quels sont les obstacles qui l’empêchent d’avancer dans son travail?23 Note du traducteur : Dans une équipe de développement auto-organisée, les tâches ne sont pas assignéesde l’extérieur. Les membres de l’équipe prennent les tâches en fonction de leur compétence et leurdisponibilité.24 Le revoir à la hausse ou à la baisse selon le cas.Traduction non officielle -Version 1.0 Avril 2012 Page 11
  12. 12. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comL’équipe de développement se sert de la mêlée quotidienne pour : Evaluer l’avancement vers le butdu Sprint ; Estimer les tendances de l’avancement vers l’achèvement du Backlog du Sprint. La mêléequotidienne permet ainsi, d’optimiser la probabilité d’atteindre l’objectif du Sprint.Le plus souvent, l’équipe de développement se rencontre immédiatement après la mêléequotidienne pour mettre à jour le planning du Sprint (Backlog du Sprint). A travers cette mise à jourquotidienne, l’équipe doit être à tout moment en mesure d’expliquer, au Product Owner et auScrum Master, comment elle compte procéder pour atteindre le but du Sprint dans le temps qui luireste.Le Scrum Master s’assure de la bonne organisation de la mêlée quotidienne par l’équipe dedéveloppement. Cependant, c’est à l’équipe qu’incombe la responsabilité de gérer la réunion.Le Scrum Master apprend à l’équipe de développement comment tenir la mêlée dans un délai de 15minutes. Il s’assure également que seuls les membres de l’équipe de développement participent à laréunion. En effet, la mêlée ne doit pas être considéré comme un point d‘avancement du projet. Elleest conçue uniquement pour les personnes qui réalisent les éléments du Backlog du produit.Les mêlées quotidiennes sont donc des réunions clés pour l’inspection et l’adaptation. Ellespermettent : d’améliorer la communication ; de minimiser le recours à d’autres réunions ; d’éliminerles obstacles ; de promouvoir la prise de décision rapide et d’améliorer la connaissance de l’équipede développement sur le projet.Revue de SprintLa revue du Sprint a lieu à la fin de ce dernier. Elle permet d’inspecter l’incrément et adapter leBacklog du produit si nécessaire. Pendant la revue, l’équipe Scrum et les parties prenantes discutentce qui a été réalisé dans le Sprint. Basés sur ces échanges et sur les éventuelles modificationsintroduites sur le Backlog du produit durant le Sprint, les participants travaillent ensemble sur ladéfinition de ce qu’il faut faire pour la suite.De plus, la revue du Sprint est une réunion informelle. La présentation de l’incrément est destinée àobtenir du feedback de la part des participants et à encourager la collaboration.Pour un Sprint d’un mois, la durée maximale de la revue est de quatre heures. Ce time-box estproportionnel à la durée du Sprint. Par exemple, pour un Sprint de deux semaines, la revue ne doitpas dépasser deux heures.La revue du Sprint inclut les éléments suivants : • Le Product Owner identifie les éléments « Finis » et ceux qui ne le sont pas ;25 • L’équipe de développement discute de ce qui a bien fonctionné durant le Sprint, des problèmes rencontrés et comment elle les a traités ; • L’équipe de développement effectue une démonstration des éléments « Finis » et répond aux questions concernant l’incrément ;25 Note du traducteur : Parmi les éléments du Backlog du produit sélectionnés pour le SprintTraduction non officielle -Version 1.0 Avril 2012 Page 12
  13. 13. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.com • Le Product Owner discute le Backlog du produit dans son état actuel. Il ou elle estime les dates probables d’achèvement en se basant sur l’avancement à ce jour ; • L’ensemble des participants collabore à définir le travail à faire pour la suite. De ce fait, la revue fournit des inputs précieux aux réunions de planification suivantes.Le résultat de la revue du Sprint est un Backlog de produit mis à jour qui définit les élémentsprobables pour le Sprint suivant. La conclusion de la revue peut également être un changement totaldu Backlog pour répondre à de nouvelles opportunités par exemple.Rétrospective de SprintLa rétrospective du Sprint est une opportunité mise à la disposition de l’équipe Scrum pour faireson auto inspection et établir un plan d’amélioration pour le prochain Sprint.La rétrospective se fait après la revue du Sprint et avant la réunion de planification du Sprint suivant.Son time-box est de 3 heures pour un Sprint d’un mois. Cette limite est proportionnelle à la duréedu Sprint.L’objet de la rétrospective peut se résumer dans les points suivants : • Inspecter comment le dernier Sprint s’est déroulé par rapport aux personnes, aux relations, aux processus et aux outils ; • Identifier et ordonner les principaux éléments ayant bien fonctionné ainsi que les améliorations potentielles ; • Définir un plan d’action pour mettre en place les actions permettant à l’équipe Scrum d’améliorer sa façon de travailler.Le Scrum Master encourage l’équipe Scrum à améliorer son processus de développement et sespratiques au sein du framework Scrum. L’objectif est de rendre ces processus plus efficaces et plusagréables lors du Sprint suivant.Lors de la rétrospective, l’équipe Scrum peut adapter sa définition de « Fini » dans le but d’accroitrela qualité des produits qu’elle livre.Avant la fin de la réunion, l’équipe Scrum doit identifier les améliorations à mettre en place pour leSprint suivant. En implémentant ces améliorations, l’équipe Scrum applique sur elle-même lespratiques d’inspection et d’adaptation. Même si les améliorations peuvent être implémentées àn’importe quel moment du projet, la rétrospective constitue une opportunité formelle pour sefocaliser sur l’inspection et l’adaptation.Les artefacts ScrumLes artefacts Scrum sont une représentation, sous des formes diverses, du travail ou de la valeurproduits par l’équipe. Ils offrent de la transparence et constituent des ingrédients alimentantl’inspection et l’adaptation. Les artefacts sont pour maximiser la visibilité des informations requisespour assurer la réussite des équipes Scrum dans la livraison d’incréments «Finis»26.26 Note du traducteur : Les artefacts sont : le Backlog de Produit, Le Backlog de Sprint, l’incrément et ladéfinition de « Fini ». Ils seront présentés plus loin dans ce document.Traduction non officielle -Version 1.0 Avril 2012 Page 13
  14. 14. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comBacklog de produitLe Backlog du produit est une liste ordonnée contenant tout ce qui est requis dans le produit. C’estaussi l’unique source des besoins pour toute modification du produit. Cet artefact est sous laresponsabilité exclusive du Product Owner. La responsabilité inclut le contenu du Backlog, sadisponibilité et l’ordre de ses éléments.Un Backlog de produit n’est jamais complet. En début du projet, il expose uniquement les besoinsconnus et les mieux compris à ce stade du projet. Il évolue ensuite au rythme de l’évolution duproduit et de son environnement. C’est aussi un artefact dynamique : Il change constamment pouridentifier de quoi le produit a besoin afin qu’il reste pertinent, compétitif et utile ; Tant que leproduit existe son Backlog doit exister.Le Backlog du produit liste toutes les caractéristiques27, les fonctionnalités, les besoins, lesaméliorations et les correctifs. Ces éléments constituent les changements à introduire sur le produitdans ses versions futures. Chaque élément possède une description, un ordre et une estimation28.Les éléments du Backlog du produit sont souvent ordonnés par leur valeur, leur risque, leur prioritéet leur nécessité dans le produit. Les éléments avec un ordre élevé doivent être réalisés en premier.L’ordre d’un élément est le reflet du degré de sa prise en considération et de l’importance duconsensus dont il bénéficie : Plus son ordre est élevé, plus l’élément est considéré et plus leconsensus à son égard et à l’égard de sa valeur sont importants.Les éléments avec un ordre élevé sont plus concis et plus détaillés que les éléments d’ordre inférieur.Par exemple, ils possèdent des estimations plus précises, établies grâce à une clarté plu grande et àun niveau de détail plus fin.Les éléments qui occuperont l’équipe de développement durant le prochain Sprint ont unegranularité fine. Cette granularité est obtenue en décomposant les éléments en sous élémentspouvant être « Finis » en l’espace d’un Sprint. Ces éléments sont «prêts » ou «actionnables » pourêtre sélectionnés lors de la réunion de planification du Sprint.A mesure que le produit est utilisé et que le marché fournit du feedback, le Backlog du produits’élargit et devient plus exhaustif. De plus, les besoins n’arrêtent pas de changer faisant du Backlogdu produit un artefact vivant ; Des évolutions dans le métier, dans les conditions du marché ou dansla technologie peuvent provoquer des modifications dans le Backlog du produit.Un produit doit avoir un seul Backlog même si généralement plusieurs équipes Scrum travaillent surle même produit. Dans ce cas, on peut ajouter un attribut au Backlog pour regrouper les éléments29.Un Backlog de produit se prépare de façon continue. La préparation du Backlog est l’action d’ajouterles détails, les estimations et l’ordre à ses éléments. C’est un processus continu dans lequel le27 Note du traducteur : Features en anglais.28 Note du traducteur : Il s’agit d’une estimation de la taille de l’élément. A l’instar des autres méthodes Agile,Scrum emploie en général les points (Story points) pour estimer la taille.29 Note du traducteur : Regroupement es éléments par équipe.Traduction non officielle -Version 1.0 Avril 2012 Page 14
  15. 15. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comProduct Owner et l’équipe de développement travaillent ensemble30. Pendant la préparation, leséléments du Backlog sont passés en revue et mis à jours. Mais les éléments peuvent être mis à joursà n’importe quel moment31 par le Product Owner ou avec son accord.La préparation du Backlog est une activité à temps partiel qui a lieu pendant le Sprint. Elle impliquele Product Owner et l’équipe de développement. Cette dernière possède souvent la connaissance dudomaine lui permettant de réparer le Backlog de façon autonome32. Quand et comment faire lapréparation est du ressort de l’équipe de développement. Mais le temps consacré à la préparationne doit pas dépasser 10% de sa capacité pendant le Sprint33.L’équipe de développement est responsable de l’établissement de toutes les estimations. LeProduct Owner peut influer l’équipe en l’aidant à comprendre les fonctionnalités à réaliser et choisirdes solutions alternatives par exemple. Cependant, les estimations finales reviennent à l’équipe dedéveloppement.Suivre l’avancement vers un butA tout moment, le Product Owner doit être en mesure de connaitre le travail total restant à fairepour atteindre un objectif34. Il traque ce reste à faire au minimum à chaque revue de Sprint.Pour ce faire, le Product Owner compare le reste à faire à la fin du Sprint courant avec les restes àfaire à la fin des Sprints précédents35. Cela lui permet d’évaluer l’avancement de l’achèvement dutravail planifié pour la date souhaité de l’objectif. Cette information d’avancement est visible àtoutes les parties prenantes.Plusieurs techniques d’estimation de l’avancement ont été utilisées : Burndown, Burnup et autrespratiques de projection. Elles ont toutes prouvé leur utilité. Cependant, elles ne remplacent pasl’importance de l’empirisme. Dans des environnements complexes, ce qui va arriver reste dudomaine de l’inconnu. Seul ce qui s’est réellement passé peut être utilisé pour la prise de décision etla préparation du futur.Backlog de SprintLe Backlog de Sprint est constitué : de l’ensemble des éléments du Backlog du produit sélectionnéspour ce Sprint ; du plan de réalisation de ces éléments36. Il s’agit d’une prévision (Faite par l’équipede développement) de la fonctionnalité à livrer dans le prochain incrément, et des tâchesnécessaires à cette livraison.30 Note du traducteur : Le Scrum Master peut également participer en tant que facilitateur31 Note du traducteur : En dehors du processus de préparation32 Note du traducteur : A mon avis cette affirmation n’est valable que pour des équipes de développement trèsmature dans l’utilisation de Scrum. Pour des équipes qui débutent, l’implication du Product Owner et du ScrumMaster est indispensable.33 Note du traducteur : Contrairement aux événements, Scrum n’impose donc pas de fréquence et de date pourpréparer le Backlog du produit. C’est à l’équipe Scrum d’organiser des réunions de préparation selon lesbesoins, mais sans dépasser les 10% de sa capacité.34 Note du traducteur : Il s’agit ici du but du produit final35 Note du traducteur : Les restes à faire à la fin des Sprint précédents sont des informations connues. Elles sontconsignées dans l’historique du projet (On utilise souvent ce que l’on appelle le Burndown du produit).36 Note du traducteur : Il s’agit des tâchesTraduction non officielle -Version 1.0 Avril 2012 Page 15
  16. 16. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comLe Backlog du Sprint définit le travail que l’équipe de développement effectuera pour transformerles éléments du Backlog du produit en un incrément « Fini ». Il permet ainsi de visualiser toutes lestâches identifiées comme nécessaires à l’atteinte du But du Sprint.Le Backlog du Sprint est suffisamment détaillé afin de permettre à l’équipe de développement decomprendre son avancement lors de la mêlée quotidienne. L’équipe le met à jour continuellementfaisant du Backlog un artefact qui émerge tout au long du Sprint. Cette émergence apparait àmesure que l’équipe exécute son planning et à mesure qu’elle acquiert de la connaissance sur letravail à faire pour atteindre l’objectif du Sprint.Lorsque du nouveau travail est identifié, l’équipe de développement doit l’ajouter au Backlog duSprint ; Quand elle effectue un travail elle doit mettre à jour l’estimation du reste à faire ; De même,si un travail est jugé inutile, elle doit le supprimer du Backlog du Sprint. Seule l’équipe de développement est habilité à effectuer les changements sur le Backlog du Sprint :C’est sa propriété exclusive. C’est aussi l’image visible qui reflète en temps réel le travail quel’équipe de développement compte accomplir durant le Sprint.Suivre l’avancement du SprintA tout moment, l’équipe de développement doit être en mesure d’indiquer le reste à faire total duBacklog du Sprint. Elle traque cette information au moins à chaque mêlée quotidienne. Cela luipermet de déterminer la probabilité d’accomplir le But du Sprint et mieux gérer son avancement.Scrum ne tient pas compte du temps passé sur les éléments du Backlog du Sprint. Il s’intéresseexclusivement au reste à faire37.L’incrémentL’incrément s’obtient en additionnant tous les éléments du Backlog du produit réalisés durant leSprint courant et ceux des Sprints précédents38. A la fin d’un Sprint, le nouvel incrément doit être« Fini ». Ce qui signifie que l’incrément doit être utilisable et satisfaire la définition de « Fini » del’équipe Scrum. L’incrément doit répondre aux conditions d’utilisation indépendamment de ladécision du Product Owner de le déployer ou non en production.Définition de FiniLorsqu’ un élément du Backlog du Produit ou un incrément est considéré comme « Fini », tout lemonde doit avoir la même signification de « Fini ». Cette définition peut varier d’une équipe Scrum àl’autre.Les membres d’une même équipe Scrum doivent tous avoir une compréhension commune de ce quesignifie un travail fini. Cette compréhension commune constitue la définition de « Fini » de l’équipeScrum. L’équipe s’en sert pour vérifier si le travail est réellement achevé.37 Note du traducteur : Souvent dans les projets on a besoin pour des raisons d’imputation budgétaire degarder trace du temps consommé sur les activités. Si c’est le cas dans votre projet, vous pouvez ajouter unattribut au Backlog du Sprint pour stocker le temps consommé.38 Note du traducteur : Il ne s’agit pas d’une addition mathématique. Chaque incrément s’obtient par l’ajout denouvelles fonctionnalités à son prédécesseur.Traduction non officielle -Version 1.0 Avril 2012 Page 16
  17. 17. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comLa définition de Fini permet également à l’équipe de développement (Lors de la réunion deplanification du Sprint) d’avoir en sa possession tous les éléments pouvant l’aider à décider dunombre d’éléments du Backlog du Produit à inclure dans le Sprint39.L’équipe de développement livre un incrément utilisable à l’issue de chaque Sprint. Le ProductOwner peut décider de le déployer en production immédiatement. L’incrément est alors additionnéaux incréments précédents40. L’ensemble est minutieusement testé, afin de garantir que lesincréments fonctionnent ensemble.A mesure que la maturité de l’équipe Scrum augmente, elle peut étendre sa définition de « Fini »pour inclure des critères plus stricts et avoir une qualité meilleure.ConclusionScrum est gratuit et est offert dans ce guide. Les rôles de Scrum, les artefacts, les événements et lesrègles sont immuables. Bien qu’il soit possible de mettre en place des parties de Scrum uniquement,le résultat obtenu n’est pas un processus Scrum. Scrum existe uniquement dans sa globalité. Ilfonctionne bien comme conteneur pour d’autres techniques, méthodologies et pratiques41.39 Note du traducteur : En ayant en tête la définition de Fini l’équipe va considérer toutes les tâches quipermettent de satisfaire cette définition de Fini : Tâches de tests unitaires, déploiement sur lesenvironnements adéquats, guide utilisateurs, etc.40 Note du traducteur : Il ne s’agit pas d’une addition mathématique. Chaque incrément s’accroit par l’ajout denouvelles fonctionnalités à son prédécesseur.41 NDT : Il est fréquent dans des projets Agile d’utiliser Scrum avec des pratiques XP, KANBAN ou LEAN. Lespratiques CMMI ou PMBOK ne sont pas incompatibles non plus.Traduction non officielle -Version 1.0 Avril 2012 Page 17
  18. 18. Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum) Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.comRemerciementsLes personnesParmi les milliers de personnes qui ont contribué à Scrum, nous voudrions distinguer ceux qui ontjoué un rôle dans ses dix premières années. D’abord il y‘avait Jeff Sutherland collaborant avec JeffMcKenna, et Ken Schwaber travaillant avec Mike Smith et Chris Martin. Beaucoup d’autres ontcontribué dans les années qui ont suivi. Sans leur aide, Scrum ne serait pas affiné tel qu’il l’estaujourd’hui. David Starr a fourni des informations clés et des compétences rédactionnelles dans laformulation de cette version du guide Scrum.HistoriqueKen Schwaber et Jeff Sutherland ont coprésenté Scrum pour la première fois lors de la conférenceOOPSLA en 1995. Cette présentation à principalement documenté l’apprentissage que Ken et Jeff ontacquis de l’application de Scrum au cours des années précédentes.Cette histoire de Scrum est déjà considérée comme longue. Pour honorer les premiers endroits oùScrum a été essayé et affiné, nous reconnaissons « Individual », « Inc », « Fidelity Investments » et« IDX » (Actuellement GE Medical).Le guide Scrum documente le framework tel que développé et maintenu pendant plus de vingt anspar Jeff Sutherland et Ken Schwaber. D’autres sources vous fournissent des patterns, des processuset des idées montrant comment des pratiques, des facilitations, et des outils qui complètent leframework Scrum. Ces pratiques permettent d’optimiser la productivité, la valeur, la créativité et lafierté.Traduction non officielle -Version 1.0 Avril 2012 Page 18

×