Editions ENI Livres | Vidéos | e-Formations
Recueil des besoins et gestion de projet
Introduction
Une partie du recueil des besoins est incluse dans les méthodologies de gestion de projet. Même si ces méthodologies ne permettent pas d’éliciter, de spécifier le besoin, de minimiser les ambiguïtés elles peuvent néanmoins gérer la priorisation, les dépendances et même le contrôle qualité.
Il existe deux grandes familles de gestions de projets. Les méthodes traditionnelles, elles sont aussi dites en cascade, supportées par des consortiums tels que PMP, PRINCE, etc. Elles sont maintenant concurrencées par les méthodes agiles. Celles-ci peuvent être SCRUM, KANBAN, etc. le but de ces méthodes est d’être plus adaptatives que les traditionnelles.
Ce chapitre n’a pas pour vocation de vous présenter les méthodes de gestion de projets dans le détail. Nous nous intéresserons donc aux interconnections entre le recueil des besoins et la gestion de projets, dans le but de comprendre les limites mais aussi les avantages des différentes approches. La présentation des méthodes permettra donc une compréhension de notre sujet par le biais de la gestion du scope.
Dans un contexte traditionnel
Les méthodologies de gestion de projets traditionnelles, qu’elles soient PMP, PRINCE 2… sont aussi nommées en cascade. Ce sont les mêmes méthodes qui servent à créer une solution décisionnelle ou un Airbus.
Ces méthodes étant assez rigides, elles permettent néanmoins d’assurer une certaine cohérence. Voyons les plutôt comme des boîtes à outils. On utilisera le processus en fonction du contexte, des difficultés et des risques du projet. Il arrive que l’activité et le livrable associé ne soient pas strictement nécessaires. Cependant, en vérifier la nécessité contribue déjà à améliorer sensiblement la gestion des risques.
1. Présentation
Les méthodes traditionnelles sont très orientées sur les processus. Il s’agit ici de suivre une séquence d’activités. Chacune d’entre elles comportant des livrables dont le format est souvent prédéfini.
Même s’il existe des différences, elles ont toutes une approche similaire : éliciter (collecter) les besoins, définir ce qui entre et sort du scope, définir les tâches à effectuer pour répondre au scope, vérifier que le scope fonctionnel est couvert par la solution, gérer les changements du scope.
Processus de gestion de projet traditionnel
2. Éliciter les besoins
Une fois l’objectif du projet défini et la liste des parties prenantes complétée, il faut alors récupérer la liste des besoins fonctionnels. Pour cela, l’analyste pourra utiliser un panel de techniques choisies parmi les activités proposées dans le chapitre Activités de recueil des besoins. Trois livrables sont associés avec cette activité : la documentation des besoins, le plan de gestion des besoins et une matrice de traçabilité.
La documentation des besoins
Ce ou ces documents décriront la liste des exigences qui permettront de répondre aux besoins fonctionnels. Un document peut être construit de façon itérative. Dans un premier temps, les descriptions seront de haut niveau, puis on affinera avec le temps. Ils doivent cependant passer certains...
Dans un contexte agile
1. Présentation
L’objectif principal des méthodologies agiles est de délivrer rapidement un produit ayant la meilleure qualité possible grâce à une gestion lean.
Le lean management est une philosophie issue des systèmes de productions de Toyota dans les années 1990. Cette manière de gérer vise à produire seulement les composants ajoutant de la valeur au produit final et à réduire tout ce qui n’en ajoute pas. Toyota était célèbre pour sa réduction des seven wastes que l’on pourrait traduire par sept déchets (même si la traduction du mot japonais original s’approche plus de "futilité" que de "déchet") : la surproduction, le surstockage, le transport de matériel inutile, le surprocessing, les mouvements de personnel inutiles, les erreurs défauts et rebuts, les temps d’attente et les délais, la sous-utilisation de compétences. On peut facilement adapter cette philosophie à des solutions décisionnelles : la capture de données trop granulaires, un stockage redondant et des historiques trop granulaires ou/et trop longs, des couches de l’entrepôt trop nombreuses, des process trop compliqués, des équipes mal organisées, mal employées (développeurs back-end employés à développer du front-end…), des bugs et des problèmes de qualité de données, des processus mal synchronisés, des ressources matérielles non optimisées/utilisées, un management trop rigide et un manque de formation.
On se concentrera ici sur la livraison des exigences qui ont une forte valeur ajoutée pour le client (responsable produit, customer…). Les méthodologies agiles supprimeront l’inutile pour se focaliser sur les besoins strictement nécessaires. Cela est possible grâce à une méthode adaptative et réactive plutôt que prédictive et rigide.
Les méthodologies agiles mettent l’accent sur les personnes plus que sur le processus. Ainsi, une collaboration étroite entre les parties prenantes permettra de comprendre les besoins et la solution développée. Celle-ci ne comportera ni plus ni moins...
Proposition d’approche hybride
Cette démarche hybride s’approche plus d’un cycle en "W", à mi-chemin entre les deux grands types de pratiques : agile quand c’est possible, traditionnelle quand c’est nécessaire. On tirera donc le meilleur des deux mondes. C’est celle que j’ai expérimentée et qui s’est révélée la plus flexible concernant les différents projets que j’ai été amenée à conduire. Mais alors, comment ça marche ? Comme c’est hybride, tout est déjà expliqué dans les autres chapitres avec plus de détails. Afin de ne pas être trop répétitive, seules les étapes seront détaillées ci-dessous avec les références aux chapitres concernés.
Pour tirer le meilleur parti de ce chapitre, il est nécessaire d’être à l’aise avec d’autres concepts développés dans ce livre, l’arbre de buts, les méthodes agiles, la méthode des thermomètres, l’analogie du restaurant, l’analyse des processus, le sauvetage en mer.
Cette méthode permet de faciliter la gestion du scope et des délais. Elle facilite aussi le découplage des exigences (les dépendances) grâce à une gestion de la granularité et un découpage des phases de développement. Pour des problématiques de charge de travail et de délais de livraisons (cf. Quelles informations recueillir et quand ?), de réutilisabilité des composants, de contraintes d’architecture, etc. il paraît difficilement envisageable et inefficace de gérer les rapports et la construction de la base de données de façon imbriquées.
1. Le processus
Le processus est composé de cinq étapes : comprendre les objectifs, définir les process, construire les chargements et le squelette de données, définir le modèle de données métier et définir la visualisation. Les trois dernières étapes peuvent être effectuées de manière itérative. Cela peut être les différentes parties du process séparément pour une modélisation dimensionnelle (type...