Cette version HTML du Scrum Guide est un port direct de la version de novembre 2020 disponible sous forme de PDFICI.

But du Guide Scrum

Nous avons développé Scrum au début des années 1990. Nous avons écrit la première version du Guide Scrum en 2010 pour aider les gens du monde entier à comprendre Scrum. Nous avons résolu le Guide depuis lors grâce à de petites mises à jour fonctionnelles.Ensemble, nous le soutenons.

Le guide Scrum contient la définition de Scrum. Chaque élément du cadre sert un objectif spécifique qui est essentiel à la valeur globale et aux résultats obtenus avec Scrum. Changer la conception ou les idées de base de Scrum, en omettant des éléments, ou en ne respectant pas les règles de Scrum, couvre les problèmes et limite les avantages de Scrum, potentiellement même en le rendant inutile.

Nous suivons l’utilisation croissante de Scrum dans un monde toujours plus complexe.Nous sommes honorés de voir que Scrum est adopté dans de nombreux domaines où le travail est essentiellement complexe, au-delà du développement de produits logiciels où le Crum a ses racines. Au fur et à mesure que l’utilisation de Scrum se propage, les développeurs, les chercheurs, les analystes, les scientifiques et d’autres spécialistes font le travail. Nous utilisons le mot « développeurs” dans Scrum non pas pour exclure, mais pour simplifier. Si vous obtenez de la valeur de Scrum, considérez-vous inclus.

Au fur et à mesure que Scrum est utilisé, des modèles, des processus et des informations qui correspondent au framework Crum tel que décrit dans ce document peuvent être trouvés, appliqués et définis. Leur description dépasse le but du Guide Scrum, car ils sont sensibles au contexte et diffèrent largement entre les utilisations de Scrum.De telles tactiques d’utilisation dans le cadre de Scrum varient considérablement et sont décrites ailleurs.

Scrum Definition

Scrum est un framework léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour les problèmes complexes.

En un mot, Scrum nécessite un Scrum Master pour favoriser un environnementoù :

1. Un Product Owner commande le travail pour un problème complexe dans un ProductBacklog.

2. L’équipe Scrum transforme une sélection du travail en Incrément de valeur lors d’un Sprint.

3. L’équipe Scrum et ses parties prenantes inspectent les résultats et s’ajustent pour le prochain Sprint.

4. Répéter

La mêlée est simple. Essayez-le tel quel et déterminez si sa philosophie, sa théorie et sa structure aident à atteindre les objectifs et à créer de la valeur. Le cadre Scrum est volontairement incomplet, ne définissant que les parties requises pour implémenter la théorie Scrum. Scrum est construit sur la base de l’intelligence collective des personnes qui l’utilisent. Plutôt que de fournir aux gens des instructions détaillées, les règles de Scrum guident leurs relations et leurs interactions.

Divers procédés, techniques et méthodes peuvent être employés dans le cadre. Scrum entoure les pratiques existantes ou les rend inutiles. Scrum rend visible l’efficacité relative des techniques actuelles de gestion, d’environnement et de travail, de sorte que des améliorations peuvent être apportées.

La théorie de Scrum

Scrum est fondée sur l’empirisme et le lean thinking. L’empirisme affirme que la connaissance provient de l’expérience et de la prise de décisions basées sur ce qui est observé. Le lean thinking réduit le gaspillage et se concentre sur l’essentiel.

Scrum utilise une approche itérative et incrémentale pour optimiser la prévisibilité et contrôler les risques. Scrum engage des groupes de personnes qui ont toutes les compétences et l’expertise nécessaires pour faire le travail et partager ou acquérir les compétences nécessaires.

Scrum combine quatre événements formels pour l’inspection et l’adaptation au sein d’un événement important, le Sprint. Ces événements fonctionnent parce qu’ils mettent en œuvre les piliers empiriques de la transparence, de l’inspection et de l’adaptation.

Transparence

