Archive | agile RSS feed for this section
Image

le combiné « Guide PMBOK® + Guide pratique des méthodes Agiles » du Project Management Institute est disponible en français

19 Mai

Livres sur Amazon

Afin de soutenir l’éventail de plus en plus large des approches de réalisation de projets, PMI propose un PMBOK® Guide – Sixième édition accompagné du nouveau Guide de pratiques Agiles.

Le PMBOK® guide – Sixième édition contient maintenant des informations détaillées sur Agile; tandis que le Guide de Pratique Agile, créé en partenariat avec Agile Alliance®, sert de passerelle pour connecter méthodes prédictives et agilité. Ensemble, ils constituent un outil puissant pour les managers de projets.

“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.

« une main de fer dans un gant de velours » avec les approches prédictives et Agile selon Christine Rieu, Sylvain Gautier et Marc Burlereaux

3 Mai

soyons WAGILE (W-aterfall + AGILE)

Je reprends un extrait de cet article publié il y a déjà plusieurs années à l’occasion du Forum 2018 des régions du PMI® France, en particulier avec une journée sur Hybridation et bienveillance dans les projets à Sophia Antipolis

L’approche Agile dans les projets de développement de nouveaux produits permet d’assurer plus de souplesse dans la conception itérative, plus de légèreté dans la documentation et dans la formalisation, plus d’interactivité  et d’efficacité dans la conduite de réunions, et surtout plus d’implication du client tout au long du projet. En couplant une approche Lean à ces méthodes Agiles, nous supprimons en plus  toutes les étapes inutiles sans valeur ajoutée pour limiter les gaspillages et maximiser ainsi la valeur attendue du produit.

L’approche Agile semble donc être la panacée !

Mais ce n’est pas simple à réaliser et le chef de projet se posera de nombreuses questions :

  • Comment intégrer ces approches de manière réussie dans des contextes de gestion de projet mature qui sont plus traditionnels avec du développement logiciel en V ou en cascade ?
  • Comment est orchestrée la livraison en production de ces produits développés avec agilité et approche Lean  dans un processus de gestion des livraisons pour la mise en production qui lui apparaît souvent très rigide, et qui se doit de minimiser les risques liés au changement ?
  • Comment ces livraisons s’intègrent-elles dans la gestion des versions (release management), et notamment les procédures de tests (unitaire, intégration et réception des applications), la production de la documentation technique d’exploitation, de la documentation destinée aux utilisateurs et enfin la création des procédures d’installation et de déploiement ?
  • Comment éviter que ces méthodes ne soient qu’un alibi à des comportements laxistes et inefficaces, par exemple en supprimant toute documentation ?

Quel est le meilleur de chaque approche que vous puissiez utiliser sur votre projet ?

La réussite de tels projets passe par un compromis  d’usage entre l’agilité de l’approche globale de développement et la rigueur à conserver dans le processus de livraison. D’où le titre de notre communication: « une main de fer dans un gant de velours ».

Quelle que soit la  méthodologie choisie,  elle doit pouvoir s’inspirer des avantages des autres méthodes existantes.

Citons l’exemple de l’institut PMI® qui est l’autorité en matière de gestion de projets « traditionnelle » ; cet organisme  s’est naturellement  ouvert aux principes d’Agilité en créant récemment une nouvelle certification PMI-ACP® (Agile Certification Practitioner) et en intégrant l’Agilité et le Lean Management dans la gestion de projet plus traditionnelle.

Un aspect important à ajouter dans les méthodologies Agile est la gestion du risque: c’est un exemple de bonnes pratiques dérivant des méthodes traditionnelles qui doit être intégrée dans les approches agiles.

Nous terminons sur un rappel des quatre principes fondateurs du Manifeste pour le développement Agile de logiciels rédigé par Kent Beck et 16 autres signataires qui peuvent être suivis quelle que soit la méthodologie de management de projet employée.

« Ces expériences nous ont amenés à valoriser :

1.    Les individus et leurs interactions plus que les processus et les outils,

2.    Des logiciels opérationnels plus qu’une documentation exhaustive,

3.    La collaboration avec les clients plus que la négociation contractuelle,

