Encore trop de personnes haut placées dans les entreprises logicielles ne jurent que par la « productivité ». La sacro-sainte « productivité » !
Dans l’industrie classique cela revient à produire des pièces mécaniques. Dans l’industrie logicielle on représente malheureusement souvent cela comme « pisser du code » (ce qui explique « productivité »).
Cela me met hors de moi lorsque j’entends : « On ne peut pas faire de bilan des campagnes de test, ni de rétrospective, ni de documentation car ce n’est pas productif » !
A cela j’ai envie de répondre : « Hé Ho, ici le 21ème siècle et l’industrie logicielle ce n’est plus le règne du fordisme ! »
Pour être honnête, je trouve que le terme « industrialisation » dans le logiciel est sujet à confusion et je souhaite donc revenir sur différents points :
· Dans l’industrie classique on fait plusieurs fois la même pièce alors que dans l’industrie logicielle on fait 1 logiciel qui évolue ou des logiciels tous différents !
Dans l’industrie « classique » on fait toujours la même pièce et le but est juste de pouvoir en produire le plus possible au prix le plus bas possible. Cela mène à un vrai travail sur la productivité et sur la chasse à tous les moments perdus. Le film « Les temps modernes » de Chaplin le montre très bien (je sais que ce film est vieux… tout comme l’idée d’augmenter la productivité à tout prix !)
Dans l’industrie logicielle le problème n’est pas le même. Plus personne ne refait exactement le même code pour tous ses projets (sinon, c’est le même projet et un copier/coller suffit !). De plus avec le développement des méthodes itératives le logiciel évolue et est enrichi continuellement avec de nouvelles lignes de code. La problématique n’est donc plus la même (qui a déjà vu une clé à molette évoluée après son achat et proposer une option clé à laine puis une autre option tournevis ?)
· La productivité ce n’est pas seulement des lignes de codes.
Le nombre de lignes de code ne correspond pas à la qualité ni aux capacités du produit. On pourrait comparer les pièces fabriquées aux lignes de codes. Malheureusement, les lignes de code, contrairement à la fabrication des pièces, ne sont pas suffisantes pour définir la productivité d’une équipe projet sur du logiciel. En effet, dans l’industrie logicielle, la partie test et spécifications ne peuvent pas être dissociées de la productivité.
A noter : Dans ce schéma je n’intègre pas l’impact des régressions. Les régressions peuvent aisément, en cas de non maitrise du logiciel, multiplier par 2 ou 3 le temps à passer sur une fonctionnalité.
La productivité en industrie logicielle se mesure plus aisément en fonctionnalités (plus ou moins complexes) implémentées ainsi que sur le temps passé à les « réparer » ou « réparer » leurs impacts lorsqu’elles sont en production. Mettre à tout prix une fonctionnalité en production ne veut pas dire que le travail sur cette dernière est finie. Dans certains cas extrême, le coût de réparation peut même être bien supérieur au coût de développement.
· Dans l’industrie classique faire une erreur sur la deuxième pièce ne casse pas la première !
Dans l’industrie logicielle une nouvelle fonctionnalité peut casser une fonctionnalité existante, c’’est ce que l’on appelle des régressions. Ces régressions peuvent vite être très coûteuses et empêcher tout développement de nouvelles fonctionnalités.
Dans l’industrie classique ce n’est pas le cas. Des pièces sont fabriquées et une fois qu’elles sont fabriquées, s’il n’y a pas de défaut alors tout va bien. Par contre, dans l’industrie classique comme dans l’industrie logicielle les pièces (ou fonctionnalités) fonctionnent dans un système plus grand (roue pour une voiture, connexion pour un logiciel), pour ces 2 industries il est nécessaire d’avoir des tests du type tests intégration.
· La communication entre les différentes équipes est obligatoire dans l’industrie logicielle
Dans l’industrie classique, pas besoin de connaitre celui qui fait le châssis de la voiture pour pouvoir faire des pneus. L’important est de suivre les plans et de fabriquer toujours la même pièce.
Dans l’industrie logicielle ce n’est pas le cas. Les testeurs doivent intervenir le plus tôt possible dans le cycle de développement (shift left) mais surtout beaucoup communiquer à tout moment du projet. L’idée pour le testeur est de trouver les anomalies au plus tôt pour que ces dernières soient corrigées au plus tôt. La communication entre les différents acteurs et compétences d’un projet est un point central dans les méthodes agiles (Scrum, Kanban) et la philosophie DevOps.
Conclusion :
Il faut arrêter de vivre dans le passé! Par industrialisation du développement logiciel on n’entend pas augmentation de la capacité à écrire des lignes de codes. Lorsque l’on parle d’industrialisation du développement logiciel il faut en fait entendre la mise en place de processus communs permettant de standardiser des méthodes de travail. Cela permet de faciliter le travail quotidien des acteurs du projet, de limiter au maximum les dépendances envers 1 personne qui serait le seul à avoir certaines connaissances mais aussi d’améliorer efficacement le rythme de livraison de fonctionnalités de qualité.
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
