[Laurent]

Bonjour julien,

Désolé du delais de reponse je vais regardé ce qui à pu se produire si vous n’avez pas eu de chances vous etes peu etre tombé dans un update de la DB qui a empeché la sauvegarde de vos réponses.

[Laurent]

Oui oui tout à fait l’examen SAFe n’est pas sous surveillance vous pouvez donc appliquer des outils de traductions sans contraintes, le site ne le bloque pas.

[Laurent]

Bonjour

Oui c’est tout à fait possible en suivant ce tuto: https://www.scrum.org/support/using-google-translate-chrome-take-assessments

[Laurent]

Bonjour Allan,

Vous pouvez nous contacter à contact@crossthink.fr mais voici vos réponses:

– Safe Agilist existe en anglais ou en français pour l’examen, si vous le choisissez en français vous aurez entre parenthèses la question en anglais aussi.
– Dans votre cursus vous avez plusieurs choses : la certification scrum-league à passer en priorité, la safe agilist et la psm/pspo 😊

N’hesitez pas à nous appeler si vous avez d’autres questions

[Laurent]

Bonjour Laetitia, Pour pmp vu qu’il s’agit d’un examen complexe prenez votre temps pour le preparer afin de le passer dans les meilleures conditions 😉

[Laurent]

Bonjour,

Voici mes feedbacks:

1/ Mise en production d’un incrément durant un sprint : Selon le cadre Scrum, l’incrément de produit doit être potentiellement livrable à la fin de chaque sprint, ce qui signifie qu’il doit répondre à la Definition of Done (DoD) et être de qualité suffisante pour être utilisé par les clients. Cependant, la décision de mettre réellement en production cet incrément est généralement prise par l’entreprise selon sa stratégie de déploiement. Certaines équipes peuvent choisir de déployer après la Sprint Review pour intégrer les feedbacks reçus lors de cette réunion, tandis que d’autres peuvent déployer avant si elles opèrent dans un environnement de déploiement continu. Cela dépend donc des politiques de l’organisation et de l’accord avec les parties prenantes.

2/ Gestion des bugs non prévus durant un sprint : Si un bug est signalé au Product Owner (PO) et n’était pas prévu dans le backlog du sprint, le PO a plusieurs options.
Il peut décider de :
Replanifier : Si le bug est urgent et critique, le PO peut choisir de le faire traiter immédiatement, potentiellement en ajustant ou en replanifiant les autres éléments du sprint si nécessaire. Ceci est souvent fait en consultation avec la Scrum Team pour évaluer l’impact sur le sprint en cours.
Attendre le prochain sprint : Si le bug n’est pas critique, le PO peut décider de l’ajouter au backlog et de le prioriser pour un traitement dans un sprint futur.
Dans les deux cas, la clé est la communication et la collaboration au sein de l’équipe Scrum. Le PO doit équilibrer les besoins immédiats contre les objectifs à long terme et l’impact sur la capacité de l’équipe à livrer les engagements du sprint.
L’ajout de travail au milieu d’un sprint peut perturber la planification et la dynamique de l’équipe, donc une telle décision doit être prise avec prudence et en accord avec les pratiques Agile d’adaptation et de flexibilité, tout en respectant les limites de la capacité de l’équipe.
J’espère que ces explications vous aideront à mieux naviguer ces situations dans vos projets Scrum ! Si vous avez d’autres questions, n’hésitez pas à demander.

[Laurent]

Bonjour julie, je vois qu’arnaud à repondu à votre demande, si besoin n’hesitez pas à me le dire.

Excellente journée

• Cette réponse a été modifiée le il y a 1 année et 4 mois par Laurent.

[Laurent]

De rien désolé du retard de réponse j’étais complètement passé à coté de votre question 😅

[Laurent]

Bonjour,

Pour mieux comprendre ces questions et leurs réponses, je vais vous donner quelques éclaircissements.

Question 1 : L’équipe Scrum est en effet en discussion constante avec le Product Owner (PO) concernant les priorités du backlog produit. Cependant, c’est bien le PO qui a le dernier mot sur ce sujet, car il est responsable de maximiser la valeur du produit et du travail de l’équipe de développement.

La réponse “2- Les contester auprès des parties prenantes” est correcte dans le sens où l’équipe Scrum, en désaccord avec le PO, peut partager ses préoccupations avec les parties prenantes. Cependant, cela ne signifie pas que l’équipe Scrum peut outrepasser le PO et revoir les priorités de manière autonome.

Question 2 : Les objectifs de qualité dans le contexte Scrum correspondent effectivement à la Definition of Done (DoD), mais ils concernent également d’autres aspects qualitatifs du produit. Par exemple, ils pourraient concerner des standards de code, des tests d’acceptation, ou encore la performance du produit.

La réponse “1- il faut maintenir les objectifs de qualité même si l’équipe n’avance pas comme prévu” est correcte car le respect de ces objectifs de qualité est essentiel pour garantir un produit viable et de haute qualité.

La réponse “3- On peut rediscuter Les objectifs de qualité” est également correcte car, dans un contexte Scrum, l’amélioration continue est clé, et cela inclut une réévaluation régulière des objectifs de qualité. Cela se fait généralement lors de la rétrospective, comme vous l’avez bien mentionné, ou à d’autres moments appropriés.

Cependant, il est important de noter que rediscuter des objectifs de qualité ne signifie pas nécessairement les abaisser pour accélérer le développement. Il s’agit plutôt d’identifier des moyens d’améliorer la qualité ou de rendre le processus de développement plus efficace.

[Laurent]

Bonjour,