4.    L’adaptation au changement plus que le suivi d’un plan.

Nous reconnaissons la valeur des seconds éléments mais privilégions les premiers ».

sans dénigrer les items du côté droit, on favorise ceux à gauche

La démarche Agile doit être envisagée plutôt comme une véritable philosophie de développement

Nous avons voulu rassembler des conseils très pratiques pour dérouler les étapes d’un projet de façon Agile, en nous inspirant de nos expériences sur des contextes projets très variés. Mais nous insistons sur l’importance de comprendre qu’une démarche, quelle qu’elle soit, n’est pas la panacée, si on se contente de l’utiliser comme une « boîte à outils avec check-list intégrée ». La démarche Agile doit être envisagée plutôt comme une véritable philosophie de développement, qui mise sur l’engagement des employés et leur participation. Il faut savoir prendre dans chaque méthode ce qui est « bon pour l’entreprise », sachant que chaque entreprise est unique et a ses propres spécificités de fonctionnement qui en font sa richesse. Face aux méthodes traditionnelles, les méthodes Agiles sont une révolution, mais elles peuvent aussi apporter leur part de lourdeur et de contrainte, selon l’usage que l’on en fait.

L’Agilité c’est bien mais la contrôler c’est mieux

–       L’approche SCRUM n’est pas la panacée, notamment si elle n’est pas accompagnée par le Management et la Maîtrise d’Ouvrage (MOA)

–       L’approche Lean de l’industrie ne peut être transposée dans tous les contextes

–       L’esprit AGILE est avant tout le moteur qui garantira le succès, du Senior Management aux gens de terrain

–       Il faut bien sélectionner les outils AGILEs convenant le mieux à l’entreprise

–       Un coaching pragmatique est un facteur clé de réussite

–       Le dogmatisme doit être jeté aux oubliettes

–       Et il faut contextualiser la démarche qui ne peut être standard pour tous les domaines (de l’industrie spatiale à Google, en passant par l’aéronautique, l’industrie automobile, le secteur bancaire…).

CertYou est partenaire de DantotsuPM

Et l’Agilité mal comprise et mal appliquée pourra causer encore plus de dommage que les méthodes traditionnelles.

Soyons WAGILE ! Contraction de WATERFALL (méthodes de développement traditionnelles) et AGILE … d’où « Agilité une main de fer dans un gant de velours ! »


Si ce sujet vous intéresse, ne manquez pas le Forum 2018 des régions du PMI® France: Hybridation et bienveillance dans les projets (7 PDUs)

Inscriptions en ligne

PMI is a registered mark of Project Management Institute, Inc.

vers l’hybridation : Waterfall + Agile = Un monde en disruption !

24 Avr

Un monde en disruption… par Stéphane Derouin – Ancien Président et Fondateur du PMI France, Président de PMGS.

  • Incertitude, risques et difficulté à gérer la transformation
  • Complexité, (a)synchronie et accélération des temps
  • Primauté de l’innovation
  • Déferlement du Digital qui « rebat les cartes »
  • Nouvelles générations, nouveaux entrants
  • Le Vertical ne répond plus ni aux besoins ni aux attentes : « Servant Leadership »
  • Montée de l’interdépendance, du collaboratif, « monde en réseau »

Waterfall ?

Mode déterministe et planifié – on connaît le périmètre du projet qui est placé sous la responsabilité d’un Project Manager.  Adapté lorsqu’il y un besoin important de contrôle des spécifications et de maîtrise du périmètre du projet

Exemples : projets de pont, d’autoroute, de centrale nucléaire

Relisez ce billet de Serhiy Kharytonov sur le choix entre les méthodes « en cascade », RUP et agile

Agile ?

Mode incrémental et collaboratif. On ne connaît pas le périmètre du projet et il est animé par un Scrum Master. Innovation, R&D, rupture technologique. Adéquation avec les besoins mouvants du projet ou du client

Exemples : jeux vidéo, réseau social, projets digitaux

Agile recouvre un grand nombre de techniques et approches

Les différences majeures entre Waterfall et Agile :

