70 questions d’entretien sur la méthodologie agile

70 questions d’entretien sur la méthodologie agile
MIN
03 Juin 2024

De nos jours, la méthode agile est largement utilisée dans la gestion des logiciels et il existe une forte demande de scrum masters, de développeurs et de testeurs dans les projets agiles. Dans cet article, nous avons compilé une liste des meilleures questions d’entretien agile.

Questions d’entretien sur les méthodes agiles

Questions.1. Qu’est-ce que la méthodologie agile ?

Réponse : La méthodologie agile est utilisée pour le développement de logiciels. Elle se concentre sur les méthodes de développement incrémentiel, dont l’objectif est de fournir un produit rapidement.

Question.2. En quoi la méthodologie agile diffère-t-elle des méthodologies traditionnelles ?

R : La principale différence entre la méthodologie agile et les autres méthodologies traditionnelles est que la méthodologie agile suit un modèle de développement incrémental, alors que les méthodologies traditionnelles suivent un modèle séquentiel.

Dans la méthodologie agile, la phase de développement et la phase de test se déroulent simultanément. Dans la méthodologie traditionnelle, la phase de test commence après la phase de développement.

La méthodologie agile offre de la flexibilité car elle facilite la mise en œuvre des changements. Dans la méthodologie traditionnelle, il est difficile d’intégrer des changements parce que les exigences sont gelées avant le début du travail de développement.

La méthodologie agile nécessite moins de documentation. Grâce à la livraison rapide, les développeurs apportent des modifications au code en fonction des besoins. Alors que dans la méthodologie traditionnelle, le processus de développement ne commence qu’une fois que l’équipe dispose des exigences documentées.

Les clients sont impliqués dans chaque phase du cycle de vie du logiciel agile, en examinant le produit et en suggérant des changements si nécessaire. Dans la méthodologie traditionnelle, les clients sont principalement impliqués dans la phase de recueil des besoins. Le produit fini apparaît généralement au cours des dernières étapes du cycle de développement.

Question.3. Pouvez-vous citer quelques cadres agiles ?

Réponse :

  • Scrum
  • Cristal
  • Méthode de développement des systèmes dynamiques (DSDM)
  • Développement axé sur les caractéristiques (FDD)
  • Kanban
  • Développement de logiciels adaptatifs (ASD)
  • Développement de logiciels allégés (LSD)

Question.4. Qu’est-ce qu’un manifeste agile ?

Réponse : Le Manifeste Agile est un document sur le développement agile de logiciels préparé par 17 professionnels du développement de logiciels partageant les mêmes idées et publié en février 2001. Il s’appuie sur 4 valeurs fondamentales et 12 principes de base.

Question.5. Quelles sont les quatre valeurs du Manifeste Agile ?

R : Les quatre valeurs fondamentales du Manifeste Agile sont les suivantes :

  • Les individus et les interactions plutôt que les processus et les outils.
  • Travailler sur des logiciels à partir d’une documentation complexe.
  • Collaborer avec le client dans le cadre des négociations contractuelles.
  • Réagir au changement au lieu de s’en tenir au plan.

Question.6. Quels sont les 12 principes contenus dans le manifeste agile ?

Réponse : Les 12 principes du Manifeste Agile sont les suivants :

  • Notre priorité absolue est de satisfaire nos clients en leur fournissant des logiciels de qualité dans les délais impartis et de manière continue.
  • Accueillir les changements d’exigences, même à un stade avancé du développement. Les processus agiles mettent le changement au service de l’avantage concurrentiel du client.
  • Fournir des logiciels fonctionnels fréquemment, de quelques semaines à quelques mois, avec une préférence pour les délais les plus courts.
  • Les spécialistes du marketing et les développeurs doivent travailler ensemble au quotidien tout au long du projet.
  • Construisez des projets autour d’individus motivés. Donnez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour faire le travail.
  • L’entretien personnel est la méthode la plus efficace pour transmettre des informations à l’équipe de développement et au sein de celle-ci.
  • Les logiciels fonctionnels sont la principale mesure du progrès.
  • Les processus agiles favorisent le développement durable. Les sponsors, les développeurs et les utilisateurs devraient être en mesure de maintenir un rythme constant indéfiniment.
  • Une attention constante à l’excellence technique et à une bonne conception accroît l’agilité.
  • La simplicité – l’art de maximiser la quantité de travail non effectué – est essentielle.
  • Les meilleures architectures, exigences et conceptions sont créées par des équipes qui s’organisent elles-mêmes.
  • À intervalles réguliers, l’équipe réfléchit à la manière de devenir plus efficace, puis ajuste son comportement en conséquence.

Question. 7. Qu’est-ce que la programmation extrême ?

R : La programmation extrême (Extreme Programming ou XP) est l’une des approches les plus populaires du développement agile de logiciels. Il utilise une approche orientée objet et suit les mêmes pratiques que celles incluses dans le Manifeste Agile.

