Discussion :

[ddacosta]

Bonjour à tous,

Je me présente, David, étudiant en dernière année d'école de commerce. Vous allez me dire que je suis perdu ici au milieu des développeurs. Il est vrai, je suis un peu perdu mais pour une bonne raison. En effet, je prépare actuellement ma thèse professionnelle de fin d'étude portée sur le sujet de l'industrialisation des développements informatique.
C'est un sujet (sofware factory) qui a quelques années mais qui ne connaît pas encore de fort succès.

Je me permets de venir vous solliciter pour la raison suivante :

La problématique de ma thèse est de savoir comment amener cette solution d'industrialisation sur le marché. Pour celà je vais m'intéresser principalement sur la segmentation du marché. J'ai donc, en plus de mes revues de littérature, une enquête à réaliser auprès des principaux interessés : les développeurs.

Je vous demande donc vos avis sur l'industrialisation et le software factory : selon vous cela peut répondre à quels besoins, pour quels métiers, les avantages/inconvenients, les limites...

Pour finir mon année d'étude, je travaille chez NourY Solutions, qui a mis en ligne dernièrement une software factory .NET open source du nom de Salamanca. Je vous encourage la tester, cela vous aidera certainement à mieux me répondre.

En esperant avoir un maximum de réponse et lancer un débat !

Merci pour les quelques minutes consacrées

David

[el_slapper]

Je ne fais pas des masses de .NET(seulement en dev perso), mais "l'industrialisation des développements" est un vieux serpent de mer qui revient régulièrement, auquel j'ai cru pendant longtemps, et finalement, ça ne marche jamais.

Ca ne marche jamais parceque el développement n'est pas une activité répétitive. En automobile(de loin les meilleurs pour tout ce qui est industrialisation et procédures qualité), on fabrique toujours le même airbag. Par contre, il a fallu 20 ans pour le mettre au point.

Au vu des contraintes de fabrication, les procédures de fabrications sont extrêmement strictes pour s'assurer du déclenchement seulement quand nécéssaire, de la bonne explosion des bâtons de dynamite, du bon déploiement du coussin, etc.....tout celà est très difficille à reproduire à chaque airbag, d'ou l'utilisation massive de procédures qualité. Par contre, la R&D a été faite une fois, c'est bon, ça marche. Mais personne ne pouvait prévoir qu'elle prendrait 20 ans, et qu'elle perçerait quelques plafonds(12 mètres de haut, les plafonds).

Le truc, c'est que le dévelloppement, c'est de la R&D, et seulement de la R&D. La partie "production", c'est juste le déploiement, ça n'est pas toujours anodin, mais c'est en général déjà bien maitrisé. Pas besoin de rajouter des couches qualité/industrialisation. Quand au développement, eh bien on ne développe jamais 2 fois la même appli(sinon, il suffirait de la recopier, et ça, c'est maitrisé). Donc, nonobstant les habituelles modularisations, aussi anciennes que le développement lui-même, je ne vois pas comment industrialier plus en amont. Le rêve, effectivement, c'est de créer des interfaces qui permettent de génerer ET les écrans ET leurs comportement. Seulement, si on peut faire de belles choses sur les écrans(les outils .NET étant un bel exemple - pas le seul - à ce sujet), le comportement, lui, est toujours tributaire d'un fonctionnement local. Donc à faire à la mimine, suivant les instructions du demandeur.

Désolé d'être si négatif, mais je considère ton sujet comme un faux bon sujet.

[gangsoleil]

Bonjour,

Dans certains cas tres precis, je peux voir l'utilite d'un generateur de code - a condition bien sur que celui-ci soit exempt de bugs :-).
Dans la plupart des cas, comme l'a dit el_slapper, le developpement n'est pas repetitif, ou du moins faussement repetitif. Je le vois au quotidien avec l'integration de produits open-source :
Une personne developpe un logiciel qui repond a son besoin precis. Comme il est philantrope, il le met sous licence libre, et chacun peut l'utiliser gratuitement. Plus tard, je cherche un truc qui reponde a mon besoin tres precis. Je trouve la logiciel, qui semble repondre, mais une fois que je l'utilise, je m'apercois qu'il ne repond qu'a 60% de ce qui m'interesse.
Alors certes, je peux reprendre le code de la base existante et ajouter mes fonctionalites, mais au final c'est long, presque aussi long que de coder mon logiciel.