Waterfall

  • Emphase sur les processus
  • Priorisation fixée dans le plan de projet sur les livrables
  • Équipe projet avec un Chef de Projet
  • Client en périphérie – Effet tunnel
  • Management centralisé
  • Management directif et contrôlant

Agile

  • Emphase sur les individus
  • Priorisation basée sur la « business value » et mise à jour régulièrement
  • Équipe projet restreinte auto-gérée avec un Scrum Master
  • Client au cœur du projet
  • Management décentralisé
  • Mode collaboratif et « Servant Leadership »

…et la partition reste encore à composer !


Alors, venez nombreux rencontrer Stéphane et participer à Sophia Antipolis au Forum 2018 des régions du PMI® France Hybridation et bienveillance dans les projets (7 PDUs)

Inscriptions en ligne

PMI is a registered mark of Project Management Institute, Inc.

une check-list simple et concrète pour vérifier si nous faisons vraiment du Scrum ou nous y préparer et améliorer

17 Mar

Faites vous réellement du Scrum ? Are you really doing Scrum? 

Voici une check-list fort utile et déjà très utilisée qui est traduite en de nombreuses langues dont le français !
“We have used it for years” – Jeff Sutherland, co-creator of Scrum

Un petit extrait.

Téléchargez la: Scrum Checklist

CertYou est partenaire de DantotsuPM

Reasons to Adopt AgilePM® whitepaper

10 Mar

Get the whitepaper for free

Why should organizations and project professionals consider AgilePM to support their adoption or improvement of agile project management practices?

AgilePM guidance from the Agile Business Consortium offers a practical and repeatable methodology that achieves an ideal balance between the standards, rigour and visibility required for good project management, and the fast-pace, change and empowerment provided by Agile.

The white paper looks at the reasons why you should consider the AgilePM guidance for effective agile project management.

APMG est partenaire de DantotsuPM

Quels sont vos objectifs de sprint ?

7 Mar

What are your sprint goals?

https://kbondale.wordpress.com/2017/04/02/what-are-your-sprint-goals/par Kiron Bondale

Décomposer les projets en périodes de temps limitées et connues comme les sprints ou itérations est souvent associé aux approches Agiles, mais peuvent aussi être utilisés pour délivrer par rapport à des exigences détaillées sur un projet complet selon l'(infâme) approche prédictive généralement nommée « en cascade ».

L’avantage est que cela aide à focaliser une équipe sur un jeu d’articles de travail petit, réalisable, et donnant aux parties prenantes de fréquentes occasions de réagir sur des lots de travail achevés en augmentant la transparence et l’objectivité des rapports d’avancement.

Les approches Agiles encouragent la priorisation de l’arriéré de travail et cela peut aussi être une bonne pratique en utilisant des sprints sur des projets traditionnels. Mais cette priorisation pourrait ne pas être suffisante de produire le niveau souhaité d’énergie et de focus de l’équipe. Alors, pourquoi ne pas mettre sur l’agenda permanent de l’équipe de définir des objectifs spécifiques à chaque cérémonie de  planification de sprint ?

Les objectifs de sprint peuvent aider en :

  • Fournissant une mesure de progrès allant au-delà de la livraison d’individuels  articles de travail de l’arriéré de produit. Des objectifs de sprint significatifs donnent des événements marquants à célébrer !
  • Donnant de la visibilité aux accomplissements qui dépassent la livraison du contenu planifié. Par exemple, terminer tous les articles de travail du sprint avec zéro défaut. Ou bien, compléter tous les engagements du sprint sans exiger d’heures supplémentaires de la part des membres d’équipe. Voici 2 choses qui méritent d’être célébrées.
  • Aidant l’alignement et le focus de l’équipe de livraison et des parties prenantes principales sur un objectif clairement partagé. Cela peut encourager l’autodiscipline dans l’équipe qui peut utiliser l’objectif de sprint comme un déterminant clé pour déterminer si un nouvel élément de travail proposé mérite ou pas d’entrer dans l’arriéré de sprint.

CertYou est partenaire de DantotsuPM

Les objectifs de sprint ne devraient pas être dictés, ils devraient plutôt émerger de la méthode globale de travail collectif de l’équipe et sont un bon contrôle de si l’équipe est alignée sur la vision complète du projet.

