Devons-nous changer de paradigme pour le développement d’applications informatiques?

Ce me semble être un des secrets les mieux gardés du moment en informatique : nous opérons souvent sur un paradigme qui est faux en utilisant la métaphore de l’usine et de la production « industrielle ».

A quoi bon des métaphores ?

De nos jours, la métaphore la plus fréquemment utilisée pour désigner une organisation en charge de développement logiciel est celle d’une usine, ou software factory en bon franglais. Nous parlons également de spécification et de conception de logiciel, laissant entendre que le reste n’est plus une tâche de création, qu’il n’y a plus qu’à faire comme c’est prévu, à suivre le plan de fabrication.

Ainsi, avec l’arrivée des concepts issus du Lean Management, nous sommes tentés d’utiliser de plus en plus des méthodes et outils organisationnels issues des chaînes d’assemblage – et il n’y aurait plus qu’à assembler des composants prédéfinis, réutilisables, et tous nos soucis seraient résolus. Nous pourrions donc nous inspirer des méthodes utilisées pour monter des voitures ou des ordinateurs, et plus de projets en retard, plus de besoins métier inassouvis ! Cette métaphore a remplacé celle de la construction de bâtiment et de ponts – je ne suis pas trop sûr de savoir pourquoi, d’ailleurs. Peut-être la précédente n’était-elle pas suffisamment fertile en concepts associés permettant de guider nos organisations informatiques, ou peut-être s’est-on rendu compte que la métaphore ne fonctionnait pas.

Oui, mais quel est le problème ?

La question est liée à l’utilité d’une métaphore. Une métaphore est bonne et utile si elle « fonctionne » et inspire par analogies de nouvelles idées, démarches, concepts, analyses, etc. par un rapprochement de domaines distincts. Une bonne métaphore donne des outils pour imaginer et décider, par jeu d’analogies. Par exemple, la fenêtre est une métaphore pratique pour l’espace d’interaction avec une application informatique, parce qu’elle permet d’imaginer l’accès à des « domaines » différents, de voir ce qui se passe dans ces « zones ». Elle permet d’imaginer de l’ouvrir, de la fermer, d’attacher un contexte mental à une fenêtre. La métaphore touche à ses limites lorsqu’on parle de superposer plusieurs fenêtres, ce qu’on ne peut pas avec des vraies fenêtres dans des murs….

Ou alors, un pont peut être une bonne métaphore pour une interface applicative: il permet de faire passer des objets (métaphores pour les données) d’un côté à l’autre; il est une construction particulière, supplémentaire, nécessitant un effort; il faut se mettre d’accord sur le point de départ et d’arrivée. Par contre, il ne représente qu’une interface point à point, et ne permet pas d’imaginer de réutiliser des interfaces pour faire des services partagés.

Nous voyons donc qu’une métaphore peut être utile, mais peut également avoir des limites, et il faut dans ce cas en être conscient pour l’utiliser correctement. Une métaphore peut être complètement nocive si la plupart des décisions que l’on prend en l’utilisant ne sont pas pertinentes- ou encore si elle amène naturellement à prendre des décisions « évidentes » dans le contexte de la métaphore mais qui en fait sont nuisibles.

Imaginons par exemple un chef de projet informatique qui a un problème de retard prévu sur les livraisons. Dans les usines, pour augmenter rapidement la quantité produite, on fait des heures supplémentaires. Le chef de projet utilise la métaphore de l’usine et la pense pertinente. Il demande donc à ses développeurs de venir travailler le samedi. Sauf qu’en l’occurrence le problème n’était pas sur la quantité produite, mais sur la clarté du besoin et les arbitrages associés. Le résultat est que les développeurs ont produit plus, mais plus de choses non conformes aux attentes. Du coup il y a plus de corrections à apporter sur la base de retours utilisateurs, et le « retard » augmente !

Pourquoi la métaphore de l’usine est-elle un mauvais guide ?

Mon propos aujourd’hui est donc d’affirmer que cette nouvelle métaphore de l’usine appliquée au développement de logiciel est fausse, incorrecte. Complètement et tout simplement. Et elle n’a jamais été même proche de la réalité. Et donc les analogies et orientations que nous pourrions prendre en nous appuyant sur cette métaphore seront au mieux hasardeuses, au pire nocives.

Comparons les modèles d’usine de fabrication et de développement logiciel:

