Guide Nexus™ Le guide ultime de Nexus : L’exosquelette de développement Scrum à grande échelle

Développé et maintenu par Ken Schwaber et Scrum.org Août 2015

Table of Contents Aperçu de Nexus............................................................................................................................. 2 L’objectif du Guide Nexus...............................................................................................................2 Définition de Nexus........................................................................................................................2 Contexte de Nexus .........................................................................................................................2 Le cadre de travail Nexus................................................................................................................3 Le flux de processus Nexus .............................................................................................................4 Pratiques logiciel............................................................................................................................5

Nexus .............................................................................................................................................. 5 Les Rôles Nexus..............................................................................................................................5 L’Équipe d’Intégration Nexus .......................................................................................................5 Les événements Nexus ...................................................................................................................7 Planification de Sprint Nexus........................................................................................................7 Mêlée Quotidienne Nexus ...........................................................................................................7 Revue de Sprint Nexus.................................................................................................................8 Rétrospective de Sprint Nexus......................................................................................................8 Affinage ......................................................................................................................................9

Artefacts Nexus ............................................................................................................................ 10 Backlog de Produit .................................................................................................................... 10 L’Objectif Nexus ........................................................................................................................ 10 Le Backlog de Sprint Nexus ........................................................................................................ 10 Incrément Intégré ..................................................................................................................... 10 Transparence d’Artefacts.............................................................................................................. 10 Définition de “Terminé”............................................................................................................. 11

Notes de fin .................................................................................................................................. 11 Remerciements............................................................................................................................. 11 Notes de traduction ..................................................................................................................... 12 Glossaire des termes de traduction............................................................................................... 12 T RANSLATED BY : Bastien Gallay

Copyright Scrum.org, 2015 All Rights Reserved

Page 1 (Version 1.1)

Aperçu de Nexus L’objectif du Guide Nexus Nexus est un cadre de travail pour développer et maintenir les initiatives de développement logiciel ou de produit à grande échelle. Il utilise Scrum comme base de construction. Ce Guide comprend la définition de Nexus. Cette définition inclut les rôles, événements et artefacts de Nexus, ainsi que les règles qui les relient. Ken Schwaber et Scrum.org ont développé Nexus. Ils écrivent et fournissent ce Guide Nexus.

Définition de Nexus Nexus 1 (n) : Unité de développement (dans Scaled Professionnal Scrum) Nexus est un cadre de travail composé des règles, événements, artefacts et techniques qui permettent de relier et faire converger le travail de trois à neuf Équipes Scrum travaillant sur un Backlog de Produit unique pour construire un Incrément Intégré atteignant un objectif.

Contexte de Nexus Le développement logiciel est complexe et l’intégration de ce travail en un logiciel fonctionnel implique beaucoup d’artefacts et activités devant être coordonnés pour créer un résultat « Terminé ». Le travail doit être organisé, séquencé, les dépendances résolues et les résultats présentés. Le logiciel présente une difficulté particulière étant donné qu’il n’est pas physiquement présent. De nombreux développeurs logiciel ont utilisé le cadre de travail Scrum pour travailler collectivement en équipe afin de développer un Incrément de logiciel fonctionnel. Toutefois, si plus d’une Équipe Scrum travaille sur le même Backlog de Produit et dans la même base de code pour un produit, les difficultés émergent. Si les développeurs d’une même équipe ne sont pas tous colocalisés, comment communiquent-ils lorsqu’ils effectuent un travail qui affectera les autres ? S’ils travaillent dans différentes équipes, comment vont-ils intégrer leur travail et tester l’Incrément Intégré ? Ces défis apparaissent quand deux équipes assurent l’intégration et cela devient significativement plus difficile avec trois équipes ou plus.

NDT : le terme nexus signifie liaison, connexion. Par soucis de cohérence, et s’agissant du nom du cadre de travail lui même, ce terme reste le même que dans la version originale en anglais. 1

Copyright Scrum.org, 2015 All Rights Reserved

Page 2 (Version 1.1)

