Conduite de projet des spécifications fonctionnelles aux livrables

Objectifs :

  • obtenir des livrables rapidement ;
  • assurer la conduite du changement en montrant rapidement des écrans, maquettes ou prototypes aux utilisateurs ;
  • garantir que les livrables des spécifications fonctionnelles correspondent aux livrables de l’application.

Cas d’utilisation :

Un cas concret va nous permettre d’illustrer un mode d’application des méthodes agiles : la mise en place d’une application de gestion de travaux. L’article se focalise sur la réalisation des spécifications fonctionnelles et ne traite donc pas de l’audit de l’existant et de la collecte des besoins. L’application visé est en quelque sorte un ERP métier comprenant une gestion de commande qui encapsule une gestion de travaux et propose un extranet qui permet au client de suivre l’avancement de leur commande et de commander en ligne.

Principe itératif, allotissement, groupe de travail

Cette première étape d’allotissement à plusieurs objectifs :

  • paralléliser les travaux entre les différents intervenants : maîtrise d’ouvrage, maîtrise d’œuvre et utilisateurs ;
  • obtenir rapidement les premiers livrables ;
  • faciliter la gestion et la tenu du planning en permettant de travailler en avance de phase.

Pour le cas d’utilisation présenté précédemment, nous pouvons imaginer le découpage suivant :

  • extranet client ;
  • gestion des contacts ;
  • gestion des commandes ;
  • gestion des travaux ;
  • tableaux de bord et reporting ;
  • circuit de validation ;
  • reprise des données ;
  • intégration dans le système d’information ;
  • etc.

Ce découpage va donner naissance à des groupes de travail (GT) qui auront pour mission de réaliser le cahier de spécifications pour chacun des lots. Les utilisateurs impliqués dans les groupes de travail dépendent de leur fonction respective. Par exemple, pour les GT extranet client et gestion des contacts il semble judicieux d’y impliquer des commerciaux « référents », pour la gestion des travaux les techniciens opérationnels « référents », etc. Une maquette est réalisée et intégrée aux spécifications afin de valider la navigation et l’ergonomie.

Le schéma ci-dessous illustre le principe itératif qui va permettre d’aboutir aux livrables ainsi que la numérotation des versions.

Principe itératif des spécifications aux livrables
Principe itératif des spécifications aux livrables

Le document de spécifications fonctionnelles qui est utilisée pour développer le premier prototype est visionné en 0.9.

Les prototypes réalisées sur la base de la version 0.9 des spécifications fonctionnelles sont donc présentés rapidement aux futurs utilisateurs afin de recueillir les premiers retour et de réaliser une premier phase d’ajustement.

Ces ajustements sont reportés dans les spécifications fonctionnelles en incrémentant le numéro de version (0.9.X) ou X correspond au nombre d’itération. Outre la validation rapide des prototype auprès des utilisateurs qui offre de multiples avantages en terme de conduite du changement, cette façon de faire permet de mieux gérer le planning. Toutefois, il est important de « limiter » le nombre d’itérations pour ne pas voir « gonfler » les spécifications. La version 1.0 des spécifications sera finalement la version correspondant à la dernier itération sur les spécifications.

Cette démarches’appuie sur un mode itératif et incrémental : les spécifications « deviennent » une partie du produit : dès la première version des spécifications validées, la maîtrise d’œuvre débute le premier prototype du module correspondant pendant que la maîtrise d’ouvrage prépare le cahier de recette. Les utilisateurs valide la maquette puis les prototypes ; la phase de recette débute sur le premier prototype (V0.9).

Les livrables sont donc :

  • les spécifications v1.0 correspondant réellement au produit qui a été conçus ;
  • le produit ou module qui a été développé ;
  • le cahier de tests et les résultats correspondant ;
  • les sources de l’application et les tests unitaires associés ;
  • les tests de montés en charge réalisés par la MOEd ;
  • les documentations correspondant (API, Utilisateurs, Administration, Exploitation, etc.)
  • le cas échéant le prototype est validée RGAA sur les outils libres type : w3c, t.a.w, ou sur les outils propriétaire type ocawa.