Bonsoir, 😄😄 merci. Ça me permet de faire des connexions. J ai eu un projet avec des SFG et on était dans un mode classique, je comprends. Clair et précis, merci d avoir pris la peine de me répondre 🙂🙂.
Bonjour Alice. Comme toujours une vidéo très intéressante. Mais à la fin je me pose une question. Dans un projet Agile le business analyst n'a donc plus lieu d'être ? A moins que le business analyst et le producteur owner soit la même personne et que la différence se fasse sur la méthode et les livrables. En effet dans les deux cas le BA et le PO sont l'interface entre le futur utilisateur du produit et le SI ?
bonjour à toi, merci pour ton commentaire. Le BA est plus que jamais utile en agile, puisque la vision de la conception logicielle est particulièrement "user-centric" (et non plus "product-centric" comme il y a qq années. Du coup, il faut bien des experts de la compréhension des enjeux économiques et métiers, et ça c'est de la Business Analyse :). En revanche, les compétences pour chaque rôle agile sont multiples (exemple: le PO a des compétences en gestion de projet, gestion de produit, et... business analyse. Le développeur a des compétences de dév, mais aussi parfois d'UX/UI designer, de BA et doit s'insérer / s'intéresser à la gestion de projet pour planifier les sprints etc). Le BA, quand il est un rôle agile, peut soit être PO, soit PPO (proxy PO), soit UX/UI Designer, soit testeur métier (voire QA), soit BA rattaché à la scrum dev team, soit PM, et j'en passe. Si tu as une fiche de poste de BA dans une ESN, par exemple, il se peut que sur une mission on te demande d'être PO. Puis sur une autre, PPO. Puis sur une autre BA chargé de rédiger les US et les critères d'acceptance, et de faire les tests métiers. Etc. Je t'invite à regarde d'autres vidéos de cette chaîne, j'en parle... C'est sujet à confusion et débat, car pas mature du tout en matière d'organisation interne et/ou projet. Mais quand on est formé à la BA, on sait comment se positionner clairement, avec une identité et des responsabilités comprises de tous. Le problème, c'est quand on est autodidacte (98% des BA), ou quand on ne perçoit son rôle de BA que par rapport à une gestion de projet précise (waterfall ou Scrum, par exemple). Je le dis souvent, mais de nos jours, la formation n'est plus une option... J'espère t'avoir aidé :).
DSFG : Quel type de projet l'utilise en 2024 ? Merci Alice. Oui je me demande qui l'utilise déjà dans le milieu informatique, et dans d'autres domaines.
@BestOfBusinessAnalyst bonsoir Alice, Je vais essayer de faire mieux 😉 Je me demandais si les methodes de projets classiques (donc non agile) utilisant DSFG (générales) était encore beaucoup utilisée. Si oui, dans quel genre de projet, d'entreprises ? La méthode agile ayant tellement pris d'ampleur dû à sa grande flexibilité, je demandais si les autres méthodes sont encore très présentes.
ah je comprends mieux. Oui bien sûr, les méthodes de gestion traditionnelles sont encore très utilisées. Aussi, il faut savoir que la plupart des chefs de projets ne sont ni formés ni certifiés. Et que de façon naturelle et instinctive, ceux-ci ont tendance à piloter leurs projets étape par étape, comme un simili modèle en cascade (sauf qu'ils ne connaissent pas les bonnes pratiques et livrables). Et aussi, quand on parle d'agilité, on parle en général de "pseudo agilité", avec juste le jargon (backlog produit, sprint, PO) mais derrière se cache du modèle traditionnel, tout ou partie. Si tu savais le nombre d'ESN qui me disent "mes clients me demandent de travailler en agile, alors qu'ils ne sont pas eux-mêmes agiles, ils veulent qu'on livre au forfait une solution pour laquelle ils n'ont pas identifié correctement leurs besoins réels - mais ils veulent qu'on livre vite un MVP. Alors pour avoir le contrat, on écrit "agile", sinon on est recalé lors de la propale". Pour en revenir à la gestion de projet traditionnelle, appliquée en connaissance de cause : oui et encore oui, il y a plein de cas où ces méthodes sont bien plus efficaces que l'agilité surtout mal appliquée. J'ai travaillé avec des clients dont la décision de choisir tel ou tel modèle de gestion de projet était motivée au préalable en vérifiant les prérequis dans une checklist. Selon les résultats de cette checklist, la recommandation était "waterfall", "scrum", "spirale" etc... Et ça, à mon sens, c'est la meilleure façon de faire. Pas de dogmatisme ni de mode, mais pragmatisme et connaissance éprouvée des bonnes pratiques méthodologiques + formation de l'équipe projet sur des dernières.
Les SFG ou peut - être faut- il des SF Trés Générales ? ne sont - elles pas utiles quand même pour avoir une vision générale du projet ? ou alors on utilise une Expression de Besoin pour ça...
c'est exactement ma vision : je n'ai jamais compris Scrum, que je trouve bien trop rigide, alors que les spécialistes l'ont classé comme "Agile" ! et personne ne parle de méthode hybride ! cascade + agile = meilleure vision / partage / apprentissage-feedback ex : la philosophie de scrum, telle que tout le temps présentée, met au second plan le développement de la structure et des supports, privilégiant l'apport de valeur, mais ce qui n'est pas dire officiellement, c'est que c'est surtout la "valeur perçue VISIBLE" ! et on ne parle jamais de la "valeur perçue d'exigence" (ex : stabilité, infrastucture IT, scalabilité etc) hors ces derniers points font partie de la préparation : SFG & éxigences Donc expliquer qu'un SFG / SFD doit être complet est aujourd'hui contre productif. Seuls les projets à plusieurs millions ou pluri-annuels dans le secteur privé nécessite cette analyse exhaustive (en théorie dans le public aussi, mais ce n'est pas fait d'où les dépenses incontrolées de l'empereur de france !) conclusion : des SFG & exigences (ici parcellaires) seraient nécessaires comme support (aspects invisibles mais nécessaires) (60% à 80% des 1ers sprints) pour terminer un "train" (SaFe) avec les aspects plus visibles (comme une récompense du travail précédent)
Hello, en fait, les SFG sont remplacées, dans le cadre agile, par des story maps. Puis déclinées en epics / themes. Aussi, il faut comprendre ce qu'on entend par l'agilité. Car il y a de l'agilité à petite échelle (Scrum) et grande échelle (comme SAFe). Et même à petite échelle, on peut agiliser le développement (les fameux product backlogs et sprints), mais également la réflexion stratégique sur le besoin source. Donc, on peut être hybride en matière d'organisation : traditionnel pour l'analyse des besoins métiers (AMOA), puis on fige les besoins. Puis seulement on va traduire en exigences logicielles, et cette partie sera "agile", avec un socle défini, mais à l'intérieur, une conception et un développement en mode agile. Si on passe maintenant à l'agilité à grande échelle (au niveau non pas du produit / projet mais du service ou de l'entreprise), on agilise l'ensemble du processus, depuis l'initiative à son analyse en fonction de ce qu'elle apporte à l'entreprise/ l'administration cliente, dans sa chaîne de valeur. Mais, pour conclure: il y a un manque de recul et de compréhension dans les entreprises et les DSI, ce qui fait qu'on mélange un peu tout, et que la confusion dessert les projets, produits et les entreprises elles-mêmes. Il faut se former et avoir une vision systémique, et là, tout est clair... (j'en parle dans mes formations, mais c'est un vrai chemin de croix pour transmettre inlassablement les bonnes pratiques!). J'espère t'avoir aidé à progresser dans ta compréhension.
hello, merci pour ta participation très intéressante à cet échange! Je crois que je vais faire une vidéo dessus :). Tu peux lire ma réponse à @FRED062FP, je parle de cette hybridation. Et outre scrum and Co, on a aussi des approches incrémentales et itératives comme RUP.
Bonsoir, 😄😄 merci. Ça me permet de faire des connexions. J ai eu un projet avec des SFG et on était dans un mode classique, je comprends. Clair et précis, merci d avoir pris la peine de me répondre 🙂🙂.
Bonjour Alice. Comme toujours une vidéo très intéressante. Mais à la fin je me pose une question. Dans un projet Agile le business analyst n'a donc plus lieu d'être ? A moins que le business analyst et le producteur owner soit la même personne et que la différence se fasse sur la méthode et les livrables. En effet dans les deux cas le BA et le PO sont l'interface entre le futur utilisateur du produit et le SI ?
bonjour à toi, merci pour ton commentaire. Le BA est plus que jamais utile en agile, puisque la vision de la conception logicielle est particulièrement "user-centric" (et non plus "product-centric" comme il y a qq années. Du coup, il faut bien des experts de la compréhension des enjeux économiques et métiers, et ça c'est de la Business Analyse :). En revanche, les compétences pour chaque rôle agile sont multiples (exemple: le PO a des compétences en gestion de projet, gestion de produit, et... business analyse. Le développeur a des compétences de dév, mais aussi parfois d'UX/UI designer, de BA et doit s'insérer / s'intéresser à la gestion de projet pour planifier les sprints etc). Le BA, quand il est un rôle agile, peut soit être PO, soit PPO (proxy PO), soit UX/UI Designer, soit testeur métier (voire QA), soit BA rattaché à la scrum dev team, soit PM, et j'en passe. Si tu as une fiche de poste de BA dans une ESN, par exemple, il se peut que sur une mission on te demande d'être PO. Puis sur une autre, PPO. Puis sur une autre BA chargé de rédiger les US et les critères d'acceptance, et de faire les tests métiers. Etc. Je t'invite à regarde d'autres vidéos de cette chaîne, j'en parle... C'est sujet à confusion et débat, car pas mature du tout en matière d'organisation interne et/ou projet. Mais quand on est formé à la BA, on sait comment se positionner clairement, avec une identité et des responsabilités comprises de tous. Le problème, c'est quand on est autodidacte (98% des BA), ou quand on ne perçoit son rôle de BA que par rapport à une gestion de projet précise (waterfall ou Scrum, par exemple). Je le dis souvent, mais de nos jours, la formation n'est plus une option... J'espère t'avoir aidé :).
@@BestOfBusinessAnalystquel monde tellement vaste.
Intéressante réponse à cette bonne question.
DSFG : Quel type de projet l'utilise en 2024 ?
Merci Alice.
Oui je me demande qui l'utilise déjà dans le milieu informatique, et dans d'autres domaines.
hello Guillaume, je dois être fatiguée, mais je n'ai pas compris ta question 😅. Si tu pouvais me la reformuler, je te répondrai avec plaisir😀
@BestOfBusinessAnalyst bonsoir Alice,
Je vais essayer de faire mieux 😉
Je me demandais si les methodes de projets classiques (donc non agile) utilisant DSFG (générales) était encore beaucoup utilisée.
Si oui, dans quel genre de projet, d'entreprises ?
La méthode agile ayant tellement pris d'ampleur dû à sa grande flexibilité, je demandais si les autres méthodes sont encore très présentes.
ah je comprends mieux. Oui bien sûr, les méthodes de gestion traditionnelles sont encore très utilisées. Aussi, il faut savoir que la plupart des chefs de projets ne sont ni formés ni certifiés. Et que de façon naturelle et instinctive, ceux-ci ont tendance à piloter leurs projets étape par étape, comme un simili modèle en cascade (sauf qu'ils ne connaissent pas les bonnes pratiques et livrables). Et aussi, quand on parle d'agilité, on parle en général de "pseudo agilité", avec juste le jargon (backlog produit, sprint, PO) mais derrière se cache du modèle traditionnel, tout ou partie. Si tu savais le nombre d'ESN qui me disent "mes clients me demandent de travailler en agile, alors qu'ils ne sont pas eux-mêmes agiles, ils veulent qu'on livre au forfait une solution pour laquelle ils n'ont pas identifié correctement leurs besoins réels - mais ils veulent qu'on livre vite un MVP. Alors pour avoir le contrat, on écrit "agile", sinon on est recalé lors de la propale". Pour en revenir à la gestion de projet traditionnelle, appliquée en connaissance de cause : oui et encore oui, il y a plein de cas où ces méthodes sont bien plus efficaces que l'agilité surtout mal appliquée. J'ai travaillé avec des clients dont la décision de choisir tel ou tel modèle de gestion de projet était motivée au préalable en vérifiant les prérequis dans une checklist. Selon les résultats de cette checklist, la recommandation était "waterfall", "scrum", "spirale" etc... Et ça, à mon sens, c'est la meilleure façon de faire. Pas de dogmatisme ni de mode, mais pragmatisme et connaissance éprouvée des bonnes pratiques méthodologiques + formation de l'équipe projet sur des dernières.
Les SFG ou peut - être faut- il des SF Trés Générales ?
ne sont - elles pas utiles quand même pour avoir une vision générale du projet ?
ou alors on utilise une Expression de Besoin pour ça...
c'est exactement ma vision : je n'ai jamais compris Scrum, que je trouve bien trop rigide, alors que les spécialistes l'ont classé comme "Agile" !
et personne ne parle de méthode hybride !
cascade + agile = meilleure vision / partage / apprentissage-feedback
ex : la philosophie de scrum, telle que tout le temps présentée, met au second plan le développement de la structure et des supports, privilégiant l'apport de valeur,
mais ce qui n'est pas dire officiellement, c'est que c'est surtout la "valeur perçue VISIBLE" ! et on ne parle jamais de la "valeur perçue d'exigence" (ex : stabilité, infrastucture IT, scalabilité etc)
hors ces derniers points font partie de la préparation : SFG & éxigences
Donc expliquer qu'un SFG / SFD doit être complet est aujourd'hui contre productif. Seuls les projets à plusieurs millions ou pluri-annuels dans le secteur privé nécessite cette analyse exhaustive (en théorie dans le public aussi, mais ce n'est pas fait d'où les dépenses incontrolées de l'empereur de france !)
conclusion : des SFG & exigences (ici parcellaires) seraient nécessaires comme support (aspects invisibles mais nécessaires) (60% à 80% des 1ers sprints) pour terminer un "train" (SaFe) avec les aspects plus visibles (comme une récompense du travail précédent)
Hello, en fait, les SFG sont remplacées, dans le cadre agile, par des story maps. Puis déclinées en epics / themes. Aussi, il faut comprendre ce qu'on entend par l'agilité. Car il y a de l'agilité à petite échelle (Scrum) et grande échelle (comme SAFe). Et même à petite échelle, on peut agiliser le développement (les fameux product backlogs et sprints), mais également la réflexion stratégique sur le besoin source. Donc, on peut être hybride en matière d'organisation : traditionnel pour l'analyse des besoins métiers (AMOA), puis on fige les besoins. Puis seulement on va traduire en exigences logicielles, et cette partie sera "agile", avec un socle défini, mais à l'intérieur, une conception et un développement en mode agile. Si on passe maintenant à l'agilité à grande échelle (au niveau non pas du produit / projet mais du service ou de l'entreprise), on agilise l'ensemble du processus, depuis l'initiative à son analyse en fonction de ce qu'elle apporte à l'entreprise/ l'administration cliente, dans sa chaîne de valeur. Mais, pour conclure: il y a un manque de recul et de compréhension dans les entreprises et les DSI, ce qui fait qu'on mélange un peu tout, et que la confusion dessert les projets, produits et les entreprises elles-mêmes. Il faut se former et avoir une vision systémique, et là, tout est clair... (j'en parle dans mes formations, mais c'est un vrai chemin de croix pour transmettre inlassablement les bonnes pratiques!). J'espère t'avoir aidé à progresser dans ta compréhension.
hello, merci pour ta participation très intéressante à cet échange! Je crois que je vais faire une vidéo dessus :). Tu peux lire ma réponse à @FRED062FP, je parle de cette hybridation. Et outre scrum and Co, on a aussi des approches incrémentales et itératives comme RUP.