Principes de gestion agile

Un article de Wikipédia, l'encyclopédie libre.

Les méthodes agiles, comme Scrum, demandent un modèle de gestion particulier.

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 compexité 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, tel qu'appliqué 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.

[modifier] Les goulots 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 ce cette contrainte ; il faut l'optimiser pour augmenter la vitesse de production de l'ensemble de l'usine.

[modifier] 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 1er tâche arrive au goulot (en aval) et le temps pour livrer la dernière tache du goulot. Supposant que ce soit votre DBA, 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.

[modifier] 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: Appluing the Theorie of COnstraints for Business Result. ISBN 0131424602