Discussion :

[souviron34]

Je crois qu'on l'apelle aussi "l'Extrem Programming"...
.

FAUX

Cela n'a rien a voir...

L'Extreme Programming n'est que l'allegement des procedures et l'etablissement d'un cycle de developpement en cycle rapide.

Cela ne signifie en aucune maniere "de la programmation spontanee"...

Et c'en est meme le contraire : c'est une methodologie de developpement, simplement plus simple et proche de la realite que les "classiques". Mais, en tant que methodologie, elle implique une METHODE...

Elle ne prone pas (et elle, comme toutes les autres, interdit meme) le "developpement spontane"..

[LooserBoy]

Désolé!

[gokud-o-matic]

Elle ne prone pas (et elle, comme toutes les autres, interdit meme) le "developpement spontane"..

Interessant. Ca signifie donc que les concepteurs de l'extreme programming voient le developement spontane comme contre-productif la ou s'applique leur methode. Et vu la popularite de cette methode, beaucoup de gens semblent etre d'accord.

[Garulfo]

Je suis complètement en accord avec Souviron.

Et pour répondre à gokud-o-matic ce que ça montre surtout c'est que beaucoup de programmeurs sont complètement à côté de la plaque quand ils utilisent ce qu'ils croient être des méthodes d'XP. L'XP demande une excellente gestion de l'effort, une très bonne discipline et de bonne compétence en rédaction de documentation.

[souviron34]

ou, en resume :

ne pas prendre "extreme" pour "n'importe quoi"

Et, pour repondre a gokud-o-matic, c'est juste que c'est INCOMPATIBLE avec l'idee de methodologie.

Soit on suit une methode, et donc on est "methodique", soit on n'en suit pas, et donc on est "spontane" : c'est du vocabulaire de base...

Ce que nous avons explique tout au long de ce fil :

ce qui est valable pour 30 lignes de code d'un projet perso qu'on mettra a la poubelle 5 minutes apres, on s'en fiche.
dans tout projet professionnel, il y a un minimum auquel on est en droit de s'attendre

[Invité]

Bonjour,

Le sujet "Qui pratique la programmation spontanée ?" a donc été posté il y a 5 ans par Doloop : le 28/12/2003.

Au 7 février 2008, son post aura manifesté l'activité suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
-     27 pages sur le forum
-    353 pages sous word (en brut)
-    404 réponses
-    128 membres à l'origine des 404 réponses
- 70.033 affichages

Sauf erreur, le dernier message de Doloop, l'auteur de la question, date du 23/02/2004, soit moins de deux mois après avoir posté sa question et sa dernière activité date du 26/06/2004. Depuis, silence radio ! Bien qu'orphelin depuis maintenant 4 ans, le sujet vit toujours.

Autre question postée par Doloop le 23 février 2004, moins de deux heures après sa dernière intervention concernant sa première question :

Quelles sont vos méthodes de programmation et de débogage ?

Cette question, bien que toujours "vivante" n'a pas eu le succès de la première :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
-      3 pages sur le forum
-     34 réponses
- 11.254 affichages

C'était un 'tit bilan...

[Garulfo]

Bonjour,\
[...]
C'était un 'tit bilan...

T'es à la retraite et tu t'ennuies c'est ça ??

Il te reste à calculer le nombre de caractères

[Invité]

Bonjour,

T'as tout compris. Je m'interrogeais sur l'issue de ce forum que je surveille depuis un bon moment. A part offrir l'occasion de s'exprimer, que va-t-il en ressortir ?

Il te reste à calculer le nombre de caractères

Je pensais faire une synthèse mais je ne suis pas certain que ça vaille le coup. Bien que retraité, je conserve l'obsession d'investir "utile".

Je pense que sur le sujet, chacun a ses vérités. L'informatique étant multiple, il faut accepter la diversité qui permet de s'enrichir. Il faudrait plusieurs vies pour n'aborder que quelques aspects de l'informatique. Pour ma part, je n'ai eu le temps que d'en aborder qu'un seul. Et je l'ai abordé à ma façon... Mais je n'en parlerai que sous la torture.

