Fabrication vs développement de logiciels [fermé]

On dit souvent que l'industrie du logiciel est immature par rapport à la fabrication. Plus précisément en ce qui concerne le processus.

Question : Pouvons-nous, en tant que développeurs, apprendre des processus de l'industrie manufacturière? L'adoption de leurs processus peut-elle augmenter le taux de réussite du développement logiciel?

Mon point de vue : dans la fabrication, la création d'un produit est fortement axée sur les processus. Vous pouvez avoir une usine où chaque personne a un ensemble spécifique de tâches qu'elle suit. Un travailleur (ou un robot) peut serrer une vis toute la journée. Ensuite, la tâche suivante du processus est effectuée par le spécialiste suivant. Les travailleurs (et les robots) ne découragent pas le processus ni ne fabriquent quelque chose "à la volée". Les pièces se déplacent tout au long du processus et la sortie est un produit fini. Cela fonctionne bien et les entreprises obtiennent des produits sans défauts à 99,99966%. Les entreprises éliminent les inefficacités au fil du temps. C'est impressionnant et peut très bien être le signe d'une industrie mature.

Lors de la fabrication, un processus défini peut littéralement créer le produit fini. Je ne pense pas que ce soit le cas dans les logiciels. Nous pouvons avoir des processus pour le contrôle des sources, la révision du code, les feuilles d'enregistrement, la collecte des exigences, le SDLC, etc. Mais l'exécution de ces processus ne crée pas en soi un produit fini. Ces processus peuvent être bénéfiques, mais ils sont orthogonaux à la création réelle.

Supposons que votre entreprise soit mandatée pour créer un logiciel qui recherchera des millions d'images pour trouver les visages d'un criminel. Malgré l'environnement lourd axé sur les processus, le développeur doit s'engager à créer des choses "à la volée". Faire des choses à la volée est contraire à l'esprit de fabrication. Un bon processus de fabrication peut être exécuté sans réflexion par un robot.

Pour la création d'algorithmes complexes qui ne sont pas encore compris dans l'esprit d'un humain, il est nécessaire de créer des choses à la volée. Le développement logiciel n'est pas la suite d'un processus, mais la création d'un processus à exécuter par un ordinateur. C'est une différence fondamentale. Peu importe le nombre de processus orthogonaux que nous mettons en place autour du développement, nous recourrons toujours à le faire "à la volée" en matière de création.

Tout le monde à qui je parle semble d'accord avec l'état d'esprit de fabrication. Suis-je seul dans mes pensées?

La différence fondamentale entre le développement et la fabrication de logiciels est que pour les logiciels, la phase de conception est pratiquement tout. La production réelle (partie de la chaîne de montage dans la fabrication traditionnelle) consiste à copier quelques fichiers autour. Dans le logiciel, la conception du produit est le produit.

Alors oui, nous pouvons apprendre des processus de fabrication, mais seulement si nous gardons à l'esprit que nous devons considérer la phase de conception, pas la phase de production, et que de nombreux processus de fabrication sont conçus pour faire face aux limites spécifiques d'une chaîne de production coûteuse. , qui ne s'applique tout simplement pas aux logiciels.

Un exemple de modèle de processus qui fonctionne très bien dans les logiciels, mais échoue souvent horriblement dans la conception des produits, est la conception itérative - vous commencez avec un prototype minimal et ajoutez des fonctionnalités à chaque itération. Construire un prototype de voiture pour voir à quoi ressemble la nouvelle conception du bouton de la lunette arrière est ridicule, mais dans le logiciel, cela a du sens (appuyez simplement sur F5 et attendez quelques secondes - voilà, prêt à tester).

Si nous examinons les processus de conception de produits, les meilleures industries à examiner se divisent en deux catégories:

• ceux où la production peut être réalisée aux taux des produits de base; par exemple l'industrie du disque (1% ou moins du prix d'un CD est la cuisson et l'impression), les supports graphiques, etc.
• ceux dont les quantités sont si faibles que la phase de conception est le facteur de coût le plus important (articles de luxe, produits hautement personnalisés, marchés de niche ...)