Extreme programming est responsable de l’introduction de concepts qui sont aujourd’hui largement utilisés comme pratiques standard, tels que les histoires d’utilisateurs, l’intégration continue et le développement piloté par les tests. L’un des avantages de la programmation extrême est qu’elle offre la flexibilité nécessaire pour intégrer des exigences changeantes à tout moment du cycle de développement.

Question. 8. Quels sont les cinq principes de base de la programmation extrême ?

Répondez : Les cinq valeurs ou principes de base de la programmation extrême sont les suivants :

  • Communication – Ce principe met l’accent sur une communication précoce et étroite entre les parties concernées (en particulier les développeurs et les parties prenantes).
  • Simplicité – L’idée de base de ce principe est de travailler d’abord sur les fonctions immédiates et de rester simple. Le code doit être facile à mettre en œuvre et peut être remanié si des changements sont nécessaires.
  • Retour d’information – Trois sources sont utilisées pour recueillir le retour d’information. En effectuant des tests unitaires, on obtient un retour d’information sur le système. Les tests d’acceptation permettent de recueillir les commentaires des clients et les jeux de planification permettent de recueillir les commentaires des autres membres de l’équipe chargée du logiciel.
  • Courage – Ce principe met l’accent sur le courage nécessaire pour concevoir des fonctionnalités immédiates, en se concentrant uniquement sur le présent. Une équipe agile doit également avoir le courage de reconnaître que les exigences peuvent changer à l’avenir et qu’elles doivent être intégrées dans le code.
  • Respect – Ce principe se concentre sur le respect de soi, le respect des autres et le respect des autres membres de l’équipe.

Question.9. Quelles sont les quatre activités cadres de la programmation extrême ?

Réponse :

  • Planification
  • Proposition
  • Programmation
  • Essais

Question.10. Qu’est-ce que le refactoring ?

R : La refonte est le processus qui consiste à modifier un code source existant sans en changer la fonctionnalité.

Question.11. Qu’est-ce que la programmation en binôme ?

R : La programmation en binôme est une technique utilisée dans le cadre du développement agile de logiciels, dans laquelle deux développeurs travaillent en équipe. L’un des deux développeurs écrit le code et est connu sous le nom de « pilote », tandis que l’autre révise le code et est connu sous le nom d’observateur. Ils peuvent échanger leurs rôles si nécessaire.

Question.12. Quels sont les avantages de la programmation en binôme ?

Réponse :

  • La programmation en binôme permet d’obtenir un code de meilleure qualité et moins d’erreurs dans le code, car l’autre développeur vérifie constamment le code au fur et à mesure qu’il est écrit.
  • La programmation en binôme permet de trouver plus facilement des solutions à tout problème survenant pendant le codage, car l’autre partenaire peut apporter son aide.
  • Il facilite le transfert de connaissances, car si l’un des partenaires est plus expérimenté, il peut enseigner à l’autre développeur.

Question.13. Quelles sont les différentes techniques d’estimation dans un environnement agile ?

Réponse : Les techniques d’estimation agiles sont utilisées pour estimer l’effort de travail. Voici quelques-unes des techniques d’estimation agile :

Planifier le poker

Tailles des t-shirts

Estimation de l’affinité

Méthode de tri

Le système des seaux

Méthode des trois points

Vote par points

Question. 14. Qu’est-ce que la technique du poker de planification ?

  • R : Le planning poker est une technique d’estimation qui implique une collaboration entre les membres de l’équipe. Elle est réalisée avant le début de l’itération avec l’aide des développeurs.
  • Chaque membre recevra un jeu de cartes de poker de planification. Les valeurs des cartes sont similaires aux nombres de Fibonacci. Ces chiffres représentent des points d’histoire ou des jours.
  • Le Product Owner (PO) lit et explique l’histoire de l’utilisateur à l’équipe. Les développeurs peuvent en discuter plus avant s’ils ont des questions.
  • À l’issue de la discussion, chaque membre évalue l’effort qu’il a consacré à l’élaboration de l’histoire et choisit en privé une carte qui représente cet effort.
  • Toutes les cartes sont révélées en même temps et si elles sont toutes identiques, l’histoire est estimée en fonction de la valeur de la carte.
  • Si les valeurs des cartes diffèrent, une nouvelle discussion s’engage et se poursuit jusqu’à ce que tous les membres de l’équipe se mettent d’accord sur le même nombre.

Question. 15. Quelle est la technique de dimensionnement des t-shirts ?

Réponse : Le T-shirt sizing est une technique d’estimation utilisée pour mesurer la taille d’une user story et est utilisé principalement lorsque des éléments du backlog relativement importants doivent être estimés. Dans les tailles de t-shirt, les tailles de t-shirt (XS, S, M, L, XL) sont utilisées pour estimer l’histoire. Une décision sur la taille doit faire l’objet d’une discussion ouverte.

Question .16. Qu’est-ce que le développement logiciel allégé (LSD) ?

R : Le développement logiciel allégé est une méthodologie agile itérative qui reprend les principes du « processus de fabrication allégé » et les applique au processus de développement logiciel.

