Accueil › Certifications › PMI-ACP › Questions gratuites

Questions gratuites PMI-ACP — PMI Agile Certified Practitioner (PMI-ACP)

Téléchargez gratuitement 37 questions d'entraînement pour la certification PMI-ACP proposée par PMI. Toutes les questions sont accompagnées de corrections détaillées avec explications techniques.

Caractéristiques de l'examen blanc

Code de certificationPMI-ACP
ÉditeurPMI
Nombre de questions37
TypeQCM avec 4 réponses possibles
Niveauassociate
CatégorieIT
Prix100% gratuit

Aperçu de 8 questions représentatives

Voici un échantillon aléatoire de 8 questions tirées de notre base d'entraînement PMI-ACP. Pour accéder aux 37 questions complètes, lancez l'examen blanc gratuitement.

Question 1
Une équipe pratiquant l'Extreme Programming (XP) rapporte une couverture de test unitaire de 92%, mais les bugs en production restent élevés. Quel aspect critique du développement XP devrait être investigué EN PRIORITÉ ?
  1. La qualité des tests et le couplage du code : une couverture quantitative n'indique pas si les tests valident les scénarios critiques ou les chemins d'intégration.
  2. L'infrastructure de déploiement ; augmenter la fréquence des releases XP pour tester plus tôt en production.
  3. La discipline du pair programming ; certains développeurs contournent la pratique et produisent du code untested.
  4. Le refactoring insuffisant du code existant ; accélérer la dette technique pour améliorer la testabilité.
Question 2
Une startup Agile dans le secteur fintech reçoit une exigence de conformité (audit externe imminence) qui impose des documentations de trace d'audit détaillées. Comment le Product Owner intègre-t-il cette contrainte sans casser le rythme itératif ?
  1. Ajouter la conformité comme critère d'acceptation dans les user stories régulieres ; intégrer le travail de trace audit au sprint comme une feature métier, non un overhead.
  2. Créer un sprint de conformité séparé pour centraliser tout le travail d'audit et éviter la dispersion entre les stories fonctionnelles.
  3. Externaliser la conformité à une équipe dédiée qui produira la documentation en parallèle sans impacter le développement Agile.
  4. Retarder la conformité post-livraison du produit ; gérer l'audit comme un projet waterfall après la sortie Agile.
Question 3
Une équipe Agile utilise des burn-down charts mais remarque que le chart ne montre pas les vrais blocages (dépendances externes, débogages). Quels ajustements à la métrique rendront-ils plus réflectifs de la vraie santé du sprint ?
  1. Ajouter des couches au burn-down : % de travail bloqué, % attendant une dépendance externe, et % en vrai progrès pour visualiser les vrais obstacles.
  2. Abandonner le burn-down ; utiliser uniquement des métriques de flux Kanban pour une vision continue.
  3. Ignorer les blocages dans le burn-down ; c'est normal en Agile ; utiliser une métrique séparée de 'santé du sprint'.
  4. Augmenter la fréquence de mise à jour du burn-down à horaires quotidiennes pour plus de granularité.
Question 4
Une organisation en transition agile pilote un framework hybride Scrumban : sprints de 2 semaines avec review continue en Kanban. Les parties prenantes exigent une prévisibilité de release annuelle. Quelle approche de planification aligne la prévisibilité au cadre hybride sans le désactiver ?
  1. Planifier par tranches trimestrielles avec roadmap indicative, autoriser Kanban à fluidifier l'ordre dans chaque tranche, et synchroniser releases entre sprints Kanban.
  2. Revenir à un Scrum pur avec planification en 4 quarterly releases ; abandonner Kanban pour assurer la prévisibilité.
  3. Fixer chaque story Kanban à un sprint calendaire pour forcer la synchronisation et publier des calendriers détaillés de livraison.
  4. Mettre en place une prévision par machine learning sur les données historiques pour deviner les dates de release exactes.
Question 5
Une organisation déploie lean Startup principles dans une équipe R&D interne. Quel cycle de feedback MINIMAL mais pertinent guide l'expérimentation Agile sans tomber dans le prototypage infini ?
  1. Build → Measure (métrique définie) → Learn (décision pivot/persévérance) ; itérer avec hypothèses explicites et seuils d'abandon clairs.
  2. Design → Test → Build → Deploy ; reproduire le cycle sprint classique mais avec des exigences de sortie moins formelles.
  3. Research → Build → Feedback utilisateur ; répéter jusqu'à satisfaction subjective sans définir de métriques d'apprentissage.
  4. Ideate → Prototype → Demo → Déploiement minimaliste ; maximiser la fréquence pour compenser l'absence de données.
Question 6
Une équipe multiprojets utilise Kanban pour trois flux clients différents. Le Work In Progress (WIP) total est limité à 20, mais un flux est bloqué par une dépendance externe. Quelle stratégie respecte les principes Kanban tout en optimisant le flux global ?
  1. Transférer le WIP non utilisé du flux bloqué vers les autres flux pour maintenir la limite globale et maximiser la livraison.
  2. Augmenter la limite WIP globale à 25 jusqu'à résolution de la dépendance externe pour éviter un goulot d'étranglement.
  3. Créer un buffer de travail exploratoire pour le flux bloqué afin de maintenir l'équipe productive durant l'attente.
  4. Réduire la limite WIP à 15 sur tous les flux et attendre la résolution de la dépendance sans ajustement des capacités.
Question 7
Un administrateur produit doit décider si une décision critique affectant 40% de la roadmap doit être prise par consensus d'équipe ou par directive du sponsor. Quels facteurs contextuels guidant la décision sont les PLUS pertinents dans un environnement agile ?
  1. L'urgence de la décision, le risque d'implémentation, et le niveau de défiance si la décision est imposée contre l'expertise équipe.
  2. La hiérarchie organisationnelle, les politiques d'escalade, et la position formelle du décideur dans l'organigramme.
  3. La facilité logistique de convoquer le consensus et le nombre total de personnes affectées par la décision.
  4. Les précédents historiques de prises de décision similaires et l'historique de succès des directives antérieures.
Question 8
Lors d'une planification de release, l'équipe estime 160 points pour une feature clé, mais la date limite est dans 2 sprints (capacité : 50 points/sprint). Comment un Product Owner Agile gère-t-il cette tension de manière stratégique ?
  1. Négocier le scope avec stakeholders pour un MVP de 90 points livrable en 2 sprints, avec roadmap claire pour les 70 points restants.
  2. Demander à l'équipe d'augmenter sa capacité à 80 points/sprint et accepter une qualité réduite pour respecter le délai.
  3. Ajouter une ressource temporaire pour augmenter la capacité de 40 points nets ; livrer la feature complète dans 2 sprints.
  4. Reporter la date limite de 2 sprints supplémentaires et gérer les attentes stakeholder en continu.

Accédez aux 37 questions complètes gratuitement

Aucune carte bancaire requise. Examen chronométré, corrections détaillées, score final.

Lancer l'examen blanc PMI-ACP →

Pourquoi s'entraîner avec Certifexpress ?