La Business Analysis en contexte Agile

Business Analysis Agile

(temps de lecture moyen : 1 m 30 s)

Les particularité de la Business Analysis dans les projets Agile
Avantages et inconvénients pour la Business Analysis en contexte Agile

Pour la définition exacte, je vous renvoie à celle du Manifeste Agile (www.agilemanifesto.org), très complète. Retenez que le cycle de vie d’un projet Agile est centré sur le développement itératif de la solution ciblée.

Les particularité de la Business Analysis dans les projets Agile

Le BA en contexte agile
Source : IIBA
  1. La première particularité est qu’un tel projet ne comporte pas obligatoirement d’acteur « Business Analyst ». Par contre, dans tout projet agile, le rôle de Business Analyst existe. Il peut par ailleurs être exercé par plusieurs acteurs : développeur, leader technique etc.
  2. La collecte et l’analyse des besoins fonctionnels est réalisée de manière itérative. Ceux-ci sont affinés au fur et à mesure que la solution prend forme.
  3. Il est primordial de s’assurer que les besoins émergents restent cohérents avec les objectifs organisationnels, stratégiques et métier de la solution cible.
  4. Dans le cas où un acteur Business Analyst existe (= Product Owner), celui-ci doit s’assurer que l’information métier est disponible au niveau de granularité requis par l’équipe de développeurs. L’objectif est de permettre à celle-ci de travailler dans les temps impartis par l’itération. Rappelons qu’en Agile, plus les cycles d’itération sont courts, mieux c’est…
  5. La différence de timing des projets Agile a une conséquence sur le contenu des livrables.

Ceux-ci sont divisés en 2 catégories :

  • Dans la première catégorie, on retrouvera ceux nécessaires à l’itération en cours. Leur utilisation est temporaire. Le Business Analyst favorisera donc toute documentation visuelle apportant une valeur ajoutée rapide au développeur, comme les diagrammes ou les listes.
  • Dans la seconde catégorie, on retrouvera les documents dédiés à la description de la solution dans son ensemble. Leur utilisation est donc prévue sur le long terme. Ainsi, le Business Analyst s’attardera davantage sur la description : cas d’utilisation, spécifications détaillées, documents de formation etc.

Avantages et inconvénients pour la Business Analysis en contexte Agile

Les avantages d’une méthodologie Agile pour la Business Analysis sont liés à un retour d’expérience très rapide. Nul besoin d’attendre le déploiement de la solution pour découvrir les non-conformités. Cela permet donc d’accroître la qualité de la solution livrée.

Les inconvénients sont bien entendus liés à la compréhension et à l’utilisation des bonnes pratiques de la Business Analysis par les acteurs du projet. Si ceux-ci sont mal formés, les risques de livrer une solution construite sur une architecture et des fonctionnalités incohérentes sont d’autant plus grands. On ne s’improvise pas plus Business Analyst que développeur .NET. Une formation et une prédisposition s’imposent.

Un autre handicap est lié au dévoiement des pratiques de l’agilité… De nos jours, agile est trop souvent confondu avec rapidité, au point que l’un de ses pères fondateurs, Ron Jeffries, préconise d’arrêter de travailler avec ! (pour plus d’information, vous pouvez lire l’article Marre des pseudo-projets agiles! )

Vous comprendrez donc l’importance fondamentale de répertorier et de promouvoir les bonnes pratiques de la profession auprès des équipes Agile et du Client!

Envie de devenir Business Analyst?

Téléchargez dès maintenant mon e-book GRATUIT et apprenez enfin les fondamentaux de ce métier!

2 réflexions au sujet de « La Business Analysis en contexte Agile »

  1. Bonjour et merci pour ta question ;).
    Petite correction ; dans les approches agiles il n’existe justement pas de rôle Business Analyst, pas plus que celui de chef de projet. Effectivement, c’est très troublant, quand on est habitué à travailler dans un contexte projet traditionnel (cycle en V/en cascade), de se retrouver dans une équipe agile. Même avec une formation SCRUM, par exemple, les BA ont du mal à se positionner clairement. Pourtant, quand on a compris le périmètre de la BA, c’est assez simple :).
    L’analyse métier comporte les mêmes activités : analyses et recommandations d’avant-projet (étude d’opportunité, business case, cadrage), conception fonctionnelle (que ce soit au travers des spécifications fonctionnelles générales et détaillées dans les projets traditionnels, ou du Product Backlog et des user stories dans les approches agiles), tests fonctionnels, formation utilisateurs etc. Ce qui change, c’est le périmètre fonctionnel (toute la solution initialement planifiée vs des fonctionnalités découvertes au fur et à mesure des sprints), les livrables (très documentés en tradi, juste en support pour faciliter le dev en agile), le timing (jalons projet vs sprints), les parties prenantes (CP, architecte, technical leader, développeur, client MOA en gestion de projet traditionnelle, vs Scrum Master, Dev Team, Product Owner en agile SCRUM par exemple). Mais encore une fois, les activités perdurent.
    Je t’invite à lire un certain nombre d’articles déjà parus sur le sujet pour compléter ma réponse :
    le rôle du product owner“, “Business Analysts : faut-il avoir peur du grand méchant SAFe ?“, “4 étapes pour devenir un vrai Business Analyst agile“, “7 choses que les Business Analysts doivent savoir sur l’agilité” et “Marre des pseudo-projets agiles!“.

  2. Dans certain projet Agile, il existe déjà un acteur ” product owner”, et aussi un acteur” business analyst”.
    Alors, quel est la différence en terme de responsablité et rôle entre les 2?
    Qu’est ce qu’il faut faire concrètement pour un ” business analyst” dans un projet agile? ( la rédaction des US, ordonnance des product backlogue, tester la fonctionnalité, etc???)
    Merci à l’avance pour votre partage d’expérience

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *