Menu

Rôle des analystes commerciaux dans SCRUM et pourquoi un contrôle qualité est-il le meilleur pour ce rôle?

  • Principal
  • Test Agile
  • Rôle des analystes commerciaux dans SCRUM et pourquoi un contrôle qualité est-il le meilleur pour ce rôle?

role business analysts scrum

outil de réparation pc gratuit windows 10

Essayez Notre Instrument Pour Éliminer Les Problèmes

Rôle de premier plan des analystes commerciaux dans SCRUM:

Un Business Analyst qui est bientôt appelé BA joue un rôle très radical et important dans SCRUM .

Cette personne est le lien entre le propriétaire du produit / client et l'équipe technique informatique. Bien que nous ayons rencontré plusieurs tutoriels sur notre site Web sur BA, ce tutoriel sera en quelque sorte unique et vous expliquera l'importance de BA dans SCRUM.

Explorons!!

=> Consultez TOUS les tutoriels Business Analyst ici.

Rôle des analystes commerciaux dans SCRUM et pourquoi un contrôle qualité est-il le meilleur pour ce rôle_

Ce que vous apprendrez:

Responsabilités d'un BA

Il y a plusieurs rôles d'analystes d'affaires dans Scrum et il y a certaines responsabilités auxquelles un BA devrait adhérer.