Beaucoup de dépendances émergent au sein du travail d’équipes multiples qui collaborent afin de créer un Incrément complet et « Terminé » au minimum une fois chaque Sprint. Ces dépendances sont liées : 1. Aux besoins : le périmètre des besoins peut se recouper et la manière de les implémenter peut aussi les affecter de manière croisée. Cette connaissance devrait être prise en compte au moment d’ordonner le Backlog de Produit et lors de la sélection des besoins. 2. A la connaissance du domaine : les personnes dans l’équipes ont différentes connaissances des métiers et des systèmes informatiques. Cette connaissance devrait être établie afin que l’Équipe Scrum assure son niveau de satisfaction et peut aussi minimiser le nombre d’interruptions entre les équipes durant le Sprint. 3. Aux artefacts de logiciels et de tests : les besoins sont ou seront matérialisés dans du code logiciel et des suites de tests. Dans la mesure où les besoins, les connaissances des membres d’équipes et les artefacts de code/test sont établis pour une même Équipe Scrum, les dépendances entre les équipes peuvent être réduites. Lorsqu’un développement logiciel utilisant Scrum passe à grande échelle, ces dépendances de besoins, de domaines de connaissances et d'artefacts logiciel/test sont en mesure de piloter l’organisation d’équipe. Si tel est le cas, la productivité sera optimisée.

Le cadre de travail Nexus Nexus est un exosquelette encadrant les Équipes Scrum multiples qui travaillent ensemble pour créer un Incrément Intégré. Nexus est cohérent avec Scrum et ses composantes seront familières à ceux qui ont déjà travaillé sur des projets Scrum. Il se différencie par l’attention particulière portée aux dépendances et à l’interopérabilité entre les Équipes Scrum, livrant au moins un Incrément Intégré “Terminé” à chaque Sprint. Comme montré dans le graphique suivant, Nexus est constitué de : 





Rôles : un nouveau rôle, l’Équipe d’Intégration Nexus, est introduit pour coordonner, coacher et superviser l’application de Nexus et opérer Scrum afin d’en retirer les meilleurs résultats. L’Équipe d’Intégration Nexus est composée d’un Product Owner, d’un Scrum Master et de Membres de l’Équipe d’Intégration Nexus. Artefacts : toutes les Équipes Scrum utilisent un seul et même Backlog de Produit. Au fur et à mesure que les éléments du Backlog de Produit sont affinés et préparés, des indicateurs favorise la visibilité en permettant de savoir quelle équipe fera le travail au sein d’un Sprint. Un nouvel artefact, le Backlog de Sprint Nexus, est désormais introduit pour aider à la transparence durant le Sprint. Toutes les Équipes Scrum maintiennent leur Backlog de Sprint Individuel. Évènements : les événements sont ajoutés, placés autour ou remplacent (dans le cas de la Revue de Sprint) les événements Scrum pour les compléter. Ainsi modifiés, ils

Copyright Scrum.org, 2015 All Rights Reserved

Page 3 (Version 1.1)

servent à la fois l’effort global de l’Équipe Scrum dans le Nexus et chaque équipe individuelle.

Cadre de travail Nexus™, exosquelette de Scrum à grande échelle

Le flux de processus Nexus Tout travail dans un Nexus peut être effectué par tous les membres des Équipes Scrum, en tant que membres pluridisciplinaires du Nexus. Sur la base des dépendances, les équipes peuvent choisir les membres les plus appropriés pour effectuer un travail spécifique. 





Affiner le Backlog de Produit : le Backlog de Produit doit être décomposé de manière à ce que les dépendances soient identifiées et supprimées ou minimisées. Les éléments du Backlog de Produit sont affinés en tranches de fonctionnalités finement découpés et les équipes à même d’effectuer le travail peuvent être identifiées dès que possible. Planification de Sprint Nexus : les représentants appropriés de chaque Équipe Scrum se rencontrent pour discuter et revoir le Backlog de Produit affiné. Ils sélectionnent les éléments de Backlog de Produit pour chaque équipe. Chaque Équipe Scrum planifie alors son propre Sprint, en interaction avec les autres équipes de manière appropriée. Le résultat est un ensemble d’Objectifs de Sprint alignés avec un Objectif Nexus global, le Backlog de Sprint de chaque Équipe Scrum et un Backlog de Sprint Nexus unique. Le Backlog de Sprint Nexus rend transparents tous les éléments du Backlog de Produit sélectionnés ainsi que toutes dépendances. Travail de développement : toutes les équipes développent le logiciel, intégrant fréquemment leur travail dans un environnement commun qui peut être testé pour assurer que l’intégration est effectuée.

