• 8 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 03/11/2021

Contrôlez le travail de l'équipe Scrum

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Compétences évaluées

  • Contrôlez le travail de l'équipe

Description

À travers ce quiz, continuez à expérimenter différentes situations réelles de la vie d’un Scrum Master.

  • Question 1

    Au démarrage du projet, vous avez aidé votre équipe Scrum à formaliser la définition du “prêt” pour une User Story :

    DÉFINITION DU PRÊT POUR UNE USER STORY
    • Pattern « En tant que… je veux… afin de… » respecté
    • Règles de gestion présentes
    • Maquettes d’écrans présentes
    • Contrat d’interface disponible si web service requis
    • Vue par l’équipe en Product Backlog Grooming
    • Business Value renseignée
    • Complexité inférieure ou égale à 13 points
    • Critères d’acceptation présents

    Votre Product Owner présente lors d’un Sprint Planning une User Story qui ne comporte pas les maquettes d’écrans, car il n’a pas eu le temps de les faire. Il affirme qu’il les donnera à l’équipe en cours de sprint.

    Quels arguments avancez-vous pour le convaincre de ne pas embarquer cette User Story  ?

    Attention, plusieurs réponses sont possibles.
    • Embarquer une User Story dont l’estimation n’est pas fiable met à mal l’engagement de l’équipe 

    • Si l’équipe commence à embarquer une User Story non prête, cela peut devenir une mauvaise habitude

    • L’équipe ne peut pas garantir que la User Story respecte la complexité maximale fixée à 13 points

    • L’équipe s’est fixé une règle de conduite à laquelle elle ne souhaite absolument pas déroger

  • Question 2

    Au démarrage du projet, vous avez aidé votre équipe à formaliser la définition du “terminé” pour une User Story :

    DÉFINITION DU TERMINÉ POUR UNE USER STORY
    • Code comité
    • Normes de codage respectées
    • Revue par les pairs
    • Couverture de code par les tests unitaires > 80%
    • Déployée dans un environnement d'essai
    • Tests de performance passants
    • Documentation à jour
    • Acceptée par le Product Owner

    Pendant une itération, l’équipe fait le constat qu’elle n’arrive pas à respecter la définition du “terminé” car elle n’est pas outillée pour passer certains tests de performance. Quelle action votre équipe doit-elle mener en priorité ?

    • Supprimer les tests de performance passants de la définition du terminé

    • Embarquer dans le prochain sprint une Story pour outiller les tests de performance

    • Reporter à plus tard les tests de performance qui n’ont pas pu être passés

  • Question 3

    Pour faciliter la compréhension du besoin entre votre Product Owner et vos développeurs, vous recommandez l’utilisation du langage Gherkin pour l’écriture des tests de la User Story suivante :

    En tant que responsable des achats, je veux valider toutes les commandes de plus de 100 000 euros afin de vérifier que ces dépenses sont bien légitimes.

    Vous fournissez 3 exemples de tests associés :

    Test 1 : Étant donné que je suis connecté à l’application, lorsque je vais sur la page d’accueil, alors le nombre de commandes à valider apparaît.

    Test 2 : Étant donné la page des commandes, lorsque je clique sur le bouton “Mes commandes à valider”, alors seules les commandes de plus de 100 000 euros restent affichées.

    Test 3 : Étant donné la page d’accueil, lorsque je clique sur “Mon profil”, alors je peux modifier mes informations personnelles et les enregistrer.

    Un seul des 3 tests respecte le format Gherkin. Lequel ?

    • Le test 1

    • Le test 2

    • Le test 3