A bientôt ! Je vais faire une petite sieste devant les petites momies de la 5.

Bon courage les actifs

[FR119492]

Bonjour à tous !

Pour en rajouter une couche à un débat déjà passablement touffu, je voudrais témoigner de ma longue expérience en la matière.

Avoir un cahier des charges précis, sur la base duquel on construit une approche structurée du développement à effectuer, c'est très joli; c'est la situation idéale dont tout professionnel du développement rêve. Malheureusement, ça ne m'est jamais arrivé ! En pratique, le cahier des charges est toujours vague, contradictoire et irréalisable, mais il faut bien faire avec. Le "client" croit tout savoir, mais, en fait, il ne sait même pas ce qu'il veut. C'est donc le développeur qui devra le deviner. Souvent les données du problème tombent au goutte à goutte, et à chaque nouvelle goutte, on se rend compte qu'on avait mal compris les désirs du client, ou que ceux-ci ont changé. On doit donc développer d'une manière que je qualifierais d'itérative plutôt que de spontanée.

A la fin, je dirais que le bon développeur est celui qui est suffisamment fin psychologue pour persuader le client que ce qu'il lui livre correspond exactement à ses voeux.

Jean-Marc Blanc

[ArHacKnIdE]

A la fin, je dirais que le bon développeur est celui qui est suffisamment fin psychologue pour persuader le client que ce qu'il lui livre correspond exactement à ses voeux.

Là on arrive au niveau grand maître de la programmation

Faut programmer les clients

correspond exactement à ses voeux.

Mais d'une manière différente

[FR119492]

Mais d'une manière différente

Mais ça, ce n'est pas nécessaire de le lui dire!
Jean-Marc Blanc

[seven7]

Généralement ça se passe comme ça :

[Invité]

Bonjour à tous,

J'étais inquiet, je croyais avoir tué la discussion avec mon 'tit bilan. Ouf !

Je vois que le dessin humoristique des années 70 avec les balançoires s'est sophistiqué, ça fait plaisir de le revoir. Merci seven7 !

[Invité]

Bonjour les développeurs "instantanés",

Symbolisée par la caricature proposée par seven7, cette désolante réalité que j'ai vécue dès mes premiers développements, au début des années 70, est à l'origine d'une démarche personnelle visant à supprimer tout intermédiaire entre le développeur et l'utilisateur.

Constatant que chacun interprète sans concession ce qui se dit sur les forums en fonction de son vécu, je plante tout de suite le décor...

Informaticien-fonctionnaire, j'ai consacré les 35 années de ma carrière à l'informatique de gestion de type départemental, au sens anglo-saxon du terme. C'est-à-dire à l'informatisation d'entités administratives de la taille d'un service, d'une division.

Mon intervention vise simplement à apporter ma modeste contribution à la discussion, "toutes choses égales par ailleurs", comme disent les économistes, pour relativiser mon discours.

Ma recherche personnelle et mon parcours professionnel, donc, m'ont conduit à informatiser façon écrivain public (approche "bottom-up"). J'appelle ma démarche de développement "APL/AML" : Au Pied Levé/A Main Levée. D'où, l'intérêt que je porte à cette discussion.

D'autres que moi ont bien sûr élucubré sur ce thème, je ne fais que témoigner d'une pratique qui dans cet esprit a donné satisfaction aussi bien aux utilisateurs qu'à moi-même.

Si je ne me reconnais pas vraiment dans toute cette technicité dont regorgent les forums, j'ai retrouvé beaucoup de similitude dans ma démarche avec les principes méthodologiques RAD et l'adhocratie.

