En résumé, l’industrialisation permet de dupliquer à grande échelle le produit conçu lors de la phase de création en s’assurant de sa qualité et en maîtrisant les coûts au plus juste, car l’ensemble de ses caractéristiques est connu précisément.
Or, n'en déplaise à certains, le développement logiciel est par essence une activité créative, au même titre que l’écriture d’un livre, la réalisation d’un dessin ou d’une peinture ou l’élaboration d’une nouvelle théorie mathématique.
En effet, si le programme existait déjà, personne ne demanderait à un développeur de l’écrire, donc de le créer…
La conception de logiciel ne peut donc être industrialisée puisque comme nous l’avons constaté précédemment, il est indispensable de disposer d’au moins un exemplaire physique pour pouvoir estimer précisément les ressources nécessaires à sa fabrication à grande échelle et avoir les informations nécessaires aux divers contrôles de qualité.
Il est donc très délicat sinon impossible d’estimer de manière fiable les ressources humaines, techniques et temporelles nécessaires à la conception d’un logiciel, et encore plus difficile de définir les spécifications permettant de s’assurer qu’il répond bien aux besoins.
J'en connais qui me rétorqueront qu’il est tout de même possible d’industrialiser à minima le développement d’un logiciel à l’aide de framework et autres briques logicielles « clef en main ».
Cependant, la colle nécessaire pour assembler ces briques afin d'obtenir le programme demandé devra être inventée et nécessitera donc toujours un effort créatif.
En conséquence, même en recourant à de tels outils, il reste impossible de donner une estimation précise et fiable du temps nécessaire à la réalisation d’un programme.
Car en réalité, les frameworks et autres briques logicielles ne permettent pas d’industrialiser le processus de développement d’un logiciel.
Ils facilitent uniquement la vie du développeur en lui permettant d’utiliser du code en théorie de bonne qualité, correctement documenté et conçu pour répondre aux besoins essentiels et communs à la plupart des programmes.
Évidemment, cela lui permet de développer plus rapidement son programme, mais ce n’est pas pour cela qu’il pourra estimer plus précisément le temps qu’il mettra à le concevoir dans son intégralité, d’autant que parfois, ces outils peuvent au contraire lui faire perdre du temps indépendamment de sa volonté.
De même, certains outils tels que les frameworks de tests unitaires ou fonctionnels ainsi que certaines méthodologies comme le TDD permettent effectivement d’estimer la qualité du code, tout comme les méthodes agiles permettent d’estimer le temps nécessaire à la réalisation d’un ensemble de tâches en se basant sur le temps passé précédemment pour réaliser d’autres tâches plus ou moins complexes.
Cependant, ces estimations sont empiriques et n’ont donc pas la précision absolue et intangible de celles ayant court dans le cadre d’un processus industrialisé.
En conclusion, demander à un développeur le temps qu’il mettra à développer un logiciel n’est pas la même chose que demander à un peintre en bâtiment le temps qu’il va mettre et le nombre de pots de peinture dont il aura besoin pour peindre un mur de 12 m² en vert.
C’est en fait comme demander, s’ils étaient encore de ce monde, à Léonard de Vinci le temps qu’il va mettre à peindre le tableau d’une femme posant devant un paysage ou bien à Albert Einstein le temps qu’il lui faut pour inventer une théorie expliquant la relation entre l'espace, le temps, et peut être éventuellement d'autres paramêtres.
Et je suis prêt à parier que dans les deux cas, la réponse serait du style « un certain temps ».
12 réactions
1 De Sébastien Douche - 15/05/2013, 16:22
C'est la raison de l'absence totale d'estimation du temps dans mon équipe. Il est impossible de quantifier quand tu crées un nouveau logiciel. Par contre j'ai beaucoup travaillé sur le fait de découper en petite tâche le plus rapidement livrable (les grosses elles sont en // du flux principal, merci Git).
Ce qui sous entend implicitement que toutes les méthodos qui veulent d'une manière ou d'une autre estimer du temps sont de la foutaise. Bref, toutes en sommes.
2 De Cyrano - 15/05/2013, 16:51
De mémoire, ce sujet avait fait l'objet d'une conférence à Nantes l'an dernier, je ne sais plus trop laquelle malheureusement. Mais les conclusions étaient sensiblement les mêmes : j'en arrive même à me demander s'il est raisonnable d'envisager qu'il pourrait en être autrement dans un avenir plus ou moins proche.
3 De bthuillier - 15/05/2013, 17:03
Je suis plutôt d'accord sur le fond, mais là où je suis pas d'accord c'est tes comparaisons avec l'écriture d'un livre, réalisation d'un dessin ... .
Je trouve que comparer le développement/programmation avec les métiers de l'artisanat en général aurait été beaucoup plus pertinent et adapté. On peut faire même directement une analogie entre les estimations dans l'artisanat du batîment et le développement.
4 De VincentLg - 15/05/2013, 17:03
Tout en étant d'accord sur la grande difficulté à estimer la conception d'un logiciel, il est encore plus difficile (impossible?) de répondre à une demande d'estim d'un client "un certain temps".
On peut faire des prototypes, des maquettes, des séances d'estimation en profitant de l'expérience des devs présents... il existe heureusement des solutions (même imparfaites) mais qui permettent au client de prendre une decision et aux devs de livrer (occasionnellement ;)) dans les temps.
Même en faisant un "forfait agile" on ne peut pas nier la nécessité pour un client d'avoir une idée globale du coût de réalisation de son projet, quitte à facturer cette prestation si il faut prototyper...
Quand mon garagiste me dit "Pour identifier la panne je vais devoir tout démonter, c'est facturé. Ensuite je vous ferais un devis pour réparer la panne" Même si je trouve ça injuste sur le moment je finis par payer car c'est honnête et transparent. Quand je code je ressemble plus à mon garagiste qu'à Léonard de Vinci ou Einstein... je reste donc sceptique à l'idée qu'un processus de création original serait totalement impossible à estimer.
5 De Thierry - 15/05/2013, 18:09
Complètement d'accord, mais dans les faits je comprends aussi la volonté du client d'avoir une idée de ce que ça va lui coûter.
Je crois que je vais coller ton billet en lien dans mes estimations
6 De Adirelle - 16/05/2013, 09:19
C'est rigolo, je n'aurai pas pris cette extrait de Wikipedia, car elle parle d'offre et non de produit. Je trouve que la phrase précédente est bien plus pertinente par rapport au contenu de ce billet : "Dans une entreprise, le service industrialisation est chargé de mettre en œuvre les actions nécessaires pour permettre la fabrication en série des prototypes créés par le bureau d'études ou le service R&D".
7 De Erwan - 16/05/2013, 09:56
J'aurais plutôt dit "Tout est relatif"
8 De mageekguy - 16/05/2013, 10:31
@VincentLg : Le garagiste travaille sur un système fini et déjà existant, dupliqué en grand nombre et de plus documenté très précisément, à tel point que des barèmes de temps par type d’opération sont établis par les constructeurs automobiles pour chaque type et marque de véhicule.
Il dispose de plus de toutes les informations nécessaires pour contrôler la qualité de son travail et vérifier que le véhicule continue à répondre à ses spécifications d'origine à postériori de son intervention.
Il fait certes un effort créatif pour établir le diagnostique, mais vu que le système sur lequel il travaille est connu dans ses moindres détails, existe dans le monde réel et est dupliqué en grand nombre, l'effort est différent (et non moindre) de celui que doit faire un développeur qui part « de rien » pour créer un logiciel et l'estimation du temps est par conséquent plus fiable et plus facile pour le garagiste.
Il existe en effet des procédures à suivre pour l'établir défini par le constructeur ainsi que les retours d'expérience des autres garagistes.
Nous sommes donc en plein dans l'industrialisation et en tant que développeur, tu ne peux donc te comparer à un garagiste (ou alors, tu fais de la MOA en bénéficiant d'une excellente documentation sur un programme qui n'évolue plus, mais dans ce cas, tu ne fais plus à mon sens du développement logiciel).
Je dirais que tu ne pouvais pas choisir de plus mauvaise comparaison ;).
Quand à la notion de « forfait agile », je ne relèverais pas, même si je comprends le besoin pour le client d'avoir une estimation des coûts pour prendre une décision.
Mais ce n'est pas parce qu'il en a besoin qu'il est possible de lui indiquer précisément, malheureusement, ou bien qu'il faut absolument le faire.
Une telle estimation est un miroir aux alouettes, et si elle permet au client de prendre une décision, il le fait sur une base très approximative, voire totalement fausse.
Et je ne suis pas du tout convaincu que baser un investissement sur une information aussi peu fiable soit une bonne chose, aussi bien pour le client que pour le vendeur.
Il y a d'autres facteurs beaucoup plus pertinents à prendre en compte sur lesquels se baser pour prendre ce type de décision, et je ne suis pas le seul de cet avis.
9 De VincentLg - 16/05/2013, 16:22
@mageekguy En lisant ta réponse je reconnais que ma comparaison ne tient pas au niveau de la dificulté à "estimer" une tâche.
Concernant l'article de Woody, dans ma réalité (qui n'est peu être pas la même que vous) je n'ai pas le luxe de choisir mes clients, certains ont une vision différentes, des process à respecter... je n'éduque pas ces personnes, je travaille à leur service.
je n'ai pas la prétention de dire à mes clients "Ma façon de faire est la bonne, vous allez vous plantez si vous ne faites pas comme dans le bouquin Scrum pour les nuls". Je fais des compromis, c'est selon moi la seule solution possible en contexte réel.
Enfin une dernière remarque sur l'article pour revenir au sujet, plus que le fond ou finalement je trouve l'analyse très juste (mais difficile à appliquer dans la réalité), la forme me gêne, en tant que développeur, les parallèles avec l'art ou Einstein donne, selon moi, une image très prétentieuse de notre métier. Mais ça n'est pas le sujet du billet.
10 De mageekguy - 16/05/2013, 17:22
@VincentLg : J'ai des choses à dire à propos de ta réponse, notamment sur le fait de travailler « au service du client » et non de l'éduquer.
Cependant, je pense que cela mérite un billet dédié.
11 De Denis - 19/05/2013, 18:25
Un sincère grand bravo à vous pour un point de vue que je partage entièrement ! Les programmeurs sont et seront des artisans. L'illusion de l'off-shoring ne peut pas nous enlever cette réalité.
12 De bertrandMa - 02/06/2013, 23:40
Je partage totallement cette vision. C'est à mon sens une des raisons du succès du model "startup" dans le secteur versus soustraitance/off-shoring . L'entreprise est sont propre client et sa vision est orientée produit, fonctionnalité, usabilité... après que le projet sorte 1 semaine ou 1 mois plus tard ce n'est pas le plus important. Le risque pour ces startup c'est souvent de vouloir changer de modèle en grandissant