Lean > LeReseau > LeForum > LeanAdministratif (r11)    Changements récents | Index | Recherche | Go
  • Accueil
  • Le Projet
  • Actualités
      Lettres J Womack
      Lettres D Jones
      Gemba Coach
  • Publications
      Bibliographie
      GlossaireLean
  • Présentations
  • Le Réseau
      AnnuaireDuLean
      Formations
      Stages/Emplois
      FoireAuxQuestions
      Club des traducteurs
  • Videos
  • Beta-Services
      Recherche
      Achat de livres
      Carte du lean
  • Séminaires
  • RSS

  • Lettre d'information

    - Pour être tenu(e) au courant des nouveautés du Projet Lean Entreprise, laissez-nous votre adresse électronique :

    Projet Lean Entreprise
    Département SES
    Télécom Paristech
    46 rue Barrault
    75634 PARIS Cedex 13
    Tél. 01 45 81 74 01

    Contact mél
    Se rendre à Télécom Paristech

    Toutes les rubriques
    Admin
    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 :

    • le localisme ad hoc : développer ou acheter en local des applications mal fichues mais très personnalisées qui outillent les processus de travail et les gèlent ;
    • le centralisme aveugle : des applications centrales "one size fits all" qui ne correspondent pas aux manières de faire en local.

    Pour naviguer efficacement, deux idées :

    • le choix des technologies (et surtout des formats des stocks et des flux de données, tout ce qui permet l'interopérabilité, y compris les classes d'objets si vous êtes "objet", les schémas XML, les langage de développement) doit être effectué globalement, et faire l'objet d'une évolution raisonnée par la DSI ;
    • le choix des développements à effectuer, de la dynamique de mise en place, doit être local. Il faut surtout éviter de faire de l'informatisation le préalable à l'amélioration, car l'informatique a tendance à figer les processus, plus encore que le papier.

    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

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

    Page LeanAdministratif . { Éditer | Attacher un fichier | Pages liées | Version imprimable | Versions }
    Page mise à jour le 2004-11-09 parMain.TWikiGuest
    Parents: WebHome > LeReseau > LeForum
    Les contenus de ce site restent la propriété de leurs auteurs respectifs.