La comparaison de Pierre entre la peinture et les méthodes Agiles est très juste, on boucle sur des itérations en interne mais on livre qu’une fois l’oeuvre terminée.

Pour le travail préparatoire (aussi appelé étude):
http://www.culture.gouv.fr/documentation/joconde/fr/decouvrir/expositions/Main/expo_main_oeuvre.htm

Un travail préparatoire consiste à faire un élément isolé (ex: une main), avec plus ou moins de complexité, pour voir lequel est le “meilleur”. Certaines fois, le travail (ou étude) est juste réalisé pour s’entrainer, aucun objectif à court terme, par contre 10ans plus tard le peintre ressort son étude pour la répliquer sur un tableau.

Pour la prog, je le fais sur des choses très limitées, les deux dernières fois étaient télécharger un fichier puis le copier dans le cache de la carte SD sous Android, et parser un fichier xml sous Android. Dans les deux cas, je finis avec une fonction/méthode que je copie/colle dans le vrai programme.
ça s’intègre très bien avec le Lean car toute (ou presque) action se trouve dans une fonction/méthode isolée. L’inconvénient est qu’on ne sait pas trop dans quelle classe copier/coller les fonctions, je me retrouve avec des classes un peu bizarre qui font un peu n’importe quoi (ex: FileManager = la classe pour faire des trucs avec des fichiers XD ).
A l’arrivée, on a un pack de librairies, en PHP c’est puissant car on réutilise beaucoup, en Java ça demande une bonne réflexion pour ne pas finir avec 40 classes statiques…

Ps: désolé, je ne voulais pas mettre à mal l’analogie avec les cathédrales et la peinture ;) . Moi même j’ai beaucoup de mal à expliquer le Lean (ou continuous development) et je n’ai pas d’analogie claire -_-

C’est un peu la différence que je fais entre Lean et Agile : le but du premier est d’exposer le produit au monde réel le plus vite possible, alors que le second se contente d’itérations en interne.

Vu l’employeur de Sylvain (à moins qu’il ait changé depuis) ça m’étonnerait que son but soit de mettre en production le plus vite possible.

Ceci dit je veux bien des infos sur le concept de “travail préparatoire” aussi. J’aime bien les prototypes jetables (j’écrirais quelque chose là-dessus un jour…) mais ça n’a pas l’air d’être exactement ça.

Le souci de l’oeuvre d’art, c’est que même si tu peux ajuster via les différentes couches, ton n’oeuvre ne sera jamais exposée tant que inachevée.. J’imaginais plutôt Notre Dame en effet (oui oui, je suis passé devant ce week end) où grosso modo tu définis l’emplacement au sol, la hauteur, la structure générale, puis t’attaques aux fondations. Puis étage par étage. Les fidèles ont commencé à se recueillir alors que la coeur et les deux tours n’étaient pas terminées: tu releases un MVP exploitable de ta solution rapidement. Tu te rends compte qu’il faut des contreforts (de toutes façons, c’est plus joli ainsi je trouve :)), on peut imaginer que c’est un premier retour user, avec des tests de montée en charge, chose ignoré/mal conçu initialement qu’il faut rapidement adapter. Puis viennent les dorures, les vitraux, les enluminures, les cierges, les curés toussa toussa.

Je reste donc intimement persuadé que l’oeuvre d’art, tu la sors one-shot et tu ne la touches pas (on aurait fait sourire la Joconde depuis longtemps sinon) tandis que ta cathédrale (ou une tour d’entreprise à la Défense par exemple) tu suis plus le cheminement que j’ai essayé d’expliquer ci-dessus.

Je ne connais pas par contre ce concept de “travail préparatoire”. Peux-tu m’en dire plus?

C’est vraiment l’inverse, une cathédrale est une somme monstre de calcul, dés le départ il faut calculer l’emplacement de chaque élément car c’est un jeu de force mécanique qui maintient l’ensemble. Par exemple à Notre Dame, l’architecte de départ à fait des erreurs de calcul et il a fallu ajouter des arc-boutants (qui empêchent les murs de partir vers l’extérieur).
Autre exemple, l’espace entre les colonnes définit la hauteur maximale de la cathédrale.

En peinture c’est totalement différent, toutes les peintures sont la superposition de couches. Certes il faut penser au début où on veut aller mais avec une marge de manoeuvre assez large, par exemple modifier l’emplacement d’une main ou réduire la taille d’une lance. On ne le remarque que dernièrement grâce à l’analyse des oeuvres avec des outils scientifiques, sur certaines peintures c’est carrément des personnages qui ont été effacés !!
La méthode de travail est assez malléable aussi: Rembrandt, pour la Ronde de nuit, avait fait des portraits des personnes seules sur des toiles à taille humaine, ensuite il les reproduisait sur la toile finale.
Je ne parle même pas des travail préparatoires, où sur une toile le peintre va faire 10, 20 voir 30 mains, pour trouver la main parfaite qu’il reproduira sur l’oeuvre.

Ps: je code avec le concept de travail préparatoire, un projet test où je ne fais qu’une seule action qui est ensuite recopier dans le vrai projet.

Par contre en effet, tant que cela fonctionne, que les tests passent et que cela tient une charge raisonnable, go prod. Toujours à temps ensuite de refacto / scaler comme il se doit, ou adapter en fonction des retours :)

Merci pour tes commentaires qui sont toujours intéressants et bienvenus! ;)

Je préfère construire des datacenters en containers (http://is.gd/RLMf8t pour la référence) : des blocs grossiers avec des interfaces bien définies qu’on peut assembler de manière modulable pour tester des choses. Si un bloc faiblit on le remplace par un autre plus solide.

La qualité du code doit dépendre de la criticité du bloc quand même. N’allez pas prendre le risque de perdre des données client au nom de l’”agilité”. Pareil si vous écrivez du code installé chez le client, c’est plus dur à patcher. Mais pour du code non-critique côté serveur, ma politique serait presque : “ça a l’air de marcher, ça passe quelques tests de base, mettons-le en prod”, et ensuite on affine.