Copyright Scrum.org, 2015 All Rights Reserved

Page 4 (Version 1.1)



 

Mêlée Quotidienne Nexus : les représentants appropriés de chaque Équipe de Développement Scrum se réunissent quotidiennement pour identifier s’il existe un problème d’intégration. Si identifié, l’information est retransmise à la Mêlée quotidienne de l’Équipe Scrum. Les Équipes Scrum utilisent ensuite leur Mêlée Quotidienne pour créer un planning pour la journée, en s’assurant de s’occuper des problèmes d’intégration relevés durant la Mêlée Quotidienne Nexus. Revue de Sprint Nexus : toutes les équipes se rencontrent avec le Product Owner pour revoir l’Incrément Intégré. Les ajustements peuvent être faits au Backlog de Produit. Rétrospective de Sprint Nexus : les représentants appropriés de chaque Équipe Scrum se rencontrent afin d’identifier les défis communs. Ensuite, chaque Équipe Scrum effectuent une Rétrospective de Sprint individuelle. Les représentants appropriés de chaque équipe se rencontrent à nouveau pour discuter des actions nécessaires sur la base des défis communs pour fournir des renseignements ascendants.

Pratiques logiciel Un certain nombre de pratiques de développement logiciel sont nécessaires pour relier le travail des Équipes Scrum collaborant pour créer un Incrément Intégré. La plupart de ces pratiques requièrent de l’automatisation. L’automatisation aide à gérer le volume et la complexité du travail et des artefacts, spécifiquement dans un environnement à grande échelle.

Nexus Les rôles, événements et artefacts découlent des caractéristiques de but et d’intention de leurs rôles, événements et artefacts correspondants documentés dans le Guide Scrum.

Les Rôles Nexus Un Nexus contient une Équipe d’Intégration du Nexus et entre trois à neuf Équipes Scrum.

L’Équipe d’Intégration Nexus L’Équipe d’Intégration du Nexus a la responsabilité de s’assurer qu’un Incrément Intégré (le travail combiné accompli par un Nexus) est produit au minimum à chaque Sprint. Les Équipes Scrum sont responsables du développement d’un Incrément de logiciel potentiellement livrable, tel que prévu en Scrum. Tous les rôles des membres d’une Équipe Scrum sont prévus dans le Scrum Guide. L’Équipe Intégration Nexus est une Équipe Scrum composée :   

Du Product Owner D’un Scrum Master Un ou plusieurs Membres d’Équipe d’Intégration Nexus

Copyright Scrum.org, 2015 All Rights Reserved

Page 5 (Version 1.1)

En cas de nécessité, les membres de l’Équipe d’Intégration Nexus peuvent aussi travailler dans les Équipes Scrum de ce Nexus, si cela s’avère opportun et nécessaire. Si c’est le cas, la priorité doit être donnée au travail de l’Équipe d’Intégration Nexus. Autrement dit, l’appartenance à l’Équipe d’Intégration Nexus prend le pas sur l’appartenance à l’Équipe Scrum individuelle. Cette préférence aide à assurer que le travail pour résoudre les problèmes qui affectent plusieurs équipes est prioritaire. La composition de l’Équipe d’Intégration Nexus peut évoluer pour refléter les besoins actuels du Nexus. Les activités courantes que l’Équipe d’Intégration Nexus pourraient mener incluent le coaching, le conseil et la mise en avant des dépendances et des problèmes inter-équipe. Elle peut également réaliser des travaux issus du Backlog de Produit. L’Équipe d’Intégration Nexus prend possession de tout problème d’intégration. Elle a la responsabilité de l’intégration réussie de tout le travail de toutes les Équipes Scrum dans le Nexus. L’intégration inclut la résolution de toute contrainte inter-équipe, technique ou non, pouvant entraver la capacité du Nexus à livrer un Incrément constamment Intégré. Ils devraient aussi solliciter l’intelligence collective montante du Nexus pour réussir cette résolution. Le Product Owner dans l’Équipe d’Intégration Nexus Un Nexus n’utilise qu’un seul Backlog de Produit et, comme décrit dans le cadre de travail Scrum, un Backlog de Produit n’a qu’un seul Product Owner ayant le dernier mot sur son contenu. Le Product Owner est responsable de la maximisation de la valeur du produit et du travail accompli et intégré par les Équipes Scrum. Le Product Owner est dans l’Équipe d’Intégration Nexus. Le Product Owner est responsable de l’ordonnancement et de l’affinage du Product Backlog afin qu’un maximum de valeur découle des Incréments Intégrés créés par un Nexus. La manière dont ceci est fait peut varier largement selon les organisations, les Nexus, les Équipes Scrum et les individus. Le Scrum Master dans l’Équipe d’Intégration Nexus Le Scrum Master dans l’Équipe d’Intégration Nexus a la responsabilité globale d’assurer que le cadre de travail Nexus est compris et mis en oeuvre. Ce Scrum Master peut aussi être un Scrum Master dans une ou plusieurs autres Équipes Scrum dans ce Nexus. Les Membres de l’Équipe d’Intégration Nexus Le travail de développement à l’échelle requiert des outils et des pratiques que les Équipes Scrum individuelles utilisent fréquemment. L’Équipe d’Intégration Nexus est constituée de professionnels du logiciel qualifiés dans l’utilisation de ces pratiques et outils ainsi que dans le domaine de l’ingénierie système en général. Les Membres de l’Équipe d’Intégration Nexus s’assurent que les pratiques et outils sont implémentés, compris et utilisés pour détecter les dépendances et intégrer fréquemment tous les artefacts dans une définition de “Terminé”. Les Membres de l’Équipe d’Intégration Nexus ont la responsabilité de coacher et guider les Équipes Scrum d’un Nexus pour qu’elles puissent acquérir, implémenter et apprendre ces pratiques et outils. En outre, ils coachent les Équipes Scrum sur les standards de Copyright Scrum.org, 2015 All Rights Reserved

