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
Un équipe mixte avec des members fullstack et autres très spécialisés débat sur la specialization vs. généralisme. Quel équilibre Agile recommande-t-il pour optimiser la flexibilité et la livraison ?
  1. Favoriser une 'T-shaped' : profondeur en un domaine, largeur en plusieurs domaines voisins ; combiner généralisme croissant avec expertise spécialisée.
  2. Maximiser le généralisme pour éliminer tout goulot d'étranglement ; chaque personne doit maîtriser tous les domaines.
  3. Accepter les silos spécialisés ; l'efficacité de la specialization surpasse les bénéfices du généralisme.
  4. Équilibrer strictement : 50% spécialisation, 50% généralisme dans le temps de travail de chaque personne.
Question 2
Lors d'une rétrospective, 60% de l'équipe identifie le manque de communication entre le domaine backend et frontend comme obstacle. Cependant, les deux groupes travaillent physiquement à proximité. Quel diagnostic le Scrum Master devrait-il investiguer EN PRIORITÉ ?
  1. Les protocoles d'interface implicites et les attentes découvertes trop tard dans le sprint, plutôt que la distance physique.
  2. La charge de travail excessive empêchant des interactions synchrones ; réduire les story points acceptés par sprint.
  3. L'absence d'outils de collaboration ; implémenter une plateforme unifiée de partage de code et de documentation.
  4. La faiblesse des compétences techniques interpairs ; organiser des sessions de pair programming intensives.
Question 3
Un équipe avec 8 membres débat si elle devrait rester une équipe unique ou se scinder en deux équipes de 4. Quels facteurs Agile/Scrum guidance utiliserait-elle pour cette décision ?
  1. Complexité du domaine, dépendances de communication entre les modules du produit, et capacité des deux nouvelles équipes à converger sur des interfaces clés.
  2. La vélocité actuelle ; si elle dépasse 50 points/sprint, scinder pour améliorer la capacité absolute.
  3. La taille de l'équipe ; Scrum recommande strictement 3-9 personnes ; 8 est à la limite donc scinder.
  4. L'espace physique disponible ; si les 8 membres ne rentrent pas dans une salle, scinder l'équipe.
Question 4
Lors d'une planification de capacité, un manager estime que l'équipe aurait une capac ité de 60 points sur le sprint suivant en raison de congés planifiés. L'équipe rapporte habituellement 50 points. Comment un Product Owner Agile répond-il ?
  1. Utiliser 50 points pour planifier ce sprint ; valider avec l'équipe et ajuster la backlog planifiée ; célébrer si davantage est complété.
  2. Accumuler les 10 points supplémentaires et les ajouter à la backlog planifiée pour optimiser l'utilisation de la capacité théorique.
  3. Accepter 60 points sur la base que les congés devraient augmenter la concentration mentale et donc la productivité de l'équipe.
  4. Réduire la backlog à 40 points par précaution et garder les 20 points en reserve pour les urgences imprévues.
Question 5
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 6
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 7
Un administrateur de projet remarque que lors des rétrospectives, l'équipe identifie toujours les mêmes problèmes (communication, documentation) mais peu de changements sont appliqués. Comment le Scrum Master peut-il briser ce cycle ?
  1. Sélectionner UN seul problème par sprint, définir une action d'expérimentation concrète avec propriétaire, et mener une rétro de rétro pour valider l'impact avant d'ajouter un nouveau problème.
  2. Augmenter la fréquence des rétros à deux par sprint pour générer davantage de momentum dans l'implémentation des changements.
  3. Documenter systématiquement tous les problèmes dans un registre et les attribuer à un propriétaire nommé pour suivi externe.
  4. Reconnaître que certains problèmes sont inévitables dans les projets Agile ; continuer les rétros mais sans expectation de progrès.
Question 8
Une équipe adopte Test-Driven Development (TDD) et rapporte une augmentation de 40% du temps de développement initial, mais une réduction de 60% des bugs post-livraison. Comment un product owner évalue-t-il cette trade-off ?
  1. Calculer le coût total de la vie du produit (initial + correction bugs + support) ; TDD réduit généralement le TCO malgré une vélocité apparente ralentie.
  2. Rejeter TDD ; accepter une vélocité plus haute en développement initial, même avec plus de bugs post-livraison.
  3. Accepter TDD seulement pour les modules critiques ; les autres pourraient être développés sans tests unitaires.
  4. Implémenter un compromis : utiliser TDD pour 50% du code et l'approche classique pour l'autre moitié.

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 ?