NEW
Font size
WorksheetsR3.10 Séance 4 : Approche Agile
Total questions: 41
Worksheet time: 21mins
Le Manifeste Agile a été créé en :
1995
2001
2007
2015
Le Manifeste Agile a été rédigé par :
Des employés de Google
Des chefs de produit
17 praticiens du développement logiciel
Le comité IEEE
Quelle valeur est mise en avant par l’agilité ?
Processus plus importants que les individus
Individus et interactions
Documentation exhaustive
Respect strict d’un plan
L’agilité privilégie :
L'adaptation au changement
Le respect d’un plan initial
Le contrôle centralisé
La documentation lourde
L’un des 4 piliers du Manifeste Agile est :
Corriger avant de produire
Logiciel opérationnel
Documentation obligatoire
Validation par un auditeur externe
Le Product Owner est responsable de :
Tester le produit
Encadrer l’équipe
Maximiser la valeur du produit
Configurer les serveurs
Le Scrum Master :
Décide des tâches à faire
Valide les développements
Facilite le cadre Scrum
Signe le contrat client
L’équipe Scrum (Développeurs) doit être :
Hiérarchisée
Auto-organisée
Supervisée en continu
Composée d’au moins 15 personnes
Qui est responsable du Product Backlog ?
Le Product Owner
Le Scrum Master
L’équipe de développement
Le client
Qui garantit la bonne compréhension des pratiques Scrum ?
Le client
Le Scrum Master
Le Sprint a une durée maximale de :
8 semaines
6 semaines
4 semaines
2 semaines obligatoires
L’objectif principal du Daily Scrum est :
Détailler les problèmes techniques
Faire un point complet sur le sprint
Synchroniser l’équipe en 15 minutes
Mettre à jour le Product Backlog
L’événement qui inspecte l’incrément produit est :
La retrospective
La Sprint Planning
La Sprint Review
Le Grooming
L’événement pour améliorer les processus internes est :
Sprint Review
Rétrospective
Backlog Refinement
Daily Scrum
Quel événement n’est pas officiellement un événement Scrum ?
Le Backlog Refinement
Le Sprint
La Sprint Review
La Daily
Quel artefact représente la liste ordonnée des besoins du produit ?
Sprint Backlog
Product Backlog
Release Backlog
Planning Board
Quel artefact contient l’objectif du sprint et les éléments sélectionnés ?
Sprint Backlog
Product Backlog
Incrément
Burndown Chart
L’incrément doit être :
Optionnel à chaque sprint
Potentiellement livrable
Dépendant d’autres sprints
Validé par un auditeur externe
Qui définit la Definition of Done ?
Le client
L’équipe Scrum
Le directeur technique
Le Scrum Master seul
La Definition of Done sert à :
Définir les tâches à faire
Prioriser les User Stories
Garantir que le travail est terminé
Définir les risques projet
Une User Story décrit :
Le design technique
Un besoin utilisateur
Le code à produire
La documentation requise
Une bonne User Story respecte :
CMMI
INVEST
ITIL
PMBOK
Dans les critères d'acceptation, “En tant que…” correspond à :
L’objectif
Le rôle
La valeur
Le contexte technique
Dans les critères d'acceptation, “Je veux…” correspond à :
Le rôle
Le besoin
La justification
Le test
Dans les critères d'acceptation, “Afin de…” correspond à :
La description fonctionnelle
Le rôle
La valeur métier
Le planning
Les critères d’acceptation servent à :
Décrire l’architecture
Affecter les ressources
Définir les conditions pour valider une US
Écrire les tests unitaires
Le langage Gherkin est associé à :
Kanban
SAFe
BDD
Portfolio Management
Quelle structure correspond à Gherkin ?
How / Why / What
Given / When / Then
If / Else / End
Do / Check / Act
Un scénario Gherkin :
Décrit un comportement attendu
Décrit le planning projet
Les critères d’acceptation doivent être :
Longs et détaillés
Testables
Rédigés par le Scrum Master
Non négociables
Les estimations agiles se font souvent en :
Heures
Euros
Story Points
Jours-homme uniquement
Le Planning Poker utilise :
Une échelle linéaire
La suite de Fibonacci
Des nombres pairs
Une grille horaire
Les Story Points mesurent :
Le coût réel
La durée
La complexité/effort
Le nombre de développeurs
La vélocité représente :
Le nombre de commits
Le nombre d’heures travaillées
Le nombre de points réalisés par sprint
Le nombre de bugs corrigés
Une estimation en Story Points est :
Une estimation de temps
Relative
Fixée par le PO
Identique pour toutes les équipes
Le Product Backlog est :
Un planning des tâches quotidiennes
Une liste hiérarchisée des risques
Une liste ordonnée des besoins du produit
Un document obligatoire de spécifications détaillées
La Sprint Planning sert principalement à :
Définir la durée du sprint
Réviser la Definition of Done
Décider ce que l’équipe va accomplir pendant le sprint
Valider le code produit
La vélocité permet à l’équipe :
De mesurer le taux de bugs
D’estimer la capacité future d’un sprint
De déterminer le temps passé par développeur
De planifier les tests unitaires
Le Planning Poker favorise :
L’estimation individuelle et confidentielle
Les décisions du Product Owner
Le consensus de l’équipe par estimation relative
Une estimation en heures pour chaque tâche
Les Story Points permettent d’estimer :
La date exacte de livraison
Le nombre de documents à rédiger
L’effort relatif d’une User Story
Le temps nécessaire pour coder un module
L’intégration continue (CI) permet :
D’automatiser la gestion du backlog
De détecter rapidement les régressions
De supprimer les tests
De livrer uniquement en fin de sprint