Page 6 (Version 1.1)

développement, d’infrastructure ou d’architecture nécessaires à l’organisation pour assurer le développement d’Incréments Intégrés de qualité. Si leur responsabilité première est assurée, les Membres de l’Équipe d’Intégration Nexus peuvent aussi travailler comme membres d’Équipe de Développement dans une ou plusieurs Équipes Scrum.

Les événements Nexus La durée des événements Nexus est guidée par la durée de l’événement correspondant dans le Guide Scrum. Ce sont des timeboxes supplémentaires par rapport à leur événement correspondants Scrum.

Planification de Sprint Nexus L’objectif de la Planification de Sprint Nexus est de coordonner les activités de toutes les Équipes Scrum dans un Nexus pour un seul Sprint. Le Product Owner apporte la connaissance métier et guide la sélection et les décisions à propos de la priorité. Afin de débuter la Planification de Sprint Nexus, les représentants appropriés de chaque Équipe Scrum valident et ajustent l’ordonnancement du travail tel que créé durant les événements d’Affinage. Tous les membres des Équipes Scrum devraient participer pour minimiser les problèmes de communication. L’Objectif de Sprint Nexus est défini lors de la Planification de Sprint Nexus. Il décrit le but à atteindre par les Équipes Scrum durant le Sprint. Une fois que l’ensemble du travail est compris, chaque Équipe Scrum devra accomplir sa propre Planification de Sprint séparée. Si la réunion est conduite dans un espace colocalisé, les équipes peuvent continuer de partager les nouvelles dépendances trouvées. La Planification de Sprint Nexus est complète quand chaque Équipe Scrum a fini son événement de Planification de Sprint individuelle. De nouvelles dépendances peuvent apparaître durant la Planification de Sprint Nexus. Elles devraient être identifiées et minimisées. La séquence de travail entre les équipes peut aussi être ajustée. Un Backlog de Produit affiné de manière adéquate minimisera l’émergence de nouvelles dépendances durant la Planification de Sprint Nexus. Tous les éléments de Backlog de Produit sélectionnés pour le Sprint ainsi que leurs dépendances devraient être visualisées dans le Backlog de Sprint Nexus. Le Backlog de Produit devrait être suffisamment affiné, avec les dépendances identifiées et éliminées ou minimisées avant la Planification de Sprint Nexus.

Mêlée Quotidienne Nexus La Mêlée Quotidienne Nexus est un événement où les représentants appropriés des Équipes de Développement Scrum individuelles inspectent l’état actuel de l’Incrément Intégré et

Copyright Scrum.org, 2015 All Rights Reserved

Page 7 (Version 1.1)

