Planification et découplage

Pour aller vite et être en mesure de respecter les jalons demandés, il est indispensable de simplifier et de découpler les activités qui sont a réaliser. Malheureusement la grande majorité des techniques de planification traditionnelles conduisent plutôt à augmenter ce couplage et pour s’en rendre compte il suffit de comparer les approches traditionnelles et agiles sur 3 aspects essentiels de la planification :

• Gestion des dépendances
• Utilisation des ressources
• Chemin critique

Gestion des dépendances

Dans un GANTT, les dépendances sont une choses acquises et les outils de gestion de projet traditionnels permettent de modéliser les dépendances entre les activités. Une bonne partie du temps de planification est réservé à l’identification et la modélisation des dépendances, puis ensuite à leur gestion pour tenir compte des évènements qui surviennent sur le projet (et il y en a toujours). Et bien que cette activité soit généralement l’apanage du chef de projet, elle se révèle très consommatrice de temps utile.

En agilité, les équipes vont utiliser ce temps initial (identification et modélisation) pour rendre les activités indépendantes les unes des autres et ne plus avoir à gérer celle-ci ultérieurement. Cette pratique génère donc un gain de temps substantiel durant la réalisation du projet.

J’entends souvent dire « ce n’est pas possible de casser les dépendances sur mon projet !« , mais généralement cela veut plutôt dire « j’ai l’habitude de gérer mes dépendances et je n’ai pas envie de faire autrement !« , car à chaque fois que j’ai aidé l’équipe, nous avons trouvé des solutions pour ne pas avoir de dépendances.

A titre d’exemple, je citerais le travail des équipes de Thales Avionique qui développent du logiciel embarqué et qui ont réussi à découpler le logiciel du matériel (au moins à 99,9 %) … ce que tout le monde pensait impossible !

Utilisation des ressources

Avec un outil de gestion de projet traditionnel vous pouvez obtenir facilement les courbes d’utilisation de chaque ressources, et l’on enseigne aux chefs de projets à optimiser cette utilisation ce qui revient à dire qu’il faut utiliser chaque ressource au maximum de sa disponibilité. L’idée sous-jacente est d’éviter d’avoir une ressource qui ne fait rien car c’est de l’argent perdu. Cette pratique induit beaucoup de complexité dans le planning car de nombreux couplages sont générés pour tenir compte de cette utilisation maximale.

En agile, nous nous appuyons sur la théorie des files d’attentes qui démontre clairement que pour aller vite il faut garder du mou et ne pas utiliser ses ressources à 100 % des capacités.

A titre d’exemple, il ne viendrait d’ailleurs jamais à l’esprit d’un industriel d’utiliser son parc de serveurs à 100% de ses capacités car il ne pourrait plus traiter la moindre demande supplémentaire ou l’augmentation d’un type de demande sur une période donnée. Lorsque je réalise les UAT en mode agile, je demande à une partie de l’équipe de l’équipe technique d’être présente dans la salle où se passent les tests et simplement d’attendre d’être sollicités. Il ne font rien mais sont immédiatement disponible lorsqu’une demande arrive, ce qui au bilan, est beaucoup plus efficace et moins couteux pour le projet.

Chemin Critique

Avec un PERT, vous pouvez visualiser le chemin critique de votre projet et l’on apprend au chef de projet à réduire au minimum le temps nécessaire pour parcourir ce chemin critique. Comme précédemment, cette activité génère beaucoup de couplage sur les autres activités, voir même des découpages aberrants pour gagner quelques jours sur ce chemin critique.

A propos de PERT, connaissez-vous le projet POLARIS lors duquel la technique du PERT a été initialement créée … mais en fait jamais utilisée … ce qui n’empêche pas d’être enseigné lors de toutes les « bonnes formations » de Chef de Projet !

En agile, et plus précisément en Lean, l’approche consiste à ne pas accepter l’idée d’avoir un unique chemin critique et donc de faire en sorte qu’il n’existe pas. Pour cela il faut étudier la possibilité d’avoir des alternatives au cas ou quelque chose ne se passerait pas correctement, par exemple avoir plusieurs fournisseurs pour le même besoin, ou pratiquer le « Set Based Design » qui permet de développer un éventail de solutions qui permettront de prendre les décisions le plus tard possible et d’éviter d’avoir un seul chemin critique.

Cette approche permet de toujours respecter les jalons du projet car une des solutions sera toujours disponible en temps et en heure, et même si elle s’avère plus chère au quotidien, elle génère une économie au niveau du système … c’est le principe  même d’une assurance !