Bref, tout ca pour exprimer que les besoins ne sont jamais exactement les memes dans l'informatique, car ce n'est pas le concepteur qui impose son besoin (cas de l'airbag par exemple), mais le client.

Si on prenait une demande client pour les airbags, on trouverait :

• Besoin de douceur du materiau (tissus hypoallergenique)
• Besoin d'ouverture deux fois plus rapide que les autres car vehicule plus puissant (peu importe le prix)
• Besoin d'airbags de couleurs, a la demande lors de la construction (possibilite de l'avoir en bleu a pois verts)
• Besoin de pouvoir changer la couleur avec le temps
• Besoin de pouvoir le diagnostiquer soi-meme
• Besoin d'une possibilite de declenchement manuel, en appuyant sur un bouton
• ...

Je pourrai continuer longtemps cette liste, a laquelle je suis confronte chaque jour lors de demandes client.

[ddacosta]

Merci à vous !
Vos réponses confirment mes observations auprès des différents sites de développeurs et des livres blancs lus relatifs au sujet : on a tous des avis différents sur l'industrialisation !
Plus que des avis différents, il y a plusieurs définitions qui sortent.

J'ai enfin validé ma problématique de thèse : l'acceptabilité d'une solution de rupture : l'industrialisation des développements informatiques.

Dans mes démarches théorique j'étudie les concepts d'industrialisation, de standardisation et de modularisation. Là sera la difficulté car il y a tellement de variantes de définitions

D'après ce que je sais maintenant, on est en mesure d'automatiser la partie ORM, chose que pas mal d'outils open source font.
La partie activité métier est déjà moins industrialisée, je me trompe ?

D'autres avis ?

[el_slapper]

(.../...)
D'après ce que je sais maintenant, on est en mesure d'automatiser la partie ORM, chose que pas mal d'outils open source font.
La partie activité métier est déjà moins industrialisée, je me trompe ?

D'autres avis ?

ben non, encore le même gugusse : la partie métier est rarement industrialisée. Et plus la société est grande, moins elle l'est. Il est impressionant de voir l'abysse de différences qu'il peut y avoir entre la SG et BNPParibas - alors que ces 2 sociétés font exactement le même métier.

Si les différences entre un salon de coiffure et un autre salon de coiffure sont assez dérisoires pour qu'une solution standard logicielle suffise aux deux. Mais plus on monte en taille d'entreprise, et plus l'entreprise tentera de faire mieux que ses concurrents au niveau organisationel. Celà passe par des choix qui, dans le monde moderne, impactent fortement le système d'information. Et la manière dont le métier est géré. Partant de là, "industrialiser le métier", c'est empêcher les grandes sociétés de chercher à gagner un avantage concurrentiel par des pratiques organisationelles innovantes.

[ddacosta]

Mais plus on monte en taille d'entreprise, et plus l'entreprise tentera de faire mieux que ses concurrents au niveau organisationel

Je suis tout à fait d'accord avec toi

. Partant de là, "industrialiser le métier", c'est empêcher les grandes sociétés de chercher à gagner un avantage concurrentiel par des pratiques organisationelles innovantes.

Avec du recul, je me suis forgé l'idée qu'un développeur est un artisan. Aujourd'hui, comme tu l'as déjà comparé avec l'industrie automobile, beaucoup de processus métier sont industrialisé, en tout cas une grande partie. Cependant, pour gagner en compétitivité, il faut se demarquer grâce à un avantage concurrentiel.

Par exemple le designer de Seat créé une nouvelle voiture innovante (nouveau design, caracteristique etc..). Or, lors de sa fabrication, une mutlitude de modules sont génériques aux modèles proches (ibiza=golf par exemple). L'industrie automobile économise en coût et en délai de production.

Pour le développeur, il me semble que c'est pareil. Pour la majorité de ses développements d'applications métier il se base sur les mêmes bibliothèques. Alors pourquoi ne pas les industrialiser ? Il peut tout à fait modifier certains codes à la main par la suite s'il en a le besoin.

Là où je veux en venir, c'est que la valeur ajoutée du développeur est dans le développement de la spécificité métier de l'application. Tout comme un artisan, il dégage son talent dans la personnalisation et le savoir-faire qui lui est propre.

[el_slapper]

(.../...)
Par exemple le designer de Seat créé une nouvelle voiture innovante (nouveau design, caracteristique etc..). Or, lors de sa fabrication, une mutlitude de modules sont génériques aux modèles proches (ibiza=golf par exemple). L'industrie automobile économise en coût et en délai de production.