Certains des principes adoptés sont la livraison rapide, l’élimination du gaspillage, l’optimisation du temps et des ressources de développement, l’amélioration de la qualité des produits, etc.

Question.17. Qu’est-ce que Kanban ?

R : Tout comme Scrum, Kanban est l’un des cadres populaires utilisés dans le développement agile de logiciels. Kanban est le terme japonais pour tableau noir. Dans ce cadre, les éléments de travail ou « user stories » sont affichés sur le tableau Kanban, et l’équipe peut voir l’état d’avancement de chaque « user story » sur le tableau. Kanban permet de développer le produit en un seul grand cycle de développement au lieu d’avoir des itérations (comme Scrum). Le Kanban est incrémental et non itératif.

Question.18. Qu’est-ce que Scrumban ?

R : Scrumban est une méthodologie de développement agile qui est une combinaison de scrum et de kanban.

Scrumban est principalement utilisé dans les projets de maintenance où les processus scrum sont améliorés à l’aide des principes Kanban. Assister l’équipe de projet dans l’optimisation des processus.

Une partie du scrumban consiste à déterminer la quantité de travail qui peut être effectuée au cours d’un sprint et à hiérarchiser les tâches.

La partie Kanban de scrumban est utilisée pour améliorer les processus et visualiser le flux de travail. Scrumban utilise le système Kanban à flux tendu, dans lequel les éléments sont continuellement tirés du carnet de commandes.

Question.19. Qu’est-ce que le développement piloté par les tests (TDD) ?

Réponse : Le développement piloté par les tests (TDD) est un processus de développement de logiciels dans lequel les cas de test sont d’abord écrits, puis codés. Les cas de test sont écrits pour vérifier ce que le code est censé faire.

Voici les règles de base du processus de développement TDD :

  • Tout d’abord, un test unitaire décrivant la fonction du système est rédigé.
  • L’étape suivante consiste à exécuter le test. Il échoue parce que la fonction n’existe pas dans le système.
  • Écrivez le code qui contiendra la fonction dans le système. L’idée de base est d’écrire un test simple pour que le cas de test passe.
  • Retravaillez le code si nécessaire.
  • Répétez les étapes ci-dessus pour les autres fonctions du système.

Question.20. Qu’est-ce que DevOps ?

R : DevOps est un ensemble d’idées et de pratiques qui relient le développement de logiciels (Dev) et les opérations informatiques (Ops). DevOps réunit les équipes de développement et d’exploitation afin de fournir des logiciels fiables et de haute qualité et de réduire le temps de développement.

Question.21. Quelles sont les différences et les similitudes entre les approches scrum et agile ?

La méthodologie agile est utilisée pour le développement de logiciels. Elle se concentre sur les méthodes de développement incrémentiel, dont l’objectif est de fournir un produit rapidement. Scrum est l’un des cadres de la méthodologie agile qui relève de la gestion de projet agile. Il est également utilisé dans le développement de logiciels.

La méthode agile suit une approche incrémentale et itérative pour mener à bien les projets. Scrum est également de nature incrémentale et itérative.

Question.22. Pouvez-vous expliquer brièvement ce qu’est un test agile ?

Réponse : Le test agile est un processus de test de logiciels qui suit les principes du développement agile de logiciels. Le processus de développement agile est un processus itératif dans lequel les exigences changent constamment en fonction des besoins du client. Le test agile est un processus continu qui se déroule parallèlement au processus de développement. Les tests agiles impliquent des tests continus du système jusqu’à ce que la qualité souhaitée du logiciel soit atteinte.

Question. 23. En tant que testeur agile, quelle approche devez-vous adopter lorsque les exigences changent constamment ?

Tout d’abord, lors de la création des cas de test, l’équipe de test agile devrait se concentrer sur l’écriture de cas de test génériques qui peuvent être utiles lors de la modification des cas de test à l’avenir.

Le testeur agile doit travailler avec le propriétaire du produit et l’analyste commercial pour comprendre les exigences modifiées et les risques associés au changement afin de modifier les cas de test.

L’équipe de test ne doit procéder aux tests automatisés qu’après avoir figé les exigences.

Question .24. Quelles sont les caractéristiques d’un bon testeur agile ?

Réponse : Vous trouverez ci-dessous quelques caractéristiques importantes qu’un bon testeur agile doit posséder :

  • Un testeur agile doit avoir une compréhension approfondie des principes et concepts agiles.
  • Un testeur agile doit être capable de comprendre rapidement et clairement les exigences du projet.
  • Il doit être un bon communicateur car le processus agile encourage une interaction constante avec les analystes commerciaux, les développeurs et les autres testeurs.
  • Un testeur agile doit être capable de gérer des exigences changeantes. Il doit être en mesure de comprendre les risques liés au changement et de modifier les scénarios de test en fonction de l’évolution des besoins.

Question. 25. Quelles sont les méthodes de test agiles ?