Manufacturing Développement logiciel
Les tâches sont… Répétitives Non répétitives
Les tâches sont… Prédictibles Non prédictibles
Les besoins exprimés sont… Une contrainte forte Un axe de pilotage
Les besoins exprimés sont… Fixes Evolutifs
Le travail est… Borné Non borné
Le coût du retard est… Homogène Non homogène
La durée des tâches est… Homogène Non homogène
La variabilité est… Toujours du gaspillage Nécessaire et pas toujours du gaspillage
Les produits intermédiaires sont… Des objets physiques De l’information
La création de valeur se fait… Par transformation de la matière Par création d’information
Les stocks sont… Visibles Invisibles

Ces quelques critères de comparaison font apparaître des obstacles à une transposition directe de méthodes issues de la fabrication d’objets physique au développement de logiciel, et donc autant de faiblesses de l’application de la métaphore de l’usine dans le domaine informatique.

Pouvons-nous illustrer ce propos ?

Une voiture est fabriquée dans une usine. Aux options près, elle est identique à celles qui l’ont précédées. Elle est conforme à un plan de fabrication déjà utilisé pour d’autres voitures. Une fonctionnalité est implémentée sur un logiciel. Il va peut-être se conformer à un plan si une conception détaillée a été faite, mais ce sera la première et la dernière fois que ce « plan » sera utilisé.
Un dossier de fabrication est fourni à une usine pour mettre en place une chaîne pour un nouveau modèle de voiture. Ce dossier a déjà été validé par d’autres usines ou des équipes d’ingénierie en fabriquant un prototype. Un dossier de conception détaillé est fourni à une équipe de développement. Il n’a jamais servi à fabriquer du logiciel. On ne sait donc pas s’il est suffisamment complet ni compréhensible.
Le délai pour une étape de fabrication est prévisible, et a pu être estimé avant le démarrage de la première chaîne de fabrication, en particulier par des prototypes. Le délai pour le développement de composants logiciels est très imprévisible, sauf dans les cas où la même équipe a déjà réalisé des adaptations du même type. Qui plus est, il dépend fortement du développeur individuel et de l’équipe.
Un incident provoque l’arrêt de la chaîne, un lot de voiture n’est pas fabriqué. La perte d’argent est linéaire en général et se réduit aux voitures devant être réalisées. Certains éléments du logiciels ne sont pas réalisés. Il se peut que dans ce cas le logiciel en entier n’ait plus aucune valeur. La perte est non linéaire, et potentiellement hors de proportion par rapport au coût de réalisation des éléments manquants.
Les tests de fonctionnement de grille-pain sont réalisés par un sous-traitant. Le responsable produit, l’usine et le sous-traitant se mettent d’accord sur les tests à réaliser et rédigent un document qui est appliqué par le sous-traitant. Un changement de spécification résulte dans un changement dans le document, mais le coût en est répercuté sur les milliers de grille-pain qui sont testés ensuite Les tests autour d’une nouvelle fonctionnalité sont réalisés par un sous-traitant. Le client final, l’équipe de développement et le sous-traitant se mettent d’accord sur les tests et rédigent un document. Quand une spécification change, le document est changé, mais ce coût de changement n’est porté que par un seul logiciel.
Le service achat d’une usine négocie l’achat de boulons, ou même de pompes ou de produits plus complexes. Il va préciser la qualité attendue et les tolérances, et pourra ainsi se mettre d’accord sur le prix d’un lot. Des tests par échantillonnage seront ensuite réalisés et permettront de s’assurer de la conformité des livraisons. Le service achat négocie l’achat de prestations de développement informatique. Il ne sait pas préciser la qualité d’une ligne de code, d’un homme-jour ou d’un point de fonction. Il ne va négocier que le prix, éventuellement des profils d’intervenants. Personne ne sait ensuite mesurer clairement la qualité du logiciel et le respect de tolérances permises. C’est donc le seul paramètre de prix qui va être utilisé pour piloter l’intervention, sans définition claire de la qualité associée.

En synthèse, pourquoi cette métaphore ne fonctionne-t-elle pas ?

