TWiki . Lean . LeanAdministratif

Y a-t-il des exemples de Lean dans la gestion des projets informatiques ?

Catherine Chabiron


Bonjour,

Il y a une très grosse littérature sur le développement informatique, et de plus en plus de livres et articles sur le lean appliqué à l'informatique (on parle souvent de "développement itératif et incrémental" et de "méthodes agiles" - ce qui est peut-être une bonne traduction de "lean", finalement)... Ces méthodes s'opposent aux méthodes "séquentielles" (on parle de "waterfall" en informatique).

A noter que l'on peut établir un historique de ces méthodes "agiles", et que l'on constate alors que les premières références partnent de... Demming (l'inventeur du cycle PDCA et gourou de la qualité qui a été fort bien lu par Toyota) et à von Neumann (l'un des inventeurs de l'ordinateur).

En fait, les deux approches (waterfall vs itératif/incrémental) existent depuis fort longtemps, et l'itératif a été dominant au départ de l'informatique : c'est le department of defense US qui a fait triompher le waterfall dans les années 1960, principalement sur la base d'un rapport mal pensé d'un analyste qui n'avait pas trouvé la littérature pro-agile à l'époque (c'est du moins ce qu'il a avancé deux décennies plus tard, face à la lourde responsabilité qui lui retombait sur les épaules)...

Il semble donc que, depuis le DEBUT de l'informatique, les SEULS projets qui aient réussis aient TOUJOURS été associés à des méthodes itératives/incrémentales, qui se définissent par 10 caractéristiques :

  1. feed-back from user
  2. empirical project management
  3. design-to-cost
  4. parallel design, coding, testing and documentation
  5. iterative development
  6. code-based milestones
  7. fixed timebox
  8. test-driven development
  9. learning et community building
  10. risk-conscious management

De manière plus détaillée :

  1. feed-back from user : si on veut de l'itératif rapide, il faut que l'utilisateur puisse s'exprimer très souvent. Plusieurs méthodes demandent qu'un représentant de l'utilisateur soit présent sur le site de développement ;
  2. empirical project management : dès lors qu'on SAIT que le projet est incertain, l'objectif est de monitorer aussi précisément que possible ce qui se passe et les délais estimés, qui n'arrêtent pas de changer. Ca ne sert à rien de dire que le projet est "en retard" par rapport à une date arbitraire fixée initialement, mais c'est important de moduler la charge (supprimer des fonctions s'il le faut) pour respecter les timebox et gérer le plan commercial ;
  3. design-to-cost : classique, surtout dans les cas où il y a du hardware ;
  4. parallel design, coding, testing and documentation : on ne produit pas de doc préalable au code, on ne fige pas l'architecture au préalable du code ;
  5. iterative development : au moins deux itérations, si possible beaucoup plus. Chaque itération doit délivrer du soft fonctionnel et assurant une fonctionnalité concrète recherchée (exemple réel sur un système de repérage de missiles : l'itération 1 sait tracker 1 missile, l'itération 5 sait tracker une multiplicité de missiles) ;
  6. code-based milestones : c'est le code qui permet de savoir si on est "on-track", pas des documents explicatifs. Le management doit VOIR LE PRODUIT FONCTIONNER à chaque review (gemba ?) ;
  7. fixed timebox : (depuis 1 journée jusqu'à 6 mois, le plus souvent entre 1 et 8 semaines) : le principe, c'est qu'on décide au début de la timebox de ce qu'on va faire dans la timebox. Si on se rend compte qu'on a voulu trop en faire, on élimine des specs mais ON N'ETEND JAMAIS LA TIMEBOX. Il semble qu'on ait souvent au moins deux niveaux de timebox, et même trois : daily build (pour tester en permanence l'intégration du code de chaque développeur à l'ensemble), "sprint" (en Scrum, 1 mois, qui est la timebox principale de gestion de l'équipe), "release timebox" (6 mois, par exemple, qui oriente les décisions plus stratégiques)
  8. test-driven development : on définit ce que doit faire un module par un jeu de tests (automatisés si possible). On peut ensuite modifier le code tant qu'on continue à passer les tests
  9. learning et community building : l'apprentissage est la raison principale de l'itératif. C'est pour obtenir cet apprentissage qu'on fait des itérations. La construction d'une équipe permet de faire littéralement exploser la productivité collective de l'équipe (x10)
  10. risk-conscious management : il y a toujours des élément de risque dans un projet informatique. Dès lors, chaque itération (et surtout les premières) doivent s'efforcer de mesurer, circonscrire et réduire le risque, en attaquand d'emblée les parties les plus risquées (ou en faisant monter en compétence l'équipe pour lui permettre de les assumer).

Godefroy Beauvallet - 13 octobre 2004


Je vous suis assez bien sur l'approche itérative que vous décrivez, mais quelle est a contrario la méthode waterfall ou séquentielle ? (j'ai besoin des 2 descriptions pour voir où nous nous situons dans nos projets informatiques en cours). Catherine Chabiron


Le modèle de la cascade voit le processus de développement comme un "dossier" qui avance selon des phases successives clairement séparées : analyse de besoin, design/architecture, programmation (coding), tests techniques, validation fonctionnelle, intégration et maintenance. C'est le modèle classique utilisé par les administrations, et symbolisé par le "cahier des charges fonctionnels" qui (censément) recense l'intégralité des besoins et par le diagramme de GANTT (dont les lignes constituent la cascade, en fait).

On parle de modèle en "cascade" car chaque démarrage de phase est déclenché par la recette de la phase précédente. On n'est donc pas censé commencer à coder avant d'avoir une expression de besoin complète (donc immuable), pas censé tester tant qu'on n'a pas fini de coder (pour ne pas se disperser), etc.

Le modèle de la cascade est très adapté si l'on est dans un cadre totalement déterministe et, notamment, que l'on est totalement clair sur le besoin et qu'on maîtrise totalement les technos utilisées. Autant dire qu'en informatique, c'est rarement le cas. Le développement va faire apparaître des boucles de rétro-action en permanence. Par exemple, on va devoir reprendre le besoin quand on tombe sur une "bonne idée" d'interface, par exemple, ou modifier la techno utilisée tardivement pour faire face à de l'inattendu. Dans un modèle cascade, cela apparaît comme une catastrophe ("mais vous nous aviez donné une date ferme !") alors que c'est le quotidien des projets informatiques, en fait...

Quand il y a des relations contractuelles entre acteurs (une SSII et un donneur d'ordre, par exemple), la tentation de la cascade est grande (ça simplifie le contrat et on espère faire porter les risques au contractant) mais cela produit des gros problèmes par la suite ("vous avez changé les specs hors délais", par exemple).

Le modèle itératif s'avère nettement mieux adapté quand le besoin est peu clair (souvent le cas car les utilisateurs ont beaucoup de mal à dégager leur besoin) ou qu'il est changeant (ce qui est souvent le cas quand on mène de front refonte de process et informatisation). Il est également très bien adapté quand on cherche le bon point d'équilibre entre ce qu'on informatise et ce qu'on laisse gérer "humainement" (parce qu'on est pas conduit à tout figer d'entrée, ni à paramétrer de manière extraordinairement complexe pour se laisser des marges a posteriori).

Bien entendu, il y a tout un continuum de modèles de développement entre la cascade et le pur itératif (modèle dit "en spirale", "prototypage rapide", etc.) mais cela masque le fait qu'il y a des options de base très divergentes entre ces deux pôles : la cascade suppose que l'on puisse essentiellement définir a priori le besoin, tandis que l'itératif prend comme une donnée de base que le besoin va être codéfini dans le cours du projet (et pas simplement dans les premières phases).

Ceci clarifie-t-il suffisamment les choses pour que vous sachiez où vous vous situez ? Si ce n'est pas le cas, posez-vous deux questions : (i) écrivons-nous des cahiers des charges fonctionnels (ou des expressions de besoin) de plus d'une page ? (ii) les utilisateurs rencontrent-ils les développeurs (j'ai bien dit les développeurs, pas quelqu'un de la DSI mais bien les gens qui fabriquent l'appli) au moins deux fois par semaine ? Si vous avez répondu oui à (i) ou non à (ii), vous êtes plus "waterfall" que vous ne le devriez ;-).

Godefroy Beauvallet - 22 octobre 2004


Alors nous sommes effectivement plus waterfall que nous le devrions, particulièrement dès que nous abordons les phases de développement où nous cessons de voir aussi fréquemment les utilisateurs (nous les réintroduisons dans le circuit au niveau des tests et des formations). Toutefois, tout développement d'applications à l'échelle d'un Groupe tombera inévitablement dans le travers d'une organisation waterfall, parce que le nombre d'acteurs est très (trop ?) important : non seulement les utilisateurs, qui peuvent avoir des besoins très hétérogènes, mais également les fournisseurs internes, qui ont eux mêmes des priorités en conflit avec ce que nous leur demandons. Nous vivons un tel exemple dans notre Groupe avec le développement d'extractions de données en provenance d'une cinquantaine de plateformes différentes, qui alimenteront une application de suivi des incidents qualité clients ou fournisseurs. Les utilisateurs (500 répartis sur 150 sites dans le monde) ont eux-mêmes développé ou acheté des applications locales qu'il s'agit de remplacer ou d'interfacer, d'autres (une majorité) n'avaient rien développé et attendent beaucoup d'une application centrale fournie clés en main. Il n'est pas matériellement possible de consulter tous ces utilisateurs (ou leurs représentants, choisis parmi eux), en permanence pendant toutes les phases du projet. Nous essayons toutefois de rester flexibles, de prendre en compte leurs demandes d'évolution, mais nous sommes quand même en mode waterfall. Conclusion de ce qui précède : l'avenir est-il au développement de petites applications locales, modulables, sur lesquelles la méthode itérative s'applique plus aisément, et offrant ainsi une meilleure garantie de réussite ? Faut-il renoncer à toute offre d'application centrale qui a pourtant le mérite d'offrir à tous un minimum de prestations et de faciliter la vision d'ensemble pour le management ? Une info intéressante au sujet de ce choix cornélien (applications modulables, probablement locales, développées en itératif et applications centrales, standardisées, développées en mode waterfall) : lors d'un meeting récemment organisé par Cisco et réunissant 200 CIOs, un des points majeurs de la discussion a porté sur le besoin de réduire la complexité et le nombre des systèmes informatiques actuels en standardisant les business process. Tous ces CIOs ont indiqué que c'était le challenge des années à venir. L'exemple de GM est intéressant : ils auraient économisé 1 B$ en consolidant et en diminuant le nombre de leurs systèmes (de 7000 à 3000 en 7 ans). Ils conduisent en parallèle une standardisation des process et ont nommé des Process Officers dans un certain nombre de domaines.

Catherine Chabiron - 26 octobre 2004


On peut d'ailleurs ajouter au débat sur les systèmes informatiques lean l'extrait suivant de l'article de Dan Jones "Au delà de la réduction des coûts" publié sur ce site (il suffit de remplacer machine par système informatique):

"Nous ne devrions surtout pas passer à coté de la signification de la réflexion de Toyota. La plupart des ingénieurs dessinent de nouveaux équipements (ce type de comportements se vérifie également pour les nouveaux systèmes logiciels) et rêvent encore d’une machine plus grosse, plus performante, plus rapide et plus fiable. Et, comme résultats, vous pouvez souvent constater une situation ridicule illustrée par la présence d’un alignement de grosses machines sur le sol de l’usine produisant une pièce qui peut tenir dans votre main.

Récemment, j’ai été visiter une usine comme celle-ci en Allemagne, où ils aiment les grosses machines. Heureusement, cette firme réalise maintenant que les grosses machines ne représentent pas un gage de réussite pour l’avenir. A l’instar de Toyota, ils utilisent désormais des systèmes plus simples, moins chers et plus maniables pour leur prochaine génération de produits. Ils m’ont alors montré plusieurs prototypes issus de leur prochaine génération : il s’agit de machines de taille plus réduite, modulaires et qui peuvent intervenir à n’importe quel moment de la production pour fabriquer des petits produits. Ces machines nécessitent moins de connaissances de la part de l’opérateur et peuvent être changées de place très facilement.

Cela facilite grandement la compression de chaque chaîne de valeur, et de ce fait, les actions créatrices de valeur peuvent être placées, autant que possible, les unes à côté des autres. Ce n’est pas seulement plus intelligent, mais c’est également plus simple et moins cher. En sus, la capacité de production peut être augmentée (et redéfinie) à l’aide de plus petits incréments pour s’adapter aux changements de demande au cours de la vie d’un produit dans chaque région.

La chose la plus intéressante est sans doute que dessiner plus petit de manière plus adaptée avec des machines plus simple est un challenge plus excitant pour la prochaine génération d’ingénieurs que de dessiner la prochaine grosse machine. A mon sens, chaque société doit penser à ça, plutôt que de faire confiance à des machines inadaptées. Travaillez-vous à repenser et simplifier l’organisation de votre système d’équipement et de production pour le futur ?"

Ceci pourrait parfaitement s'adapter aux systèmes informatiques, mais c'est à l'encontre de la direction prise par les entreprises ces dernières années et de la tendance à la standardisation et au regroupement évoqués ci-dessus.

Catherine Chabiron - 26 octobre 2004


En fait, il y a à mon sens deux écueils à éviter :

Pour naviguer efficacement, deux idées :

A noter que l'on appelle parfois abusivement "développement" ce qui est en fait du paramétrage d'interface ou de solutions de workflows ou de groupware.

Enfin, sur l'odée que l'itératif conviendrait uniquement aux petits projets, cela ne semble pas du tout avéré dans les faits : en particulier, il ne s'agit naturellement pas que TOUS les clients participent au développement, mais que des représentants des clients soient présents dans les locaux de l'équipe de dev, participent aux réunions, valident les réalisation ; par ailleurs, il reste possible de segmenter un très gros projets en "sprints" de durée fixe (un mois par exemple) et de mettre en prod (au moins sur des sites pilotes) les résultats mois après mois.

Si l'on observe les projets menés en waterfall, il semble bien que les plus gros projets soient ceux qui rencontrent le plus de problèmes (encore récemment, avec le projet ACCORD à Bercy). C'est donc peut-être bien là, contre-intuitivement, que l'effet "itératif" peut être le plus intéressant. Encore faut-il bien séparer ce qui ressort de la politique informatique de ce qui ressort de chaque projet de développement spécifique.

Godefroy Beauvallet - le 26 octobre 2004


Eric VALERY - le 18 Novembre 2004

Permettez-moi de rentrer dans cette passionnante discussion.

Personnellement sur les aspects qui semble animer cette discussion, j'y répond par un concept très simple l'e-soft management.

Je me base sur de nombreux exemples, quelques expériences personnelles dans des entreprises de toutes tailles et sur des réflexions personnelles ou des travaux sur le management des acteurs de l'entreprise en vue d'améliorer l'efficience de la relation client-fournisseur dans son sens large.

Je vous propose de vous imaginer en train de fournir à vos utilisateurs (clients) des outils spécifiques qui leur rendent service (le problème essentiel consiste à maîtriser la taille de l'outil).

Vous obtenez ainsi au fur et à mesure des demandes et des développements une réponse aux besoins des clients. Ces outils pour les personnes sont beaucoup plus pertinents pour améliorer la productivité de l'entreprise qu'un ERP ou tout autre logiciel centralisé, d'ailleurs techniquement on arrive à de telles limites que même oracle propose du grid computing qui sous entend que c'est quand même plus simple si les serveurs sont plus petits et si les applications ne sont pas monstrueuses (personnellement j'attend l'ERP qui me fera le café le matin en arrivant au bureau).

Car l'informatique est le seul domaine ou métier dans lequel on fait croire au gens que tout est possible et donc ou on intègre tout en un seul logiciel. Premièrement, il faudrai savoir à quoi cela sert, deuxièmement, c'est totalement anti productif pour les utilisateurs et même générateur de refus ce qui finalement amêne à la conclusion que le logiciel est mauvais (???)

Prenons un exemple d'outil existant pour appuyer mes propos. Un jardinier utilise un sécateur pour couper des roses. Pour tailler une haie il utilise un ... taille-haie (bravo). Cela ne vous viendrait pas à l'esprit de lui concevoir un outil qui fasse taille haie et sécateur en même temps, non. Alors pourquoi oui en informatique.

Je pense que le problème provient du fait que l'on est incapable de savoir quelles informations sont nécessaires pour permettre à nue entreprise de fonctionner et quelles informations sont pertinentes. Du coup, les clients demandes, on crée, et on se retrouve à tous travailler pour stocker des informations que personne n'utilise jamais.

Un autre exemple plus parlant: dans le cadre de ce que j'apelle le domaine de management des achats et des stocks, les utilisateurs des produits doivent pouvoir sortir les produits du stock de manière très simple. Utilisont donc par exemple ce qui existe comme procédé dans la grande distribution lorsque vous passez au caisses. L'utilisateur dispose d'un outil pour dire qu'il a utilisé le produit. Pour être bien organisé, tous le monde ne passe pas des commandes. Donc, il faut un outil pour ceux qui passent des commandes. Il font peut être aussi les réceptions ou des mises à jour du stock. Ils ont des fonctions différentes, ils doivent avoir un outil différent. Derrière tout cela, ce sont bien entendu les mêmes bases de données qui sont utilisée. Mais on a évité d'introduire des couts de formation des problèmes de compréhension et on a mis à disposition du plus grand nombre des outils qui servent à l'amélioration de la performance globale. Et la comptabilité dans tout cela, on lui fait un outil qui sert à consolider les données des commandes, ou les inventaires. Ce dont elle a besoin. Elle n'est pas chargée de controler le stock en temps réel que je sache, sinon cela veut dire que plusieurs personnes font la même chose dans l'entreprise et qu'il y a du temps à gagenr en améliorant l'organisation.

Ouf !

Je ne sais pas si ces quelques exemples, auront apporté quelque chose, mais je crois que nous devons forcément nous tourner vers l'amélioration du travail de l'autre pour nous aider à améliorer le nôtre. Pour moi c'est cela l'e-soft management.

Pour d'autres contacts : http://www.e-softmanagement.com

Merci et à bientôt peut être


je travaille actuellement avec un de mes clients sur de l'optimisation des processus de validation d'application informatiques (étapes de validation et édition des rapports associés). Ils ont dejà fait de gros progrés (50% des couts et 30% des delais). Il est tres clair que nous y sommes arrivés en utilisant les outils du lean manufacturing le splus basics (cartgraphies des flux et analyse de valeur notamment). Pour plus de renseignements: jpboyer@theaitgroup.com

No such template def TMPL:DEF{PROMPT:after}

----- Revision r16 - 2005-07-28 - 14:50:09 - GodefroyBeauvallet
Les contenus de ce site restent la propriété de leurs auteurs respectifs.