Réponse :

  • Développement guidé par le comportement (BDD)
  • Développement piloté par les tests d’acceptation (ATDD)
  • Tests exploratoires
  • Tests par session

Question. 26. Quelles sont les phases du cycle de vie des tests agiles ?

R : Le cycle de vie des tests agiles est divisé en plusieurs étapes :

  • Planification des tests agiles – Dans cette phase, les parties prenantes créent des calendriers pour les plans de test et les produits à tester.
  • Réunions quotidiennes (Daily Scrum Meetings) – Ces réunions permettent de discuter de l’état d’avancement des activités de test réalisées la veille et de fixer les objectifs de test pour la journée.
  • Revue de l’agilité des tests – Ces réunions sont organisées chaque semaine avec les parties prenantes afin de faire le point sur les progrès réalisés.
  • Préparation à la mise en production – Au cours de cette phase, un examen des fonctionnalités est effectué pour vérifier si elles sont prêtes à être mises en production.
  • Analyse d’impact – Cette phase permet de recueillir les réactions des parties prenantes et de préparer les objectifs pour le cycle de vie suivant.

Question .27. Quelle est la différence entre le développement incrémental et le développement itératif ?

R : Dans la méthode de développement itératif, le logiciel est développé et livré au client. Une fois que le client a fait part de ses commentaires, ceux-ci se reflètent dans le logiciel, qui est à nouveau développé par sprints avant d’être livré au client.

Dans la méthode de développement incrémental, le logiciel est développé par incréments. Chaque incrément contient les propriétés complétées de certaines sous-fonctions du système.

Question .28. Qu’est-ce qu’une version candidate ?

R : Une version candidate est une version du système qui est fonctionnelle et qui est diffusée en interne à des fins de test. Il n’est pas utilisé pour le déploiement en production. L’assemblage est testé pour s’assurer qu’aucun problème critique n’est présent dans le système.

Une version candidate est un code/version/construction mis à disposition pour s’assurer qu’aucun problème critique n’a subsisté au cours de la dernière période de développement. Il est utilisé pour les tests et équivaut à la version finale.

Question .29. Qu’est-ce qu’un « build breaker » ?

Réponse : Un build breaker est une situation dans laquelle un bogue dans le logiciel arrête la compilation et provoque des avertissements ou des plantages dans un environnement de test automatisé. Cela se produit lorsque les développeurs inscrivent accidentellement des bogues dans le logiciel.

Question .30. Comment l’assurance qualité peut-elle apporter une valeur ajoutée à une équipe agile ?

  • Les testeurs participent à des séances d’analyse des risques afin d’identifier les risques et les mesures à prendre pour les éviter.
  • Les testeurs étudient les récits des utilisateurs et participent à la création des critères d’acceptation.
  • Ils effectuent des tests exploratoires sur les nouvelles fonctionnalités développées.
  • Ils peuvent fournir un retour d’information continu et rapide aux développeurs du système au fur et à mesure qu’ils testent le logiciel.
  • Les testeurs sont impliqués dans les tests automatisés.
  • Le testeur aide à détecter les erreurs qui se produisent dans le système.
  • Les testeurs peuvent essayer de réfléchir différemment aux différents scénarios à tester afin d’élargir la couverture des tests et de trouver davantage de bogues dans le système.

Question .31. Quels sont les avantages du modèle agile ?

  • Le modèle agile permet une livraison rapide et continue des logiciels.
  • Le modèle agile étant flexible, il permet de s’adapter à tous les changements proposés par les clients.
  • Le processus agile implique un niveau élevé d’interaction entre les différents membres de l’équipe, ce qui permet d’identifier rapidement tout problème dans le processus de développement.
  • Le modèle agile permet d’augmenter le nombre de clients de logiciels car la livraison est rapide et après chaque incrément, un produit fonctionnel est livré au client.
  • Les clients peuvent avoir un aperçu du produit pendant et après chaque incrément, ce qui leur donne l’assurance que le processus de développement évolue dans la bonne direction.

Question . 32. Quels sont les inconvénients du modèle agile ?

  • Comme les exigences changent fréquemment, les développeurs peuvent ne pas être en mesure de quantifier toute l’étendue de l’effort requis dans le processus de développement.
  • La méthode agile met moins l’accent sur la documentation, ce qui peut poser des problèmes à l’avenir, en particulier pour les nouveaux participants au projet.
  • Une participation continue de l’équipe du client est attendue, ce qui implique que l’équipe du client soit disponible pour les réunions.
  • Si l’équipe du client n’est pas en mesure d’expliquer clairement le résultat final du système, le projet peut déraper.
  • Le processus de développement agile nécessite des développeurs expérimentés qui ont les compétences nécessaires pour développer un système avec la capacité de prendre des décisions rapides et critiques au cours du processus.
  • L’interaction permanente de chaque membre de l’équipe est attendue, ce qui augmente le temps et l’énergie nécessaires au travail de l’équipe.

Questions d’entretien pour le Scrum Master

Question.33. Pouvez-vous expliquer brièvement le concept de Scrum ?

R : Scrum est l’un des cadres agiles les plus répandus. Les activités du cadre Scrum sont les exigences, l’analyse, la conception, le développement et la livraison.

Dans Scrum, la liste des exigences est ajoutée à un backlog appelé backlog de produit. Des unités de travail appelées « sprints » sont créées pour répondre aux exigences. Chaque sprint contient certaines exigences du carnet de commandes et peut durer de 2 à 4 semaines.

Question. 34. Pourquoi scrum est-il considéré comme un cadre de processus léger ?

Réponse : Le cadre agile scrum est un cadre de processus léger car il ne comporte que quelques règles et procédures. Ce cadre est flexible et adaptable et peut facilement intégrer des changements dans les exigences. Dans le cadre de scrum, le développement du produit est divisé en sprints de courte durée.

Question. 35. Quand utilisons-nous la méthodologie agile scrum ?

Réponse :

  • Lorsque les exigences ne sont pas claires.
  • Lorsqu’il y a une forte probabilité que les exigences soient modifiées au cours du développement.
  • Scrum peut également être utilisé lorsqu’il est nécessaire de livrer rapidement un produit.
  • Lorsque l’équipe de développement est auto-organisée et interfonctionnelle.

Question. 36. Quels sont les trois piliers de scrum ?

Réponse : Les trois piliers de scrum sont les suivants :

  • Transparence – tous les aspects du processus de développement du produit doivent être visibles pour les parties concernées, telles que l’équipe de développement, le client, le maître de stage, etc.
  • Vérification – Les participants à la mêlée doivent vérifier périodiquement les artefacts de la mêlée pour voir s’il y a quelque chose qui bloque le progrès.
  • Adaptation – Si des questions ou des problèmes sont identifiés au cours de l’examen, des ajustements ou des changements doivent être apportés au processus pour corriger les problèmes.

Question. 37. Qu’est-ce que le sprint ?

R : Dans Scrum, un sprint est une période courte, limitée dans le temps, au cours de laquelle une équipe de développement effectue une certaine quantité de travail pour créer un produit pouvant être mis sur le marché. C’est l’unité de base du développement dans le scrum.

Question. 38. Combien de temps dure le cycle scrum ?

R : Le cycle Scrum ou sprint dépend de la taille de l’équipe et du projet. Le sprint ne doit pas dépasser un mois, c’est-à-dire j. 4 semaines. Normalement, un sprint dure en moyenne quelques semaines.

Question. 39. Quels sont les principaux artefacts du processus scrum ?

Réponse : Les artefacts du processus Scrum sont chargés de fournir des informations clés à l’équipe de développement et au client. Ils aident à comprendre les détails du développement d’un produit.

Il existe trois artefacts en particulier :

  • Backlog du produit – Le backlog du produit est une liste d’éléments à réaliser par le propriétaire du produit. Il s’agit d’exigences, d’améliorations, de caractéristiques, etc.
  • Backlog de sprint – Le backlog de sprint est une liste de tâches sélectionnées dans le backlog de produit et devant être réalisées au cours d’un sprint spécifique.
  • Incrément – Un incrément consiste en une liste de tous les éléments du backlog de produit qui ont été achevés pendant les sprints. C’est l’un des résultats de la mêlée.

Question.40. Pouvez-vous nous parler des différents événements réalisés au cours de chaque sprint scrum ?

R : Scrum se compose des quatre événements suivants, qui sont utilisés pour la révision et la personnalisation :

  • Planification du s print – La planification du sprint implique une discussion détaillée du travail à effectuer sur le projet au cours du sprint.
  • Mêlée quotidienne – La mêlée quotidienne dure 15 minutes et permet de discuter des activités de l’équipe de développement pour les 24 heures à venir. Il comprend également des discussions sur le travail effectué au cours des dernières 24 heures.
  • Revue de sprint – La revue de sprint est effectuée à la fin du sprint. Il est réalisé afin de discuter de l’augmentation.
  • Rétrospective du s print – Une rétrospective du sprint est effectuée afin que l’équipe de développement puisse examiner et discuter des améliorations ou des changements qui peuvent être apportés au prochain sprint pour une plus grande efficacité.
  • Question. 41. Qu’est-ce que la planification de sprint ?

R : Dans la planification de sprint, un plan est établi pour le travail qui doit être fait dans un sprint particulier. Dans le cas d’un sprint mensuel, la planification du sprint est limitée à un maximum de 8 heures. Le maître de mêlée est chargé de veiller à ce que les participants comprennent l’objectif de la mêlée.

Voici deux questions auxquelles il convient de répondre lors de la planification d’un sprint :

Qu’est-ce qui peut être livré au cours d’un sprint ? – Le propriétaire du produit discute de l’objectif du sprint et sélectionne les éléments du backlog du produit à inclure dans le backlog du sprint.