En fait, le développement d’un logiciel, au sens très large, incluant l’analyse du besoin, conception technique, conception fonctionnelle, le développement lui-même, les tests et la mise en production, tout ceci est une activité de conception de produit et pas de fabrication. Le produit en question est un produit logiciel, qui vise à satisfaire un certain besoin, à couvrir un certain « marché », bien souvent à usage unique comme les logiciels d’entreprise, ou au moins dont la duplication se fait rapidement et sans difficulté particulière, comme les logiciels grand public. Cette conception est d’abord génération d’information, et non pas mouvement d’atomes, et c’est elle qui crée la quasi-totalité de la valeur du produit logiciel.

Pourquoi essayons-nous néanmoins d’appliquer les modèles de fabrication issus de l’industrie ?

Souvent, cette application de modèles issus de l’industrie se fait dans un objectif de rationalisation et d’amélioration d’efficacité. Les projets informatiques ne vont pas bien, et/ou coûtent trop cher, et nous cherchons donc des solutions issues de domaines où les activités tournent mieux, où elles sont prévisibles et répétables – plus rassurantes donc. Nous cherchons aussi les (objectivement impressionnantes) économies d’échelle et gains (réels) d’efficacité que la production industrielle a permis, et que nous n’avons pas atteints dans le logiciel. Un regard très – trop – rapide sur le développement logiciel fait apparaître des zones « d’amateurisme », que l’on va s’empresser de corriger en demandant un fonctionnement plus « professionnel », plus « industriel ».

Mais tout ceci est illusion. Reprendre les mots et les pratiques de la fabrication en série ne permet pas de mieux « fabriquer » du logiciel « en série ».

Que faire alors ?

Est-ce une bonne ou une mauvaise nouvelle ? Les deux. La mauvaise est que nous allons devoir changer nos métaphores, ce qui va entraîner un changement dans l’espace des solutions et des outils. La bonne est que nous allons pouvoir nous tourner vers des espaces sémantiques nouveaux et une littérature différente pour nous inspirer dans la compréhension de nos processus et la recherche de pistes d’amélioration. Nous pouvons par exemple nous inspirer des méthodes et démarches de conception de produit utilisées dans l’industrie, comme décrit dans Managing the Design Factory, et nous découvrons que les problématiques, les enjeux, et même certaines des solutions et outils utilisées peuvent réellement nous aider à mieux comprendre et gérer nos systèmes d’information.

Les constructeurs automobiles savent que la conception de nouveaux modèles de voiture n’est pas un processus de fabrication « industriel », sur lequel on peut adapter les métaphores d’une usine. Ma réponse à la question du titre est donc: oui, changeons, inspirons-nous de leurs pratiques et d’autres, mais des bonnes, sans copie servile mais en transposant avec pertinence.