Le processus et le travail émergents doivent être visibles par ceux qui exécutent le travail ainsi que par ceux qui reçoivent le travail. Avec Scrum, les décisions importantes sont basées sur l’état perçu de ses trois artefacts formels. Les artefacts qui ont une faible transparence peuvent conduire à des décisionsqui diminuent la valeur et augmentent le risque.

La transparence permet l’inspection. L’inspection sans transparence est menaçante et inutile.

Inspection

Les artefacts Scrum et la progression vers les objectifs convenus doivent être inspectés fréquemment et avec diligence afin de détecter des variances ou des problèmes potentiellement indésirables. Pour aider à l’inspection, Scrum fournit une cadencedans la forme de ses cinq événements.

L’inspection permet l’adaptation. L’inspection sans adaptation estconsidéré comme inutile. Les événements Scrum sont conçus pour provoquer le changement.

Adaptation

Si des aspects d’un procédé s’écartent en dehors des limites acceptables ou si le produit d’extraction est inacceptable, le procédé en cours d’application ou les matériaux en cours de production doivent être ajustés. L’ajustement doit être effectuéau plus tôt possible pour minimiser les écarts supplémentaires.

L’adaptation devient plus difficile lorsque les personnes impliquées ne sont pas autonomes ou autogérées. Une équipe Scrum devrait adapter le momentil apprend quelque chose de nouveau par l’inspection.

Valeurs de Scrum

L’utilisation réussie de Scrum dépend du fait que les gens deviennent plus compétents pour vivre cinq valeurs:

Engagement, Concentration, Ouverture, Respect et Courage

L’équipe Scrum s’engage à atteindre ses objectifs et à se soutenir mutuellement. Leur objectif principal est le travail du Sprint pour faire les meilleurs progrès possibles vers ces objectifs. L’équipe Scrum et ses intervenants sont ouverts sur le travail et les défis. Les membres des équipes Scrum se respectent mutuellement pour être des personnes capables et indépendantes, et sont considérés comme tels par les personnes avec lesquelles ils travaillent. Les membres de l’équipe de mêlée ont le courage de faire ce qu’il faut, de travailler sur des problèmes difficiles.

Ces valeurs donnent une orientation à l’équipe Scrum en ce qui concerne son travail, ses actions et son comportement. Les décisions qui sont prises, les mesures prises et la manière dont Scrum est utilisé devraient renforcer ces valeurs, pas les diminuer ou les affaiblir. Les membres de l’équipe Scrum apprennent et explorent les valeurs quils travaillent avec les événements et artefacts Scrum. Lorsque ces valeurs sont incarnées par l’équipe Scrum et les personnes avec lesquelles elles travaillent, les piliers empiriques de la transparence, de l’inspection et de l’adaptation deviennent la confiance dans la construction de la vie.

Équipe de Scrum

L’unité fondamentale de Scrum est une petite équipe de personnes, une équipe de Scrum.L’équipe Scrum se compose d’un Scrum Master, d’un Product Owner et de développeurs. Au sein d’une équipe Scrum, il n’y a pas de sous-équipes ou hierarchies.It est une unité cohésive de professionnels concentrés sur un objectif à la fois, l’objectif du produit.

Les équipes Scrum sont interfonctionnelles, ce qui signifie que les membres ont toutes les compétences nécessaires pour créer de la valeur à chaque Sprint. Ils sont également gérants, ce qui signifie qu’ils décident en interne qui fait quoi, quand et comment.

L’équipe de Scrum est assez petite pour rester agile et assez grande pour accomplir un travail important dans un Sprint, généralement 10 ou moins people.In en général, nous avons constaté que les petites équipes communiquent mieux et sont plus productives. Si les équipes Scrum deviennent trop grandes, elles devraient envisager de s’organiser en plusieurs équipes Scrum cohésives, chacune se concentrant sur le même produit. Par conséquent, ils doivent partager le même Objectif Produit, le même Carnet de commandes et le même Propriétaire de produit.