identifient les nouveaux problèmes d’intégration ou les nouvelles dépendances inter-équipes découvertes. Durant la Mêlée Quotidienne Nexus, les participants devraient se focaliser sur l’impact de chaque équipe sur l’Incrément Intégré et exprimer :   

Le travail du jour précédent a-t-il été intégré avec succès ? Si non, pourquoi ? Quelles nouvelles dépendances ont-elles été identifiées ? Quelles informations nécessitent d’être partagées dans toutes les équipes du Nexus ?

Durant la Mêlée Quotidienne de Nexus, les Backlog de Sprint Nexus devraient être utilisés pour visualiser et gérer les dépendances courantes. Le travail qui est identifié durant la Mêlée Quotidienne Nexus est alors rapporté aux Équipes Scrum individuelles afin qu’elles le planifient dans leur Mêlée Quotidienne.

Revue de Sprint Nexus La Revue de Sprint Nexus est tenue à la fin du Sprint pour récolter du feedback sur l’Incrément Intégré qu’un Nexus a créé au long du Sprint. La Revue de Sprint Nexus remplace la Revue de Sprint individuelle d’une Équipe Scrum car l’Incrément Intégré dans sa totalité est au centre pour récolter le feedback des parties prenantes. Il est parfois impossible de montrer le travail terminé en détail. Des techniques peuvent être utilisées pour maximiser la récolte de feedback des parties prenantes.

Rétrospective de Sprint Nexus La Rétrospective de Sprint Nexus est l’occasion formelle pour un Nexus de se focaliser sur l’inspection et l’adaptation. Il comprend trois parties : 1. La première partie est l’occasion pour les représentants appropriés d’un Nexus de se rencontrer et d’identifier les problèmes qui ont eu un impact sur plus d’une seule équipe. L’objectif est de rendre les problématiques communes transparentes pour toutes les Équipes Scrum. 2. La deuxième partie consiste à tenir, pour chaque Équipe Scrum, leur propre Rétrospective Scrum comme décrite dans le cadre de travail Scrum. Elles peuvent utiliser les problèmes levés dans la première partie de la Rétrospective Nexus comme point d’entrée de leurs propres discussions. Les Équipes Scrum individuelles devraient créer des actions pour s’occuper de ces problèmes durant leur propre Rétrospective de Sprint. 3. La troisième et dernière partie est une opportunité pour les représentants appropriés de chaque Équipe Scrum de se rencontrer une nouvelle fois et de s’accorder sur la manière de rendre visuel et de suivre les actions identifiées. Ceci permet au Nexus dans son ensemble de s’adapter.

Copyright Scrum.org, 2015 All Rights Reserved

Page 8 (Version 1.1)

Parce qu’elles ont des dysfonctionnements de grande échelle en commun, toutes les Rétrospectives devraient s’occuper des sujets suivants :   

Du travail est-il resté inachevé ? Le Nexus a-t-il généré de la dette technique ? Tous les artefacts, en particulier le code, ont-ils été fréquemment (tous les jours) intégrés avec succès ? Le logiciel a-t-il été construit, testé et déployé avec succès assez souvent pour empêcher une accumulation écrasante de dépendances non-résolues ?

Pour les questions ci-dessus, répondez si nécessaire à :   

Pourquoi est-ce arrivé ? Comment la dette technique peut-elle être réduite ? Comment le récurrent peut-il être empêché ?

Affinage A l’échelle de Nexus, il y a de nombreux niveaux d’affinage. Seuls les éléments de Backlog de Produit suffisamment indépendants peuvent être sélectionnés et utilisés sans générer de conflit majeur entre les Équipes Scrum du Nexus. Le nombre, la fréquence, la durée et la présence de la réunion d’Affinage sont basés sur les dépendances héritées du Backlog de Produit. Plus il y a de complexité et de dépendances, plus les éléments de Backlog de Produit doivent être affinés pour supprimer les dépendances. Les éléments du Backlog de Produit passent par différents niveaux de décomposition, depuis les requêtes très larges et vagues, jusqu’au travail actionnable qu’une seule Équipe Scrum pourrait livrer au travers d’un Sprint. L’affinage de Backlog de Produit à grande échelle sert un double objectif. Il prévoit quelle équipe livrera quel élément de Backlog de Produit, et il identifie les dépendances entre ces équipes. Leur visualisation permet aux équipes de surveiller et minimiser les dépendances. La première partie de l’Affinage inter-équipe devrait être passée à décomposer les éléments de Backlog de Produit suffisamment en détail pour comprendre quelle équipe pourrait les livrer et dans quel ordre durant les Sprints à venir. La seconde partie de l’Affinage devrait être dédiée principalement aux dépendances. Les dépendances devraient être identifiées et visualisées au travers des équipes et Sprints. Les Équipes auront besoin de cette information pour ré-ordonner l'enchaînement et la distribution de leur travail afin de minimiser le nombre de dépendances inter-équipes. Un nombre suffisant de réunions d’Affinage ont été effectuées durant un Sprint si les éléments du Backlog de Produit sont prêts et sélectionnables avec le minimum de dépendances durant la réunion de Planification de Sprint.

