Product Owner vs. Business Analyst
Вставка
- Опубліковано 9 лис 2020
- Toutes les infos en description ⤵️
✅ Vous voulez devenir Business Analyst ou vous souhaitez vous professionnaliser, mais ne savez pas par où ni quoi commencer? Visitez cette page : bestofbusinessanalyst.fr/par-...
-----
🎞️ Dans cette vidéo : En milieu agile, le rôle de Business Analyst n'existe pas officiellement. Celui qui s'en rapproche le plus est celui de Product Owner. Voici un récapitulatif sur leurs différences de rôle et responsabilité.
Le Business Analyst ne travaille pas de la même manière selon le modèle ou la méthode choisie. Or la méthode traditionnelle de gestion de projet en V ou en cascade, et la méthode agile imposent au Business Analyst des exigences différentes.
1. Le contexte projet agile
Dans méthode agile SCRUM, il n’y a que 3 rôles définis à l’intérieur de l’équipe Projet : le Scrum Master, le PO, et la Dev Team. Dans les projets agiles, le rôle de BA n’a donc pas d’existence officielle, mais ce qui s’en rapproche le plus est le rôle de PO.
Comment le BA peut-il savoir ce que l’on attend de lui dans les projets agiles, quand il n’a pas la casquette de PO ?
2. Rôle et Responsabilités du Product Owner
Le Product Owner en milieu agile a 5 objectifs principaux:
#1 Définir la vision du produit (ex: mise à jour du product backlog)
#2 Agir comme point focal client de l’équipe de développement
#3 Définir les contraintes de la solution et du projet (ex: exigences non-fonctionnelles)
#4 Prioriser les tâches du sprint
#5 Piloter et encourager le feedback utilisateur
3. Les rôles du Business Analyst agile
Le Business Analyst, lui, peut endosser des rôles différents:
- Facilitateur
- Product Owner
- Remplaçant de PO
- PO adjoint
- Coach
- Chargé de communiquer les critères d'acceptance
- Chargé des tests fonctionnels
- Garant de la vision et des objectifs métiers du projet
- Chargé de définir les besoins
Si en tant que BA, on vous demande d’intervenir sur un projet agile, la première chose à faire est de vous faire préciser votre rôle et vos responsabilités sur le projet.
Il faut néanmoins être doublement formé :
- A l’approche agile retenue sur votre projet (XP, SCRUM, SAFe…)
- A la business analyse en SI (cf ma masterclass: www.bestofbusinessanalyst.fr/cours-en-ligne/).
🎧 Écouter ce replay sur Soundcloud: / product-owner-vs-busin...
---
RÉFÉRENCES CITÉES DANS LE LIVE:
Guide SCRUM: www.scrum.org/
Contexte agile: bestofbusinessanalyst.fr/cont...
Exigences non-fonctionnelles: bestofbusinessanalyst.fr/comm...
-----
✅ Vous faites vos premiers pas ? Téléchargez le livre blanc "Introduction à la Business Analyse" : bestofbusinessanalyst.fr/prod...
✅ Découvrez les nombreux aspects de la Business Analyse avec mon livre digital "Les Fondamentaux de la Business Analyse (la pratique opérationnelle, pas la théorie) - 3ème édition" : bestofbusinessanalyst.fr/prod...
✅ Informez-vous continuellement sur la Business Analyse grâce à ma newsletter bimensuelle (articles, podcasts, vidéos, infos événements et formations etc): bestofbusinessanalyst.fr/la-n...
🎓 Vous êtes déjà prêt(e) à devenir Business Analyst? Pour vous professionnaliser et/ou être accompagné personnellement, rdv sur mon site internet bestofbusinessanalyst.fr/bout...
🌍 Où me trouver :
www.bestofbusinessanalyst.fr
BestOfBusinessAnalyst
bestof_ba
www.linkedin.com/company/bestofbusinessanalyst
www.soundcloud.com/bestofbusinessanalyst
/ bestofbusinessanalyst
📨 Envoyez-moi vos questions à alice@bestofbusinessanalyst.fr - Наука та технологія
![C'est quoi, un cahier des charges? [définition, enjeux & impacts]](http://i.ytimg.com/vi/lU0wFuAAAcw/mqdefault.jpg)
Merci pour toutes tes vidéos Alice! Je les ai presque toutes regardé 👌🏽
Une petite remarque : la priorisation des tâches du sprint est de la responsabilité de la Dev team.
La priorisation du product backlog est de la responsabilité du PO.
merci pour ta précision 😊
Merci @Alice tu es une vraie chance pour toutes les entreprises (ESN et clients).En effet grâce à tes vidéos le taux de réussite des projets progresse.
Oh merci beaucoup Didier ! Je n'en sais rien mais j'essaie d'apporter ma contribution à notre communauté 🙏
Tu as tout dit,
Ça répond à ma question,
Merci👍
Merci, superbe présentation :)
La philosophie Agile, et les méthodes qui en découlent ne sont pas le problème dans les entreprises je pense. Un projet qui ne marche pas avec une méthode Agile, je doute que il marcherait mieux avec un projet qui utiliserait une autre méthode.
J'ai le sentiment, le problème n'est il pas plus lié à la nature humaine ? Qui fait que nous avons tous du mal à rester dans une case particulière (un scope pour notre rôle). De plus nous avons tous une compréhension différents du scope de chacun ce qui fait que les organisations se retrouvent souvent avec des morceaux de scope qui ne sont couvert par personne et d'autres parties du scope qui sont couvert par plusieurs personne et peut donc créé un problème de vision/direction donnée.
Ces points ne me semblent solutionné dans aucune méthode de gestion de projet. Ce qui explique que malgré les méthodes Agiles, le succès des projets est rarement faramineux.
On oublie souvent également que la gestion de projet Agile c'est avant tout une façon différente de gérer les risques. Et c'est un point qui est rarement compris par les entreprises et les différents intervenants dans les projets.
Hello FreedNut,
C'est toujours la même problématique : existe t il une méthode universelle? L'agilité est un état d'esprit (cadre méthodologique). Or les organisations se l'approprient comme étant une méthode universelle applicable à tous les contextes et cultures d'entreprise.
J'ai déjà participé à des projets où le préalable était la sélection d'une gestion de projet, avec une grille de critères. Le résultat était sans appel : il faut utiliser un modèle de type waterfall (car, entre autres, client et utilisateurs non disponibles). Le client a pourtant catégoriquement opté pour du SCRUM. Aïe.
Voici un article intéressant que m'a justement envoyé ce matin un des élèves de ma masterclass (Lionel, que je remercie au passage:)): "La méthode Agile Scrum ne marche pas, elle fonctionne dans seulement 15 % des cas, rencontrant donc un échec dans 85 % des cas"
www.developpez.com/actu/303675/La-methode-Agile-Scrum-ne-marche-pas-elle-fonctionne-dans-seulement-15-pourcent-des-cas-rencontrant-donc-un-echec-dans-85-pourcent-des-cas-selon-Gene-Bond-directeur-executif-chez-iiSM-ORG/
En bas d'article, il y a la source complète en anglais.
Cela rejoint ton commentaire. Et effectivement, quand on regarde le Standish Group Chaos Report de 2015, le taux d'échec des projets IT est de 71%... malgré l'adoption des approches agiles (même si cela a un peu amélioré ce score par rapport au précédent rapport de 1994)
@@BestOfBusinessAnalyst Merci pour tes éclaircissements Alices, suite a ton argument, quel approche faut-il donc opter vu que d'après le Standish Group Chaos Report 2015 comme tu l'as dit le taux d'echec des projet IT est de 71%. serait-il mieux de continuer a faire recours aux méthodes traditionnelles?
Excellente vidéo
Merci Alice,
Merci Alice ❤️
Bonjour, est ce qu'un BA peut rédiger des US de AàZ? C'est a dire, au delà tests d'acceptance? Je suis PO et je n'ai pas le temps de rédiger toutes les US et notre PPO ne délivre pas assez rapidement pour le dev. Nous avons un BA dans l'équipe et je voulais savoir si le BA pouvait aider le PPO et faire des petites briques.
Ce que j'en retiens, c'est qu'il n'y a pas qu'une seule règle et qu'il faut adapter au contexte.
Bonjour @pysordes, absolument! Le Business Analyst peut venir t'épauler pour rédiger intégralement les US. En revanche, pour éviter le mode "pompier / patate chaude", les frustrations et autres incompréhensions, je te conseille de définir clairement les rôles et responsabilités du BA, que ce soit entre PO / PPO / BA mais aussi vis à vis de l'équipe de dev.
👍
Très sympa encore comme vidéo. J'étais arrivé au même conclusion avec mon propre parcours.
Mais je serais curieux de connaître ton avis. Vois tu une différence entre Business Analyst et Fonctional Analyst ?
Hello FreedNut,
Functional Analyst = Consultant fonctionnel = Business Analyst IT orienté solution. Il conçoit et met en oeuvre la solution informatique, c'est à dire ses fonctionnalités + exigences non fonctionnelles. D'où, je pense, son nom de "functional".
Mais un Business Analyst IT travaille également en amont de la solution, côté métier (AMOA ou MOA, comme on dit en France):
- Avant le projet, pour analyser le besoin de changement exprimé par l'organisation, faire une étude d'opportunité, et le business case (analyse financière)
- En début de projet, pour cadrer le périmètre du projet, puis éliciter la vision stratégique, les besoins métiers, identifier les contraintes externes et internes etc, puis recommander "la meilleure solution possible qui répondra à la nécessité ou au désir de changement de l'organisation".
- C'est là qu'interviendra le Functional Analyst, qui concevra la solution IT, qui est l'une des réponses pour satisfaire le besoin de changement, sachant qu'il y a d'autres réponses "métier" (processus, procédures), et "gouvernance" menées en parallèle par les autres BA qui ne sont pas "fonctionnels", en collaboration étroite avec les managers et cadres dirigeants.
Pour une vulgarisation de la BA, tu peux rendre visite à mon blog : bestofbusinessanalyst.fr/def-business-analysis/
@@BestOfBusinessAnalyst D'accord, j'avais oublie la distinction que tu fais entre BA IT et les autres type de BA. Mais d'accord j'ai la même compréhension des choses que toi, juste que je n'avais pas dans l'idée de faire des distinctions entre BA.
Merci pour ta réponse ! :)