C'est une erreur fondamentale d'essayer d'appliquer des processus de la fabrication physique au développement de logiciels: le développement de logiciels n'est pas répétitif (si c'est votre travail, allez chercher un autre travail), il n'est que partiellement prévisible, il n'y a que très peu de limitations physiques ( la vitesse du matériel étant une), et l'approche adoptée et les résultats peuvent être très personnels. L'application des philosophies de la chaîne de montage à ce qui est fondamentalement une question de pensée analytique et créative peut (et a souvent) des effets dévastateurs.

Si vous vouliez écrire le même logiciel encore et encore (au lieu de simplement le copier), vous pourriez le faire très efficacement via une chaîne de montage.

Mais la création de logiciels n'est pas une tâche répétitive, chaque module est uniqe. C'est pourquoi la comparaison avec la fabrication n'est pas valide.

Je pense que la réponse que vous cherchez est applicable ou réaliste ici. Ce que je pense que vous voulez savoir, c'est comment pouvons-nous configurer nos processus pour qu'ils ressemblent davantage à l'industrie manufacturière. Au lieu de cela, je pense que la vraie question devient "Savoir ce que font les industries manufacturières et autres pour construire des produits de qualité, que pouvons-nous apprendre?" ou "Que peut faire l'industrie du logiciel pour améliorer la qualité?"

Malheureusement, la réponse à cette question n'est pas claire, car l'industrie du logiciel elle-même ne connaît toujours pas la réponse. Afin de pouvoir répondre à cette question, l'industrie du logiciel doit faire des recherches sur ce qui fonctionne et pourquoi? Par exemple, des études ont montré que le Test Drive Design (TDD) conduit à une amélioration de la qualité. Bien que la question de la productivité semble encore sans réponse ou du moins pas encore complètement comprise. En ce qui concerne ce que les preuves montrent jusqu'à présent:

• Les revues de code sont excellentes et ont montré qu'elles détectaient le plus de bugs, mais l'efficacité d'une revue chute assez fortement après la première heure de revue. Étant donné que la personne moyenne ne peut lire que quelques centaines de lignes de code par heure, cela suggère que les développeurs décomposent les modifications en morceaux plus petits.
• Plus il faut de temps pour trouver un bug, plus il sera cher (temps et argent) de le corriger. Donc, si un développeur le trouve lors de l'écriture du code, nous disons que le coût est de 1. Si un unittest le trouve plus tard, le coût est de 10, si EVT le trouve, le coût est de 100 et ainsi de suite.
• Certaines preuves suggèrent que plus les exigences sont complexes, plus la solution est complexe et plus la solution est complexe, plus il y aura de bogues.

Il y a un homme du nom de Greg Wilson qui a fait un excellent discours à ce sujet il y a quelques années. Voici un lien vers la conférence: Greg Wilson Talk

En plus de cela, je dirais revenir sur votre propre travail et trouver les thèmes avec les types d'erreurs que vous introduisez ainsi que les parties avec lesquelles vous luttez. Compilez ces résultats, puis créez une liste de contrôle à insérer dans votre processus à différents endroits pour vous aider à faire un meilleur travail. Personnellement, j'ai regardé en arrière au cours des dernières années de mon travail et constaté qu'il y a des thèmes communs aux problèmes que j'introduis. Plus précisément, j'ai constaté que

• Je ne me souviens pas souvent de construire toutes les variantes menant à la rupture de la construction.
• Souvent, je ne pense pas aux éléments suivants pour chaque changement. Le bon cas, le mauvais cas et les cas exceptionnels.
• Tous les scénarios possibles qui pourraient se produire. Notez que c'est vraiment difficile car il y en a beaucoup.

Depuis que j'ai trouvé des thèmes pour mes erreurs, j'ai créé des listes de contrôle que j'utilise automatiquement, en raison de leur insertion dans mes scripts, qui m'aident à contourner ces problèmes. Il y avait un livre écrit à propos de cet appel, le "manifeste liste de contrôle" qui détaille comment les utiliser à bon escient. Personnellement, je l'ai trouvé très perspicace.

Il ne s'agit pas d'adopter "leurs" processus. Il s'agit d'adopter "certains" processus, qui n'ont pas les inconvénients habituels et bien appréciés d'utiliser des processus de chaîne de montage pour des efforts créatifs. La chose la plus importante à noter ici est l'idée que la qualité des processus se traduit directement par la qualité du produit.

Les meilleurs processus, ou produits d'ailleurs, sont ceux qui correspondent au scénario d'utilisation prévu comme une main dans la main. La chose à laquelle penser est que la partie réelle de l'écriture de code est à peu près la seule qui, au moins au niveau macroscopique, n'est pas répétitive. Toutes les autres facettes, telles que le contrôle de version, le suivi des bogues, la planification, les estimations, les mesures, etc. le sont, et l'utilisation d'un processus standard, personnalisé et éprouvé peut vous aider au moins dans ces domaines.

Donc non, le processus de développement logiciel ne peut pas être assimilé à la production à la chaîne de montage et en tant que tel "leurs processus" ne sont pas OK, mais la phase de conception de production / conception de produit du produit dans une industrie manufacturière peut être celle à laquelle s'inspirer.

Question: Pouvons-nous, en tant que développeurs, apprendre des processus de l'industrie manufacturière? L'adoption de leurs processus peut-elle augmenter le taux de réussite du développement logiciel?

Réponse: oui, bien sûr. Les développeurs de logiciels peuvent tirer de nombreuses leçons de la fabrication, même si le développement de logiciels est un processus créatif. Le développement de logiciels est lui-même un processus, et il comprend de nombreux autres processus. Mieux vous pouvez définir et contrôler ces processus, mieux vous maîtrisez le processus de développement logiciel dans son ensemble. Cela ne signifie pas que vous devez prescrire chaque frappe effectuée par un développeur; cela signifie simplement qu'en tant que développeur, vous effectuez naturellement des tâches dans un certain ordre, et ces tâches peuvent souvent être gérées. Voici quelques exemples:

• suivi des défauts: lorsqu'un bug est observé ou signalé, que se passe-t-il? L'écrivez-vous sur un morceau de papier et le collez-vous sur une pointe «enquête»? Enlevez-vous plus tard ces morceaux un à la fois, examinez-les et éventuellement déplacez-les vers le pic «résolu»? Si vous le faites sans échec chaque fois que vous recevez un rapport de bogue, vous disposez d'un processus bien défini et mesurable, et vous êtes probablement beaucoup mieux que quelqu'un qui a un système de suivi de défauts sophistiqué et de haute technologie qui est si onéreux que certains membres de l'équipe suivent les bogues autrement, ou pas du tout.

• contrôle de version: il y a de fortes chances que vous utilisiez le contrôle de version là où vous travaillez, et le contrôle de version est évidemment beaucoup plus utile lorsque tout le monde l'utilise de la même manière.

• conception du produit: décidez-vous des fonctionnalités à mettre en œuvre en lançant des fléchettes sur un mur recouvert de post-it? Si oui, vous avez un processus. Je ne pense pas que quiconque dirait que c'est un excellent processus, mais au moins c'est un point de départ. Si vous changez le processus, comment pouvez-vous être certain que votre changement était en fait une amélioration, à moins que vous ne mesuriez avant et après? Tu ne peux pas.

• revues de code: Une revue de code serait-elle utile si le processus de revue et les critères de codage changeaient pour chaque revue? Bien sûr que non.

• cycle de vie du développement logiciel: l'ensemble de l' analyse -> conception -> mise en œuvre -> test -> cycle de maintenance est un processus qui doit être clairement défini.

Dans chacun de ces cas, la mise en place d'un processus vous permet de mesurer les entrées et les sorties et de déterminer si les modifications que vous apportez ont l'effet escompté. Ne pas avoir de processus en place signifie que vous devinez simplement quand vous essayez d'améliorer votre façon de travailler. C'est vraiment ce qu'est la fabrication, et cela n'a de sens que d'emprunter les outils de raffinement successifs de la fabrication lorsqu'ils sont appropriés.

Il y a tout un domaine consacré à la définition et à l'amélioration des processus utilisés pour créer et maintenir des logiciels; cela s'appelle le génie logiciel . Il n'est pas surprenant que vous ayez des questions sur le processus de développement en lisant sur CMMI - CMMI est un produit du Software Engineering Institute .

Le développement de logiciels a déjà adopté de nombreux concepts de fabrication:

• Il est difficile de ne pas voir l'influence des pièces interchangeables d'Eli Whitney sur la POO et le développement à base de composants .

• Les techniques de gestion de projet utilisées dans le développement de logiciels ne sont pas très différentes de celles développées pour la fabrication. À titre d'exemple, le monde du logiciel n'a adopté que récemment le concept Kanban qui a été développé il y a des décennies chez Toyota, et les diagrammes de Gantt ont été utilisés dans la fabrication bien avant la construction du premier ordinateur électronique.

• Les méthodologies de gestion de la qualité comme Six Sigma qui ont été développées pour la fabrication ont été adaptées au développement de logiciels.

Malgré l'environnement lourd axé sur les processus, le développeur doit s'engager à créer des choses "à la volée".

Êtes-vous en train de me dire que quelqu'un va décider par lui-même d'ajouter un patch au package de reconnaissance faciale, et qu'il va l'ajouter dans la version de production sans créer d'abord un problème dans le système de suivi, en faisant réviser la conception, vérifier le code dans le contrôle de version, ou demander aux gens de tester de le regarder en premier? Notre processus nécessite ces éléments pour de très bonnes raisons. Si par «à la volée» vous voulez dire «en dehors du processus», c'est inacceptable.

Faire des choses à la volée est contraire à l'esprit de fabrication.

Encore une fois, si «à la volée» signifie «en dehors du processus», vous avez raison. Mais si vous pensez que la fabrication ne nécessite pas une réflexion rapide et le développement de solutions créatives aux problèmes, vous vous trompez. Toutes sortes de problèmes surviennent dans le processus de fabrication - les cupcakes n'ont pas suffisamment de crème, les surfaces peintes cessent soudainement de passer le test de rayures de QA, 20% des pièces finies manquent d'un anneau de retenue important, le système de mélange de la pâte a cassé un partie critique...