Copyright Scrum.org, 2015 All Rights Reserved

Page 9 (Version 1.1)

Artefacts Nexus Les artefacts représentent le travail ou la valeur à fournir pour apporter la transparence et les opportunités nécessaires à l’inspection et à l’adaptation, tel que décrit dans le Guide Scrum.

Backlog de Produit Il n’y a qu’un seul Backlog de Produit pour un Nexus entier et toutes ses Équipes Scrum. Le Product Owner est responsable du Backlog de Produit, y compris son contenu, sa disponibilité et son ordre. A grande échelle, le Backlog de Produit doit être compris à un niveau tel que les dépendances peuvent être détectées et minimisées. Pour favoriser cette résolution, les éléments de Backlog de Produit sont souvent déterminés à une granularité appelée fonctionnalité “découpée finement”. Les éléments de Backlog de Produit sont jugés “prêts” pour une Planification de Sprint Nexus quand ils peuvent être sélectionnés pour être terminés par les Équipes Scrum avec aucune ou un minimum de dépendance avec les autres Équipes Scrum.

L’Objectif Nexus Durant la réunion de Planification de Sprint Nexus, un objectif pour l’ensemble du Sprint est formulé. Il est appelé l’Objectif Nexus. C’est la somme de tout le travail et de tous les Objectifs de Sprint des Équipes Scrum au sein du Nexus. Le Nexus devrait faire une démonstration des fonctionnalités qu’ils ont développé pour atteindre l’Objectif Nexus à la Revue de Sprint Nexus.

Le Backlog de Sprint Nexus Un Backlog de Sprint Nexus est la composition de tous les éléments de Backlog de Produit des Backlogs de Sprint des Équipes Scrum individuelles. Il est utilisé pour mettre en valeur les dépendances et le flux de travail durant le Sprint. Il est mis à jour au minimum chaque jour, souvent pendant la Mêlée Quotidienne Nexus.

Incrément Intégré L’Incrément Intégré représente la somme de tous les travaux intégrés et complétés par un Nexus. L’Incrément Intégré doit être utilisable et potentiellement livrable, ce qui veut dire qu’il doit satisfaire la définition de “Terminé”. L’Incrément Intégré est inspecté lors de la Revue de Sprint Nexus.

Transparence d’Artefacts Tout comme Scrum, son bloc de construction, Nexus est basé sur la transparence. Une Équipe d’Intégration Nexus travaille avec les Équipes Scrum, au sein d’un Nexus et de l’organisation,

Copyright Scrum.org, 2015 All Rights Reserved

Page 10 (Version 1.1)

afin de s’assurer que la transparence est visible au travers des artefacts et que l’état d’intégration de chaque Incrément est largement compris. Les décisions faites sur la base de l’état des artefacts Nexus sont seulement aussi efficaces que le niveau de transparence des artefacts. Les informations incomplètes ou partielles mèneront à des décisions incorrectes ou défaillantes. L’impact de ces décisions peut être élargi à l’échelle du Nexus. Un manque complet de transparence rendra impossible la conduite efficace d’un Nexus vers une minimisation des risques et une maximisation de la valeur. Le logiciel doit être développé de manière à ce que les dépendances soient détectées et résolues avant que la dette technique ne devienne inacceptable. La caractéristique d’une dette technique inacceptable est lorsque l’intégration se produit, et qu’il reste incertain que toutes les dépendances soient résolues. Dans ce cas, les dépendances non-résolues restent cachées dans le code et la base de test, réduisant la valeur globale du logiciel.