Cela dit, pour recoller au plus près de la discussion, je comprends tout-à-fait ce que veut dire doloop quand il dit :
- "Devant le clavier, on sait immédiatement ce que l'on a à faire, il suffit de transposer ce que l'on voit mentalement sur l'écran."
- "Avec l'expérience, par concentration, les solutions sur les points délicats des programmes, apparaissent dans la tête sous forme de flash."
- "La programmation spontanée, c'est avant tout du travail mental assisté par de la méthode."
- "Une personne sur un autre forum avait dit qu'il devenait en quelque sorte le programme."
- "Il m'est déjà arrivé de continuer à débugger un programme l'ordinateur éteint, on l'allume est c'est bien ça."
- "J'ai remarqué que conduire une voiture pour moi, nécessitait plus d'effort d'attention cérébrale, que de passer une journée entière à programmer et à débugger."
- "A chaque programme réalisé, l'auto-satisfaction est quasi inexistante, on est content que le programme soit terminé, on n'est pas déçu mais sans plus, on pense plus au prochain qu'a celui qui vient d'être fait."

Je ne vais pas reprendre tout ce qui s'est dit dans cet esprit depuis plus de quatre ans. Je rappelle simplement quelques uns de ses premiers arguments pour identifier sa façon de fonctionner que j'assimile à la "sophrologie".

Le Docteur Alfonso CAYCEDO, psychiatre d’origine colombienne, ne formalisa le concept qu’à partir de 1960. Sa « RELAXATION DYNAMIQUE » comme il l’appelle alors, synthétise et occidentalise les pratiques du Yoga, du Bouddhisme et du Zen. Leurs effets sur la conscience humaine devant lui permettre de traiter ses patients.

Intuitivement mais consciemment, je pratique la sophrologie depuis toujours. C'est en quelque sorte un mode de vie. Beaucoup de personnes la pratiquent sans le savoir. Pour ma part, j'ai toujours eu conscience de fournir l'effort mental qui consiste à se sophroniser. Les principaux domaines pour lesquels j'ai ou j'ai eu recours à la sophrologie sont les études, le sport de haut niveau, mon métier de développeur, la conduite automobile, etc.

Je n'ai mis un mot sur ce que je pratiquais qu'à l'occasion de la naissance de mon ainé, en 1977. Un médecin, le docteur Davrou, proposait alors à un goupe de femmes enceintes de les préparer à l'accouchement par la sophrologie. Le docteur Davrou enseignait déjà les pratiques de la sophrologie aux cancéreux en phase terminale. Il s'impliquait également dans le sport, notamment dans l'entraînement de l'équipe nationale de volley-ball.

Petite digression à propos de la sophrologie et du sport :

Disciple du Docteur Alfonso CAYCEDO depuis 1963, le docteur Raymond ABREZOL est l’un des premiers Sophrologues à avoir adapté les techniques sophrologiques au sport (dès 1966).