exact, mais c'est aussi parcequ'elle travaille avec les contraintes du matériel, qui sont autres que celles du logiciel. Il n'y a pas 50 manières de fabriquer un arbre de transmissions, et surtout pas 50 manières rentables.

Pour le développeur, il me semble que c'est pareil. Pour la majorité de ses développements d'applications métier il se base sur les mêmes bibliothèques. Alors pourquoi ne pas les industrialiser ? Il peut tout à fait modifier certains codes à la main par la suite s'il en a le besoin.

Attention. Il y a 2 niveaux là-dedans : les bibliothèques techniques et les bibliothèques fonctionelles.

Les bibliothèques techniques, parfois sont maison(mais ça, c'est surtout vrai dans le jeu vidéo, en info de gestion ça a tendance à disparaitre), mais le plus souvent sont des standards disponibles partout(payants ou open source, c'est un autre débat). Ca s'étend, et c'est une bonne chose. Si quelqu'un a déjà fait une bibliothèque pour envoyer un mail en automatique, je ne vois pas l'interêt de le refaire.

Par contre.

Je n'ai jamais vu de bibliothèque fonctionelle transverse à plusieurs entreprises. Je travaille avec des gros, je précise. Et chacun a des besoins et des méthodes totalement différentes. Même sur des concepts connement identiques.

Exemple : un RIB, c'est tout con. un code banque sur 5, un code guichet sur 5, un numéro de compte sur 2, et une clef. Ben même ça, c'est géré différement suivant les banques. Spécialement sur la problèmatique du RIB invariant. Quand un client change d'agence au sein de la même banque, son code guichet change - donc son RIB aussi. Or ça emmerde le client. Donc la plupart des banques ont créé un "RIB invariant" qui résoud le problème. Seulement, les solutions choisies sont radicalement différentes. Chez certains, le "RIB invariant" est juste une astuce d'affichage. Le vrai RIB avec le vrai code guichet est toujours utilisé partout, c'est juste à l'affichage que l'on transcode. Chez d'autres, on a modifié tous les traitements pour que le code guichet n'aie plus aucune valeur. Chez d'autres enfin, on affiche carrément les 2 RIB, le RIB "société" et le RIB "agence" à l'écran.

Aucune de ses solutions n'est mauvaise en soi. Seulement, je serais curieux de savoir comment on industrialise des pratiques aussi opposées sur des données aussi fondamentales(le numéro de compte, en bancaire, c'est un peu comme le volant dans une voiture, difficille de le passer par pertes et profits)

Là où je veux en venir, c'est que la valeur ajoutée du développeur est dans le développement de la spécificité métier de l'application. Tout comme un artisan, il dégage son talent dans la personnalisation et le savoir-faire qui lui est propre.

Ah mais on est totalement d'accord. Simplement, ce sur quoi je veux porter ton attention, c'est que le périmètre de "spécificité métier de l'application" va très loin, et s'étend souvent au-delà de l'application elle-même.

[ddacosta]

Simplement, ce sur quoi je veux porter ton attention, c'est que le périmètre de "spécificité métier de l'application" va très loin, et s'étend souvent au-delà de l'application elle-même.

Tout à fait, d'où le besoin de se consacrer davantage à cette partie. L'industrialisation peut soit réduire le temps global d'un projet, soit permettre de consacrer un temps utile au développement de la spécificité métier et garantir davantage le succès du projet.

Puis pour revenir à l'artisan, il a beau être talentueux dans son domaine, une commande reste une commande, il doit restituer ce qu'on lui demande en amont. Il doit donc consulter d'autres personnes, d'autres spécificités ou un cahier des charges pertinent (ce dernier est aussi primordial à la réussite du projet, ce qu'on oubli souvent malheureusement, mais ceci est un autre débat).

Je suis donc bien d'accord avec toi que la spécificité métier de l'application va bien plus loin que l'application elle-même.

[ddacosta]

Je relance le débat, j'espère avoir de nouveaux commentaires sur le thème de l'industrialisation :
- les pour et les contre
- passage de l'ère artisanale à l'ère industrielle : votre avis ?
- quel est votre pouvoir de décision en entreprise : pouvez-vous facilement intégrer un outil d'industrialisation dans vos projets ? (selon votre poste biensur : DSI, Développeur, Chef de Projet...)
- etc...

De plus, sauriez-vous où je peux observer des conversations sur ce sujet ? (blog, forum...)


Merci de votre participation