De la gestion de projet à la gestion de workflow

Il y a une chose qui me chiffonne lorsqu’on s’intéresse aux méthodologies agiles, telle qu’elles sont définies « by the book », ou telle qu’elles sont enseignées. On y décrit un fonctionnement à base de sprints de développement, qui s’enchaînent les uns après les autres, avec une durée de l’ordre de la quinzaine de jours. Même en décrivant la partie qui se situe en amont du développement (écriture de user stories, gestion du backlog), et celle qui se situe en aval (tests, validation, mise en production), tout reste centré sur le développement.

Au final, dans la vraie vie, ces périodes de conception et de validation finissent par manger sur la période de 2 semaines qui devrait être consacrée au développement. On se rend compte assez vite des limites du système…

De mon point de vue, il faut prendre la gestion de projet à un plus haut niveau. Et il faut définir un workflow global, qui va permettre à tous les intervenants du projet de savoir ce qu’ils ont à faire et pour quand. Je vais illustrer cela en expliquant ce qui est mis en place dan mon entreprise ; c’est le fruit d’un process dérivé de la méthode Scrum, qui est affiné sans cesse depuis plus de 5 ans.

Phases et étapes

Pour commencer, le workflow des projets est découpé en 3 phases :

• Conception : Tout le travail qui va servir à définir fonctionnellement le projet.
• Développement : La réalisation technique du projet.
• Validation : Les différentes phases de test qui aboutiront à la mise en prod.

Chacune de ces phases peut contenir jusqu’à 6 étapes (que l’on « active » ou non en fonction des besoins du projet).

En phase de conception :

• Acceptation du projet : Le brouillon de projet écrit par un client interne est accepté. Juste pour vérifier qu’on ne nous demande pas la lune, et que c’est bien en phase avec les besoins de l’entreprise.
• Expression de besoin : L’expression de besoin du client est suffisamment claire pour qu’on lance le projet officiellement.
• Wireframes : Si le projet a besoin de wireframes (ce qui est souvent le cas pour des projets web), ils sont réalisés puis validés par les intervenants.
• Maquettes : Idem pour les maquettes.
• Cahier de test : Un cahier de tests doit être écrit par le chef de projets fonctionnel (équivalent au Product Owner en Scrum). Il déterminera les points essentiels qui définiront si le projet fonctionne ou non.
• Spécification fonctionnelle : Écrit aussi par le chef de projets, tous les détails du fonctionnement du projet y sont écrit. Ce qui est présent dans la maquette ne doit pas y être décrit, sauf si des interactions n’y apparaissent pas.

En phase de développement :

• Réunion de lancement : Clients et développeurs se rencontrent pour s’assurer que tout le monde a le même niveau d’information sur le projet, et lever les principales zones d’ombre.
• Spécification technique : Le développeur en charge du projet commence par faire ses analyses techniques, réfléchit à comment il va procéder et en écrit les grandes lignes noir sur blanc. Il fait une estimation fine du temps de développement et soulève les éventuelles questions techniques non triviales.
• Début du développement : Il est important de signifier aux clients qu’on a commencé à travailler sur un projet. C’est équivalent à déplacer un post-it sur un kanban-board.
• Fin du développement : Étape validée lorsque l’ensemble du développement est terminé et que le développeur a déroulé le cahier de tests.
• Tests automatisés : Suivant les projets, le développeur peut être amené à écrire des tests unitaires et/ou des tests Selenium.
• Validation du code : Le code produit est relu par au minimum un autre développeur.

En phase de validation

• Démo : Pour les projets ayant nécessité plusieurs jours de développement, le développeur présente au client le résultat. Cette étape est faite de manière informelle pour les plus petites réalisations.
• Validation du développement : Le projet est déployé sur une machine virtuelle, et le client déroule le cahier de tests.
• Validation du merge : Le projet est mergé avec les autres projets de la même release. L’ensemble de la release est deployé sur un serveur de test. Les développeurs vérifient que leurs projets fonctionnent correctement, sans régression causée par le merge.
• Validation en pré-production : La release est déployée en pré-production, et les chefs de projets fonctionnels déroulent un sous-ensemble des cahiers de tests.
• Validation en production : Après mise en production, les clients déroulent un sous-ensemble des cahiers de tests, pour vérifier que tout est conforme.
• Post-mortem : Si l’un des intervenants du projet estime qu’il le faut, une réunion est organisée pour revenir sur le déroulement des projets, ce qui s’est bien ou mal passé, les écueils rencontrés et comment faire pour ne pas répéter les mêmes erreurs à l’avenir.

Ces trois phases sont aussi importantes les unes que les autres. Un projet mal spécifié sera voué à l’échec. Un développement mal pensé ou dont l’avancement n’est pas communiqué ne pourra pas être testé et validé correctement. Enfin, si un projet n’est pas testé et validé avec toute l’attention nécessaire, on prend le risque de mettre des choses non acceptables en production (projet non conforme à ce qui était attendu, bugs de régression ou ajout de nouveaux bugs).

L’idée n’est pas simplement d’augmenter le nombre de statuts possible pour un projet (ou d’augmenter le nombre de colonnes dans un kanban-board), même si c’est un effet mécanique. L’important est surtout de penser et suivre le projet dans son entièreté.

Un tel workflow peut sembler complexe, mais sa représentation graphique est assez simple.
Pour un projet donné, nous pouvons choisir de voir toutes ses étapes en même temps :

Ou bien nous pouvons choisir une version condensée (dans les listes de projets, par exemple), qui montre l’étape en cours dans chaque phase :

Je pense sincèrement qu’à force de vouloir simplifier à l’extrème la gestion de projet, et en se focalisant trop sur le développement au détriment des autres étapes du projet, on perd de vue l’ensemble du travail nécessaire. En gérant le workflow global, on a plusieurs effets positifs :

• Chacun sait ce qu’il a à faire, et pas uniquement les développeurs. Les clients, les designers, les chefs de projets, … tout le monde peut avoir une todo-list claire lui indiquant ses priorités à un instant T (écrire une spécification, relire du code, valider un projet en pré-production, etc.).
• Il est possible de faire un rétro-planning. Chaque étape pouvant avoir une deadline, il est très facile de voir si un projet peut être mis en production à une certaine date. Plutôt que d’attendre de voir si le développement peut commencer à temps, on peut réagir dès que la validation du besoin est en retard.
• Les personnes qui n’ont pas de notion en gestion de projet et qui ne peuvent pas être formées à l’agile/Scrum/kanban (ce qui est normal et logique dans une entreprise où différents métiers sont représentés) ont une vue claire de l’état d’avancement des projets qui les intéressent.

Je ne suis pas en train de dire que le fondement principal de la méthodologie agile − à savoir de découper finement les projets et de faire des itérations courtes pour s’assurer fréquemment qu’on avance dans la bonne direction − est erroné. Pas du tout.
Je dis juste que partout où j’ai vu de l’agile « classique », la gestion de projet était plus une gestion des développements qu’autre chose (avec un peu de validation avant mise en production), et que cela forçait à avoir des process parallèles pour gérer les autres aspects comme les spécifications ou les maquettes. Et la nécessité de former l’ensemble de l’entreprise à l’agile est certes une bonne chose, mais trop souvent les agilistes oublient que la plupart de leurs collègues ont un travail qui n’a rien à voir avec le leur (demander à un marketeux de retenir les concepts du Scrum est illusoire ; un modérateur ne devrait pas se sentir perdu lorsqu’il se retrouve à suivre 1 à 2 projets par semestre).