Accueil › Certifications › PSD-I › Questions gratuites

Questions gratuites PSD-I — Professional Scrum Developer I (PSD I)

Téléchargez gratuitement 40 questions d'entraînement pour la certification PSD-I proposée par Scrum.org. Toutes les questions sont accompagnées de corrections détaillées avec explications techniques.

Caractéristiques de l'examen blanc

Code de certificationPSD-I
ÉditeurScrum.org
Nombre de questions40
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 PSD-I. Pour accéder aux 40 questions complètes, lancez l'examen blanc gratuitement.

Question 1
Un Product Owner reçoit une demande de feature d'un gros client 2 jours avant la fin d'un sprint en cours. L'équipe estime 13 points story. Quelle approche respecte les principes Scrum ?
  1. Terminer le sprint en cours sans interruption. Ajouter la feature au backlog pour le prochain sprint, discuter la priorisation avec le client.
  2. Interrompre le sprint pour absorber la nouvelle feature, re-estimer les autres stories et expliquer au client que Scrum = flexibilité totale.
  3. Promettre d'implémenter la feature dans une hotfix urgent en dehors des sprints réguliers pour conserver la relation client.
  4. Refuser catégoriquement la feature car elle casse la vélocité prévue et expliquer que le backlog se remplit trop rapidement.
Question 2
Qu'est-ce que le 'continuous integration' (CI) et pourquoi est-il incompatible avec les branches de longue durée ?
  1. CI = merger souvent vers main et tester automatiquement. Branches longues retardent le merge, cachent les conflicts tardifs, cassent l'intégration continue.
  2. CI est un processus de compilation automatique. Les branches longues ralentissent CI car elles acumulent beaucoup de commits avant merge.
  3. CI demande de pousser au serveur à chaque commit. Les branches longues isolent les commits localement, donc elles évitent le surcharge du serveur CI.
  4. CI signifie que tous les devs travaillent sur la même branche. Les branches longues créent des devs parallèles sans intégration réelle.
Question 3
Une équipe doit décider : mettre à jour des dépendances mineures (patch) ou attendre la prochaine release majeure. Les updates patch ont une adoption forte mais peu de nouvelles features. Comment décider ?
  1. Mettre à jour les patches régulièrement (tous les 1-2 sprints) via un processus de test léger car les risques sont minimaux et les bénéfices de sécurité importants.
  2. Attendre la release majeure suivante pour faire une seule grosse mise à jour et amortir les coûts de test et d'intégration.
  3. Vérifier les changelogs patch et ignorer les updates qui n'ajoutent pas de features visibles pour le business.
  4. Paralléliser : maintenir deux versions (stable + latest) en production et migrer les utilisateurs progressivement via feature toggles.
Question 4
Qu'est-ce que l'inversion de dépendances et pourquoi est-ce crucial pour la testabilité d'une architecture en couches (présentation, métier, persistence) ?
  1. Abstraire les dépendances via des interfaces : les couches hautes dépendent d'interfaces, pas de l'implémentation concrète, permettant l'injection de mocks.
  2. Placer toutes les dépendances dans une couche centrale d'injection, et faire que chaque module importe de cette couche centrale.
  3. Reverser l'ordre des dépendances : faire que persistence appelle métier qui appelle présentation pour qu'aucune couche ne dépende des autres.
  4. Utiliser un conteneur d'injection de dépendances qui automatiquement remplace les dépendances réelles par des mocks durant les tests.
Question 5
Un dev senior critique une PR que le junior a soumise en disant : 'Ce code n'est pas idiomatic.' Le junior ne comprend pas la critique. Comment structurer le feedback ?
  1. Expliquer l'idiom avec des exemples concrets, montrer des patterns courants du langage, suggérer la refactorisation avec justification.
  2. Faire un commit automtique 'fixup' qui montre l'idiom correct et demander au junior d'étudier le code pour apprendre.
  3. Demander au junior de relire la stdlib et les best practices du langage avant de soumettre des PRs à nouveau.
  4. Rejeter la PR et lister 5 ressources pédagogiques sur les idioms du langage pour que le junior se forme hors du contexte.
Question 6
Une équipe Scrum constate que ses stories prennent 2-3 sprints pour être complétées. Les dépendances entre composants backend et frontend créent des goulots. Quelle pratique devrait-elle implémenter en priorité ?
  1. Réduire la taille des stories et implémenter le pair programming pour réduire les dépendances et accélérer le feedback inter-équipes.
  2. Augmenter la durée du sprint à 4 semaines pour laisser plus de temps aux dépendances externes et planifier davantage.
  3. Créer un équipe séparée dédiée à la résolution des dépendances et relancer les tâches depuis zéro chaque sprint.
  4. Utiliser une méthodologie en cascade pour documenter toutes les dépendances en amont et éliminer les incertitudes.
Question 7
Une equipe doit implémenter une feature complexe qui demande une nouvelle architecture interne (refactor majeur) avant de coder la feature. Combien de sprints prévoir pour le refactoring ?
  1. Planifier des phases : refactor incrementalement en 1-2 sprints en parallèle des petites features, puis déployer la grosse feature en parallèle.
  2. Dédier 2-3 sprints complets au refactor en 'mode infrastructure', puis livrer la feature dans les sprints suivants sans interruption.
  3. Implémenter la feature d'abord avec l'architecture existante, puis refactoriser après la livraison pour que le business voit de la valeur tôt.
  4. Créer une branche parallèle pour le refactor, livrer la feature dans main, puis merger la branche refactor une fois prête.
Question 8
Qu'est-ce que le 'technical debt' et comment un développeur professionnel évalue l'impact d'un remboursement vs. l'ajout de nouvelles features ?
  1. Code laissé en 'mauvais état' pour vitesse court-terme. Impact : bugs croissants, velocity ralentit, maintenance coûteuse. Trade-off : feature rapide vs. débtt futur.
  2. Bugs connus non-résolus qui 'coûtent' en effort. Le remboursement significa toujours fixer les bugs ; les features ajoutent du debt secondaire.
  3. Couverture de tests incomplete. Rembourser = augmenter la couverture ; ajouter features crée plus de debt si la couverture reste basse.
  4. Dépendances obsolètes ou outdated. Rembourser = updater les dépendances ; features demandent aussi des dépendances qui augmentent le debt.

Accédez aux 40 questions complètes gratuitement

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

Lancer l'examen blanc PSD-I →

Pourquoi s'entraîner avec Certifexpress ?