QCM : Scrum : rôles et fonctionnement (46 questions)

Explication

ISO 10006 décrit un processus unique d’activités coordonnées et maîtrisées, avec un début, une fin et des exigences notamment de délais, de coûts et de ressources. La formulation d’« entreprise temporaire » relève du PMI, tandis que les activités récurrentes relèvent des opérations.

Explication

Le PMI définit le projet comme une entreprise temporaire initiée pour fournir un produit, un service ou un résultat unique. La coordination de plusieurs projets caractérise un programme, et leur alignement stratégique relève du portefeuille.

Explication

Un programme coordonne plusieurs projets liés ainsi que leurs interdépendances, leurs ressources et leurs budgets. Un projet livre un résultat sous contraintes, tandis qu’un portefeuille sélectionne et aligne les projets sur la stratégie et la valeur business.

Explication

L’approche classique planifie en détail au départ puis exécute le projet phase par phase. L’adaptation par itérations courtes caractérise l’agile, tandis que l’hybride combine les deux approches selon le contexte.

Explication

Le chemin critique est le chemin le plus long du réseau de tâches et fixe la durée minimale du projet. Le nombre de tâches ou de dépendances, pris isolément, ne définit pas le chemin critique.

Explication

Les principes agiles prévoient une réflexion périodique sur les moyens de devenir plus efficace. La livraison régulière, l'adaptation au changement et la collaboration avec le client sont des principes distincts.

Explication

Le Manifeste agile valorise davantage la réponse au changement que le suivi d'un plan. Les autres choix inversent cette valeur ou confondent avec d'autres paires du Manifeste.

Explication

Le taux de succès est de 39 % pour l'agile et de 11 % pour l'approche traditionnelle, soit un écart de 28 points. Les valeurs 52 % et 60 % correspondent aux résultats mitigés; 9 % et 29 % sont les taux d'échec.

Explication

En Scrum, le délai et le coût sont fixes, tandis que le périmètre des fonctionnalités livrées varie. Le périmètre fixe caractérise plutôt l'approche classique.

Explication

Le diagramme de Gantt suit les heures ou les jours réalisés même si le produit n'est pas livré. Le burndown chart, lui, ne compte que le travail effectivement livré.

Explication

Scrum organise le développement par cycles fixes appelés sprints, au cours desquels une équipe pluridisciplinaire réalise le produit de manière itérative et incrémentale. La livraison finale confond Scrum avec une progression classique, tandis que les cycles variables et le travail individuel contredisent la définition du cadre.

Explication

Le thème central de Scrum consiste à inspecter puis adapter de façon répétée. La visibilité des indicateurs relève de la transparence, le suivi régulier de l’inspection, et une planification définitive ne correspond pas à une boucle d’ajustement.

Explication

Les trois piliers sont la transparence des indicateurs, l’inspection régulière de l’avancement et l’adaptation destinée à minimiser les déviations futures. La planification et l’assignation ne remplacent pas ces piliers, et la stabilité ou la spécialisation ne constituent pas le troisième pilier.

Explication

Le Product Owner porte la vision du produit, cherche à maximiser sa valeur et son ROI, et crée, priorise et affine le product backlog. La répartition des tâches et le choix de la méthode de réalisation relèvent mal du rôle de l’équipe, tandis que la facilitation et la suppression des obstacles sont du ressort du Scrum Master.

Explication

Le Product Owner peut accepter ou refuser le travail en revue et décide des priorités, mais l’équipe choisit la quantité de travail qu’elle prend pour le sprint. Le Scrum Master soutient l’équipe plutôt que de lui attribuer le travail, et les parties prenantes ne déterminent pas cette quantité.

Explication

L’équipe de développement est pluridisciplinaire et auto-organisée : elle choisit les éléments du sprint ainsi que la manière de les réaliser. Le Product Owner établit les priorités, tandis que le Scrum Master aide l’équipe sans lui assigner les tâches.

Explication

