Piloter une recette

Le pilotage budgétaire

Dans la présente section, nous aborderons une tâche transverse aux projets de recette : son pilotage par la charge.

Nous n’entrerons pas dans des considérations financières faisant intervenir les coûts des ressources humaines et techniques : ce livre n’est pas à destination des directeurs de projet.

Nous n’aborderons pas non plus l’évaluation de charge et son suivi pour les tests unitaires, estimant que cette tâche fait partie intégrante de l’évaluation et du suivi de la phase de réalisation par le CP MOE.

Pour mémoire, nous rappelons que nous avons préconisé dans le chapitre Organiser les tests unitaires une fourchette de 20 à 33 % de la charge de développement pour estimer l’effort nécessaire et suffisant à consacrer aux tests unitaires.

Nous allons détailler en revanche :

Le pilotage d’une recette technique dans un chantier de release.
Le pilotage d’une recette technique dans un chantier de maintenance.
Le pilotage d’une recette fonctionnelle.

1. La recette technique d’un projet de release

Nous avons décomposé un projet de recette en quatre tâches (ORGANISER, PRÉPARER, EXÉCUTER, CLÔTURER) décomposition à laquelle nous ajoutons PILOTER bien évidemment.

Logiquement, évaluer la charge globale consiste à évaluer celle de chacune de ces tâches.

a. Évaluer la charge de l’organisation

La tâche ORGANISER consiste à produire principalement deux livrables : le plan de test et le dossier d’organisation.

Sa charge est logiquement consommée dans son intégralité par le CP Recette.

Cette activité réclame une charge fixe plus ou moins indépendante de la taille du projet qui pourra aller de 1 jh à 10 jh. Elle sera d’autant plus chronophage que vous aurez des entretiens à conduire si vous devez effectuer une analyse de risques et une collecte d’exigences.

Mais des considérations techniques peuvent aussi vous demander plus de temps, par exemple une réflexion sur la constitution pertinente d’une plateforme de tests. Nous songeons ici notamment aux recettes techniques des applications mobiles qui nécessitent une réflexion poussée...

Risques et reporting

1. Les risques d’un projet de recette

a. En recette fonctionnelle ou VABF

Le principal risque se situe dans l’absence d’une structure en charge des recettes techniques.

Cette absence se traduit par un besoin de compenser l’effort de test en recette fonctionnelle, compétence que la MOA n’a pas toujours.

Aussi, lorsque l’application présentera un taux trop important d’anomalies, la recette fonctionnelle ne sera plus possible… et la recette technique non plus puisque non anticipée.

Seule solution : une recette "pompier".

Un risque secondaire est cependant possible si une équipe d’experts intervient pour des recettes technico-fonctionnelles : que la MOA se décharge de sa responsabilité d’homologuer un métier sur les épaules de ressources qui prennent alors des décisions trop importantes au regard de leur niveau d’implication.

Ce risque peut survenir principalement lorsque les recettes sont externalisées auprès d’un prestataire de services.

b. En recette technique

Il n’est pas rare que les spécifications fonctionnelles changent en cours de projet : une expression de besoins mal cadrée représente donc un premier risque essentiellement vers la fin de la phase PRÉPARER car il ne sera peut-être plus possible de rectifier les cahiers de recette : il y a un planning à tenir.

Les autres risques de ce projet sont davantage localisés dans la phase EXÉCUTER de la recette, à la première réception de l’application dans un chantier de release.

Dès lors que l’application sort de la phase de développement, sa relative qualité représente le premier des risques. C’est à ce moment-là seulement que l’on saura si l’application est testable. Le début...