Définition de “Terminé” L’Équipe d’Intégration Nexus est responsable de la définition de “Terminé” qui pourrait être appliquée à l’Incrément Intégré développé à chaque Sprint. Toutes les Équipes Scrum d’un Nexus adhèrent à cette définition de “Terminé”. L’Incrément est “Terminé” seulement quand il est utilisable et potentiellement livrable par le Product Owner. Un élément de Backlog de Produit peut être considéré comme “Terminé” quand cette fonctionnalité a été ajoutée avec succès au produit et intégrée dans l’Incrément. Toutes les Équipes Scrum sont responsables du développement et de l’intégration de leur travail dans un Incrément qui satisfait ces caractéristiques. Les Équipes Scrum Individuelles peuvent choisir d’appliquer une définition de “Terminé” plus stricte en leur sein, mais ne peuvent pas appliquer de critères moins rigoureux que ceux convenus pour l’Incrément.

Notes de fin Nexus est gratuit et offert dans ce guide. Comme avec le cadre de travail Scrum, les rôles, artefacts, événements et règles Nexus sont immuables. Bien qu’implémenter seulement des parties de Nexus est possible, le résultat n’est pas Nexus.

Remerciements Nexus et Scaled Professional Scrum ont été collaborativement développés par Ken Schwaber, David Dame, Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber et Gunther Verheyen.

Copyright Scrum.org, 2015 All Rights Reserved

Page 11 (Version 1.1)

Ce guide a été traduit de sa version originale en anglais fournie par les développeurs cités cidessus. Les contributeurs de la traduction sont Bastien Gallay, Cédric Bodin, Pascal Menardais, Samuel Cranford, Carole Miguet, Frédéric Duffau et Stéphane Desmets.

Notes de traduction La traduction de ce document Nexus Guide est proposée afin de permettre à tous l’accès au cadre de travail Nexus de Scrum.org. Nous espérons avoir trouvé un juste milieu entre traduction littérale et interprétation, car nous avons essayé de ne pas trahir l’idée d’origine tout en donnant le plus de sens possible aux propos. Afin de rester cohérent la littérature agile francophone, nous avons choisi de ne pas traduire certains termes (par exemple : "Sprint" ou "feedback") Pour leur aide, je remercie en particulier à Claude Aubry, Fabrice Aimetti, Olivier Dugas, Pascal Roy, Vincent Tencé et Ernst Perpignand.

Glossaire des termes de traduction Terme utilisé dans le Guide Nexus original

Terme utilisé dans cette traduction

at scale

à grande échelle

Daily Scrum

Mêlée Quotidienne

Done

Terminé

feedback

feedback

framework

cadre de travail

Increment

Incrément

Integrated Increment

Incrément Intégré

Nexus

Nexus (le terme nexus signifie liaison, connexion. Par soucis de cohérence, et s’agissant du nom du cadre de travail lui même, ce terme reste le même que dans la version originale en anglais)

Nexus Daily Scrum

Mêlée Quotidienne Nexus

Nexus Integration Team

Équipe d’Intégration Nexus

Nexus Process Flow

Flux de Processus Nexus

Copyright Scrum.org, 2015 All Rights Reserved

Page 12 (Version 1.1)

Nexus Sprint Backlog

Backlog de Sprint Nexus

Nexus (Sprint) Goal

Objectif (de Sprint )Nexus

Nexus Sprint Planning

Planification de Sprint Nexus

Nexus (Sprint) Retrospective

Rétrospective (de Sprint) Nexus

Nexus Sprint Review

Revue de Sprint Nexus

Product Backlog

Backlog de Produit

Product Owner

Product Owner

Scrum Development Team

Équipe de Développement Scrum

Scrum Guide

Guide Scrum

Scrum Master

Scrum Master

Sprint Retrospective

Rétrospective de Sprint

Sprint Review

Revue de Sprint

Scrum Team

Équipe Scrum

Sprint

Sprint

Sprint Backlog

Backlog de Sprint

Sprint Goal

Objectif de Sprint

Timeboxes

Timeboxes

Recurrence

Récurrence

Thinly sliced

Décuopé finement

To coach

Coacher

To order

Mettre en ordre

To refine

Affiner

To visualize

Visualiser, rendre visuel

Copyright Scrum.org, 2015 All Rights Reserved

Page 13 (Version 1.1)