La Business Analysis en contexte Agile

(temps de lecture moyen : 2 m 30 s)

> Le Manifeste Agile et les piliers de l’agilité

> Les particularité de la Business Analyse dans les projets agiles

> Avantages et inconvénients pour la Business Analyse en contexte agile

La gestion de projet est en constante évolution depuis le début de l’informatique en entreprise. Au fil des années, des méthodes nouvelles ont vu le jour et ont été expérimentées dans le monde entier sur des projets extrêmement variés. Après la gestion traditionnelle en cascade, puis le cycle en V, les méthodes incrémentales et itératives et finalement le modèle en spirale, sont apparues les méthodes agiles à petite échelle au début des années 2000, puis une décennie après, les méthodes agiles à grande échelle.

En effet, les projets informatiques gérés de manière traditionnelle  faisaient face à un taux d’échec dramatiquement élevé, et deux causes racines promettaient d’être traitées grâce à l’approche agile : le manque de feedback utilisateur et la durée du cycle de développement.

L’une des méthodes agiles les plus utilisées au monde est SCRUM, détrônant de loin les Extrem Programming (XP), Feature Driven development (FDD), et autres Crystal Clear. Plus récemment, le framework SAFe qui combine les méthodes agiles et le lean management est entré massivement dans les organisations souhaitant s’agiliser à grande échelle (et non pas uniquement dans le cadre de la mise en place d’un projet informatique).

Le Manifeste Agile et les piliers de l’agilité

Toutes les méthodes agiles suivent les 12 principes généraux du Manifeste Agile que je vous recommande de lire au préalable.

Les piliers du manifeste agile sont les suivants :

• Les méthodes agiles ont une approche itérative au travers de cycles appelés « sprints ».
• Les méthodes agiles valorisent les individus, les interactions et la collaboration plutôt que les processus et les outils.
• Elles valorisent également le logiciel opérationnel plutôt que la documentation.
• Les méthodes agiles privilégient la collaboration avec le Client plutôt que la négociation contractuelle.
• La réponse flexible aux demandes de changement est également privilégiée, contrairement au strict suivi d’un plan comme le requièrent les méthodes de gestion de projet traditionnelles.
• Les méthodes agiles nécessitent une formation préalable de tous les acteurs du projet, notamment en raison de la terminologie spécifique partagée par la « Project Team ».
• Enfin, le Business Analyst comme le reste de l’équipe, peut être sollicité à tout instant. Ceci est donc différent des gestions de projet traditionnelles pour lesquelles la charge de travail des parties prenantes dépend de la phase du projet.

Les particularités de la Business Analyse dans les projets agiles

Source : IIBA®

1. La première particularité est qu’un projet agile 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. Le recueil et l’analyse des besoins ainsi que la conception fonctionnelle sont réalisés 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 praticien en Business Analyse existe (par exemple, le 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 agiles a une conséquence sur le contenu des livrables (appelés des artefacts).

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

• Dans la première catégorie, on retrouvera ceux nécessaires à l’itération (sprint) 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 fonctionnelles détaillées, documents de formation etc.

Avantages et inconvénients pour la Business Analyse en contexte agile

Les avantages d’une approche agile pour la Business Analyse 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 Analyse 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 agiles et du Client!