En définissant des buts, l’habituel acronyme SMART (Spécifique, Mesurable, Réalisable, Approprié et Temporel) peut être utilisé pour les évaluer et les affiner.

À la fin d’un sprint, la démonstration devrait inclure une présentation des objectifs et si vraiment ils ont été atteints et la cérémonie de rétrospective de l’équipe devrait inclure leur examen et l’identification d’idées d’objectifs pour améliorer les sprints futurs.

Comme l’a dit Albert Einstein: “si vous voulez vivre une vie heureuse, liez-la à un but, pas aux gens ni aux choses.”

 

Selon Lyssa Adkins, les coach Agile doivent pouvoir enseigner l’approche Agile à leurs équipes en moins de 10 minutes ! Voici ce qu’elle suggère de dire (en anglais).

fausses idées sur l’arriéré de produit (Product Backlog)

13 Fév

L’Arriéré de Produit n’est pas une liste géante d’histoires utilisateurs

Misconceptions about the Product Backlog

http://www.extremeuncertainty.com/misconceptions-product-backlog/  par leontranter

Il y a beaucoup de fausses idées sur l’Arriéré de Produit. En fait, je dirais que c’est probablement l’artefact le moins bien compris de Scrum. Et cela peut causer de gros problèmes, pas seulement pour votre produit et son planning, mais pour vos développeurs également. Étant un propriétaire de produit et manager cette chose est un travail difficile et il est facile se tromper. Cet article dissipera certaines des fausses idées sur l’arriéré de produit.

L’Arriéré de Produit n’est pas une liste géante d’histoires utilisateurs

Beaucoup de gens pense que l’arriéré de produit est essentiellement une grande liste d’histoires d’utilisateurs, classées de la plus haute à la plus faible priorité. Comme si vous aviez un grand tableau et chaque ligne dans le tableau était une histoire d’utilisateur, avec un identificateur, un nom et une description et c’est votre arriéré.

Cela semble agréable et simple, mais c’est un arriéré de produit épouvantable, pour nombre de raisons :

  • Les histoires ne sont reliées l’une à l’autre d’aucune façon significative
  • Il n’y a aucune dépendance entre les histoires
  • Les histoires sont non seulement sans rapport l’une avec l’autre mais elles ne sont liées à aucun horizon particulier ou version
  • Il n’y a aucune explication “de l’image plus grande” sur comment les histoires touchent au produit, ses fonctions et sa vision.

Un arriéré de produit est vraiment une feuille de route

Un bon arriéré de produit commence par une feuille de route, qui est une vue très de haut niveau de l’avenir du produit. Il y a évidemment beaucoup de choses que nous ne savons pas au commencement, mais un propriétaire de produit devrait commencer par une feuille de route et une vision de comment le produit pourrait se développer puis commencer à décomposer ce plan en des fonctionnalités ou des épopées et des versions ou des horizons.

roadmap to success...

Il s’agit d’une feuille de route

Cela vous permet de :

  • Rapprocher des histoires l’une de l’autre, via une fonction ou une épopée
  • Donner les dépendances entre histoires
  • Définir les fonctionnalités et épopées et quelle valeur elles fournissent et pourquoi vous les construisez.

Les fonctionnalités et épopées peuvent entrer dans l’arriéré. Et elles peuvent avoir leur propre description avec valeur, risque, bénéfices, dépendances et critères d’acceptation définis. Elles peuvent être évaluées et priorisées. Tout cela fournit “l’image plus grande”, la « big picture ». Si vous avez juste une liste d’histoires, comme quelqu’un l’a une fois dit, vous avez “un sac de feuilles, au lieu d’un arbre”.

Un arriéré de produit devrait être un arbre, pas un sac de feuilles

Donc vous voulez vraiment des histoires dans votre arriéré, mais vous voulez d’autres choses aussi. Et vous voulez que les histoires découlent de ces autres choses. Les histoires entrent en dernier, pas en premier.

arbre de la connaissanceAinsi, si vous voulez un arbre :

  • Débutez avec une vision de produit et une feuille de route
  • Décomposez-les en fonctionnalités et épopées
  • Dressez la carte des fonctionnalités et des épopées sur des horizons ou des versions
  • Décomposez -les alors en histoires d’utilisateur.

C’est un grand sujet et qui mérite beaucoup plus de couverture. Je recommanderais que vous lisiez User Story Mapping par Jeff Patton si vous voulez en savoir davantage.

Vous n’avez pas besoin d’évaluer toutes les histoires de l’arriéré

Certaines personnes pensent que vous devez avoir des évaluations sur tout dans l’arriéré, parce qu’autrement les items ne sont pas prêts à être travaillés. C’est-à-dire, ils ne respectent pas votre définition de « Prêts » (Ready). Et avoir quelques histoires prêtes à engager est bon, vous n’avez pas besoin que tout l’arriéré soit prêt à être entrepris. Le fait est que certaines des choses dans l’arriéré pourraient ne pas être travaillées avant une longue période de temps. Certaines d’entre elles pourraient ne jamais être développées. Et c’est OK.

Souvenez-vous, votre arriéré est fondamentalement superflu. Pour être plus spécifique, c’est le gâchis de type « Inventaire » en Lean. C’est une pile de choses qui restent là à attendre. Sans faire quoi que ce soit, sans allant où que soit, sans ajouter aucune valeur. Vous pouvez dépenser beaucoup de temps à construire, définir et évaluer un énorme arriéré de choses. Ou vous pouvez dépenser ce temps à faire en réalité du travail. C’est-à-dire à construire un logiciel.

Trouvez le bon équilibre

balance temps vs ressourcesIl existe un bon équilibre et le trouver n’est pas aisé. Si vous n’évaluez rien, vous ne savez pas combien de temps il faudra pour construire quoi que ce soit. Si vous évaluez tout, c’est beaucoup de travail. Je pense qu’il est bon d’utiliser un système « n+1 » ou « n+2”, où vous avez le prochain ou les 2 sprints suivants de travail bien défini et évalué et prêt à entreprendre. Ainsi, si vous entrez dans la planification de sprint, vous pouvez avoir une vue d’où vous allez vous rendre. Et si les choses changent et que vous décidez de prendre quelque chose d’autre dans l’arriéré qui est un peu plus loin, vous pouvez aussi le faire. Mais vous ne dépensez pas 90 % de votre temps en planification et estimations.

Mais comment faisons-nous la planification d’une version si nous n’avons pas évalué les histoires ?

Les gens se bloquent sur ce point, mais c’est très simple. Vous pouvez simplement utiliser des moyennes. Donc, vous avez les un ou deux sprints d’histoires évaluées et pour le reste de votre arriéré, vous pouvez juste utiliser des points d’histoire médians (pour cette équipe) pour chaque histoire. Si vous avez 50 points d’histoires dans vos deux sprints suivants, avec une moyenne de 6.2 points (ce ne sera probablement pas un nombre de Fibonacci). Vous avez 30 autres histoires dans votre arriéré. Donc votre taille d’arriéré de produit est de 186 (6.2 fois 30) plus 50 (vos sprints évalués) pour un total de 236. Vu ? Facile.

La vérité est, quelques histoires s’avéreront être plus grandes que la moyenne et certaines s’avéreront être plus petites et c’est OK. Parfois votre vitesse sera plus élevée, parfois plus lente et c’est OK. Si vous le pouvez, essayez de faire décomposer les histoires en tailles semblables, proches des 5 ou 8. Cela rend l’affaire plus simple et plus précise. Vous pouvez même faire des estimations approximatives pour des fonctionnalités où vous n’avez pas décomposer les histoires, avec des évaluations de niveau de fonctionnalité, ou en utilisant un nombre moyen d’histoires par fonctionnalité et en multipliant le tout.

Souvenez-vous, l’estimation n’est pas porteuse de tant de valeur en premier lieu. N’y investissez pas trop de temps. Parce que les incertitudes sur les bénéfices sont plus fortes que les incertitudes sur les dépenses.

Vous ne devriez pas mettre chaque idée à laquelle vous pouvez penser dans l’arriéré

