Dernier article sur le thème "pas d'agilité en forfait" de mon cahier. Je vais écrire ici à propos des pratiques agiles de conduite de projet applicables même dans un cadre non agile, comme un projet au forfait. Il s'agit cette fois de pratiques qui découlent (entre autres) de Scrum : le morcellement des tâches, le chiffrage par échelons, le management visuel et les réunions sur un temps limité.
Commençons par le morcellement des tâches. Lorsqu'une affaire est conclue, que les parties se sont mises d'accord sur un périmètre, le plan du projet est constitué de morceau trop gros au chiffrage incertain. Cela peut être un bon exercice de reprendre les différents items avec l'équipe afin de les morceler en tâches d'un ou deux jours. J'y vois plusieurs intérêts. Tout d'abord, cela déclenche une discussion technique. On élabore rapidement une solution technique au problème posé. La décomposition en tâches vient alors naturellement. Cela mène également à une réévaluation du chiffrage global de la partie. S'il est moins élevé, on se réjouit. S'il est plus élevé, on peut faire le paris que les autres éléments seront sur-chiffrés ou alors revoir la conception technique et refaire une distribution en tâches. C'est quelques chose que j'ai fait en contexte Scrum pour chiffrer des stories complexes[1] avec l'équipe.
Toujours concernant le chiffrage, j'ai adopté le façon systématique le chiffrage par échelon, classiquement avec les termes de la suite de Fibonacci (1, 2, 3, 5,...). Le chiffrage reflète l'incertitude. Pourquoi choisir 4 au lieu de 3 ou 5 ? Est-ce qu'on a une connaissance suffisante du problème pour faire une estimation supérieure à 5 ? Le chiffrage par échelons permet de comparer les différents items chiffrés : cet item est plus complexe que celui-ci que j'ai chiffré à trois, je le chiffre donc à 5. La pratique de chiffrage est quelque chose d'abstrait après tout. Elle permet juste d'avoir un budget.
Sans transition, parlons du management visuel. Beaucoup de fanatiques d'Excel doivent trouver cette pratique ridiculement réactionnaire. Cependant, avec un tableau et des post-it, vous aurez un contrôle étonnant sur vos projets ! Utiliser les principes du Kanban avec un nombre limité de tâches par étape est également une bonne idée pour améliorer la productivité. Le tableau doit pouvoir être vu et être accessible à chaque membre de l'équipe pour le faire évoluer en temps réel.
Terminons par les réunions quotidiennes. Elles sont une bonne idée s'il y a un nombre limité de membres dans l'équipe (5 ou 6 personnes ?). Dans le cas contraire, cela demande beaucoup d'effort pour bouger tout le monde et ces réunions deviennent ennuyeuses. Je vous déconseille d'adopter cette pratique si vous n'avez pas de tableau de tâches sur lequel vous appuyer, le but étant que chaque membre puisse avoir un aperçu global de l'avancement du projet. Vous pouvez sinon vous limiter à une réunion hebdomadaire d'une heure maximum dans laquelle vous pouvez fixer les objectifs de la semaine suivante et faire le bilan de la semaine passée.
Ceci est le dernier article de ma mini série. Comme vous pouvez le voir, mon point de vue est de minimiser l'usage des pratiques Scrum quand la situation ne s'y prête pas. Tout n'est pas à jeter mais Scrum perd grandement de sont intérêt dans une démarche non agile. Ne cherchez pas à utiliser des buzzwords, de faire des standups et des burndown charts à tout bout de champ. Ne communiquez pas de product backlog si vous êtes contractuellement engagés à livrer des spécifications. Concentrez-vous plutôt sur les pratiques d'ingénierie qui restent applicables à toutes les situations.
[1] vous l'aurez compris, complexe ici signifie d'une charge supérieure à deux jours.