L’équipe Scrum est responsable de toutes les activités liées aux produits de la collaboration, de la vérification, de la maintenance, de l’exploitation, de l’expérimentation, de la recherche et du développement, et de tout ce qui pourrait être nécessaire. Ils sont structurés et habilités par l’organisation pour gérer leur propre travail. Travailler dans les sprints à un rythme durable améliore la concentration et la cohérence de l’équipe de mêlée.

Toute l’équipe Scrum est responsable de créer une amélioration précieuse et utile à chaque Sprint. Scrum définit trois responsabilités spécifiques au sein de l’équipe Scrum: les développeurs, le Product Owner et le ScrumMaster.

Développeurs

Les développeurs sont les personnes de l’équipe Scrum qui s’engagent à créer n’importe quel aspect d’un Incrément utilisable à chaque Sprint.

Les compétences spécifiques requises par les Développeurs sont souvent larges et variables avec le domaine de travail. Cependant, les Développeurs sont toujours joignables pour:

• Créer un plan pour le Sprint, le Backlog Sprint;

• Inculquer de la qualité en adhérant à une Définition de Done;

• Adapter leur plan chaque jour vers l’Objectif du Sprint; et,

• Se responsabilisant mutuellement en tant que professionnels.

Product Owner

Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de l’équipe Scrum. La façon dont cela est fait peut varier considérablement d’une organisation à l’autre, d’une équipe Scrum à l’autre et d’un individu à l’autre.

Le Product Owner est également responsable de la gestion efficace du Backlog Produit, ce qui comprend :

• Développer et communiquer explicitement l’Objectif du Produit ;

• Créer et communiquer clairement les éléments du Backlog Produit;

• Commander des articles de Carnet de commandes de produits; et,

• S’assurer que le Carnet de commandes de produits est transparent, visible et compris.

Le Propriétaire du produit peut effectuer le travail ci-dessus ou peut déléguer la responsabilité à d’autres. Quoi qu’il en soit, le Propriétaire du produit restecomptable.

Pour que les propriétaires de produits réussissent, l’ensemble de l’organisation doit respecter leurs décisions. Ces décisions sont visibles dans le contenu et la commande de l’arriéré de produits, et par l’incrément inspectable lors de l’examen de l’empreinte.

Le Propriétaire du produit est une personne, pas un comité. Le Product Owner peut représenter les besoins de nombreuses parties prenantes dans le carnet de commandes des produits. Ceux qui souhaitent modifier l’arriéré de produits peuvent le faire en essayant de convaincre le Propriétaire du produit.

Scrum Master

Le Scrum Master est responsable de l’établissement de Scrum tel que défini dans le Guide de Scrum. Ils le font en aidant tout le monde à comprendre la théorie et la pratique de Scrum, à la fois au sein de l’équipe Scrum et de l’organisation.

Le Scrum Master est responsable de l’efficacité de l’équipe Scrum. Ils le font en permettant à l’équipe Scrum d’améliorer ses pratiques, dans le cadre du CRUM.

Les Scrum Masters sont de véritables leaders au service de l’équipe Scrum et de la plus grande organisation.

Le Scrum Master sert l’équipe Scrum de plusieurs façons, y compris:

• Coacher les membres de l’équipe dans l’autogestion et la fonctionnalité croisée;

• Aider l’équipe Scrum à se concentrer sur la création d’incréments à haute valeur qui répondent à la Définition de Done;

• Provoquant la suppression des obstacles à la progression de l’équipe Scrum; et,

• S’assurer que tous les événements Scrum ont lieu et sont positifs, productifs et conservés dans le délai imparti.

Le Scrum Master sert le Product Owner de plusieurs façons, y compris:

• Aider à trouver des techniques pour une définition efficace des objectifs du Produit et une gestion efficace de l’arriéré de produits;

• Aider l’équipe Scrum à comprendre le besoin d’éléments d’arriéré de produits clairs et concises;

• Aider à établir une planification empirique des produits pour un environnement complexe; et,

• Faciliter la collaboration des parties prenantes à la demande ou au besoin.

Le Scrum Master sert l’organisation de plusieurs façons, notamment:

• Diriger, former et accompagner l’organisation dans son option Scrum ;

