Publié en mai 2011

L’analyse opérationnelle du projet

Dans un projet traditionnel, la création du WBS permet de préparer l’exécution de l’ensemble des tâches à effectuer. Dans le cas de projets logiciels, c’est impossible, parce que seuls des éléments partiels sont prédéterminés. Il est donc primordial de bien planifier le cadre temporel dans lequel évoluera l’équipe. Il faut alors procéder par itérations, en définissant leur nombre et leur durée dès le commencement. Les itérations constituent le cadre rigide du projet, chacune devant démarrer et se terminer dans les temps initialement prescrits. Une itération ne devrait jamais être trop longue ni trop courte. Dans le premier cas, la détermination dynamique des tâches est trop espacée, alors que dans le second, peu de travail est accompli, la majorité du temps étant consacré à multiplier les itérations.

La durée habituelle des itérations dans les projets de logiciel est de deux ou trois semaines. Elles durent parfois plus longtemps, si l’équipe est gérée de façon matricielle et que ses membres ont des responsabilités dans plusieurs projets exécutés en parallèle.

Chaque itération doit contenir un certain nombre de tâches prédéterminées en plus des tâches décidées en cours d’exécution. Par exemple, chaque itération doit s’amorcer par une évaluation du travail accompli, un repérage des nouvelles tâches à entreprendre et une évaluation de leur durée. Chaque membre de l’équipe se voit attribuer une ou plusieurs tâches pour la durée de l’itération. À la fin de chaque itération, une version exécutable du système logiciel doit être obtenue, pour permettre de valider le chemin parcouru. Lorsqu’un grand nombre de tâches est recensé au début d’une itération, elles doivent être hiérarchisées.

Il est préférable de rencontrer le client au début de chaque itération pour lui expliquer l’état du projet et obtenir son avis sur la hiérarchisation des prochaines tâches. Cette façon de procéder est intégrée dans la méthode Scrum.

L’une des tâches essentielles de chaque itération est la mise à jour des risques, d’autant qu’ils sont rarement statiques dans les projets logiciels. Puisqu’il existe toujours des questions ouvertes jusqu’à ce que le logiciel soit fonctionnel, les risques fluctuent selon les éléments réalisés au cours de chaque itération. Avant d’établir la priorité des tâches à accomplir lors d’une itération, les risques techniques associés aux éléments logiciels devraient toujours être réévalués, le choix des tâches étant ensuite décidé pour tenter de réduire les risques les plus graves.

Après que la ventilation des itérations dans le temps ait été faite, il est primordial de statuer sur les principaux jalons du projet. Ces derniers représentent des livrables précis, habituellement liés à une décision de poursuite ou d’arrêt (go/no-go decision) du projet. Des périodes de validation, pour évaluer les jalons essentiels du projet, doivent être instaurées. Ces jalons sont habituellement établis à rebours, en déterminant à partir des derniers livrables les éléments essentiels à leur atteinte. Un plan de contingence devrait être mis en place dès le début du projet pour chaque jalon fondamental. Ainsi, s’il n’est pas atteint, un jalon devrait nécessairement déclencher un profond remaniement du déroulement du reste du projet.