Scrum Guide FR

Alike license of Creative Commons. Page 2 Suivi de la progression d’un Sprint Incrément 16 La transparence des artéfacts Définition de « terminé Concluslon 17 Remerciements PAGF 3 1 . 16 Historique Traduction 18 Changements entre les guides Scrum de 2011 et 2013 — 19 . rg/ icenses/by-sa/4. O/legalcode and also described summary form at http://creativecommons. org/licenses/by-sa/4. 0/. Page 3 Scrum est un cadre de travail pour le développement et la maintenance de produits complexes. Ce guide définit Scrum; cette définition se compose des rôles, des événements et des artéfacts de Scrum, ainsi que des règles qui les lient. La version originale du Guide Scrum (Scrum Guide) est l’œuvre de Ken Schwaber et Jeff Sutherland, les créateurs de Scrum. Ce guide en est la traduction en français.

Scrum (n) : un cadre de travail ermettant de répondre à des problèmes complexes et 1 ni une méthode de développement de produits; c’est un canevas pour l’application de divers procédés et techniques de développement. Scrum met en évidence refficacité relative des pratiques de gestion et de développement de produit en place, de sorte que ces dernières puissent être améliorées. Scrum se compose de plusieurs éléments que sont l’équipe Scrum et ses rôles associés, les événements, les artéfacts et les règles.

Chaque élément a une raison d’être spécifique qui le rend indispensable à la réussite de l’application de Scrum. Les règles de Scrum sont les modalités qui lient événements, rôles et artéfacts entre eux. Ces règles sont décrites tout au long de ce document. Les différentes tactiques d’utilisation de Scrum, qui sont nombreuses et variées, ne sont pas couvertes par ce document. Théorie de Scrum Scrum se base sur la théorie du contrôle empirique de processus, ou l’emplrisme. L’empirisme soutient que les connaissances proviennent de ‘expérience et d’une prise de décision basée sur des faits connus.

Scrum utilise une approche itérative et incrémentale pour optimiser la prédictibilité et pour contrôler le risque. Trois piliers soutiennent l’implémentation d’un contrôle empirique de processus : la transparence, l’inspection et l’adaptation. in PAGF s 1 importants du processus doivent être visibles à ceux qui sont responsables des retombées. La transparence requiert la définition d’un standard commun pour ces aspects afin que les observateurs partagent une compréhension commune de ce qui est observé. À titre d’exemple :

Un langage commun décrivant le processus doit être partagé par tous les participants ; et, Ceux qui effectuent le travail et ceux qui en acceptent le résultat doivent partager une définition commune de « Terminé b. Les utilisateurs de Scrum doivent fréquemment inspecter les artéfacts Scrum et l’état d’avancement par rapport à un objectif de Sprint (Sprint Goal) afin de détecter les écarts indésirables. La fréquence de ces inspections ne devrait pas gêner le travail en cours. Ces inspections sont bénéfiques lorsqu’elles sont effectuées de manière diligente sur les lieux du travail par les personnes qualifiées.

Si un inspecteur détermine qu’un ou plusieurs aspects du processus dérivent hors des limites acceptables, et que le produit qui en résulte sera inacceptable, le processus ou le matériel utilisé par le processus doit être ajusté. Un ajustement doit être fait dès que possible afin de minimiser tres dérives. PAGF 1 pluridisciplinaires. Les équipes auto-organisées choisissent la meilleure façon d’accomplir leur travail, au lieu d’être dirigées par des personnes externes à l’équipe.

Les équipes pluridisciplinaires ont toutes les compétences nécessaires pour effectuer le travail sans dépendre de personnes ‘appartenant pas à l’équipe. Scrum définit un modèle d’équipe optimisant la flexibilité, la créativité et la productivité. Page 5 Les Équipes Scrum livrent des produits de manière itérative et incrémentale, maximisant ainsi les occasions de rétroaction. Les livraisons incrémentales d’un produit « Terminé » assurent la disponibilité d’une version fonctionnelle et potentiellement utile du produit.

