Lean > PremierForum > LeanAdministratif (r7)    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 fonctionnellet, intégration et maintenance. C'est le modèle classique de l'administration, symbolisé par le cahier des charges fonctionnels qui recense l'intégralité des besoins.

    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.

    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) mais 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).

    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, notamment le fait de livrer tous les mois des blocs de fonctionnalités et de modifier la suite du projet en fonction de la réception (en itératif).

    Ceci clarifie-t-il suffisamment les choses pour que vous sachiez où vous vous situez ?

    Godefroy Beauvallet - 22 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-10-22 parMain.TWikiGuest
    Parents: PremierForum
    Les contenus de ce site restent la propriété de leurs auteurs respectifs.