• Planifier et conseiller les implémentations Scrum au sein de l’organisation;

• Aider les employés et les parties prenantes à comprendre et à adopter une approche empirique pour un travail complexe; et,

• Éliminer les barrières entre les parties prenantes et les équipes Scrum.

Événements Scrum

Le Sprint est un conteneur pour tous les autres événements. Chaque événement dans Scrum est une occasion normale d’inspecter et d’adapter les artefacts de Scrum. Ces événements sont spécifiquement conçus pour permettre la transparence requise. Le fait de ne pas faire fonctionner tous les événements comme prescrit entraîne la perte d’opportunités d’observation et d’adaptation. Les événements sont utilisés dans Scrum pour créer de la régularité et minimiser le besoin de réunions non définies dans Scrum.

De manière optimale, tous les événements ont lieu au même moment et au même endroit pour réduire la complexité.

Le Sprint

Les sprints sont le battement de cœur de Scrum, où les idées sont transformées en valeur.

Ce sont des événements de longueur fixe d’un mois ou moins pour créer une cohérence.Un nouveau Sprint commence immédiatement après la conclusion du précédenTprint.

Tout le travail nécessaire pour atteindre l’Objectif du Produit, y compris la Planification des Sprints, les Mêlées quotidiennes, la Revue des Sprints et la Rétrospective des Sprints, se déroule dans les Sprints.

Pendant le Sprint :

• Aucune modification n’est apportée qui mettrait en danger l’Objectif du Sprint ;

• La qualité ne diminue pas;

• Le Backlog Produit est affiné au besoin ; et,

• La Portée peut être clarifiée et renégociée avec le Propriétaire du Produit au fur et à mesure que l’on en apprend plus.

Les sprints permettent une prévisibilité en assurant l’inspection et l’adaptation des progrès vers un objectif produit au moins tous les mois civils. Lorsque l’horizon d’aSprint est trop long, l’objectif de sprint peut devenir invalide, la complexité peut augmenter et le risque peut augmenter. Des sprints plus courts peuvent être utilisés pour générer plus de cycles d’apprentissage et limiter les risques de coût et d’effort à un laps de temps plus court. Chaque Sprint peut être considéré comme un courtprojet.

Diverses pratiques existent pour prévoir les progrès, comme les burn-down, les burn-ups ou les flux cumulatifs. Bien qu’ils se soient avérés utiles, ceux-ci ne remplacent pas l’importance de l’empirisme. Dans des environnements complexes, ce qui va se passer estinconnu. Seul ce qui s’est déjà passé peut être utilisé pour la prise de décision prospective.

Un Sprint peut être annulé si l’Objectif de Sprint devient obsolète. Seulementle Propriétaire du produit a le pouvoir d’annuler le Sprint.

Planification du Sprint

La Planification du Sprint initie le Sprint en exposant le travail à effectuer pour le Sprint. Ce plan résultant est créé par le travail collaboratif de toute l’équipe Scrum.

Le Product Owner s’assure que les participants sont prêts à discuter des éléments les plus importants du carnet de commandes des produits et de la façon dont ils correspondent à l’objectif du produit. L’équipe Scrum peut également inviter d’autres personnes à assister à SprintPlanning pour fournir des conseils.

La planification du Sprint aborde les sujets suivants :

Premier sujet: Pourquoi ce Sprint est-il précieux?

Le Product Owner propose comment le produit pourrait augmenter sa valeur et sa fonctionnalité dans le Sprint actuel. Toute l’équipe Scrum collabore ensuite pour définir un Objectif de Sprint qui explique pourquoi le Sprint est précieux pour les détenteurs. L’Objectif de Sprint doit être finalisé avant la fin de la planification de l’impression.

Sujet Deux: Que peut-on faire ce Sprint?

Lors d’une discussion avec le Propriétaire du Produit, les Développeurs sélectionnent des éléments du Carnet de commandes du Produit à inclure dans le Sprint en cours. La ScrumTeam peut affiner ces éléments au cours de ce processus, ce qui augmente la compréhension et la confiance.