Le Product Owner est responsable de maxlmiser la valeur du produit et du travail de l’équipe de Développement. La façon de jouer ce rôle peut varier grandement selon les entreprises, les Équipes Scrum et les individus. Le Product Owner est la s responsable de gérer le PAGF 7 1 Backlog est visible, transparent, et clair pour tous, et qu’il montre ce sur quoi l’Équpe de Développement travaillera prochainement ; et, S’assurer que l’équipe de Développement comprend adéquatement les items du Product Backlog.

Le Product Owner peut lui-même accomplir les tâches susmentionnées ou les déléguer ? l’Équipe de Développement. Toutefois, le Product Owner demeure responsable de ces dernières. Le Product Owner est une personne, et non un comité. Le Product Owner peut représenter les désirs d’un comité dans le Product Backlog, mais ceux qul eulent changer la priorité d’un du Product Backlog doivent consulter le Product Owner. Afin que le Product Owner réussisse dans sa démarche, tous les intervenants de Pentreprise doivent respecter ses décisions.

Les décisions du Product Owner sont visibles dans le contenu et l’ordonnancement du Product Backlog. Nul n’est permis de demander à l’Équipe de Développement de travailler à partir d’un autre ensemble de besoins, et il n’est pas permis à l’Équipe de Développement de suivre les instructions d’une autre personne. L’Équipe de Développement L’Équipe de Développement est constituée de professionnels qui ivrent à chaque Sprint un incrément « terminé » et potentiellement livrable du produit.

Seuls les membres de l’équipe de Développement créent l’incrément. Les équipes de développement sont structurées et habilitées par l’entreprise à organiser et http://creativecommons. org/licenses/by-sa/4. O/legalcode and also described in summary form at http://creativecommons. org/licenses/by-sa/4. O/. Page 6 Elle est auto-organisée. Nul (même pas le Scrum Master) n’indique à l’équipe de Développement comment transformer les items du Product Backlog en incréments de fonctionnalités potentiellement livrables.

Elle est pluridisciplinaire, avec toutes les compétences nécessaires pour créer un incrément du produit ; Scrum ne reconnait aucun titre aux membres de l’Équipe de Développement autre que celui de développeur, indépendamment du travail effectué par cette personne ; il n’y a pas d’exception à cette règle ; Scrum ne reconnaît pas d’équipes à l’intérieur de l’Équipe de Développement indépendamment des domaines spécifiques qui doivent être couverts tels que l’exécution de tests ou l’an nelle ; il n’y a pas rencontrer des difficultés à livrer un incrément de logiciel en raison de compétences limitées. ?? l’opposé, une équipe de plus de neuf membres implique trop de coordinatlon. Les grandes équipes de développement engendrent des interactions trop complexes pour être gérées efficacement par un processus empirique. À moins qu’ils ne fassent également partie de l’Équipe de Développement, le Scrum Master et le Product Owner ne sont pas pris en compte dans la taille de l’équipe. Le Scrum Master Le Scrum Master est responsable de s’assurer que Scrum est compris et mis en œuvre. Les Scrum Masters remplissent leur rôle en s’assurant que l’Équipe Scrum adhère à la théorie, aux pratiques et aux règles de Scrum.

Le Scrum Master est un leader au service de l’Équipe Scrum. Le Scrum Master aide ceux qui sont externes à l’équipe Scrum à comprendre lesquelles de leurs interactions avec l’Équipe Scrum sont bénéfiques et lesquelles ne le sont pas. Le Scrum Master aide tout le monde ? changer ces interactions pour maximiser la valeur créée par l’Équipe Scrum. Le Scrum Master au service du Product Owner Le Scrum Master sert le Product Owner de plusieurs façons. Ses servlces consistent à : Trouver des techniques de estion efficace du Product Backlog ; Aider l’Équipe Scrum à co cessité d’avoir des items