18 commentaires sur “Devons-nous changer de paradigme pour le développement d’applications informatiques?”

  • A mes yeux, la réalisation d'une application informatique se rapproche plus de la réalisation de l'usine qui traite de l'information. Une usine => Une application informatique Une usine fabrique des voitures => Une application informatique fabrique de l'information Une usine transforme de la matière première (ou des équipements) en voitures => Une application informatique transforme de l'information en de l'information (sous une forme différente : assemblée, rapprochée, etc.) Du coup le développement d'application informatique se rapproche de la conception et de la fabrication d'usine : on essaye d'appliquer des règles globales qui permettent d'assurer la bonne réalisation de l'usine, mais il s'agit de construction sur-mesure à usage unique.
  • Lumineux !
  • Excellent !
  • MERCI ! * d'avoir pris le temps de mettre à plat certaines des incohérences de cette métaphore (qui personnellement me gratte dès que j'entend un propos qui la sous-entend). * d'avoir le courage d'aller à contre-courant de cette idée devenue un lieu commun. * de rappeler qu'il existe très probablement des comparaisons plus à propos. Je ne sais pas si cette métaphore est réellement déconnante, mais ça m'a fait du bien de la voir enfin rationnellement remise en question !
  • C'est bizarre, je n'ai jamis considéré que la métaphore de l'usine était celle qui devait s'appliquer à l'informatique, précisemment parceque les problématiques de l'usine sont liées à une production d'objets parfaitements identiques, ce qui n'est jamais le cas pour l'informatique (ou alors une fois le logiciel complètement finalisé, mais ce n'est pas le propos). La métaphore industrielle qui doit s'appliquer est celle du BTP. On y retrouve les mêmes phases de conception, de réalisation et d'impondérables. Cependant les erreurs de conception ou de réalisation s'y payent beaucoup plus cher qu'en informatique: voir le cas du terminal E de l'aeroport CDG. Il y a là beaucoup de choses à apprendre d'une activité humaine plsuieurs fois millénaire. Pensez que les pyramides ont été construites sans même un malheureux Excel ou "Microsoft project"!
  • L'erreur de cette métaphore est de faire le lien entre assembler une voiture et écrire du code. Un métaphore plus juste serait écrire du code = concevoir une voiture assembler une voiture = lancer la compilation du programme
  • En réponse à plusieurs commentaires qui ont été faits, oui, je suis d'accord que la métaphore de la conception de voiture est bien meilleure. Mais malheureusement c'est celle de l'écriture du code "à la chaîne" et en "usine" qui est très souvent utilisée, implicitement ou explicitement. On n'est pas obligé de l'expliciter et de s'en rendre compte pour utiliser une métaphore, il suffit de l'avoir comme modèle mental dominant dans la culture ambiante de l'entreprise. En ce qui concerne les travaux publics, effectivement l'analogie est peut-être plus fertile, mais comme le dit toccata, il y a effectivement des méthodes qui "marchent" et d'autres qui ne marchent pas dans ce secteur aussi... Inspirons-nous des bonnes par rapport à nos besoins, contraintes et limites.
  • En effet, à mon avis la métaphore fonctionne mais décalée d'un cran. L'usine est l'application, les développeurs "codent" des machines (des composants) et des lignes de productions (des fonctionnalités). Les produit en sortie est l'information traitée selon la demande du client (seulement, il n'y a pas 1 mois entre le choix de la couleur de la voiture et la livraison :-)). Les architectes définissent les bâtiments de l'usine, leurs fonctions (usinage, peinture, assemblage, ...), les échanges entre eux. Les concepteurs font les plans d'implantation dans chaque bâtiment. La magie, c'est qu'une fois l'usine finie, on appuie sur un bouton et ça marche ! Mais en effet, même si je pense que la métaphore de l'usine est valide, je partage le besoin de nouvelles métaphores, de nouvelles visions de la création du logiciel. L'open-source en est une, la métaphore associée est moins de l'industrie que du bénévolat ou de la croissance des plantes. Je pense aussi que la gestion de projet reste une valeur sûr dans le pilotage des délais, mais avec une sensibilité particulière sur le fait que la qualité de l'application repose sur ses concepteurs humains (les japonnais on très bien compris le truc) et sur leurs qualités personnelles (connaissances, compétences, savoir-être, savoir-faire, qualité de vie, ...). C'est probablement une porte de sortie, pour nous autre, travailleurs du savoir.
  • Merci de ce manifeste "Ne restons pas prisonnier des métaphores".. @Nicolas Krzyzanowski si la métaphore nécessite une transposition c'est qu'elle est difficilement utilisable. Cela dit, avant de jeter le bébé avec l'eau du bain, un des points saillants de la métaphore "industrie" et "lean" est pour moi très clair dès lors que l'on connait cette réalité industrielle, qui n'est plus Taylorienne (penseurs d'un côté, ouvriers de l'autre) depuis bien longtemps dans les usines lean, où l'on retrouve un concept central qui peut nous inspirer : des équipes autonomes responsables de l'amélioration continue de leur processus.
  • Je tiens simplement à féliciter OCTO qui a porter le discours de l'industrialisation de développements pendant très longtemps et qui sait aujourd'hui le remettre en cause. Je suis complètement d'accord avec votre analyse et c'est vrai que l'on continue à trop souvent utiliser cette métaphore (loin d'être bonne) à défaut de trouver mieux ... Sur ce je n'ai plus qu'à me trouver un autre titre sur ma carte de visite. "Software Factory Manager" ça fait has-been.
  • Bravo pour cet article ! Cela fait longtemps que je bataille pour dire que l'industrialisation du logiciel n'est pas un objectif réaliste au moins à moyen terme. Et il n'est d'ailleurs probablement même pas souhaitable. Pour moi, s'il fallait absolument utiliser des métaphores, je pense qu'un projet informatique serait assez proche d'une activité artistique, comme la production d'un disque par exemple. Si la question est comment produire plus vite plus de code, je ne pense pas que l'industrie fournisse des modèles applicables pour le logiciel. Et qu'on arrête d'associer "industriel" et "qualité", un produit industriel n'est pas un produit de qualité, c'est juste un objet produit rapidement en grande quantité. Encore bravo, d'avoir ouvert le débat, sur ce sujet rarement remis en cause.
  • Le développement informatique est d'abord une activité de conception, étant donné que la construction a lieu une fois. Ensuite c'est de la recopie, pas de la construction de pièces supplémentaires sur des machines réglées pour, sur base des plans établis. Donc oui, le parallèle est plutôt à faire entre l'activité du bureau d'études plutôt qu'avec l'usine elle-même (les ateliers). C'est bien la raison pour laquelle existent aujour'd'hui les architectes à qui l'on demande rigueur de conception, formalisation non ambigüe et contrôle du respect des plans (entr'autres choses). Ceci étant des sources d'inspiration existent du côté industriel. Les avancées vers le SOA sont là pour nous le prouver (meilleure gestion des exigences, réutilisation comme démarche plus naturelle, assemblage de composants, ...). La démarche qualité ou le lean management sont là aussi pour nous prouver que l'indusrie, à défaut de nous donner des leçons, doit nous servir d'inspiration sur certains sujets. Qu'ils le veuillent ou non les informaticiens devront demain faire mieux en matière de qualité en particulier. Certains le font déjà. Sur ce plan en tous cas il est urgent de réduire la dimension artistique. L'initiative Squale est de ce point de vue à suivre de près.
  • Nous sommes au moins d'accord sur les aspects conception et qualité. Par contre, la construction a lieu une fois, par recopie ? Je pense au contraire qu'un logiciel significatif (grands projets, progiciels, etc.) est un produit certes unique, mais en constante évolution. C'est là, encore une grosse différence avec l'approche industrielle. La recopie dont vous parlez (pressage de CD, mise en boite, etc.) est de la production, pas de l'informatique. Je ne suis pas non plus certain de bien voir l'inspiration industrielle dans SOA. Réutilisation, composants, sont des mythes de l'informatique depuis bien longtemps déjà et leur mise en oeuvre nécessiterait bien plus qu'un nouveau type d'architecture, enfin selon moi. Je crois que nous devrons faire avec des stars/gurus pendant encore un certain temps et que le temps des ouvriers producteurs de code n'est pas encore venu. C'est essentiellement une question de complexité des processus et de niveaux d'abstraction requis. Une fois encore, c'est une question intéressante et qui mérite d'être débattue. Je vais regarder Squale (malgré son nom peu prometteur :-)
  • Certainement d'accord avec le fait que nombre de systèmes IT évoluent. La question est de savoir s'ils n'évoluent pas trop (refactoring trop fréquents) par manque d'agilité. Sur ce sujet il me semble que l'"industrialisation" va devoir progresser, en mettant en oeuvre les approches et briques technologiques qui permettront d'éviter des refactoring en profondeur (dans les tréfonds du code) trop fréquents, tout en permettant de mieux gérer la non-régression ( maintien de la qualité dans le temps). L'industrie de l'électronique (sur les principes) peut nous inspirer de ce point de vue. L'informatique doit cesser de faire trop systématiquement dans la haute couture fait main au cas par cas. Elle a atteint la maturité au niveau des repositories de données (bien que la souplesse puisse encore être améliorée), mais il lui reste à progresser au niveau des repositories des règles et paramètres. Les évolutions en cours dans le cadre du SOA sont significatives sur ces aspects. Je peux comprendre le scepticisme mais ne peut admettre la résistance culturelle qui s'apparenterait à ce que nous avons connu lors du passage du procédural à l'objet. Sans l'objet, nombre d'applications n'existerait tout simplement pas aujourd'hui.
  • Je n'ai aucune résistance face à l'objet ou à SOA, bien au contraire, tout cela va dans le bon sens. Mais je ne pense pas que ni l'objet, ni SOA vont dans le sens de l'industrialisation. C'est probablement culturel, dans mon cas personnel le mot "industrialisation" n'est pas positif du tout. Exemple : j'aime la musique, mais je n'aime pas l'industrie de la musique. Je n'ai rien contre l'industrie en général, si ce n'est que je trouve qu'il y a des domaines particuliers où elle n'apporte pas que des bienfaits. Mon idée, c'est qu'il faut plus se concentrer sur l'amélioration de la qualité que sur l'industrialisation. L'industrie n'est pas la seule pourvoyeuse de modèle pour l'amélioration de la qualité. Qui plus est, les problématiques industrielles ne sont pas nécessairement les mieux adaptées au logiciel. Cela étant dit, je vous rejoins sur le fait que l'industrie électronique est intéressante de ce point de vue, j'avais d'ailleurs failli le mentionner dans mon post précédent ! Je suis allé lire quelques documents sur Squale. L'initiative est sympathique, mais je demande à voir des résultats sur des problèmes complexes, mis en oeuvre par des équipes compétentes. A mon humble avis, cela ne peut détecter que des divergences grossières. Quand j'ai vu les références à McCall et à l'analyse de la complexité cyclomatique je dois avouer que j'ai pris un peu peur. Je ne crois pas en ITIL ou des systèmes d'analyse du code ou des tonnes de documentation pour faire réellement avancer la qualité logicielle. On se cache derrière une fausse solution. En disant cela, je suis conscient de ne pas faire avancer le problème, je n'ai pas d'autre solution facile à proposer, à part former les équipes encore et toujours, améliorer la communication, etc.
  • Si vous défendez le fait que ce sont d'abord le respect pour les collaborateurs, l'entretien de leurs compétences et la stimulation des bonnes attitudes qui feront la différence sur la qualité je vous rejoins tout à fait. Mais ceci étant acquis, il me semble que cela ne doit pas empêcher de mettre en place des mesures "froides" de contrôle qualité, s'inspirant du monde industriel. D'un côté La confiance se crée par les conditions de travail et le respect des hommes, d'un autre côté elle ne doit pas empêcher le contrôle sur la qualité. Industrialiser veut dire, selon ma compréhension propre, souhaiter faire des gains d'efficacité, c'est-à-dire traquer les gaspillages, souvent encore trop manifestes aujourd'hui en développement logiciel. Dans les tests par exemple, mais aussi dans les opérations de maintenance (notamment par manque d'agilité comme dit précédemment), dans les déploiements (où franchement les marges de progrès restent considérables). Tout cela me parait compatible avec le maintien de la satisfaction au travail. Et d'autant plus qu'il m'est arrivé d'entendre lors d'entretiens d'embauche, sous des formulations variables, "Je quitte mon emploi actuel et je viens chez vous parce que j'y perçois une volonté de s'organiser pour faire du travail de qualité". Grand merci pour cet échange.
  • Cela me fait penser à la session de Vincent Lextrait lors de l'USI 2008 "Du manufacturing au mindfacturing". En substance, Vincent disait que les bonnes idées du manufacturing (ouvrier à poste, chaîne de montage, ...) ne s'appliquait tout simplement pas au développement informatique qui était avant tout un travail intellectuel (mindfacturing). A la base du manufacturing, c'est le changement d'outil qui coûtait cher, or en informatique, changer d'outils, c'est utiliser la combinaison CTRL-TAB !!! Par ailleurs, ce qui différencie un travail physique d'un travail intellectuel, c'est d'abord les différences (de rendement) entre les personnes. Par exemple, entre le champion du monde du 100m (#10s) et ma propre performances de dimanche dernier (#16s), il y a un rapport de 1,6 arrondi à 2. Par contre, entre deux développeurs, le rapport peut être de 10, 100, 1000, 10000 voire l'infini... Je sais c'est pas politiquement correct mais cela se vérifie tous les jours. Ce qui coûte aussi cher en informatique, c'est surtout la perte d'information entre les personnes qui travaille ensembles. On appelle cela les relations interpersonnelles et plus il y a de personnes, et plus il y a de perte d'informations. Au final, mieux vaut ne pas organiser une équipe de développeurs par spécialité (ou outils comme dans le manufacturing) car c'est la situation la pire où les personnes ne se comprennent pas. Par exemple, un développeur IHM, un développeur "couche métier", un développeur base de données. C'est pourtant le découpage classique qu'on trouve dans une équipe de développeur, un découpage par couche technique, un découpage "horizontal". En fait, pour limiter au maximum ces problèmes d'incompréhension, mieux vaut un découpage fonctionnel (ou métier) où toutes les couches techniques apparaissent. Le projet est alors découpé par couche "verticale". On retombe alors sur les principes de l'agilité où c'est avant tout la valeur métier qui est mise en avant. Bref le raisonnement ayant aboutit à l'industrialisation du manufacturing est globalement bon, mais il faut le refaire pour l'appliquer au domaine du développement informatique et ne pas chercher à transposer aveuglément les bonnes pratiques du manufacturing.
  • Article
    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha