Discussion :

[B.AF]

Ok donc écrire un article sous word influence son contenu ?

Je pensais que les gens étaient capable d'abstraire le contenu des medias (et soit dit en passant c'est tout simplement la base de notre métier...).

Ca ne prouve bien que tu ne comprends pas ton sujet.

Quand on parle de langage on parle de linguistique.

Chaque langage a une histoire et une utilité.(linguistique pragmatique)

Utiliser un langage dans un contexte différent de son utilité abouti à un défaut de communication.

Word n'est pas un langage, UML oui.

Donc écrire sous word influence le contenu non, c'est le langage que tu utilises pour écrire le document qui influence le contenu.

C'est notamment grâce à cela que nous avons pu voir apparaitre la notion de langage en informatique qui se base sur une grammaire descriptive alors que la plupart des cas d'utilisation des langages "naturels" (ge : français) sont basés sur une grammaire prescriptive.

C'est justement dans le passage de la prescriptive et de son interprétation en descriptive que sont les erreurs. (amibguité structurelles)

Au milieu de cela :
Si tu considéres
Java ; descriptif
UML ; descriptif
Langage parlé; prescriptif

L'UML n'apporte pas de réponse concrête dans ce passage du prescriptif au descriptif (sauf ce qu'a essayé MDA, mais c'est techniquement quasi-impossible)
Les sources d'amibiguité sont justes déportées, donc au pire, c'est une modification de la chaine de responsabilité, mais ce n'est absolument pas un apport conséquent.

De plus, la différence entre le descriptif et le prescriptif est, globalement et de façon très schématique, la différence entre le descriptif est qu'il est normé et standardisé, alors que le prescriptif a une relation plus intime avec le contexte (micro ou macro) --> expressions pros, wordings spécifiques, structuration des phrases.

Donc la traduction demande en plus d'une analyse récursive poussée des arbres grammaticaux de devoir injecter une science du contexte.

C'est précisemment là qu'aucune méthode ou qu'aucun outil n'a réussi à fonctionner car un procédé ne peut pas se substituer (encore ?) à un être humain.

Or c'est précisemment là que réside la science d'un logiciel réalisé pour un client.

[rakakabe]

C'est précisemment là qu'aucune méthode ou qu'aucun outil n'a réussi à fonctionner car un procédé ne peut pas se substituer (encore ?) à un être humain.

Et pourtant, la majorite des gens croient qu'avec de tels outils (et l'evolution actuelle de la technologie), on devrait avoir le produit selon les previsions de depart (NB : entre nous, il ne faut jamais communiquer une date de prevision aux decideurs car pour eux si on ne veut pas etre ).

Un certain Von Braun disait (si je ne me trompe pas) : "les logiciels plantent car on se base sur la theorie qu'avec 9 femmes enceintes, on peut avoir un bebe en un mois".

Toutefois, ces outils (je dis bien outils) peuvent ameliorer le confort de developpement (ne plus parcourir des milliers de lignes de code pour comprendre l'architecture entier du logiciel, ...) pour ceux qui savent l'utiliser, et j'encourage son apprentissage (attention ! cela ne garantit pas le produit comme le disais souviron...).

[B.AF]

Parce que toute technologie a obligatoire une période d'adoption et surtout une période d'adoption au niveau entreprise.

La problèmatique de développement d'une application critique d'entreprise n'est pas la même que celle du tutorial northwind.

Or un fournisseur de technologie à un instant t ne peut qu'offrir un raisonnement empirique et pas pratique. Donc la technologie évolue, mais nouvelle ne veut pas dire mieux.

La nouveauté apporte son lot de mieux (innovation) et son lot de régression (immaturité)

Typiquement, ceux qui se sont cassés les mains sur EJB2, Entity Framework, la gestion des volumes dans GWT me comprendront.

Il y a une distorsion entre un outil et sa mise en application qu'aucun empirisme ne peut mesurer. C'est même grâce à cela qu'elle continue d'évoluer.

[hegros]

Bref, ce serait bien de revenir au sujet initial, avec des "input" d'autres personnes ayant mené des projets (des vrais) au succès...

Mais prends ta retraite papy nous sommes en plein dedans. Une des meilleures pratiques (je dis bien meilleur) est la modèlisation graphique du logiciel qui se réalise notamment avec des écrans et des états pour le côté client et d'autres choses comme des diagrammes ou des schémas pour le côté informaticien

aujourd'hui le problème c'est que le côté informaticien pour cette pratique est plutot rare c'est souvent de la tradition orale ou du code

[B.AF]

Mais prends ta retraite papy nous sommes en plein dedans. Une des meilleures pratiques (je dis bien meilleur) est la modèlisation graphique du logiciel qui se réalise notamment avec des écrans et des états pour le côté client et d'autres choses comme des diagrammes ou des schémas pour le côté informaticien

aujourd'hui le problème c'est que le côté informaticien pour cette pratique est plutot rare c'est souvent de la tradition orale ou du code

Attention, à ce train là, il va falloir écrire un livre sur l'utilité du pragmatisme dans les projets.

La gestion de projet c'est avant tout le bon sens finalement.

C'est un peu comme le livre de Fowler : Il est excellent, mais bon, il n'a pas non plus inventé l'eau chaude. (Pardon si tu me lis, et puis c'est en Français...).

D'ailleurs, son livre n'est ni plus ni moins que la mise bout à bout des erreurs de conception, de gestion, de choix et donne des pistes pour ne pas les recommencer.

Pour certains c'est une bible. Mais rien de ce qui est écrit dedans n'est fondamentalement complexe à découvrir. C'est juste que ça fait parti de ce qu'on apprend pas ailleurs que les mains dans la graisse.

Et comme aujourd'hui, on forme des ingénieurs en informatique qui ne SAVENT PAS développer, toute cette expérience s'évapore et disparait. Sur 23 environ que j'ai rencontré l'été dernier en entretien; ils m'ont tous dit "je ne vais pas rester développeur" .. et "je n'ai pas fait une école d'ingénieur pour développer"... (je force le trait, mais il suffit de regarder le forum emploi pour voir que je ne suis pas trop loin...)