Le Scrum Master aide l’équipe, le Product Owner et l’organisation à apprendre et appliquer Scrum; il supprime les obstacles, protège l’équipe des interférences et facilite les réunions. Les priorités et le backlog relèvent du Product Owner, le choix du travail de l’équipe, et l’acceptation en revue revient au Product Owner.

Explication

Un sprint dure au maximum un mois, conserve une durée constante et s’enchaîne sans pause avec le suivant. Cinq semaines dépassent la limite, une interruption rompt l’enchaînement et une durée variable contredit la régularité requise.

Explication

La première partie porte sur le quoi : le Product Owner présente les priorités et le but du sprint est fixé. La seconde porte sur le comment : l’équipe décompose le travail en tâches pour créer le sprint backlog ; inverser les parties, confier la décomposition au Product Owner ou au sprint backlog un rôle de définition du but confond les étapes.

Explication

Le daily scrum synchronise l’équipe en examinant le travail d’hier, celui prévu aujourd’hui et les obstacles. Un compte rendu au manager, les préférences du client ou les décisions du Product Owner ne remplacent pas ces trois questions.

Explication

La sprint review inspecte et adapte le produit en manipulant l’incrément et en échangeant avec les parties prenantes ; la rétrospective porte sur le processus de travail. Inverser ces cibles, confondre la review avec la planification ou avec le daily scrum attribue à ces événements un rôle différent.

Explication

Le product backlog rassemble et ordonne tout ce qui peut être fait pour un produit ; il est unique par produit, évolue au fil du projet et relève du Product Owner. Le sprint backlog concerne le sprint, l’équipe le crée, et la charte de projet remplit une autre fonction.

Explication

Un backlog émergent évolue en continu : des éléments peuvent être ajoutés, supprimés, découpés ou repriorisés. L’estimation concerne l’évaluation des éléments, la priorisation leur ordre, et le niveau de détail varie selon leur proximité.

Explication

Le sprint backlog réunit les éléments retenus pour le sprint et leur décomposition en tâches, et l’équipe le crée. Le product backlog concerne l’ensemble du produit, tandis que la Definition of Done précise les conditions de fin.

Explication

La Definition of Ready vérifie qu’une User Story est prête à entrer dans un sprint, notamment au moyen de sa clarté, de sa priorité, de ses dépendances et de son estimation. La Definition of Done vérifie qu’un élément est terminé ; les deux backlogs sont des artefacts distincts, pas des définitions de readiness.

Explication

Une User Story exprime en langage naturel une demande fonctionnelle d’un utilisateur et apporte une valeur business au produit. Une spécification d’architecture est technique, une tâche interne n’exprime pas nécessairement une demande utilisateur, et un objectif de projet est plus général.

Explication

Dans le format d’une User Story, « Afin de » exprime le bénéfice métier découlant du besoin. « Le réparateur » relève du rôle, « consulter l’historique » du besoin, et une condition vérifiable appartient aux critères d’acceptation.

Explication

Le critère Small exige qu’une User Story soit suffisamment petite pour être réalisée en un sprint. L’indépendance concerne les dépendances, l’estimabilité la possibilité d’évaluer l’effort et la négociabilité la discussion entre acteurs.

Explication

La priorisation repose sur le couple valeur-effort, afin de commencer par les éléments importants et les plus faciles à réaliser. La valeur ou l’effort pris isolément ne constitue pas le principe décrit, et l’ordre d’arrivée ne prend pas en compte ces deux critères.

Explication

Une attente de base provoque une forte insatisfaction lorsqu’elle est absente, tandis que sa présence paraît normale. Une attente proportionnelle accroît la satisfaction selon son niveau, une attente attractive enthousiasme lorsqu’elle est présente, et une fonction indifférente a peu d’effet sur la satisfaction.

Explication

Should désigne un élément important pour lequel un contournement temporaire est possible. Must est critique pour le lancement, Could est sacrifiable si le temps manque, et Won’t this time indique une exclusion du périmètre actuel.

Explication