Il peut être difficile de sélectionner le nombre de points pouvant être complétés dans un Sprint.Cependant, plus les développeurs en savent sur leurs performances passées, leur capacité à venir et leur Définition de Done, plus ils seront confiants dans leurs prévisions de sprint.

Troisième thème: Comment le travail choisi se fera-t-il?

Pour chaque élément de Backlog Produit sélectionné, les Développeurs planifient le travail nécessaire pour créer un Incrément répondant à la définition de Done. Ceci est souvent effectué en décomposant les éléments de l’arriéré de produits en éléments de travail plus petits d’un jour ou moins. Comment cela est fait est à la seule discrétion deles développeurs. Personne d’autre ne leur dit comment transformer les éléments du carnet de commandes en incréments de valeur.

L’Objectif de Sprint, les éléments de Backlog de produits sélectionnés pour le Sprint, ainsi que le plan de livraison sont appelés ensemble le SprintBacklog.

La planification du sprint est limitée à un maximum de huit heures pour une impression d’un mois. Pour les sprints plus courts, l’épreuve est généralement plus courte.

Mêlée quotidienne

Le but de la Mêlée quotidienne est d’inspecter la progression vers le Sprint et d’adapter le Backlog de sprint si nécessaire, en ajustant le travail planifié à venir.

Le Daily Scrum est un événement de 15 minutes pour les développeurs de la ScrumTeam. Pour réduire la complexité, il se tient à la même heure et au même endroit chaque jour de travail du Sprint. Si le Product Owner ou Scrum Master travaille activement sur des éléments du Backlog Sprint, ils participent en tant que développeurs.

Les développeurs peuvent sélectionner la structure et les techniques qu’ils souhaitent, tant que leur mêlée quotidienne se concentre sur la progression vers l’objectif du Sprint et produit un plan exploitable pour le lendemain de travail. Cela crée un focus et améliore l’autogestion.

Les Scrums quotidiens améliorent les communications, identifient les obstacles, favorisent la prise de décisions rapides et, par conséquent, éliminent le besoin d’autres réunions.

Le Scrum quotidien n’est pas le seul moment où les développeurs sont autorisés à ajuster leur plan. Ils se rencontrent souvent tout au long de la journée pour des discussions plus détaillées sur l’adaptation ou la planification du reste du travail du Sprint.

Revue de sprint

Le but de la Revue de Sprint est d’inspecter le résultat du Sprint et de déterminer les adaptations futures. L’équipe Scrum présente les résultats de son travail aux principales parties prenantes et les progrès vers l’objectif du produit sont discutés.

Pendant l’événement, l’équipe Scrum et les parties prenantes examinent ce qui a été accompli dans le Sprint et ce qui a changé dans leur environnement.Sur la base de ces informations, les participants collaborent sur la suite des choses. L’arriéré de produits peut également être ajusté pour répondre à de nouvelles opportunités. L’examen de l’empreinte est une session de travail et l’équipe Scrum doit éviter de la limiter à une présentation.

La Revue de Sprint est l’avant-dernière épreuve du Sprint et est limitée à un maximum de quatre heures pour un Sprint d’un mois. Pour les shorterSprints, l’événement est généralement plus court.

Rétrospective Sprint

Le but de la Rétrospective Sprint est de planifier des moyens d’augmenter la qualité et l’efficacité.

L’équipe Scrum inspecte le déroulement du dernier Sprint en ce qui concerne les individus, les interactions, les processus, les outils et leur définition. Les éléments inspectés varient souvent selon le domaine de travail. Les hypothèses qui les ont égarés sont identifiées et leurs origines explorées. L’équipe de Crum discute de ce qui s’est bien passé pendant le Sprint, des problèmes rencontrés et de la manière dont ces problèmes ont été (ou non) résolus.

L’équipe Scrum identifie les changements les plus utiles pour améliorer son efficacité. Les améliorations les plus percutantes sont abordées dès que possible. Ils peuvent même être ajoutés au Backlog de Sprint pour le nextSprint.