Manuel AGUILA (Site Internet : http://www.chronosports.fr/testsphys...ophrologie.htm) décrit l’entraînement sophrologique comme une stimulation de l’imagination par le biais de phases de visualisation : « L’athlète découvre cet état particulier où il peut corriger les épreuves qui le nécessitent et programmer ses futures performances. Lors d’une compétition, son cerveau met tout en œuvre pour reproduire ce qui a été précédemment enregistré. Au-delà de l’apprentissage technique conscient survient l’art. L’atteinte de ce niveau de réalisation, dans le cadre sportif, passe par ce que l’on nomme "le lâcher prise". En associant les pratiques sophrologiques à son entraînement, on intervient sur sa capacité de concentration et d’attention, son énergie et sa puissance physique, sa capacité de récupération après l’effort, sa motivation et sa combativité, d’éventuelles inhibitions, la confiance en soi et en ses potentiels, l’image que l’on a de soi-même, l’intégration de son schéma corporel, la sensibilité interne de son propre organisme (apprentissage des mouvements – cénesthésie, synesthésie, somesthésie), la fluidité de ses mouvements, la mémorisation de ses séquences sportives, la gestion de son seuil de douleur, sa capacité à gérer le stress, etc. ».

Concrètement, la sophronisation de l’athlète peut être vue comme un travail mental d’auto-programmation, de maîtrise de soi dans l’espace et dans le temps, chaque paramètre (effort, récupération, concentration, motivation, etc.) s’intégrant dans l’approche globale d’un ou plusieurs objectifs. Les athlètes se sophronisent tous plus ou moins consciemment et à des degrés divers. Au début du siècle dernier, lorsque le lanceur de poids Raoul PAOLI, en pleine concentration, demande à un athlète venu l’encourager, de le laisser tranquille parce qu’il est en train de devenir champion olympique, n’était-il pas en phase de visualisation pour utiliser le langage d’aujourd’hui. C’est sans doute sur les sautoirs, notamment celui de la hauteur, que les athlètes extériorisent le plus leur processus de sophronisation en mimant le saut qu’ils visualisent mentalement.

Je me suis permis cette parenthèse sportive pour mieux concrétiser l'effort mental que représente la pratique de la sophrologie et assimiler son principe dans une une démarche de développement.

[FR119492]

Bonjour à tous.

supprimer tout intermédiaire entre le développeur et l'utilisateur

Ah! comme on se retrouve. Mais c'est peut-être une question d'âge.

Je prend le risque de choquer certains, mais j'éprouve de sérieux doûtes concernant le bien-fondé des formations élémentaires en programmation (niveau bachelor ou équivalent). Pour développer des logiciels valables, il est essentiel d'avoir une vue d'ensemble sur le problème traité. Celui qui écrit un programme de comptabilité doit connaître toutes les règles de la comptabilité; les équations de Maxwell ne doivent plus avoir de secrets pour celui qui écrit un programme de calcul des phénomènes électromagnétiques. Les formations élémentaires doivent donc correspondre aux domaines d'application; à cela viendront s'ajouter des cours et surtout des travaux pratiques sur l'utilisation de l'ordinateur dans le domaine correspondant. Une orientation plus spécifiquement informatique est une spécialisation qui ne doit intervenir qu'ensuite, par exemple au niveau master.

Jean-Marc Blanc

[Ecosmose]

Connaissez vous la méthodologie MACAO ? je fais vous grace malheureusement de mes succintes et fatiguées explications car il est à 1h30 du Mat' au moment où je vous écris..
Plus de détail bientot...j'ai été un disciple de Jean Bernard Crampes , le créateur de cette Méthode et du SNI..

Si je ne me reconnais pas vraiment dans toute cette technicité dont regorgent les forums, j'ai retrouvé beaucoup de similitude dans ma démarche avec les principes méthodologiques RAD et l'adhocratie.

[Invité]

Bonjour FR119492,

Supprimer tout intermédiaire entre le développeur et l'utilisateur
C'est peut-être une question d'âge

Peut-être pas, car la caricature de Seven7 montre que le problème de communication est apparemment toujours vrai.

Il est difficile de trop s'exprimer sur le sujet car on s'éloigne alors du thème de la discussion. On pourrait initier une nouvelle discussion du genre "Direct du développeur à l'utilisateur : Une application « tout-de-suite »". Je fais ici un clin d'œil au monde de la photo et plus précisément au slogan de la première "réclame" du Polaroïd : Pourquoi attendre ? Le Polaroïd, c'est « Une photo tout-de-suite ! ». C'est ce à quoi aspirait Edwin LAN en inventant le Polaroïd, appareil photo à développement instantané. Développement instantané ?...

La majorité des membres "actifs" semble développer en SSII principalement dans le domaine de l’internet et les étudiants sont formatés "Top-Down", méthode bien hiérarchisée, bien compartimentée, avec ses étapes bien identifiées, bien documentées, bien contractualisées. Je ne condamne pas, simplement ce n'est pas et cela n'a jamais été mon truc. Je conçois tout-à-fait que ma démarche ne soit pas envisageable en SSII. Elle est déjà tellement exceptionnelle dans le seul contexte que j'ai jamais connu, l'administration. Ma démarche m'a permis d'exercer mon métier de développeur jusqu'au bout, dans un monde administratif où l'objectif a toujours été de supprimer les informaticiens en recourant à l'externalisation. L'informatique, c'est technique, le privé sait faire et le budget "sous-traitance" n'est pas imputable sur du budget "personnel".

Dans mon premier ministère où je suis resté la moitié de ma carrière, j'ai assisté à la suppression pure et simple de ma sous-direction de l'informatique. La démarche que j'ai faite de me rapprocher le plus possible de l'utilisateur au point même de m'installer chez lui, d'autres ont fait le chemin inverse. Certains utilisateurs se sont installés chez les informaticiens, ont sous-traité la conception du cahier des charges. A partir de ce cahier des charges, ils ont émis un appel d'offres, ont sous-traité le dépouillement des réponses à l'appel d'offres. Il ne restait plus qu'à confier la sous-traitance du développement à la SSII la mieux disante... Qui était bien sûr la SSII ayant réalisé le cahier des charges. Et à lui sous-traiter la maintenance par contrat de quatre ans renouvelable. Quelle est la place de l'informaticien dans ce scénario. Pour mes collègues, l'histoire s'est soldée par des départs en retraite, des dépressions, des reconversions plus ou moins bien réussies.

Pour ce qui me concerne, finalement, ma démarche m'a en quelque sorte sauvé. Mais ce n'est pas de tout repos. Pour commencer, il faut déjà trouver un sujet porteur, c'est-à-dire une problématique à l'agonie, une cause complètement désespérée. Cela m'a amené à changer plusieurs fois d'affectation. Je n'ai en fait, jamais fait partie d'une équipe de développement. Dès le départ, je suis intervenu pour résoudre des situations catastrophiques. Mes interventions ont duré progressivement deux mois, puis deux ans, puis quatre ans et les dernières, 17 ans. J'ai toujours travaillé en électron libre. Pas par conviction mais il n'était pas évident d'associer d'autres personnes dans cette démarche. Une opportunité s'est présentée une fois ; face à la réalité de la tâche, le collègue n'a tenu que trois jours. Rien n'interdit à d'autres de tenter l'expérience en équipe.

Finalement, je peux dire que je suis allé jusqu'au bout de ma démarche. Enfin presque, car j'appelle mes développements, du maquettage d'application, du maquettage de luxe mais du maquettage qui reste du jetable... Même si ça dure 17 ans. L'idée, ce n'est pas de créer du définitif très beau, très sophistiqué, mais de résoudre une problématique immédiatement, avec des moyens simples et d'aboutir au final à la création d'une documentation à postériori qui face office de documentation utilisateur, de support de formation et surtout de cahier des charges pour un développement ultérieur par une méthode classique Top-Down. On n'est plus alors dans l'inconnu (effet tunnel), ni dans l'urgence. Concernant mes derniers développements, je suis parvenu à réaliser les 2/3 de ce genre de documentation. Je ne connaîtrai toutefois jamais cette ultime étape qui consiste selon moi à tout redévelopper Top-Down avec des moyens plus sophistiqués.

Classiquement, le point de départ d'un développement pragmatique d'applicatif (Au Pied Levé) est le challenge. Plus le challenge présente de risques, de difficultés, un caractère urgent voire vital, plus il a de chances d'être « accepté ». Accepté par le responsable du service informatique, le chef du service de gestion, les gestionnaires eux-mêmes. Accepté, parce que les raccourcis qu'il implique bousculent quelque peu l'organisation fonctionnelle de l'entreprise et chahute la hiérarchie, la quelle compte tenu de la situation, n'a d'autre alternative que de s'en remettre entièrement, non sans quelque appréhension, à l'informaticien développeur qui devient alors l'homme providentiel. D’où ma référence à l’adhocratie.

Ainsi, le responsable informatique doit accepter les risques inhérents à cette démarche, comme budgéter un projet sans garantie tangible de résultat, laisser se poursuivre un développement avec l'incertitude de sa pérennité, admettre l'installation à demeure de l'informaticien développeur dans le service de gestion. De son côté, le chef du service de gestion doit vivre au quotidien la présence de l'intrus qui considère davantage ses gestionnaires que lui-même. Quant aux gestionnaires, leur confiance et leur collaboration sont à priori acquises dans la mesure où ils sont demandeurs. Il suffit d'entretenir cette confiance par une écoute attentive de leurs besoins, une réactivité sans faille, une grande disponibilité, une très grande disponibilité. A ce sujet, l'adhocratie dit ceci :

- « La contribution à des équipes ad hoc lorsqu'elle s'avère devoir être très intense ne se limite pas à 40 heures par semaine, mais suppose de travailler autant que nécessaire. Certains utilisent l'expression de "double plein temps" »

J’ai vu, FR119492, que tu avais orienté ta carrière dans le scientifique et le FORTRAN. Pour ma part J’avais fait le choix gestion et COBOL. J’espère que je ne t’ai pas ennuyé avec mes histoires. Ecrire tout ça m’a demandé du temps surtout que, j’ignore pourquoi mais je ne peux pas « éditer » ma réponse. Je ne dispose pas du bouton « Editer ». J’ai été contraint de modifier mon mot de passe à un moment donné. Je pense qu’il doit y avoir un rapport. Je passe donc par une phase "traitement de texte" afin que mon message soit clean.

Bon ! Je n'ai rien dit. Voilà que je retrouve mon bouton "Editer". Quelque chose m'échappe.

Bonne lecture

[Ecosmose]

Juste au hasard, vos pseudos sont ils des indicatifs radioamateurs ?

[Invité]

Bonjour Ecosmose,

Pour ma part, certains pseudos que j'aurais souhaité utiliser étaient déjà pris. J'en ai eu assez et j'ai choisi en quelque sorte un identifiant unique genre numéro INSEE.

IFA pour International Français d'Athlétisme et 2377, c'est tout simplement le numéro de ma carte d'international. Je suis sûr qu'il n'y en a qu'un et c'est moi. Un passé sportif, ça marque à vie. J'ai la flemme de choisir un avatar. J'avais eu une idée mais c'était déjà pris. Basta...

Si tu as suivi, course à pied, développement informatique, sophrologie, tout est lié. Mes journées commencent toutes par un footing d'au moins une heure. Physiquement, je cours mais mentalement je me sophronise "développement" et quand je m'installe devant mes écrans, je martyrise mes claviers (A Main Levée) jusque tard la nuit. Ce que je crée chaque jour s'inscrit dans une démarche à court, moyen et long terme. A ce sujet, l'adhocratie dit ceci :

« Structurer l'inconnu : la plupart des procédures traditionnelles de management encensent la structure et la prévisibilité. La difficulté dans un contexte ad hoc consiste à donner un semblant d'organisation à ce qui est apparemment inconnu. On y parvient par une planification à court terme assez précise, mais très lâche pour les étapes ultérieures. Dans ce type de projets, une trop grande partie des objectifs à moyen et long terme dépend de ce qui a été mis à jour à court terme »

Appliqué au développement, ce discours signifie que je prévois dans le menu de mes applications, les traitements que je ne développerai que le moment venu, selon l'urgence, ma disponibilité, mon imagination. En fait, je dis que je dépose le bitume juste devant le rouleau compresseur. Les américains disent "just in time".

Sinon, MACAO, je ne connais pas. Pour moi, il est maintenant trop tard, l'affaire est entendue mais je veux bien m'y intéresser pour voir. Je prends part à quelques discussions parce que je me suis trop impliqué dans le boulot (15 h/jour), que j'ai maintenant du temps et un peu de mal à tourner la page mais ces derniers temps, je commençais un peu à me lasser. Je n'allais même plus voir s'il y avait eu des réactions à mes propos. J'envisageais même de me désinscrire. Après tout, il appartient à chacun de faire sa propre expérience. On dit bien que l'histoire est un éternel recommencement. Si je m'exprime, ce n'est pas pour défendre un point de vue bec et ongles mais pour faire avancer le schmilblick de ceux qui lisent mes arguments et qui s'interrogent. De la même façon que j'ai pillé mes contemporains pour avancer dans ma recherche personnelle, juste retour des choses, j'offre mes élucubrations au pillage. Idéalement, je devrais peut-être proposer un article sur le site. Il existe dans un coin de mon micro mais le contenu est sans doute devenu obsolette quand je lis ce qui se dit sur le site.

Dernièrement, je m'interrogeais sur les méthodes agiles. J'ai l'impression que l'on en parle beaucoup. Mais les éditeurs de logiciels proposent des outils de développement toujours plus complexes. Comment peut-on être agile avec des outils nécessitant toujours plus de technicité.

J'ai cru lire quelque part que XP prétendait être une méthode agile. Un seul clavier pour deux développeurs ! Effectivement, il faut être agile. Pour ma part, si je n'ai pas au moins deux claviers pour moi tout seul, plusieurs serveurs, un ou deux micros et plusieurs sessions ouvertes sur mes écrans, je ne le sens pas. Quand je lis la prose XP, je m'interroge sur mes facultés à comprendre le français et l'informatique que je pratique pourtant depuis plus de quarante ans. Je suis allé visiter un site consacré aux méthodes agiles pour savoir ce qu'il en était. Une charte "méthode agile" y détaille une procédure qui ressemble à du Top-Down à peine allégé. Je préfère de loin la vélocité que me procure ma méthode de développement associée à ma méthode de travail.

A propos de méthodes, je trouve que dans cette discussion, il n'a pas tellement été évoqué de méthodes de programmation. Il n'a été question de programmation structurée qu'une ou deux fois et de façon entendue comme s'il n'existait rien d'autre. Pourtant, le prime posteur disait :

- "La programmation spontanée, c'est avant tout du travail mental assisté par de la méthode."

Cela signifie que dans sa tête, il faut être en quelque sorte "câblé". C'est ce que j'argumentais dans une discussion consacrée à l'algorithmique. Mes neurones fonctionnent par traitement et non par conditionnement. Dommage que Doloop ne suive plus son sujet depuis quatre ans, il aurait été intéressant qu'il développe.

Pardon tout le monde, je suis sans doute trop bavard. Ce n'est pas pour rien que mes filles m'ont décerné le diplôme du plus grand bavard.

C'est tout pour aujourd'hui !

[el_slapper]

Mais nooooon, c'est toujours intéressant de lire ce genre de choses.

Plus ça va, plus je me dis que l'important n'est pas d'avoir la bonne méthode dans l'absolu, mais d'avoir la méthode qui convient aux personnels dont on dispose et aux contraintes dont on fait face.

Dans le milieu bancaire, pour des évolutions reglementaires, devant entrer en vigueur à un jour précis, et ce, de manière transvesale dans des milliers de programmes, une forte bureaucratie est nécessaire. Car sans elle, la nécéssaire coordination de la mise en place, la nécéssaire standardisation ne sont pas possibles. Toutefois, la bureacratie doit accepter d'être faillible(car elle l'est), et si elle se rend compte d'un oubli majeur à une semaine de la deadline, elle doit accepter une démarche beaucoup plus légère pour la réalisation de l'urgence.

Et, évidemment, les gens efficace dans une démarche le seront moins dans l'autre(et vice-versa). Je suis personellement très quelconque dans une démarche structurée(mais bon, le boulot est fait), et beaucoup plus efficace en electron libre(même si je suis largement dépassé par quelques maîtres). D'autres auront d'autres qualités. La difficulté est de mettre en adéquation les personnels aux problématiques présentées.

Toutefois, l'illusion que j'ai beaucoup vue est que la méthode pouvait remplacer tout. Qu'elle se suffisait à elle même. Dans mon expérience, une méthode béton ne peut pas venir à bout d'un problème mal posé(parceque contenant des erreus de conception au départ que le client n'a jamais voulu rectifier, de peur de se dédire).