Accueil » Découvrir la Business Analyse » La BA dans la gestion de projet traditionnelle
Le Business Analyst travaille essentiellement sur les tâches en haut du cycle en V Les activités du Business Analyst lors du développement technique de la solution Combien de Business Analysts pour couvrir le cycle en V ?
En informatique, on oppose fréquemment les méthodes traditionnelles du type cycle en V ou en cascade aux méthodes et approches agiles.
5 différences majeures différencient les projets gérés de manière traditionnelle et ceux gérés de manière agile, comme vous pouvez le voir dans le tableau ci-dessous. C’est important de bien comprendre cela, car le rôle du Business Analyst, ses activités et ses livrables en dépendent.
Le cycle en V est un modèle conceptuel désignant le cycle de vie de réalisation d’un logiciel.
En synthèse, les tâches de développement se situent en bas du V. Toutes les étapes de test et de validation de la solution (partie ascendante du V) correspondent à des étapes de spécifications (partie descendante du V).
Ainsi, la recette client (acceptance) permet de tester l’implémentation des besoins fonctionnels généraux. Également, lors des tests fonctionnels, le Business Analyst vérifiera l’adéquation entre les spécifications fonctionnelles détaillées et le logiciel etc.
Le Business Analyst n’a pas la même charge de travail tout au long de ce cycle. En effet, il sera essentiellement sollicité dans les tâches en haut du cycle en V. Par exemple, il aidera le Client à rédiger son cahier des charges, ou à effectuer le cadrage. Il pourra aussi rédiger les spécifications fonctionnelles, tester fonctionnellement le logiciel et effectuer la conduite du changement.
Pendant le développement technique de la solution, il y a souvent un creux d’activité pour le Business Analyst. Je ne parle pas ici des projets de Business Intelligence ou d’implémentation d’ERP, qui requièrent également une compétence technique. Dans ces cadres précis, le Business Analyst est aussi occupé en période de développement.
Dans les autres cas, le Business Analyst doit attendre que la solution soit assez mature pour préparer ses tests fonctionnels. Cette période peut cependant être très active. En effet, il y a souvent un gros travail de rédaction de la documentation de formation utilisateur. D’autre part, il est nécessaire de préparer la gestion du changement, qui peut aller de l’analyse stratégique au niveau de l’Organisation jusqu’à la formation utilisateur.
Notez que pendant cette période, l’équipe de développement sollicite également le Business Analyst. Celui-ci est amené à clarifier les besoins, ou à réfléchir conjointement à leur remise en cause en cas de limites techniques non prévues.
Un Business Analyst peut donc être occupé sur le projet depuis le tout début jusqu’au Go Live. Cependant, le découpage des tâches par le chef de projet, ou tout simplement le manque de ressources polyvalentes peut conduire à la ségrégation des activités. On verra ainsi sur certains gros projets une kyrielle de Business Analysts ayant chacun sa spécialité.