La Rétrospective du Sprint conclut le Sprint. Il est chronométré à un maximum de trois heures pour un sprint d’un mois. Pour les sprints plus courts, l’événement est généralement plus court.

Artefacts Scrum

Les artefacts de Scrum représentent un travail ou une valeur. Ils sont conçus pour maximisetransparence des informations clés. Ainsi, tout le monde les inspectant a la même base d’adaptation.

Chaque artefact contient un engagement à s’assurer qu’il fournit des informations qui améliorent la transparence et la concentration sur lesquelles les progrès peuvent être mesurés:

• Pour le Carnet de commandes du Produit, c’est l’Objectif du Produit.

• Pour le Backlog de Sprint, c’est l’Objectif du Sprint.

• Pour l’incrément, c’est la définition de Done.

Ces engagements existent pour renforcer l’empirisme et les valeurs Scrum pour l’équipe Scrum et leurs parties prenantes.

Backlog produit

Le Backlog produit est une liste émergente et ordonnée de ce qui est nécessaire pour améliorer le produit. C’est la seule source de travail entreprise par l’équipe de Crum.

Les éléments de Backlog de produit pouvant être effectués par l’équipe Scrum dans oneSprint sont réputés prêts à être sélectionnés lors d’un événement de planification de sprint. Ils acquièrent généralement ce degré de transparence après les activités de raffinage.Le raffinement de l’arriéré de produits consiste à décomposer et à affiner les éléments de l’arriéré de produits en éléments plus petits et plus précis. C’est une activité en cours pour ajouter des détails, tels qu’une description, une commande et une taille. Les attributs varient souvent selon le domaine de travail.

Les développeurs qui feront le travail sont responsables de la mise en page. Le Product Owner peut influencer les développeurs en les aidantcomprendre et sélectionner des compromis.

Engagement: Objectif produit

L’Objectif produit décrit un état futur du produit qui peut servir de cible à l’équipe Scrum. L’Objectif du produit est l’Arriéré de produits. Le reste du Carnet de commandes produit émerge pour définir « ce qui » permettra d’atteindre l’Objectif du produit.

Un produit est un véhicule pour fournir de la valeur. Il a une frontière claire, des parties prenantes connues, des utilisateurs ou des clients bien définis. Un produit pourrait être un service, un produit physique ou quelque chose de plus abstrait.

L’objectif produit est l’objectif à long terme de l’équipe Scrum. Ils doivent remplir (ou abandonner) un objectif avant d’en prendre le suivant.

Backlog de sprint

Le Backlog de Sprint est composé de l’Objectif de Sprint (pourquoi), de l’ensemble des éléments de Backlog de produit sélectionnés pour le Sprint (quoi), ainsi que d’un plan réalisable pour la livraison de l’Incrément (comment).

Le Backlog Sprint est un plan par et pour les développeurs. C’est une image hautement visible et en temps réel du travail que les développeurs prévoient d’accomplir pendant le Sprint afin d’atteindre l’objectif du Sprint.Par conséquent, le Backlog de Sprint est mis à jour tout au long du Sprint à mesure qu’il est appris. Il devrait avoir suffisamment de détails pour pouvoir inspecterleurs progrès dans la mêlée quotidienne.

Engagement : Objectif de sprint

L’Objectif de Sprint est l’objectif unique du Sprint. Bien que l’objectif d’impression soit un engagement des développeurs, il offre une flexibilité en termes de travail exact nécessaire pour l’atteindre. L’objectif de Sprint crée également de la cohérence et de la concentration, encourageant l’équipe Scrum à travailler ensemble plutôt que sur des initiatives séparées.

L’Objectif de Sprint est créé pendant l’événement de planification de Sprint, puis ajouté au Backlog de Sprint. Comme les Développeurs travaillent pendant le Sprint, ils gardent l’objectif du Sprint à l’esprit. Si le travail s’avère différent de ce à quoi ils s’attendaient, ils collaborent avec le Product Owner pour négocier la portée du Backlog Sprint dans le Sprint sans affecter l’objectif d’impression.