Comment les travaux seront-ils effectués ? – Sur la base du backlog du sprint, l’équipe de développement doit décider de la manière de travailler pour développer un incrément utilisable.

Question. 42. Qu’est-ce que la mêlée quotidienne ?

R : La mêlée quotidienne est un événement au cours duquel les activités de l’équipe de développement pour les 24 heures à venir sont discutées. Elle est limitée à un maximum de 15 minutes. Cet événement répond aux questions suivantes

  • Qu’ai-je fait hier ?
  • Que vais-je faire aujourd’hui ?
  • Y a-t-il des obstacles qui empêchent l’équipe d’atteindre l’objectif du sprint ?

L’objectif de la mêlée quotidienne est de vérifier l’état d’avancement des éléments du carnet de commandes du sprint.

Question. 43. Qu’est-ce que le contrôle du sprint ?

R : La revue de sprint est effectuée à la fin du sprint pour vérifier l’incrément. Les parties prenantes et les équipes de développement participent à la revue de sprint. Les participants y passent en revue ce qui a été fait au cours du sprint, discutent des problèmes rencontrés par l’équipe de développement, fournissent un retour d’information, etc. Si nécessaire, le carnet de commandes est mis à jour et des informations sont fournies pour la planification du prochain sprint.

Question.44. Qu’est-ce qu’une rétrospective de sprint ?

R : Une rétrospective de sprint est effectuée après la revue de sprint et avant la planification du sprint. Il s’agit de vérifier le dernier sprint et d’adapter les changements pour améliorer le prochain sprint.

La rétrospective est limitée à un maximum de 3 heures pour un sprint mensuel. Le scrum master est chargé de diriger et de motiver les autres membres de l’équipe afin d’accroître l’efficacité du sprint.

Question.45. Qu’est-ce qu’un carnet de commandes ?

R : Un carnet de commandes est une liste d’éléments à exécuter. Il se compose d’exigences, de caractéristiques, d’améliorations, de changements, etc. Il est dirigé par le propriétaire du produit, qui est responsable de son contenu.

Le carnet de commandes évolue constamment au fur et à mesure que le développement du produit progresse et que les exigences changent.

Question. 46. Qu’est-ce qu’un backlog de sprint ?

R : Pour un sprint donné, l’équipe de développement sélectionne certains éléments du carnet de commandes sur lesquels elle travaille. Cette liste d’éléments s’appelle le carnet de commandes du sprint. Le carnet de sprint est un sous-ensemble du carnet de produit.

Question. 47. Qu’est-ce qu’un sprint zéro ?

R : Avant de commencer le premier sprint, certaines activités doivent être réalisées, telles que la mise en place de l’environnement de développement, la préparation du carnet de commandes et d’autres activités de planification liées au sprint à venir. Cette phase est appelée « sprint zéro ». Il est également connu sous le nom de Inception Sprint, Initial Sprint ou Sprint Zero.

Question. 48. Qu’est-ce qu’un point d’histoire ?

R : Le point d’histoire est une unité de mesure qui permet d’estimer l’effort total nécessaire pour achever un élément du carnet de commandes ou tout autre travail. Lors du calcul de l’effort requis, plusieurs facteurs peuvent être pris en compte : la quantité de travail à effectuer, la complexité du travail et tout risque pouvant survenir au cours du travail.

Question.49. Qu’est-ce qu’un tableau de combustion ?

  • Réponse : Le tableau d’épuisement est utilisé dans la gestion de projet pour suivre l’avancement du travail sur un projet.
  • Le tableau d’avancement indique la quantité de travail accomplie sur un projet ainsi que la quantité totale de travail sur le projet.
  • L’axe vertical du graphique de l’épuisement professionnel représente le travail total et le travail accompli. L’unité de cet axe peut être des points de tracé, des heures de travail ou des jours de travail. L’axe horizontal représente le temps pendant lequel les sprites peuvent être fabriqués, c’est-à-dire j. itérations, des jours ou des semaines.
  • Dans le graphique de l’épuisement professionnel, l’effet du changement d’échelle est clairement visible puisqu’il indique la quantité totale de travail.

Question.50. Qu’est-ce qu’un tableau de combustion ?

Réponse : Le tableau d’avancement est utilisé dans la gestion de projet pour suivre l’évolution du travail sur un projet.

  • Le tableau récapitulatif montre le montant des projets en cours.
  • L’axe vertical du graphique de l’épuisement professionnel représente la quantité de travail restant à accomplir. L’unité de cet axe peut être des points de tracé, des heures de travail ou des jours de travail. L’axe horizontal représente le temps qui sera mesuré en sprites, c’est-à-dire j. Itérations.
  • Dans le tableau d’épuisement, l’effet de la modification du champ d’application est représenté par une progression négative pour l’équipe de développement, car il n’indique pas la quantité totale de travail.

Question 51. Quels sont les différents types de diagrammes de combustion ?

R : Il existe quatre types de diagrammes de combustion :

  • Tableau d’élimination des défauts
  • Tableau d’épuisement des rejets
  • Tableau de combustion des produits
  • Tableau d’épuisement des sprints