Certains propriétaires de produit se lâchent un peu trop quand ils passent sur Agile et disent “Super, je peux mettre tout ce que je veux ici ! Étonnant !”. Et passer les 20 jours suivants à bourrer l’arriéré de plein de particules et des pièces aléatoires, comme des gosses dans une confiserie.

Ce n’est pas une bonne pratique. Souvenez-vous, les articles dans l’arriéré sont une forme de gâchis. Vous voulez une feuille de route claire et une vision pour votre produit, pas une grande liste aléatoire de blanchisserie “de choses qui pourraient être sympas”. L’arriéré devrait refléter votre vision et stratégie pour le produit. Il devrait être capable de prendre en compte des changements, mais ne l’exagérez pas et surinvestissez pas. Concentrez-vous sur votre sprint actuel et paire suivante de sprints. Essayer de penser beaucoup plus loin que cela est de la pure spéculation et n’apporte pas de valeur.

CertYou est partenaire de DantotsuPM

Vous pouvez aussi totalement enlever des choses de l’arriéré

Des personnes pensent qu’une fois que quelque chose entre à l’arriéré, il ne peut jamais en ressortir. Ils pourraient penser “quel serait le point d’ôter quelque chose de l’arriéré ? C’est juste une idée, c’est juste un item de contenu potentiel. Nous pourrions ne jamais le construire, mais il n’y a aucun mal à le garder là”. Il y en a, c’est du superflu. Il introduit de la confusion embrouille les choses. De nouveau, l’arriéré n’est pas une liste de blanchisserie, c’est une feuille de route des fonctionnalités par version et qui reflète une vision et une stratégie de produit. Tenez-le fermement et propre et à jour. N’ayez peur de supprimer des choses. Si vous voulez vraiment y revenir plus tard, vous pourrez probablement la déterrer ou y bien réfléchir de nouveau (les choses peuvent avoir changé et reprendre le besoin pourrait ne pas être une mauvaise chose de toute façon).

Les développeurs devraient avoir voix au chapitre dans l’arriéré de produit

Certains pensent que l’arriéré de produit est exclusivement le domaine du propriétaire de produit. Et c’est partiellement vrai, mais pas tout à fait. Le propriétaire de produit dit ce qui y entre et dans quel ordre. Il est responsable de l’arriéré de produit. Et généralement, les développeurs s’occupent de l’arriéré de sprint, puisque c’est leur domaine. Ils construisent la portée qui entre dans le sprint. Mais un propriétaire de produit avisé parle toujours à l’équipe comme il construit et manage l’arriéré.

Les développeurs comprennent de domaine technique du produit. Ils comprennent ce sur quoi d’autres équipes travaillent et quelles nouvelles technologies arrivent (au minimum, ils le devraient). Ils comprennent les risques techniques et les dépendances dans le travail. Donc la discussion sur l’arriéré de produit avec eux est extrêmement importante.

La planification de sprint devrait être un environnement “sans aucune surprise”. Personne ne devrait lever la main en lisant un article de l’arriéré et dire “qu’est-ce diable que cela ? Je n’ai même aucune idée de ce que cela signifie ». La planification de sprint devrait être le choix final de quels articles de portée bien définis et compris de l’équipe prêts pour entrer dans le sprint.

J’espère que cet article effacera quelques fausses idées sur l’arriéré de produit! C’est un sujet important, difficile et il existe beaucoup de lectures que vous pouvez faire si vous êtes intéressés par ce sujet.

Rencontres sur le management de projets – 26 Février au 4 Mars

12 Fév

Les 3 rendez-vous sur le management de projets et le leadership que je vous conseille pour cette période auront lieu pour le premier sur le web le lundi 26 sur la gouvernance dans un monde Agile et pour le second le mercredi 28 Février à Grasse sur le Design Thinking et le troisième à Genève sur les business analystes.

Lundi 26

How can executives and managers effectively contribute to an Agile business change, and even more importantly, should they? Or do they just leave it to a subject matter expert like a product owner, or someone similar, to make all the decisions for their organisation? Are concepts like strategic alignment, business justification, and benefits realisation even relevant in an Agile world, or is everything important just captured in a list of functions and features like a backlog? Are Agile practices only for the systems development team, or is there more involved to successful dynamic business change?