Le ROI se calcule par valeur divisée par effort : $36 \div 6 = 6$. Les User Stories sont traitées par ROI décroissant ; le rapport inversé donne environ 0,17, la soustraction donne 30 et l’ordre croissant inverserait la règle.

Explication

L’effort représente un coût de réalisation relatif qui combine effort, complexité et incertitude ; l’équipe l’estime, tandis que le Product Owner apporte la valeur. Assimiler les points aux heures confond estimation relative et durée, attribuer l’effort au Product Owner confond les rôles, et ignorer complexité et incertitude réduit à tort l’estimation à une seule dimension.

Explication

Le vote simultané limite l’influence entre participants ; les valeurs extrêmes sont ensuite expliquées et l’équipe revote jusqu’à un accord. Le vote à tour de rôle introduit une influence, retenir la médiane remplace l’accord par un calcul, et discuter avant le premier vote inverse l’ordre du processus.

Explication

La vélocité se calcule après le sprint en additionnant les points des User Stories terminées conformément à la Definition of Done : les travaux inachevés ne comptent pas. Ajouter les 8 points confond travail engagé et travail terminé ; les jours-personnes sont l’unité de capacité, pas de vélocité.

Explication

La capacité théorique se calcule en multipliant le nombre de personnes par le nombre de jours : $6 \times 8 = 48$ jours-personnes. L’addition donne 14, les points sont l’unité de vélocité, et soustraire des aléas relève de l’estimation de la capacité réelle.

Explication

La capacité réelle retranche de la capacité théorique les absences connues et les aléas : $50 - 4 - 3 = 43$ jours-personnes. Ne soustraire que les absences omet le blocage, ajouter les aléas inverse leur effet, et oublier les absences conduit à ne retirer que trois jours.

Explication

La capacité réelle s’exprime en jours-personnes, tandis que la vélocité s’exprime en points. Inverser ces unités confond les deux indicateurs ; employer les points pour les deux ou les jours-personnes pour les deux efface leur distinction.

Explication

Le burndown chart montre jour après jour le travail restant du sprint pour aider à évaluer si le travail prévu peut être terminé. Le travail accompli cumulé et le périmètre total caractérisent le burnup, tandis que les bandes d’états décrivent le diagramme de flux cumulatif.

Explication

Sur un burndown, un réel au-dessus de la ligne idéale indique un retard, car il reste davantage de travail que prévu. L’avance correspond au réel en dessous de l’idéal; un changement de périmètre ne se déduit pas de cette position à lui seul.

Explication

Le burnup représente séparément le périmètre total et le travail accompli cumulé; leur rencontre marque la fin du projet. Le burndown suit le travail restant, tandis que le diagramme de flux cumulatif montre des bandes d’états du travail.

Explication

Le diagramme de flux cumulatif représente dans le temps les bandes cumulées « À faire », « En cours » et « Terminé » et permet de voir où le travail s’accumule. Le burndown montre le travail restant, et le burnup le périmètre total avec le travail accompli.

Explication

Le lead time mesure la durée entre l’arrivée dans le backlog et la livraison, tandis que le cycle time commence au début du travail et se termine à la livraison. Confondre leurs points de départ revient à inverser ces deux définitions.

Explication

L’agile est recommandée lorsque le produit ou service est fortement innovant, tandis que l’approche classique convient mieux aux variantes de produits existants aux besoins stables. Inverser ces contextes confond innovation et stabilité ; appliquer l’agile à tout projet en fait une méthode universelle ; choisir le classique pour des besoins évolutifs méconnaît la pertinence de l’agile.

Explication

L’agile n’est pas une méthode universelle et il est inutile d’espérer être agile sans Product Owner. Le soutien managérial et l’expérience de l’équipe ne remplacent pas ce rôle, et traiter l’agile comme universelle contredit ses limites.

Explication

Le filtre de pertinence du PMI évalue de 0 à 10 trois blocs : la culture, l’équipe et le projet. Le budget et le calendrier ne remplacent pas ces blocs, les outils et méthodes ne constituent pas la triade décrite, et une réponse binaire ne correspond pas à l’échelle du filtre.