D'où ma condition indispensable pour un membre de l'équipe :
Aimer développer. Un développeur qui aime développer ne peut pas sortir des inepties sur la méthodologie, il ne peut pas concevoir que l'utilisateur ne soit pas satisfait.
Celui-là, perle devenu très rare, il faut lui donner des conditions de travail adéquates. En plus les profils doivent s'équilibrer.
Généralement, le développeur (et pour moi, un développeur, c'est un terme très valorisant) est curieux, cherche des solutions, innove, apprend constamment.

Je vais d'ailleurs donner ma pensée profonde : la plupart des chefs de projets et autre rafales de l'informatique sont pour la plupart des frustrés. Frustrés de ne pas pouvoir comprendre le développement, de ne pas pouvoir contrôler, de ne finalement pas avoir le choix. Et ça me frustre tout autant d'ailleurs de devoir me supporter un abruti qui fera de la merde sous prétexte de respecter des normes et des méthodes et de caler son chiffrage.

Une bonne gestion d'un projet informatique doit commencer par le bon sens de remettre à sa place et dans son rôle le principal producteur et contributeur du projet : le développeur.

La réalité est qu'aujourd'hui, je peux aussi faire mon vieux con :
De la plupart des éminences grises qui m'ont longuement expliqué le management, les méthodes, la planification, et le reste; c'était pour la plupart (et je persiste et je signe) des personnes incapable de pondre deux lignes de code propre et avec des connaissances techniques et opérationnelles pour le moins douteuse (je vois pas en quoi mettre des personnes sur un matrice ou faire une addition de jours reléve d'une intelligence particuliére).

Et là on arrive à la base : quand on ne comprend pas ce que l'on doit faire, ni comment le faire et encore moins avec quoi, à quoi bon dieu sert-il d'y appliquer une méthode et de s'évertuer à faire des chiffrages ?

Notre métier est dans l'ensemble malade, parce que toutes ces fonctions parasites n'ont fait que renforce la honte de devoir développer.

Nous faisons aussi un métier où la grâce est de pouvoir :

• Prendre un sujet
• Comprendre un sujet
• Abstraire un sujet
• Modéliser un sujet
• Architecture un sujet
• Matérialiser un sujet

Mais quel autre métier permet cela ???? (== Aucun)

La capacité de conception ce n'est pas le résultat de l'appareil politique et/ou d'une organisation, c'est le fruit d'individualités et souvent d'implication.

Bref, c'est confus, décousu, c'est très polémique, mais avec l'âge, je me radicalise !!!!!!

[kromartien]

Bonjour, je voudrai faire une réponse.

Je ne suis pas professionnel du tout, mais j'ai mené un projet informatique à son terme en trois-quatre semaines comme stage de fin d'année.

Je devais interfacer un appareil servant à piloter un processus en température.

Mon logiciel devait avoir une interface graphique, etc...

En fait, en progressant dans mon projet, je me suis aperçu que ce qui est le plus fondamental, une fois qu' on a fait le choix de ses outils, et qu'on a une idée à peu près claire de ce que l'on veut faire, et de bien connaître le langage utilisé pour développer.

Je pense que la conception, fondamentalement, ce n'est pas quelque chose d'indépendant du langage. L'expressivité de chaque langage va tendre à faire diverger les solutions employées dans une direction qui sera plus propice à avoir un code maintenable et concis.

Pour cela, l'architecture sera forcément différente si l'on utiliser un langage interprété et un langage bas niveau comme le C.

En somme, je crois que les connaissances théoriques sont fondamentales, mais que elles ne peuvent être appliquées correctement qu'avec des connaissances pratiques et techniques sur les langages et les technologies employées qui soient d'un très haut niveau.

Je vous invite à commenter cette déclaration, mais je suis quasiment certain que des connaissances théoriques sans connaissances techniques en informatique, c'est voué à l'échec, comme le pensait BAF dans le message précédent.

[chaplin]

D'où ma condition indispensable pour un membre de l'équipe :
Aimer développer. Un développeur qui aime développer ne peut pas sortir des inepties sur la méthodologie, il ne peut pas concevoir que l'utilisateur ne soit pas satisfait.
Celui-là, perle devenu très rare, il faut lui donner des conditions de travail adéquates. En plus les profils doivent s'équilibrer.
Généralement, le développeur (et pour moi, un développeur, c'est un terme très valorisant) est curieux, cherche des solutions, innove, apprend constamment.

C'est tellement évident qu'on y pense plus .

c'est le fruit d'individualités et souvent d'implication.

Pour des petites équipes, en particulier.

[hegros]

D'ailleurs, son livre n'est ni plus ni moins que la mise bout à bout des erreurs de conception, de gestion, de choix et donne des pistes pour ne pas les recommencer.

Oui il n'a pas réinventé l'eau chaude ou froide c'est ce qu'on appelle la rétrospective chez Scrum ou le bilan de projet chez SDMS.


Pour le reste on ne peut que plussoyer.

[B.AF]

Bonjour, je voudrai faire une réponse.

Je ne suis pas professionnel du tout, mais j'ai mené un projet informatique à son terme en trois-quatre semaines comme stage de fin d'année.

Je devais interfacer un appareil servant à piloter un processus en température.

Mon logiciel devait avoir une interface graphique, etc...

En fait, en progressant dans mon projet, je me suis aperçu que ce qui est le plus fondamental, une fois qu' on a fait le choix de ses outils, et qu'on a une idée à peu près claire de ce que l'on veut faire, et de bien connaître le langage utilisé pour développer.

Je pense que la conception, fondamentalement, ce n'est pas quelque chose d'indépendant du langage. L'expressivité de chaque langage va tendre à faire diverger les solutions employées dans une direction qui sera plus propice à avoir un code maintenable et concis.

Pour cela, l'architecture sera forcément différente si l'on utiliser un langage interprété et un langage bas niveau comme le C.

En somme, je crois que les connaissances théoriques sont fondamentales, mais que elles ne peuvent être appliquées correctement qu'avec des connaissances pratiques et techniques sur les langages et les technologies employées qui soient d'un très haut niveau.

Je vous invite à commenter cette déclaration, mais je suis quasiment certain que des connaissances théoriques sans connaissances techniques en informatique, c'est voué à l'échec, comme le pensait BAF dans le message précédent.

Moi je pense que si tu as déjà assimilé tout ça et fait ce constat, tu es plutôt sur la bonnne route

[B.AF]

C'est tellement évident qu'on y pense plus .



Pour des petites équipes, en particulier.

Oui pour des petites équipes. Les innovations ont toujours été le fruit d'individu et pas d'organisations. Les organisations suivent mais ne peuvent pas innover parce que la particularité d'une organisation est d'avoir une aversion porofonde au risque.

Or, pour innover et créer il faut prendre des risques. Prendre des risques, c'est faire un pari. On ne contrôle pas toutes les composantes du risque; mais la plupart de méthodes de gestion de projet ayant un raisonnement basé sur les coûts ne peuvent quantifier les risques dans le simple fait qu'elles sont incapables de mesurer le risque créatif.
C'est d'ailleurs ce symptôme qui fait que les adoptions technologiques sont longues, car elle sont perçues en risque et non en avantage, que les systèmes vieillissent mal car il y a la crainte et de l'échec et de la perte de l'apport.

La plupart des méthodologies de gestion de projet sont basées sur un principe d'obtenir un résultat quel qu'il soit et de pouvoir justifier le résultat.
Bref, elles permettent au prix de moyens considérables d'arriver à des résultats plutôt moyens.

[souviron34]

Oui pour des petites équipes. Les innovations ont toujours été le fruit d'individu et pas d'organisations. Les organisations suivent mais ne peuvent pas innover parce que la particularité d'une organisation est d'avoir une aversion porofonde au risque.

Or, pour innover et créer il faut prendre des risques. Prendre des risques, c'est faire un pari. On ne contrôle pas toutes les composantes du risque; mais la plupart de méthodes de gestion de projet ayant un raisonnement basé sur les coûts ne peuvent quantifier les risques dans le simple fait qu'elles sont incapables de mesurer le risque créatif.
C'est d'ailleurs ce symptôme qui fait que les adoptions technologiques sont longues, car elle sont perçues en risque et non en avantage, que les systèmes vieillissent mal car il y a la crainte et de l'échec et de la perte de l'apport.

La plupart des méthodologies de gestion de projet sont basées sur un principe d'obtenir un résultat quel qu'il soit et de pouvoir justifier le résultat.
Bref, elles permettent au prix de moyens considérables d'arriver à des résultats plutôt moyens.

@yann2 : d'où mes remarques sur "l'industrialisation".... (en particulier la dernière phrase)

[Garulfo]

[...]Un développeur qui aime développer ne peut pas sortir des inepties sur la méthodologie, il ne peut pas concevoir que l'utilisateur ne soit pas satisfait. [...]

Je pense que tu ne vis pas dans le même monde que moi.
Je t'assure que des étudiants qui aiment développer j'en vois en masse. Et ce n'est pas parce qu'ils aiment qu'ils finissent par comprendre comment se font les choses. Certains sont trop pressés et pensent que les besoins sont là pour les autres. Malgré leurs plaisirs de développer, ils sortent d'énormes inepties sur les méthodes, et les architectes oublient parfois que le logiciel n'est pas pour eux justement. Et ceci après qu'ils aient diplômé — ce qui chez nous signifie avec plus d'un an d'expérience en entreprise pour la plupart d'entre eux —. De plus, peut-être qu'en France on forme des chef de projet et des responsables des besoins et de la qualité qui ne sont pas des développeurs, mais ici ça n'existe pas de telles études. Les chefs des équipes de développeurs sont tous des développeurs à l'origine. Les ingénieurs besoins et les ingénieurs qualités le sont aussi.

Pour le peu que j'en connais en France, il n'en est pas autrement. Mais je n'ai pas beaucoup de contact avec le monde académique en France. Juste un peu. En tout cas, l'Angleterre et les USA c'est comme au Canada.

[B.AF]

(...)

Pour le peu que j'en connais en France, il n'en est pas autrement. Mais je n'ai pas beaucoup de contact avec le monde académique en France. Juste un peu. En tout cas, l'Angleterre et les USA c'est comme au Canada.

Faut arrêter aussi ce trip de flagellation de la France.
Ca n'a rien à voir avec la France.

Dans ma précédente boite, il y avait 90% des clients qui étaient hors france, et les process étaient globalement les mêmes.

Si il y a bien un métier qui n'a pas de frontiére, c'est bien le développement.

D'ailleurs pour le canada, ça me fait rire de lire ça parce que l'année derniére, je fus invité par une boite d'édition qui est TRES connue, la moitié de ses développeurs sont des Français, les patrons ne le sont pas, et il n'y avait aucune différence avec une boite de soft à londres, ou a paris.

Mais vous avez tous raison, à se flageller comme ça on peut aussi aller poser des bombes dans les bureaux quite à se tirer des balles dans le pied.

Et puis récemment, les méthodes anglo saxonnes, on a vu où elle menaient le monde et dans l'ensemble, elles laissent peu de place à l'humain, et toutes les super méthodes à échelle sont le fait des anglos saxons.

Faut arrêter de dire des conneries constamment sur la france. Etre français c'est pas un handicap génétique.

[chaplin]

Je t'assure que des étudiants qui aiment développer j'en vois en masse. Et ce n'est pas parce qu'ils aiment qu'ils finissent par comprendre comment se font les choses. Certains sont trop pressés et pensent que les besoins sont là pour les autres. Malgré leurs plaisirs de développer, ils sortent d'énormes inepties sur les méthodes, et les architectes oublient parfois que le logiciel n'est pas pour eux justement.

Certe, il n'y a pas de modèle idéal, mais il existe aussi des personnes qui aiment faire leur travail et le font méthodiquement. Sur le fait que d'aimer quelque chose n'est pas synonyme de bien le faire, c'est pas faux du moins pas forcément égale.

On peut pas toujours déshumaniser les métiers au sens où les gens sont payer pour faire un travail, sinon il y aurait des tas de vocations qui n'existeraient pas. Et les prises de risque sont plus le fruit de gens passionnés mais aussi optimismes que de gens qui viennent au travail pour gagner leur salaire à la fin du mois.

Ensuite, il y a d'une part la compétence de l'individu et après les livres où les auteurs témoignent de leur experience, par conséquent ils constituent un savoir (faire) qui exploité à bon escient peu non seulement éviter des écueils sinon les réduire mais aussi conduire à la réussite.

Les cuisiniers parlent de recette de cuisine, il en va de même pour l'informatique, ensuite l'experience et la pratique font la différence en fonction des personnes.

[souviron34]

Je pense que tu ne vis pas dans le même monde que moi.

J'avais glissé sur ce passage, mais je suis d'accord avec toi... (voir tout en bas)

De plus, peut-être qu'en France on forme des chef de projet et des responsables des besoins et de la qualité qui ne sont pas des développeurs, mais ici ça n'existe pas de telles études. Les chefs des équipes de développeurs sont tous des développeurs à l'origine. Les ingénieurs besoins et les ingénieurs qualités le sont aussi.

Pour le peu que j'en connais en France, il n'en est pas autrement. Mais je n'ai pas beaucoup de contact avec le monde académique en France. Juste un peu. En tout cas, l'Angleterre et les USA c'est comme au Canada.

Faut arrêter aussi ce trip de flagellation de la France.
Ca n'a rien à voir avec la France.
...
Faut arrêter de dire des conneries constamment sur la france. Etre français c'est pas un handicap génétique.

Euh tu t'émeus pour peu..

Il ne critique pas. Ce qu'il dit c'est qu'il se demande si il y a des formations de "Chefs de Projet", d'Ingénieur Qualité, ou Ingénieur Besoin en France...

Et d'après ce que je vois sur ce site, c'est un peu vrai (stage MOA par exemple).

Mais son dernier paragraphe est au contraire pour dire qu'il pense que c'est plutôt la même chose en France et au Canada, c'est à dire que les gens qui sont aujourdhui Chef de Projet, Ingénieur Quelité, ou Ingénieur Besoin étaient avant développeurs....

Aucune raison de s'énerver, puisque nous sommes d'accord


Quant au premier point il porte sur ceci :

Un développeur qui aime développer ne peut pas sortir des inepties sur la méthodologie, il ne peut pas concevoir que l'utilisateur ne soit pas satisfait.

Contre-exemple flagrant : les geeks et hackers..

[B.AF]

Et là c'est un mélange profond : on ne doit pas confondre la motivation avec l'expérience.

Au contraire, c'est grâce à la motivation que l'on prend de l'expérience.

"Qu'avez vous appris à l'école ? rien, si vous y aviez été vous le sauriez!" (coluche)

[B.AF]

Contre-exemple flagrant : les geeks et hackers..

Bah oui, sauf que ce sont eux qui ont fait l'informatique.

[souviron34]

Et là c'est un mélange profond : on ne doit pas confondre la motivation avec l'expérience.

Au contraire, c'est grâce à la motivation que l'on prend de l'expérience.

Bah oui, sauf que ce sont eux qui ont fait l'informatique.

Euh..... En tous cas, ce n'est pas ce qui donne de bonnes IHM ni de bons logiciels.. C'est en général plutôt cryptique (voir vi).

Qu'ils soient motivés et bons, c'est une chose.

Qu'ils soient les tenants d'une méthodologie et d'une approche centrée utilisateur, c'est plutôt le contraire...

Je pense que, par rapport à ce que tu disais, il ne faut pas avoir peur de développer, oui. Par contre, le plus important à mon avis est d'être profondément imbibé de la pensée que l'informatique n'est qu'un outil pour atteindre la satisfaction de l'utilisateur.

Alors dans cette catégorie il peut y avoir des gens qui aiment développer passionnément, mais ce n'est pas essentiel. Au contraire, je dirais... Cette catégorie sera plus prone aux nouveaux trucs et bidules technologiques, en oubliant plus le but final..

La passion doit être dans l'obtention d'un outil agréable et utile..

[B.AF]

Oui mais là c'est une question d'apprentissage et de personne.

Mais on ne peut pas demander à quelqu'un qui sort de l'école d'avoir innée la science de la satisfaction d'un client, il ne sait pas ce que c'est.

C'est de l'expérience et de la maturité et aussi une question d'encadrement.

On ne peut pas demander à un développeur qui n'a jamais pu discuter avec un client ou voir la réaction d'un client final à son travail en prendre compte dans son travail quotidien.

Ce n'est pas que la plupart des développeurs ne comprennent pas les clients, c'est que la plupart des organisations empêche le développeur de s'imprégner des attentes du client et qu'ils font ce que d'autres interfaces relatent comme étant le souhait du client.

Ce tropisme, c'est l'effet durable de l'installation de toutes les professions para informatiques.

Que reste-t-il d'autre au développeur que le plaisir de la technologie dans ce cas là ?

Je ne peux pas jeter cette image sur les développeurs, car dans la majeurs partie des cas, ils n'en sont pas responsables.

[souviron34]

Absolument...

Mais les commentaires allaient par rapport au lien de cause à effet que tu mentionnais

C'est effectivement une question d'encadrement, d'enseignement, de "sensibilisation"... et de souplesse / intelligence des grandes (et moins grandes) organisations.... et d'individus..