Product Owner vs. Business Analyst

  Рет қаралды 6,502

Best Of Business Analyst

Best Of Business Analyst

Күн бұрын

Пікірлер: 17
@broudidierkassi1456
@broudidierkassi1456 Жыл бұрын
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.
@BestOfBusinessAnalyst
@BestOfBusinessAnalyst Жыл бұрын
Oh merci beaucoup Didier ! Je n'en sais rien mais j'essaie d'apporter ma contribution à notre communauté 🙏
@GadiriLeoAbelLotfi31
@GadiriLeoAbelLotfi31 Жыл бұрын
Excellente vidéo Merci Alice,
@drsbns5592
@drsbns5592 3 жыл бұрын
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.
@BestOfBusinessAnalyst
@BestOfBusinessAnalyst 3 жыл бұрын
merci pour ta précision 😊
@dev-rachid
@dev-rachid 2 жыл бұрын
Tu as tout dit, Ça répond à ma question, Merci👍
@fila8727
@fila8727 4 жыл бұрын
Merci, superbe présentation :)
@hapikops6963
@hapikops6963 4 жыл бұрын
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.
@BestOfBusinessAnalyst
@BestOfBusinessAnalyst 4 жыл бұрын
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)
@lexusturo8208
@lexusturo8208 Жыл бұрын
@@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?
@pysordes
@pysordes Жыл бұрын
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.
@BestOfBusinessAnalyst
@BestOfBusinessAnalyst Жыл бұрын
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.
@Bineta110
@Bineta110 4 жыл бұрын
Merci Alice ❤️
@hapikops6963
@hapikops6963 4 жыл бұрын
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 ?
@BestOfBusinessAnalyst
@BestOfBusinessAnalyst 4 жыл бұрын
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/
@hapikops6963
@hapikops6963 4 жыл бұрын
​@@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 ! :)
@yvesthiery4733
@yvesthiery4733 2 жыл бұрын
👍
Product Owner vs AMOA: les explications
24:11
Best Of Business Analyst
Рет қаралды 1,2 М.
Le rôle du Business Analyst en équipe agile? [4 étapes pour trouver votre place]
29:16
كم بصير عمركم عام ٢٠٢٥😍 #shorts #hasanandnour
00:27
hasan and nour shorts
Рет қаралды 12 МЛН
Do you love Blackpink?🖤🩷
00:23
Karina
Рет қаралды 23 МЛН
Sigma Kid Mistake #funny #sigma
00:17
CRAZY GREAPA
Рет қаралды 18 МЛН
Il était une fois la vie d'un Product Owner
47:32
SuperTilt
Рет қаралды 13 М.
Mon travail ne sert à rien - ARTE Radio Podcasts
20:14
ARTE Radio
Рет қаралды 167 М.
Le gouvernement démissionne, la situation expliquée
15:26
HugoDécrypte - Actus du jour
Рет қаралды 355 М.
Scrum in 20 mins... (with examples)
19:36
Codex Community
Рет қаралды 369 М.
Quelles questions doit-on poser en phase de recueil des besoins ?
41:09
Best Of Business Analyst
Рет қаралды 7 М.
PRODUCT OWNER : quotidien, salaire, parcours | Pool
12:47