Peu de sélectifs parmi eux sont mentionnés ci-dessous.

  • Grooming du backlog produit en fonction de la hiérarchisation fournie par le product owner.
  • Analyser les besoins des clients et trouver les solutions pour y répondre.
  • Création des exigences sous forme de user stories avec des critères d'acceptation appropriés.
  • Si dans le cas où les user stories ont déjà été créées par le propriétaire du produit (avec des critères d'acceptation), passez-les en revue pour vous assurer que chaque règle métier est couverte et que les critères d'acceptation correspondent à la fonctionnalité de user story.
  • Travailler avec le product owner et les parties prenantes pour comprendre la portée, suggérer des améliorations aux exigences, etc.
  • Préparer des documents tels que les wireframes, le flux de conception, l'interface utilisateur, etc., au besoin.

En dehors de cela, un Analyste d'affaires est un participant important aux sessions de brainstorming lorsque l’équipe se réunit pour discuter du backlog du sprint à venir. Le BA guide l'équipe, les aide à comprendre les exigences et doit même parfois approuver la mise en œuvre.

Il travaille également en étroite collaboration avec les QA comme l'analyse de la couverture des tests, la conversion de cas d'utilisation du monde réel en cas de test, fournissant un aperçu pour tester des fonctionnalités complexes, etc. Le BA participe également à la réunion de planification pour aider l'équipe dans les estimations en les aidant à comprendre le flux, la complexité et la dépendance.

BA doit toujours se renseigner sur la nouvelle tendance qui se passe sur le marché, continuer à innover et se tenir au courant du domaine d'activité pour lequel le produit a été fabriqué.

BA

Business Analyst en tant que Product Owner

En fonction du client et de l'entreprise, il arrive que certaines entreprises aient le Business Analyst comme propriétaire du produit. Dans ces cas, le BA est le point de contact pour toutes les requêtes. Le BA devient alors le médiateur entre l'équipe et les parties prenantes.

Le BA doit comprendre les exigences des parties prenantes, leur réflexion sur la manière de faire progresser l'entreprise et ce que l'entreprise devrait développer (et comment). Ensuite, en fonction des exigences des parties prenantes, le BA doit créer les documents, les user stories, hiérarchiser les histoires, aider l'équipe à les comprendre, répondre à leurs questions à ce sujet, etc.

La chose la plus importante à noter ici est que cela est conseillé lorsque la BA est physiquement disponible et n’est pas géolocalisée dans un fuseau horaire différent afin d’éviter le «manque de communication».

Si le BA en tant que propriétaire du produit est géolocalisé dans un fuseau horaire différent, il n'est pas possible de l'approcher à chaque fois et le seul moyen de communiquer est par e-mails, chats ou appels, ce qui peut entraîner un manque, un écart et même mauvaise communication parfois.

Selon mon expérience, cela devrait être suivi lorsque le BA est assis dans votre bureau, à côté de votre équipe afin que votre travail ne vous gêne pas et qu'il soit facilement accessible. Du point de vue d'un BA, ils possèdent le produit au nom des parties prenantes / clients, prennent les décisions appropriées et ont même besoin d'acquérir de nouvelles compétences qui peuvent inclure l'apprentissage de certaines techniques de développement.

Avoir un Business Analyst en tant que Product Owner est un avantage supplémentaire car l'analyste commercial comprend très bien le produit, et la hiérarchisation et la portée des tâches peuvent également être négociées.

BA-PO

Analyste d'affaires en tant que membre de l'équipe

L'autre option est d'avoir le Business Analyst comme membre de l'équipe car le Product Owner ne sera pas disponible à chaque fois. Lorsque l'analyste commercial fait partie de l'équipe, il aide les pairs à gérer l'arriéré.

Avoir un Business Analyst en tant que membre de l'équipe est plus avantageux car l'équipe technique trouve qu'il est facile et confortable de communiquer avec le BA pour des clarifications ou des discussions. Le BA travaille également en étroite collaboration avec l'équipe QA pour tester, c'est-à-dire analyser la couverture, les cas d'utilisation couverts, les exigences cachées, la fiabilité ou les effets.

Parfois, les critères d'acceptation écrits par le Product Owner peuvent être vagues et peu clairs, puis en tant que membre de l'équipe, il devient de la responsabilité du BA de rédiger des critères d'acceptation élaborés et bien expliqués. Si l'équipe a besoin de plus d'informations, le BA crée également des documents filaires, des documents de flux, etc. pour aider l'équipe à comprendre les exigences.

Dans les projets à grande échelle où les modules sont répartis entre les équipes, avoir un BA pour plus d'une équipe est également un avantage supplémentaire. Étant donné que le BA est le même d'une équipe à l'autre, il peut réfléchir à l'interopérabilité des modules, à la manière dont les nouvelles fonctionnalités ou mises à jour affecteront les autres modules, etc.

Cela aiderait donc beaucoup les équipes techniques à prendre en compte des aspects tels que les user stories ou les critères d'acceptation ne le mentionnent pas toujours.

Membre BA_Team

Importance et rôle des analystes commerciaux dans l'équipe SCRUM

Le rôle des Business Analysts dans SCRUM est très important dans la réussite d'un projet. Leur implication commence dès la compréhension du besoin du client jusqu'à la démo Sprint. Ils sont le premier point de contact de l'équipe technique pour des clarifications. Ils sont encore plus importants dans les phases initiales d'un nouveau projet et des projets de grande envergure.

Le Product Owner ne sera pas toujours un bon écrivain, il vient parfois d'un bagage technique et il devient donc de la responsabilité de l'Analyste d'Affaires d'écrire les histoires, l'acceptation, les wireframes, etc.

Dans mon projet, notre bon de commande n'était pas aussi bon avec la documentation et même les user stories écrites n'étaient jamais plus de 2-3 doublures alors que les critères d'acceptation n'étaient qu'une seule ligne. C'était le Business Analyst qui avait l'habitude de les modifier, de les rendre plus explicatifs et élaborés.

Même à certains moments, il arrivait que notre PO écrivait des user stories contenant 21 points d'histoire ou plus, et l'analyste commercial devait donc consacrer du temps et des efforts supplémentaires à les décomposer et à les hiérarchiser avec le Product Owner.

Vous pouvez imaginer ce qui se passerait s'il n'y avait pas d'analyste commercial et que votre chef de produit avait créé une user story du type 'En tant que client, je veux effectuer toutes les opérations bancaires pour mon compte', avec des critères d'acceptation tels que:

  1. Le client doit pouvoir se connecter.
  2. Le client doit pouvoir effectuer des transactions sur mon compte.
  3. Le client doit pouvoir télécharger mes relevés historiques, etc.

Maintenant, à mon avis, cette user story contiendrait même plus de 34 story points, il est donc nécessaire de la décomposer davantage. Les choses empireraient pour l'équipe technique si les diagrammes de flux et les écrans d'interface utilisateur appropriés (à créer) ne sont pas fournis.

Cela conduirait à un sprint raté, et à son tour, un projet raté. Sauf si le Product Owner est un Business Analyst formé / expérimenté, il est nécessaire d'en avoir un dans l'équipe.

Pourquoi un QA convient-il le mieux à ce poste?

L'assurance qualité est une personne qui vérifie la solution proposée pour un problème / une exigence en la testant. Par conséquent, l'analyste commercial / les parties prenantes / les propriétaires de produits sont très désireux de connaître les commentaires d'un contrôle qualité. L'implication d'un BA dans les tests n'est guère plus que ce qu'elle est en développement.

Un Business Analyst travaille en étroite collaboration avec un QA pour examiner la couverture du cas de test, ce qui donne un aperçu des flux cachés ou des exigences / effets. Ainsi, ce type de partage de connaissances (par le BA) leur permet de comprendre complètement la fonctionnalité du produit, les règles métier, les attentes des clients, les flux, les dépendances et tout.

Le contrôle qualité teste toujours du point de vue du client final qui utiliserait le produit, d'où les chances d'aider le client pour des améliorations, les améliorations du produit sont plus importantes (par rapport à un développeur). Les développeurs développent le produit pour la user story donnée et l'ensemble de critères d'acceptation, mais ne réfléchissent pas toujours à la manière dont un client utiliserait le produit .

En développement, la mise en œuvre d'un produit, le flux et les règles sont bien définis mais les tests sont entièrement basés sur une pensée logique et la capacité de penser du point de vue des utilisateurs finaux.

L'assurance qualité peut commencer à jouer le rôle d'analystes commerciaux dans SCRUM en raison du grand nombre d'opportunités qui se présentent dans le travail quotidien.

Lecture recommandée => Changement de carrière d'un testeur à un BA

Il est très facile pour un QA d'accéder à des rôles tels que:

  • Étudiez les exigences très en profondeur et indiquez les lacunes dans les réunions de révision / brainstorming, etc. Essayez de réfléchir à de meilleures solutions et discutez de la même chose avec l'équipe et le BA.
  • Soyez attentif aux appels avec le Product Owner, posez des questions et partagez vos résultats. Cela renforcera la confiance du Product Owner qui montre votre intérêt pour le produit.
  • Installez-vous entre le BA et l'équipe de développement, vous devriez être le point de contact des développeurs en cas de clarifications ou de doutes.
  • Configurez le processus de test et continuez à innover, en le modifiant pour aider à livrer des sprints réussis.
  • Dans le cas de produits avec des interfaces utilisateur sophistiquées, recherchez les nouvelles tendances et suggérez de telles améliorations.
  • Comprenez complètement le produit à l'intérieur et à l'extérieur.
  • Développez une solide connaissance de vos parties prenantes, de leurs attentes et partagez votre expérience avec elles.

Cela implique également que pour accéder au rôle de BA, vous devez améliorer vos compétences. Plusieurs cours qui comprennent à la fois le niveau de base et le niveau avancé se trouvent sur le marché.

Êtes-vous BA / QA? Avons-nous souligné à juste titre tout votre rôle? Ou pensez-vous que nous avons manqué quelque chose que vous exécutez uniquement? Nous serions heureux de vous entendre. N'hésitez pas à les partager avec nous dans la section commentaires ci-dessous !!

=> Visitez ici pour voir la série Business Analyst pour tous.

lecture recommandée

^