Incrément

Un incrément est un tremplin concret vers l’objectif du produit. Chaque incrément est additif à tous les incréments antérieurs et soigneusement vérifié, garantissant que tous les incréments fonctionnent ensemble. Afin de fournir une valeur, l’Incrément doit être utilisable.

Plusieurs incréments peuvent être créés dans un Sprint. La somme des incréments est présentée lors de la revue Sprint, soutenant ainsi l’empirisme.Cependant, un incrément peut être remis aux parties prenantes avant la fin du Sprint. L’examen de sprint ne doit jamais être considéré comme une porte pourvaleur à la hausse.

Le travail ne peut pas être considéré comme faisant partie d’un incrément à moins qu’il ne réponde à la définition de Done.

Engagement: Définition de Done

La Définition de Done est une description formelle de l’état de l’Augmentation lorsqu’elle répond aux mesures de qualité requises pour le produit.

Au moment où un élément de Backlog produit répond à la définition de Done, une augmentation est née.

La définition de Done crée la transparence en permettant à chacun de comprendre quel travail a été accompli dans le cadre de l’accroissement. Si un élément de Backlog de produit ne répond pas à la définition deone, il ne peut pas être publié ni même présenté lors de la revue Sprint.Au lieu de cela, il retourne au carnet de commandes du produit pour examen futur.

Si la définition de Done pour un incrément fait partie des standards de l’organisation, toutes les équipes Scrum doivent la suivre au minimum. S’il ne s’agit pas d’une norme organisationnelle, l’équipe Scrum doit créer une définition adaptée au produit.

Les développeurs sont tenus de se conformer à la définition de Done. Si plusieurs équipes Scrum travaillent ensemble sur un produit, elles doivent définir et respecter la même définition de Done.

Note de fin

Scrum est gratuit et offert dans ce guide. Le cadre Scrum, tel que défini ici, est immuable. Bien que n’implémentant que des parties de Scrum ispossible, le résultat n’est pas Scrum. Scrum n’existe que dans son intégralité et fonctionne bien comme conteneur pour d’autres techniques, méthodologies et pratiques.

Remerciements

Personnes

Parmi les milliers de personnes qui ont contribué à Scrum, nous devrions éliminer celles qui ont joué un rôle déterminant au début: Jeff Sutherland a travaillé avec Jeff McKenna et John Scumniotales, et Ken Schwaber a travaillé avec Mike Smith et Chris Martin, et tous ont travaillé ensemble. Beaucoup d’autres ont contribué dans les années qui ont suivi et sans leur aide, Scrum ne serait pas affiné comme il est aujourd’hui.

Histoire du Guide Scrum

Ken Schwaber et Jeff Sutherland ont co-présenté Scrum pour la première fois lors de la conférence OOPSLAConference en 1995. Il a essentiellement documenté l’apprentissage que Ken andJeff a acquis au cours des dernières années et a rendu publique la première définition officielle de Scrum.

Le Guide Scrum documente Scrum tel qu’il a été développé, évolué et soutenu pendant plus de 30 ans par Jeff Sutherland et Ken Schwaber. D’autres sources fournissent des modèles, des processus et des informations qui complètent le framework Scrum.Ceux-ci peuvent augmenter la productivité, la valeur, la créativité et la satisfaction des résultats.

L’historique complet de Scrum est décrit ailleurs. Pour honorer les premiers endroits où il a été essayé et éprouvé, nous reconnaissons Individual Inc., Newspage, Fidelity Investments et IDX (maintenant GE Medical).

© 2020 Ken Schwaber et Jeff Sutherland Cette publication est proposée sous licence sous la licence AttributionShare-Alike de Creative Commons, accessible athttps://creativecommons.org/licenses/by-sa/4.0/legalcode et également décrite sous forme de résumé athttps://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce ScrumGuide, vous reconnaissez et acceptez que vous avez lu et accepté d’être lié par les termes de la licence d’Attribution à l’identique de CreativeCommons.