Concernant le grooming des user stories lors de l’itération planning, même si vous avez plusieurs itérations prêtes d’avance, il est toujours recommandé de consacrer du temps au grooming des user stories pour les itérations à venir. Cela permet de s’assurer que les user stories sont claires, bien comprises et estimées de manière appropriée. Même si les grandes lignes du backlog sont déjà définies, des ajustements et des détails peuvent être nécessaires pour chaque itération spécifique.

Pour ce qui est de la business value des objectifs non attribués (uncommitted objectives), elle n’est normalement pas prise en compte dans le calcul de l’actual business value (BV). L’actual BV est généralement basée sur les user stories qui ont été effectivement terminées et validées lors de l’itération. Cependant, les uncommitted objectives peuvent être pris en compte pour le calcul de l’achievement, qui mesure le pourcentage d’accomplissement des objectifs fixés pour l’itération.

Concernant la rétrospective du PI planning, les sujets abordés peuvent varier en fonction des besoins et des objectifs spécifiques de l’équipe ou de l’ART (Agile Release Train). Cependant, certains sujets courants peuvent inclure l’évaluation des points forts et des points faibles du PI planning lui-même, l’identification des améliorations à apporter pour les futurs PI plannings, l’examen des problèmes ou des obstacles rencontrés pendant le PI, ainsi que la recherche de solutions et la définition des actions à entreprendre pour les résoudre.

La rétrospective du PI planning peut être animée par petits groupes travaillant sur des sujets spécifiques, mais elle peut également impliquer l’ensemble de l’équipe ou de l’ART, en particulier pour les sujets qui nécessitent une discussion collective et une prise de décision commune. Les actions à entreprendre peuvent être portées soit par le groupe de rétrospective lui-même, soit par l’ART dans son ensemble, en fonction de la nature et de l’ampleur des problèmes identifiés.

J’espère que ces réponses vous seront utiles. N’hésitez pas à me solliciter si vous avez d’autres questions !

Cordialement.

[Laurent]

Bonjour Pamela,

Vous pouvez utiliser le quiz suivant : https://crossinstitute.fr/courses/examens-blanc-scrum-league-a-passer-apres-vos-autres-cours

Vous avez de nombreuses questions d’entraînement

[Laurent]

Bonjour Olivier,

Merci pour cette question très pertinente. L’objectif d’une rétrospective de sprint dans la méthodologie Scrum est d’inspecter le sprint qui vient de se terminer et de planifier des améliorations à mettre en œuvre au cours du prochain sprint. Les éléments d’action qui sont identifiés pendant cette rétrospective sont souvent des améliorations de processus ou des tâches qui aideront l’équipe à travailler plus efficacement ou à mieux répondre aux besoins des clients.

Il est vrai que normalement, les éléments du Sprint Backlog sont dérivés du Product Backlog. Cependant, les éléments d’action de la rétrospective représentent une exception à cette règle. Ils ne sont pas vraiment des fonctionnalités du produit, mais plutôt des améliorations du processus de développement. Par conséquent, ils peuvent être ajoutés directement au Sprint Backlog du prochain sprint, sans passer par le Product Backlog.

Ceci dit, il est important de noter que les méthodes agiles, y compris Scrum, sont destinées à être adaptatives et flexibles. Chaque équipe peut adapter ces pratiques à sa situation particulière. Par conséquent, si dans votre contexte, il est plus logique d’ajouter ces éléments d’action au Product Backlog et de les incorporer ensuite dans le Sprint Backlog lors de la planification du sprint, c’est tout à fait acceptable. L’important est de s’assurer que ces améliorations sont prises en compte et mises en œuvre.

En fin de compte, la désynchronisation entre les deux backlogs que vous mentionnez peut être gérée par une bonne communication et coordination au sein de l’équipe. Il est important de garder à l’esprit que le but ultime est l’amélioration continue du processus de développement et de la qualité du produit.

J’espère que cela répond à votre question. N’hésitez pas si vous avez d’autres interrogations.

[Laurent]

Bonjour,

Effectivement, dans la méthodologie Scrum qui est largement utilisée dans le développement de logiciel, le Product Owner (PO) est généralement celui qui gère le Product Backlog de manière autonome. Le Product Backlog est une liste priorisée de fonctionnalités à développer pour le produit, et le PO est responsable de définir et de prioriser ces éléments.

L’équipe de développement, quant à elle, sélectionne du travail à partir du Product Backlog pour le Sprint Backlog lors de la réunion de planification du sprint. Une fois le Sprint Backlog défini, l’équipe de développement gère en effet ce dernier de manière autonome, en déterminant la meilleure manière d’atteindre les objectifs du sprint.

Ainsi, en se basant sur les pratiques Scrum, la réponse à la question du test serait plutôt que la structuration de l’équipe de développement permet de gérer de façon autonome le Sprint Backlog, et non pas le Product Backlog. Cependant, les responsabilités peuvent varier selon les organisations et la méthode de travail adoptée.

En ce qui concerne la deuxième partie de la question, livrer des incréments en s’inspirant des meilleures pratiques UX, cela peut également faire partie des responsabilités de l’équipe de développement, bien que l’UX soit souvent une compétence spécialisée qui peut ne pas être présente au sein de chaque équipe de développement.

La réponse qui est la plus proche du framework est donc la 1 bien qu’elle ne soit pas formidable je vous l’accorde 😊

[Laurent]

Bonjour Marlene,

Le certificat vient de vous être envoyé. Désolé du délais mais nous dépendons des certificateurs qui ont des délais long pour établir les certificats.

[Laurent]

Bonjour Nadine,

Il vous suffit de suivre ce tuto pour pouvoir traduire tout les quizs en français en utilisant directement le plugin Google translate.
https://www.scrum.org/support/using-google-translate-plug-take-assessments

Si vous avez besoin d’aide dites le moi je ferais une rapide visio pour vous aider.

Cdl

[Auteur]

Messages