APMG est partenaire de DantotsuPM

Mercredi 28

Comment être plus ‘créatif’ ? Comment voir les choses autrement ? Un arsenal de méthodes, allant des ‘brainstormings’ aux bacs à sable ou au Lego sont là pour nous aider. Le Design Thinking tente d’allier le cerveau droit et le cerveau gauche.

SMPP est Partenaire de DantotsuPM – Référentiel SMPP gratuit !

Le Guide Nexus : L’exosquelette de développement Scrum à grande échelle !

9 Fév

NexusTM Guide

https://www.scrum.org/resources/online-nexus-guide

Nexus est une structure pour développer et supporter des initiatives de développement de logiciel avec Scrum à grande échelle.  Il utilise Scrum comme sa composante de base.  Ce guide contient la définition de Nexus qui consiste en des rôles Nexus, des événements, des artefacts et les règles qui les lient ensemble.  Ken Schwaber et Scrum.org ont développé Nexus et ce guide qui a été traduit en français.

Nexus (n) : Unité de développement (dans « Scaled Professional Scrum »)

Nexus est une structure composée de rôles, événements, artefacts et techniques qui lient et tissent ensemble le travail de trois à neuf Équipes Scrum travaillant sur un même et unique Arriéré de Produit pour construire un Incrément Intégré qui atteint un objectif précis.

Contexte de Nexus

Récupérez gratuitement ce document disponible en français et de nombreuses autres langues.

Le développement logiciel est complexe. L’intégration de ce travail en une application logicielle qui fonctionne contient beaucoup d’artefacts et d’activités qui doivent être coordonnées pour créer un résultat « Fait ». Le travail doit être organisé, séquencé, les dépendances résolues et les résultats organisés. Le logiciel présente des difficultés complémentaires par rapport à d’autres produits puisqu’il n’est pas physiquement présent.

Beaucoup de développeurs de logiciels ont utilisé la structure Scrum pour travailler collectivement comme une équipe pour développer un Incrément de logiciel qui fonctionne. Cependant, si plus d’une Équipe Scrum travaille sur le même Arriéré de Produit et dans le même code source pour un produit, les difficultés surgissent. Si les développeurs ne sont pas dans une même équipe géographiquement colocalisée, comment communiqueront-ils quand ils font un travail qui peut impacter les autres ? S’ils travaillent dans des équipes différentes, comment intégreront-ils leurs livrables et évalueront-ils l’Incrément Intégré ?

Ces défis apparaissent dès que deux équipes sont en jeu et deviennent significativement plus difficiles avec trois ou davantage d’équipes.

Il y a de nombreuses dépendances qui surgissent dans le travail entre des équipes multiples qui collaborent pour créer un incrément complet et « Fait » dans chaque Sprint.

Ces dépendances sont liées aux :

  1. Exigences : La portée des exigences peut se chevaucher et la façon dans laquelle elles sont mises en œuvre peut aussi les impacter les unes les autres.  Cette connaissance devrait être prise en compte dans l’ordonnancement de l’Arriéré de Produit et le choix des exigences sur lesquelles travailler.
  2. Connaissances de domaine : Les personnes dans les équipes possèdent la connaissance de divers systèmes informatiques. Cette connaissance devrait être reportée sur la carte des équipes Scrum pour s’assurer de son adéquation et réduire au minimum les interruptions et passage de relais entre les équipes pendant un Sprint.
  3. Logiciels et artefacts de tests : Les exigences sont ou seront instanciées dans le code de logiciel et des jeux de test.

En fonction des exigences, la connaissance des membres d’équipe, les artefacts de code et de test et leur alignement sur les équipes Scrum en présence peut permettre de réduire la dépendance entre ces équipes.

Quand le développement de logiciel utilise Scrum à grande échelle, ces dépendances entre les exigences, la connaissance de domaine et les artefacts de logiciel/test devraient diriger l’organisation d’équipe. Dans la mesure où ceci est réalisé, la productivité sera optimisée.

CertYou est partenaire de DantotsuPM

Image

l’Agilité est l’alignement à l’intérieur des personnes, pas physiquement ou géographiquement

28 Jan

%d blogueurs aiment cette page :