Question.52. Qu’entendez-vous par « tableau d’élimination des défauts » ?

Ans : Un diagramme d’épuisement des défauts est une représentation visuelle du travail restant dans un carnet de défauts.

L’axe vertical du graphique de combustion des bogues représente la quantité de travail restante dans le carnet de commandes. L’unité de cet axe est le nombre d’erreurs dans l’arriéré. L’axe horizontal représente le temps qui sera mesuré en sprints, c’est-à-dire j. Itérations.

Question. 53. Qu’entendez-vous par « tableau d’épuisement des rejets » ?

R : Le tableau d’épuisement des versions est utilisé pour suivre l’évolution d’une version. Représente le travail restant sur le communiqué.

L’axe vertical du graphique d’épuisement des versions représente la quantité de travail restant dans la version. L’unité de cet axe peut être des heures, des jours ou des points d’histoire. L’axe horizontal représente le temps qui sera mesuré en sprints, c’est-à-dire j. Itérations.

Question .54. Qu’est-ce qu’un tableau de combustion ?

R : Un diagramme d’épuisement de produit est une représentation visuelle du travail restant sur un carnet de commandes.

L’axe vertical du graphique d’épuisement du produit représente la quantité de travail restant dans le carnet de commandes. L’unité de cet axe est le nombre de points d’histoire. L’axe horizontal représente le temps qui sera mesuré en sprints, c’est-à-dire j. Itérations.

Question .55. Qu’est-ce qu’un tableau d’épuisement de sprint ?

R : Un tableau d’épuisement des sprints est une représentation visuelle du travail restant à accomplir au cours d’un sprint donné.

L’axe vertical du graphique d’épuisement de sprint représente la quantité de travail restant dans le sprint. L’unité de cet axe peut être des points d’histoire, des heures de travail ou des jours de travail. L’axe horizontal représente le temps à mesurer en jours.

Question .56. Qu’est-ce qu’un « pic » ?

Réponse : Le terme « spike » a été inventé dans le contexte de la programmation extrême. Il arrive que des développeurs et d’autres membres de l’équipe rencontrent un problème avec une histoire d’utilisateur particulière. Ils ne connaissent pas la solution au problème et peuvent avoir besoin de faire des recherches ou des expériences pour trouver une solution.

Spike est une expérience ou un investissement qui aide l’équipe de développement à deviner l’histoire. Spike est inscrit dans le carnet de commandes par le propriétaire du produit. Il existe deux types de pointes : les pointes fonctionnelles et les pointes techniques.

Par exemple, l’histoire de l’utilisateur comprend des exigences d’intégration avec des logiciels tiers. Les développeurs n’ont jamais travaillé avec ce logiciel et ont besoin de temps pour le comprendre. Le responsable du produit peut prendre un jour ou deux pour effectuer cette recherche et créer un pic dans le carnet de commandes.

Question no. 57. Qu’est-ce qu’une balle traçante ?

Réponse : Parfois, certaines histoires d’utilisateurs peuvent être complexes et difficiles à estimer et contenir un nouvel élément architectural avec lequel les développeurs ne sont pas familiers. Dans ce cas, une balle traçante à l’aide d’une « pointe » peut être utilisée pour explorer la faisabilité d’une solution.

Dans une balle traçante, l’un des composants de l’histoire de l’utilisateur est intégré dans la solution finale avec une quantité minimale de code et un retour d’information est obtenu. Sur la base de la mise en œuvre d’un élément, d’autres éléments de l’histoire peuvent être codés.

Question. 58. Qu’est-ce que la vélocité dans scrum ?

R : La vélocité est un indicateur clé de scrum et sert à mesurer la quantité de travail qu’une équipe de développement peut accomplir en un seul sprint. La vélocité peut également être utilisée pour estimer le délai de livraison d’autres versions.

Question. 59. Comment mesurer la vélocité dans scrum ?

R : Il existe deux types de vitesse, à savoir j. la vitesse réelle et la vitesse prévue.

  • La vitesse réelle est calculée à l’aide de la formule suivante

Vitesse réelle = nombre total de points d’histoire terminés / nombre de sprints

  • La vitesse prévue est calculée à l’aide de la formule suivante

Vitesse attendue = nombre total de points de récit estimés / nombre de sprints

Question.60. Qu’est-ce qu’une histoire d’utilisateur ?

R : Les histoires d’utilisateurs sont des descriptions simples utilisées pour représenter les besoins de l’entreprise du point de vue de l’utilisateur final. Les histoires d’utilisateurs sont plus faciles à comprendre que les exigences communes ou les cas d’utilisation.

Question.61. Qu’entend-on par « INVEST » en scrum ?

A : INVEST représente les critères de qualité d’une bonne histoire d’utilisateur Il signifie –

I – Indépendant ; l’histoire de l’utilisateur doit être telle qu’elle ne dépend pas d’une autre histoire.

