La conduite de projet

Ce n'est pas l'outil qui fait la méthode mais la méthode qui a besoin d'un outil.

Souvent, les équipes cherchent un outil qui solutionnerait la gestion de projet mais ça ne fonctionne pas. Une méthode, c'est avant tout une philosophie de conduite dont le seul but est d'assurer le succès du projet. Il faut pouvoir l'expliquer sans avoir à montrer un outil informatique et c'est ce que nous allons voir ici.

La méthode MMSK

MMSK, pour le Meilleur de Merise, Scrum et Kanban.

Merise ?

Pour les plus anciens, c'était LA méthode pré-agilité, pré-internet. Elle définit plusieurs modèles dont un dit waterfall (en cascade) pour dire que les étapes s'enchainaient (sans retour arrière). Merise donnait le cycle de vie du projet suivant :
- Schéma directeur
- Étude préalable
- Étude détaillée
- Étude Technique
- Réalisation
- Mise en oeuvre
- Qualification

Nous avons gardé ce cycle de vie car, dans les méthodes dites "agiles", le passage à la création de post-it est à notre sens souvent prématuré. Nos projets commencent donc par une étude préalable, le schéma directeur correspondant à l'inscription d'un projet dans le calendrier de l'entreprise.

L'étude préalable

C'est le début du cycle de vie de notre projet. De cette étude devra ressortir le périmètre du projet, vérifier que les objectifs sont bien définis, réalistes, en chiffrer le temps et le budget nécessaire à leurs réalisations. Il est probable qu'à ce niveau de l'étude plusieurs sous projet soient créés. Par exemple, lors de la création d'une application, ce peut être l'occasion de travailler son image avec une campagne de communication. Il faudra peut-être communiquer sur sa mise en service pour accompagner le changement, créer une charte graphique, former des personnes, ...

L'étude détaillée

Pour chaque projet, il faudra identifier les acteurs et préciser leurs rôles. Pour chaque rôle, il faudra définir, avec une extrême précision, les différents cas d'utilisation. Le livrable sera un Cahier des Charges Fonctionnel (CCF).

Pour rédiger ce cahier des charges fonctionnel avec le directeur produit (product owner), nous utilisons la verbalisation des cas d'utilisation inspirée par Alistair Cockburn (sans utiliser UML) :

Les cas d'utilisation décrits dans le CCF sont le fruit d'interviews qui peuvent être nombreuses, des acteurs du système cible ou de l'expression des besoins par le product owner.

Ils ont la forme suivante :

Un utilisateur est une personne qui est connectée à l'application et qui n'a pas de rôle particulier.

Si un utilisateur n'a pas les droits pour accéder à une partie de l'application, un message s'affiche momentanément : "Vous n'avez pas les droits d'accès pour cette ressource".

La bonne verbalisation d'un cas d'utilisation est le pont entre un besoin fonctionnel et une réalisation technique, le gage de sa bonne implémentation. Tout de suite, nous définissons les choses : si un message doit s'afficher, je le note.

La réussite d'un projet repose en grande partie sur la qualité du travail de rédaction. Une fois les cas d'utilisation rédigés, il sera possible de définir les grands domaines du projet et de réaliser un découpage organisationnel ainsi qu'un planning.

Le CCF devra donc contenir a minima :
- une liste des acteurs et de leurs rôles.
- pour chaque rôle, les cas d'utilisations verbalisés.
- un découpage organisationnel
- un planning
Il peut également contenir les jeux de données à utiliser, la méthode de test et de validation envisagée, les contacts.

L'étude technique

Le CCF en main, l'ingénierie logicielle détaille l'exécution technique : les différents services qui vont composer le système, leurs technologies, leur implémentation et la façon dont ils vont interagir/communiquer. C'est le dépôt de référence pour toutes les personnes qui travaillent sur le projet : développeurs, designers, intégrateurs. Il n'a pas vocation à centraliser les informations mais plutôt à dire où les trouver.

La réalisation

C'est là que nous quittons Merise pour Scrum/KanBan. À ce stade, les personnes qui vont travailler sur le projet ont 2 types d'informations à leur disposition :
- les cas d'utilisation
- où et comment les implémenter
Les cas d'utilisation sont convertis en Post-it et organisés en Sprint, un regroupement de cas d'utilisation qui représente des étapes de validation par le product owner.

Les post-it d'un Sprint partent d'une colonne "à faire", passent par "en train" puis "à tester" et terminent dans "fait". Que ce soit Scrum ou Kanban, le principe est de limiter à 1 (voire 2) le nombre de Post-it dans le "en train" (WIP , Work In Progress en anglais). L'idée est de rester concentré sur une tâche.

Scrum fige les sprints, il est impossible de rajouter un post-it dans la colonne à faire. C'est souvent cette restriction qui encourage la méthode Kanban. Cette dernière autorise l'ajout de "à faire". La méthode est plus pensée comme un flux que comme des itérations. Pour garder les itérations, nous autorisons l'ajout de "à faire" si et seulement si, celui-ci est indépendant des autres. Les itérations sont relativement courtes (environ 3/4 semaines).

A chaque sortie de Sprint, un point est fait avec le product owner sur l'avancée du projet comme défini dans le CCF et son planning. A chaque point il est envisageable de mettre à jour le CCF, et notamment les cas d'utilisation en le versionnant. Ces avenants au projet peuvent faire l'objet d'arbitrage et sont susceptibles d'être facturés. Ceci dit, il est primordial de mettre à jour ces documents.

Le Scrum Master

Chez nous, c'est le chef de projet. Il a 2 missions : être l'interlocuteur du product owner et isoler l'équipe de toute distraction extérieure.

La mise en oeuvre

La mise en oeuvre intervient assez tôt dans le cycle de vie ; pour le moins, une mise en oeuvre sur une infrastructure de test. Les infrastructures cibles permettent de simuler facilement un futur environnement de production et de faciliter les points post-sprint.

Le passage en production peut être très différent s'il s'agit d'une nouvelle application ou s'il s'agit de se substituer à une application existante connectée à un dépôt de données. Ce qui sera documenté dans les annexes du CCF.

La qualification, la recette.

Le point du dernier Sprint vaut qualification fonctionnelle. La mise en production vaut qualification opérationnelle.

Commence une période de maintenance curative. Les problèmes qui relèvent de l'implémentation technique doivent être corrigés. Les problèmes fonctionnels qui relèvent d'un oubli d'implémentation doivent faire l'objet d'un avenant au cahier des charges et sont donc sujets à arbitrage et engendre une facturation.

En résumé

La méthode, c'est la clé de la conduite de projet. Une phase préparatoire avec une définition verbalisée des cas d'utilisation est la garantie d'une bonne implémentation des fonctionnalités souhaitées.
La réalisation se fait par itération et se termine par un bilan. Il est possible de modifier les sprints, sous certaines conditions. Le nombre de "à faire" est limité. Il est possible de modifier le CCF mais le projet repart dans son cycle de vie.
La mise en oeuvre est largement anticipée par les techniques de CI/CD et la technologie "cloud"

Quel outil utilisons-nous pour mettre en oeuvre cette méthode ?