En fait on s’en fiche de comment ça s’appelle. C’est le rôle et les responsabilités de la personne qui sont importants.
Mon impression c’est que BA est compris comme un métier (et pas forcément le même selon les orga) alors que PO est un rôle dans un framework. Un PO reste le même rôle dans le framework, alors qu’un BA peut endosser plusieurs rôles.
Là où ça se complique c’est quand on parle de PO mais en dehors du framework Scrum, forcément il perd son sens Scrum et il est donc à redéfinir.
Bref, un mot ne suffit pas à se comprendre Surtout si on a pas le même référentiel.
Merci @jplambert et @const pour votre réponse et votre invitation. Je ne vais pas pouvoir me soustraire. Je serai avec vous sur le Live avec plaisir. Vous pouvez compter sur moi.
Marrant les sujets qui remontent tout seul… feature sympa !
Pour moi (et mon organisation) le BA dans le contexte Agile, c’est un BA et QA.
Tout le monde ne bosse pas forcément sur une « appli », certains évoluent dans un écosystème. IHM, API, référentiels, …
L’US et ses conditions d’acceptations qui constituent le DoD portent en général sur les cas nominaux. Rarement sur les effets de bords ou les adhérences aux systèmes conjoints. Le BA/QA me parait utile/nécessaire quand l’environnement nécessite des plans de test assez lourds et chronophages pour garantir le DoD dans un écosystème avec des adhérences entre applicatifs…
system
(system)
Remonté automatiquement dans la liste ()
29
Surtout si on a pas le même référentiel.
