Principes de gestion agiles

Dans l'approche de gestion de projet traditionnelle, un projet est identifié, évalué, découpé en tâches et précisément planifié. Le problème est que l'une des bases de la gestion de projet est d'estimer les tâches. Ce n'est généralement pas possible, à cause de la complexité du développement informatique.

Une autre approche est de considérer l'ensemble de l'équipe de développement comme une usine c'est-à-dire comme un ensemble de postes de travail, de machines, dont les activités sont inter-reliées. On y injecte les besoins du client comme matière première, qui sera progressivement transformé en produit final. Cette façon de voir permet d'appliquer la théorie des contraintes, comme dans le milieu manufacturier depuis plus de 30 ans.

Par exemple, on tente de réduire ce qu'on appelle l'inventaire des "en cours". Dans le cas du développement logiciel, cet inventaire est constitué des besoins du client exprimés, mais non encore livrés. Cet inventaire peut être constitué de spécifications écrites, d'architecture, de conception, de code ... non encore livrés en un logiciel fonctionnel. Il s'agit d'argent investi, qui dort dans l'entrepôt du logiciel. Les méthodes agiles tentent de réduire cet inventaire, pour pouvoir permettre au client de changer d'idée facilement.

Ce type d'idée a été exprimé dans les années 80, dans le livre The Goal.

Les goulets d'étranglements

Lors de la production de logiciel, il peut (doit) y avoir un déséquilibre dans la chaîne de production.

L'un des maillons est plus faible ; il ne fournit pas suffisamment et devient alors la limite de production de l'ensemble de l'usine à logiciel.

Comment le repérer ?
Il y a une pile de travail à faire (il est donc moins rapide que ce qui le précède) et on attend après son travail, pour poursuivre le développement ; si cette situation est récurrente, on est alors en présence d'une contrainte.
En fait, l'ensemble de la capacité de production du système est la capacité de production de cette contrainte ; il faut l'optimiser pour augmenter la vitesse de production de l'ensemble de l'usine.

Gérer autour des goulots

Si on veut réduire l'inventaire en cours, il faut simplement s'assurer que l'ensemble des autres postes en aval, ne produisent pas plus vite que le goulot. Pour savoir quand un projet sera livré, il suffit d'évaluer l'effort à réaliser au goulot. Le projet sera livré, quand le goulot aura effectué son travail, plus le temps pour que la 1^re tâche arrive au goulot (en aval) et le temps pour livrer la dernière tache du goulot. Supposant que ce soit votre DBA (Data Base Administrator), qui soit votre goulot. Le projet commence et une tâche arrive au goulot en 2 semaines. Il a pour 6 mois de travail. Il faut 3 semaines pour livrer, une fois qu'un élément est passé dans les mains du DBA. Alors, le projet prendra 7 mois et une semaine, si rien n'arrive au goulot. Le reste de la production n'a que peu d'importance sur l'échéance du goulot. À condition que tous réalisent l'importance du goulot et que nul ne le retardent inutilement. Simple, mais génial. Est-ce que ca marche ? Demandez le à Toyota, ils ont appliqué la méthode, avec un certains succès. D'ailleurs, beaucoup d'entreprises manufacturières l'utilisent depuis plus de 20 ans. Elles ont économisé 30% de dépenses, en réduisant l'inventaire.

Voir aussi

• Méthode agile
• Théorie des contraintes (TOC)

Références

• Eliyahu M. Goldratt and Jeff Cox. The Goal: A Process of Ongoing Improvement. ISBN 0-88427-061-0
• David Anderson Agile Management For software engineering: Applying the Theorie of Constraints for Business Result. ISBN 0131424602