N – Négociable ; il doit y avoir une marge de négociation dans chaque histoire.

V – Valable ; doit apporter de la valeur à l’utilisateur final

E – Estimable ; l’histoire de l’utilisateur doit être telle qu’elle puisse être estimée et que le sprint puisse être planifié correctement.

S – Petit ; il doit s’agir d’un petit travail qui peut être réalisé en 3 ou 4 jours.

T – Testable ; devrait être testable, t. j. doit comprendre des critères d’acceptation

Une bonne histoire d’utilisateur répond à tous ces critères, et si ce n’est pas le cas, l’équipe doit envisager une refonte.

Question. 62. Quels sont les trois composants d’une histoire d’utilisateur ?

Réponse :

  • Carte – La carte montre l’histoire de l’utilisateur dans sa forme brute. L’histoire de l’utilisateur est écrite sur la carte sous forme physique (post-it). Le format standard de l’histoire de l’utilisateur est le suivant : [typ používateľa] [cieľ] [nejaký dôvod] Comme je le souhaite, à .
  • Conversation – La conversation a lieu entre les clients, les propriétaires de produits, les testeurs, etc. afin de discuter des détails de la carte.
  • Confirmation – La confirmation consiste à définir des critères d’acceptation afin que l’équipe puisse confirmer que l’histoire a été mise en œuvre avec succès.

Question 63. Qu’est-ce que l’épopée ?

R : Epic est une grande histoire d’utilisateur qui peut être divisée en plusieurs petites histoires d’utilisateur. Une épopée peut être répartie sur plusieurs sprints.

Question.64. Qu’est-ce qu’une tâche dans scrum ?

Réponse : Une tâche est le travail technique qu’une équipe de développement effectue pour achever un élément du carnet de commandes dans un délai donné.

Question.65. Quelles sont les principales tâches dans Scrum ?

Réponse : Les tâches suivantes sont les principales tâches du scrum :

  • Propriétaire du produit – Le propriétaire du produit est chargé de représenter les exigences auprès de l’équipe. Il doit y avoir une vision claire de ce que doit être le produit, et cette vision doit être communiquée efficacement par le propriétaire du produit à l’équipe.

Le propriétaire du produit est également responsable de la gestion du carnet de commandes. Responsable de la liste des éléments du carnet de commandes, de leur tri, de la transparence du carnet de commandes, de la compréhension des éléments du carnet de commandes par l’équipe de développement et de l’optimisation du travail de l’équipe de développement.

  • Équipe de développement – L’équipe de développement se compose principalement de développeurs qui effectuent le développement du produit en codant, de testeurs qui testent le produit développé et d’analystes commerciaux. L’équipe de développement est responsable de la livraison d’un logiciel de qualité sous la forme d’incréments utilisables à la fin du sprint. L’équipe de développement doit être auto-organisée et interfonctionnelle. Il est important de noter que Scrum ne reconnaît aucun autre titre que celui de développeur pour une équipe de développement, quelles que soient les tâches effectuées par la personne.
  • Scrum Master – Le Scrum Master est le chef de l’équipe de développement. Il est chargé de veiller à ce que l’équipe de développement exécute correctement les tâches du sprint. Le scrum master est la personne responsable de la gestion du sprint.

Question. 66. Qu’est-ce qu’un objectif de sprint ?

R : Un objectif de sprint est un objectif fixé pour un sprint spécifique. L’objectif du sprint est créé au cours de la planification du sprint, avant que celui-ci ne commence. Dans l’objectif du sprint, une liste d’éléments du carnet de commandes est sélectionnée pour fournir la fonctionnalité appropriée.

Question. 67. Qu’est-ce qu’un tableau des tâches dans scrum ?

Réponse : Le tableau des tâches est un outil utilisé pour suivre la progression du sprint en cours. Il s’agit d’une représentation visuelle du carnet de commandes du sprint où l’équipe peut voir les tâches accomplies, celles qui sont en cours et celles qui doivent encore être commencées.

Question.68. Qu’est-ce qu’un obstacle dans le scrum ?

R : Un goulet d’étranglement est un élément qui affecte la productivité d’une équipe et ralentit les progrès.

Question.69. Pouvez-vous donner des exemples d’obstacles ?

R : Il peut y avoir des obstacles dans la mêlée :

  • Problèmes techniques
  • Problèmes organisationnels
  • Membres de l’équipe non qualifiés
  • Questions relatives aux parties prenantes
  • Problèmes d’infrastructure
  • Catastrophes naturelles

Question . 70. Qu’est-ce que la mêlée des mêlées ?

R : La mêlée des mêlées est une technique agile qui permet de compléter les réunions quotidiennes lorsque de grandes équipes travaillent sur le même projet. Dans cette technique, les groupes sont divisés en équipes agiles de 5 à 10 personnes. Chaque sous-groupe ou équipe désignera un « ambassadeur » au sein de son équipe. L’ambassadeur participe à des réunions quotidiennes avec les ambassadeurs des autres équipes.