Discussion :

[chaplin]

C'est étrange que ça puisse marcher pour tous les domaines industriels mais pas pour la finance...

Cela dépend de la rigueur exigée du métier, ou plutôt du domaine métier.

Plus que le projet comporte des risques moins on se permet d'en prendre, donc les moyens humains doivent suivrent. Mais cela n'empêche pas l'erreur.

Et pourtant je n'étais pas médecin, et je faisais que découvrir Delphi

Tiens, tiens, on fait pas mal de chose sympa avec Delphi.
Je l'ai tellement bien utilisé que je me suis fait massacré après !!

Edit:

J'arrive dans cette équipe en extérieur, en tant que "consultant ergonomie", je m'associe avec un médecin reconnu par ses pairs (élu au Conseil de l'Ordre), je monte une petite équipe, et en moins d'un an on présente un produit qui, même non fini, est non seulement classé premier lors de salons internationaux, mais que les mêmes médecoins qui faisaient grève un an avant veullent acheter directement

On a une démonstration qu'il ne faut pas beaucoup de personnes pour faire germer un projet gagnant. Cet exemple démontre qu'il faut parfois un projet en berne pour que le suivant soit un succès derrière, car les erreurs n'ont pas été commisent une deuxième fois, mais surtout qu'il y a eu un savant mélange entre les hommes et les techniques pour arriver au succès.

Il faut bien se rendre compte, que ces situations ne sont pas fréquentes et ne reflêtent pas la majorité des projets.

[B.AF]

Peut être simplement parce que la finance n'est pas une industrie et que la grande complexité est un "grand tout".

Une application de finance aujourd'hui couvre environ au sein d'un établissement financier plus de 10 métiers spécifiques qui utilisent tous des données communes.

Il est donc quasiment impossible de faire quoi que ce soit sans une connaissance exhaustive du sujet (et pas une connaissance théorique).

Ce sont des projets qui ne demandent justement pas une action ponctuelle et méthodique délimitée dans le temps mais des projets qui sont en constante évolution, demandant des algorithmes parfois très complexes et qui passent leur temps à agir en relation avec n sources d'informations et n autres produits.

Quand j'ai lu que la finance découvrait l'informatique par rapport à d'autres industries c'est complêtement faux. Les transactions / ordres sont l'anti exemple même : alors que le web marchand décolle depuis à peine 10 ans, ca fait plus de 20 ans qu'il est possible de passer des ordres électroniques --> Le fix.

Si tu veux un exemple de ce qu'est la définition d'un instrument financier pour un établissement, je t'invite à regarder l'initiative fpML.
Ca fait plus de 10 ans qu'ils sont dessus et n'ont pas terminé.

On peut expliquer la théorie d'une obligation à quelqu'un, il peut penser avoir compris et aura certainement compris ce que c'est, cela ne veut pas pour autant dire qu'il pourra développer un outil de gestion obligataire.
Parce qu'il lui manquera l'essentiel : connaitre la réalité d'une obligation.

Déterminer une instruction de réglement / livraison, ça reste faisable, mais le vrai core, il ne peut pas se baser sur une approche naïve (ce n'est pas péjoratif). Au contraire pour introduire le débat contradictoire et vérifier la qualité de l'information soumise, il faut souvent faire appel à l'expérience.
On ne peut malheureusement pas se contenter d'avoir une approche "questionnaire".

Mais on peut faire un jeu : je trouve un sujet, vous vous posez en "analystes", et on regarde jusqu'où cela méne.
D'ailleurs ce serait un excellent exemple ?

[chaplin]

Bonne idée.

C'est là où UML peut être un moyen pour venir à la rescousse de problèmes très complexes.

Jusqu'où irons les projets dans leur complexités ? C'est un autre sujet .

[yann2]

Salut

* l'hiver dernier j'étais dans une boîte qui fait les systèmes d'entraînement pour les contrôleurs du ciel. 3 pliotes (2 militaires et un civil) et 5 contrôleurs étaient à plein temps dans la boîte. Non seulement ils ajustaient, définissaient, raffinaient les demandes, mais nous les consultions environ 1 fois par jour, même pour la correction d'un bug.. Cependant, chaque décision était prise après réunion entre le Chef d'Equipe (qui en l'occurence avait été militaire aussi, mais pas pilote, et qui après avait fait informatique), nous, et les pilotes/contrôleurs. Il n'y avait donc pas d"Ingénieur-besoin" indépendant, mais la présence continue des utilisateurs du métier assure le fait que ce soft est classé 1er du monde par les contrôleurs de tous les pays...

* Deuxième exemple : une équipe de 60 personnes travaillant pendant 14 ans pour faire un logiciel de Dossier Médical Informatisé (DMP en France), avec une structure traditionnelle (cycle en V, découpage tayloriste du travail) et une approche "traditionnelle" : analyse du besoin au début (par des gens de l'équipe), puis définition du détail de la fonctionalité ((et écriture des specs) par les analystes. Résultat au bout de 14 ans : grève des médecins et infirmières pour ne même pas tester le soft tellement c'était pourri. J'arrive dans cette équipe en extérieur, en tant que "consultant ergonomie", je m'associe avec un médecin reconnu par ses pairs (élu au Conseil de l'Ordre), je monte une petite équipe, et en moins d'un an on présente un produit qui, même non fini, est non seulement classé premier lors de salons internationaux, mais que les mêmes médecoins qui faisaient grève un an avant veullent acheter directement... Et pourtant je n'étais pas médecin, et je faisais que découvrir Delphi. Sauf que je partageais la position de "Chef d'équipe" avec le médecin.

Excellent ce retour !

Tu ne serais pas en train de faire l'apologie des méthodes agiles ?
Personnellement, je crois beaucoup en cette méthode ! Impliquer le client (et surtout, l'utilisateur) dans la réalisation du produit est, pour moi, la meilleure façon d'obtenir une application répondant parfaitement aux besoins. Cependant, ce ne sont pas mes 2 petites années d'expériences qui peuvent confirmer ce sentiment.

La bonne veille méthode : Etude du besoin -> Spécification/Conception -> Réalisation (d'une traite) a montré ses limites et tu l'illustres très bien ! Qui peut penser que les besoins n'évoluent pas en 14 ans ?

Je suis content de voir qu'on en arrive là dans un thread qui s'appelle "Projets informatique : les bonnes pratiques".

J'aime beaucoup le premier paragraphe de la page wikipédia consacrée aux méthodes agiles

Les méthodes Agiles sont des procédures de conception de logiciel qui se veulent plus pragmatiques que les méthodes traditionnelles. En impliquant au maximum le demandeur (client), ces méthodes permettent une grande réactivité à ses demandes, visent la satisfaction réelle du besoin du client, et non des termes du contrat de développement. La notion de méthode agile est née à travers un Manifeste Agile signé par 17 personnalités.

• Pragmatisme
• Implication du client
• Réactivité
• Satisfaction

Tu peux développer dans ce sens ? Organisation ? Processus de développement, découpage en plusieurs petites itérations (avec livraison) ?

Pour les projets que tu cites, tu as utilisé (à la lettre) une méthode telle que eXtreme Programming, 2TUP (même si, l'agilité de 2TUP est sujette à débat) (ou autre implémentation du processus unifié), SCRUM, etc ou tu as pioché des idées (consciemment ou non) dans chacune d'entre elles ?

Yann

[Garulfo]

Peut être simplement parce que la finance n'est pas une industrie et que la grande complexité est un "grand tout". [..]

Je crois que tu te leurres à fond. La finance est très bien mathématisé, et je parle par expérience vu les chercheurs en math et en admin chez nous qui s'intéresse à ça, et donc aisément informatisable contrairement à de nombreux domaines comme l'environnement ou la médecine où a priori, il est difficile de faire des programmes. Et pourtant, les ingénieurs besoins sont utilisés aussi dans ces domaines.

Tu peux continuer à croire que c'est un cas particulier, mais ça n'est pas le cas. Comme tous les autres domaines, la finance a besoin d'ingénieur besoins. Il m'est avis que tu ne connais pas bien ce domaine (l'ingénierie des besoins).

De plus, je doute que tout ceux qui travaillent en finance aient une connaissance exhaustive du domaine. Pour automatiser une tache, il ne faut jamais avoir une connaissance exhaustive de toute façon. Et les clients doivent toujours être mis à partie. C'est ainsi quelque soit le domaine.

[Garulfo]

Cela dépend de la rigueur exigée du métier, ou plutôt du domaine métier.

Plus que le projet comporte des risques moins on se permet d'en prendre, donc les moyens humains doivent suivrent. Mais cela n'empêche pas l'erreur.
[...]

Justement, les ingénieurs-besoins sont nécessaires dans tout projet à risque. Souviron travaille dans l'aéronautique et moi, je suis en génie logiciel dans l'étude des systèmes critiques. Est-ce que la finance est plus rigoureuse que la conduite d'une centrale nucléaire ou d'un train sans pilote d'après toi ?

[chaplin]

En parlant de rigueur, comme tu l'as deviné j'insinuais tolérance à l'erreur ou marge d'erreur pour ne pas dire tolérance de panne.

Au niveau financier, les transactions bancaires doivent être justes, pas de virement aléatoire pour exagéré ou de virement simultannée sur deux comptes, rien ne se perd rien ne se créé (sauf les prêts qui augmentent la masse monétaire artificiellement ). Justement, ça va dans le sens de système critique. Dans chaque métier, il va y avoir un domaine critique, et puis il y a des modules logiciels qui vont s'appuyés sur le système dont les conséquences en cas de bug sont moins graves.

Ensuite, à bien y réflechir il y a le degrès d'inconscience du client quand il ne veut pas mesurer les risques, il aura beau rejeter la responsabilité sur le prestataire, s'il n'a pas évalué les risques, tant pis pour lui, autrement il se couvre juridiquement pour impliquer le prestataire.

Je n'ai rien contre les ingénieurs besoins, car c'est un métier qui me plairait bien, justement parce que j'ai constaté qu'il fallait une interface entre le métier et l'informatique sans pour autant dénigrer les informaticiens mais plus pour travailler en mode collaboratif, afin d'avoir une chaîne de transmission plus fluide, quand c'est possible car au fond il s'agit toujours d'argent au bout du compte. L'ingénieur besoin jouerait un rôle de médiateur.

[Luc Orient]

... Est-ce que la finance est plus rigoureuse que la conduite d'une centrale nucléaire ou d'un train sans pilote d'après toi ?

Quand on voit l'état de la finance actuellement ( sub-primes, Kerviel, Madoff, etc ) on peut avoir quelques doutes quand-même ...

[Garulfo]

En parlant de rigueur, comme tu l'as deviné j'insinuais tolérance à l'erreur ou marge d'erreur pour ne pas dire tolérance de panne.

Ce n'est pas ce qu'on appelle rigueur alors
C'est même vaguement antinomique.

Rigueur:
1. Sévérité, dureté extrême. [...]
3. Exactitude, précision, logique inflexible.
■ contraires : Douceur, indulgence. Approximation, incertitude.

Tolérance:
1. Fait de tolérer, de ne pas interdire ou exiger, alors qu'on le pourrait; liberté qui résulte de cette abstention. [...]
2. Attitude qui consiste à admettre chez autrui une manière de penser ou d'agir différente de celle qu'on adopte soi-même. ➙ compréhension, indulgence.

Je n'ai rien contre les ingénieurs besoins, car c'est un métier qui me plairait bien, [...]L'ingénieur besoin jouerait un rôle de médiateur.

Et bien moi ça ne me plairait pas du tout. Je l'étudie, je l'enseigne et je suis content de ne pas faire ce métier. Je détesterais ça. Cependant, il faut que quelqu'un le fasse. Les faits le démontrent.

[souviron34]

Excellent ce retour !
..
Tu ne serais pas en train de faire l'apologie des méthodes agiles ?
Personnellement, je crois beaucoup en cette méthode ! Impliquer le client (et surtout, l'utilisateur) dans la réalisation du produit est, pour moi, la meilleure façon d'obtenir une application répondant parfaitement aux besoins.
..
Je suis content de voir qu'on en arrive là dans un thread qui s'appelle "Projets informatique : les bonnes pratiques".

c'était noté dans les premières réponses du thread ...

Pour l'apologie, voir plus bas...

J'aime beaucoup le premier paragraphe de la page wikipédia consacrée aux méthodes agiles

• Pragmatisme
• Implication du client
• Réactivité
• Satisfaction

Tu peux développer dans ce sens ? Organisation ? Processus de développement, découpage en plusieurs petites itérations (avec livraison) ?

Voir plus bas..

Pour les projets que tu cites, tu as utilisé (à la lettre) une méthode telle que eXtreme Programming, 2TUP (même si, l'agilité de 2TUP est sujette à débat) (ou autre implémentation du processus unifié), SCRUM, etc ou tu as pioché des idées (consciemment ou non) dans chacune d'entre elles ?

Je n'ai utilisé auucne méthodolgie de ce style. MAIS mon approche a toujours été d'une part dans ce sens, parce que j'ai toujours eu profondément conscience que l'informatique n'était qu'un outil pour l'utilisateur, sans plus, et d'autre part justement par le biais de "l'ergonomie des logiciels".

J'y reviendrais plus tard, et je développerais . (peut-être demain) (pas le temps aujourdh'hui).

En très bref, je suis 100% pour une approche centrée sur l'utilisateur, et pour des "méthodes" souples. Mais n'importe quelle "méthodologie", y compris Scrum ou Xp ou autre, est forcément à ne pas suivre à la lettre. Et je crois que c'est fondamentalement l'écueil de tout ce qui arrive sur le marché : croire qu'une "méthodologie", formulée et "didactique", est une solution. Je répète ce que j'ai déjà dit ailleurs : l'industrie informatique (et les théoriciens) ont l'illusion que la création de leur produit est une chose "modélisable" et reproductible. Il n'y a rien de plus faux. Ce que nous faisons c'est de l'artisanat.

Mais je développerais ultérieurement..

Je crois que tu te leurres à fond. La finance est très bien mathématisé, et je parle par expérience vu les chercheurs en math et en admin chez nous qui s'intéresse à
...
De plus, je doute que tout ceux qui travaillent en finance aient une connaissance exhaustive du domaine. Pour automatiser une tache, il ne faut jamais avoir une connaissance exhaustive de toute façon. Et les clients doivent toujours être mis à partie. C'est ainsi quelque soit le domaine.

Encore une fois, je ne peux qu'être d'accord

Je n'ai rien contre les ingénieurs besoins, car c'est un métier qui me plairait bien, justement parce que j'ai constaté qu'il fallait une interface entre le métier et l'informatique sans pour autant dénigrer les informaticiens mais plus pour travailler en mode collaboratif, afin d'avoir une chaîne de transmission plus fluide, quand c'est possible car au fond il s'agit toujours d'argent au bout du compte. L'ingénieur besoin jouerait un rôle de médiateur.

Et bien moi ça ne me plairait pas du tout. Je l'étudie, je l'enseigne et je suis content de ne pas faire ce métier. Je détesterais ça. Cependant, il faut que quelqu'un le fasse. Les faits le démontrent.

Voui et moi j'adore ça, en fait...

J'adore apprendre les dessous d'un nouveu métier, parler avec des gens que je n'aurais jamais rencontré autrement, et y trouver une logique suffisante pour pourvoir proposer une aide efficace..

Mais justement je suis plutôt généraliste...

Et comme tu dis, il faut que quelqu'un le fasse.. Et c'et réciproque.. Autant j'ame faire partager mon expérience, autant je n'aimerais pas enseigner ... Et il faut que quelqu'un le fasse

[B.AF]

donc en gros, tant qu'on a les méthodes, on peut ne pas avoir les hommes finalement.

C'est flippant comme la gestion de projet n'a aucune reconnaissance de la valeur du travail.

On peut dire ce qu'on veut, depuis 15 ans rien n'a évolué.

Je vous le dis là, parce que je crois que fondamentalement il n'y a rien d'agile dans tout ça.

Au contraire, c'est plutôt du bon cycle en V des familles.

Pour arriver un jour à dire "On a des composants graphique java courbes, on va pouvoir faire des courbes de taux" (déjà entendu)

Je ne comprends pas cet entêtement de tous les métiers de l'informatique à ne jamais mettre le métier au milieu de la réflexion. au final, l'informatique ce n'est qu'un moyen de ...
Pourquoi accorder si peu d'importance à la réalité du terrain..

[yann2]

Salut

B.AF, je n'ai pas compris ta réponse.

donc en gros, tant qu'on a les méthodes, on peut ne pas avoir les hommes finalement.

Je ne suis pas sûr que tu l'aies dis dans ce sens mais, une chose est sûre c'est qu'une méthode agile donne beaucoup d'importance à l'équipe ! Sur l'article wikipédia il est précisé qu'il vaut mieux 15 développeurs moyens mais avec un très bon sens de l'équipe que 15 développeurs excellents mais, individualistes. Bien entendu, le mieux c'est 15 développeurs excellents avec un très bon sens de l'équipe ! (voir la partie Valeur sur l'article wikipédia). Ca rejoint un excellent bouquin que je ne regrette vraiment pas d'avoir acheté : Design Pattern, Analyse et Conception Orienté Objet (de Craig Larman, le papa des Pattern GRASP). Il porte un peu mal son nom. Il expose, de façon très clair, l'utilisation du Processus Unifié de manière agile. Je ne l'ai pas cité avant parce que je ne voulais pas influencer la discussion mais, je suis vraiment content de voir que la plupart de ce qui ait dit dans le livre rejoins ce que dit Souviron34 (parce que la théorie c'est joli mais, je préfère les preuves du terrain).

Je ne comprends pas cet entêtement de tous les métiers de l'informatique à ne jamais mettre le métier au milieu de la réflexion. au final, l'informatique ce n'est qu'un moyen de ...

Là je comprends encore moins On vient juste de dire que le client et l'utilisateur est sollicité tout au long du projet ! Et, Souviron34 vient de donner 2 exemples concrets d'applications de ce principe.

Dans ma boîte, j'ai plus l'impression qu'on s'approche de ce principe que d'un cycle en V ou en cascade traditionnel (en même temps je n'ai jamais fais de projet avec cycle en V ou cascade).

c'était noté dans les premières réponses du thread ...

Argh ! Mea culpa ! Le pire c'est que je suis ce thread depuis le début je ne m'en rappelais plus.

En très bref, je suis 100% pour une approche centrée sur l'utilisateur, et pour des "méthodes" souples. Mais n'importe quelle "méthodologie", y compris Scrum ou Xp ou autre, est forcément à ne pas suivre à la lettre. Et je crois que c'est fondamentalement l'écueil de tout ce qui arrive sur le marché : croire qu'une "méthodologie", formulée et "didactique", est une solution. Je répète ce que j'ai déjà dit ailleurs : l'industrie informatique (et les théoriciens) ont l'illusion que la création de leur produit est une chose "modélisable" et reproductible. Il n'y a rien de plus faux. Ce que nous faisons c'est de l'artisanat.

Voir plus haut ( ). Le livre dont j'ai parlé adopte la même philosophie. Certains outils (ou artefacts, qui est un meilleur terme) sont inutiles, voir gênants, pour certains projets alors qu'ils seront indispensables pour d'autres. L'auteur insiste lourdement là dessus et donne des exemples d'utilisation en précisant qu'il ne s'agit pas d'une recette

D'ailleurs on pourra noter que le Manifeste Agile est née après les méthodes sus citées.

En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se sont réunies pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles.

C'est récent, hein ? J'aime beaucoup ! 17 grosses têtes qui se rencontrent pour dire : "Hey ! Elle est pas mal ta méthode !". Comme quoi, il ne faut pas cracher sur la méthode du voisin mais, plutôt regarder ce qu'elle peut nous apporter.

Je ne me prononcerai pas sur le terme artisanat parce que je ne sais pas ce que tu veux désigner. Je veux juste préciser que je crois beaucoup à l'industrialisation du développement (d'ailleurs c'est déjà le cas ! L'utilisation d'un framework est une étape de l'industrialisation du développement). Sachant, que cette industrialisation n'est pas du tout incompatible avec les valeurs des méthodes agiles (pour peu qu'on fasse les bons choix).

Yann

[B.AF]

J'en suis un signataire.

Mais bon...Je crois qu'au final, ca finira comme le reste un diagramme sur les powerpoints des chefs de projet.

L'agile n'est pas une méthode mais une philosophie de développement.

La méthode, c'est ce qui reste à ceux qui n'ont pas la créativité.

La méthode, c'est du reporting. Rien de plus.
Il n'y a pas de sueur, pas de talent, pas d'exception, pas d'équipe.
Des process, des boites où on pose les "ressources", des gabarits de documents.

Voilà.
Et oui, l'agile, j'en suis un signataire de la premiére heure, et tous les jours j'en suis convaincu. Mais ne venez pas m'expliquer que vo ingénieurs besoins et vos découpes transverse / horizontales / verticales sont agiles.

Voilà Yann.

Quand je lis tout ça, on arrive pas à se défaire de l'académisme, on arrive pas à faire autrechose que ce que d'autres écrivent dans des livres.

Faire de l'informatique, c'est bien, faire de l'informatique pour faire autrechose c'est mieux.
Pourquoi tuer ça ?
Pourquoi s'acharner à ça ?
Malgrè toutes ses années, je ne comprends toujours pas.
La réussite d'un projet, c'est l'implication des hommes, la dimension d'équipe et la perception d'un objectif.
Ce qui fait tout c'est la compréhension de l'objecti par tous. Le reste, c'est du reporting pour fournir de la garantie.

[yann2]

re

euh... je suis perplexe. D'une part, parce que ta réponse est floue !

Faire de l'informatique, c'est bien, faire de l'informatique pour faire autrechose c'est mieux.
Pourquoi tuer ça ?
Pourquoi s'acharner à ça ?
Malgrè toutes ses années, je ne comprends toujours pas.
La réussite d'un projet, c'est l'implication des hommes, la dimension d'équipe et la perception d'un objectif.
Ce qui fait tout c'est la compréhension de l'objecti par tous. Le reste, c'est du reporting pour fournir de la garantie.

Je crois que tu te méprends sur ce que j'ai dis plus haut. Une méthode agile n'existe pas pour avoir du reporting ! Mais répond parfaitement à "La réussite d'un projet, c'est l'implication des hommes, la dimension d'équipe et la perception d'un objectif.
Ce qui fait tout c'est la compréhension de l'objecti par tous".
C'est un cadre pour augmenter le facteur de réussite ! On peut aussi adopter la méthode "Arrache" mais ça m'étonnerait que le taux de réussite des projets soit mirobolant !

La méthode, c'est ce qui reste à ceux qui n'ont pas la créativité.

La méthode, c'est du reporting. Rien de plus.
Il n'y a pas de sueur, pas de talent, pas d'exception, pas d'équipe.
Des process, des boites où on pose les "ressources", des gabarits de documents.

Voilà.
Et oui, l'agile, j'en suis un signataire de la premiére heure, et tous les jours j'en suis convaincu. Mais ne venez pas m'expliquer que vo ingénieurs besoins et vos découpes transverse / horizontales / verticales sont agiles.

Bah si tu ne veux pas l'appeler "Méthodes agiles" appelle le autrement. C'est dommage d'utiliser un autre nom mais pourquoi pas ? Sinon, je ne vois pas vraiment le rapport entre méthodes et reporting Je ne vois pas, non plus, en quoi ça nuit à la créativité ? Ou alors tu veux dire que ce n'est pas appliqué dans ton travail ? Dans ce cas, c'est dommage

Et j'espère que tu parles de ton cas personnelle et que tu n'es pas en train de me juger (moi ou l'entreprise pour laquelle je travaille) parce que tu ne me connais pas et tu ne sais rien de notre (l'entreprise pour laquelle je travaille) façon de travailler.

Enfin, pour répondre à ça :

Quand je lis tout ça, on arrive pas à se défaire de l'académisme, on arrive pas à faire autrechose que ce que d'autres écrivent dans des livres.

Non, je ne pense pas (aujourd'hui mais, ça sera certainement pareil demain) trouver mieux que les personnes qui ont écris ces bouquins. Le mieux que je puisse faire c'est :

• de les lire et voir ce que ça peut m'apporter
• Pratiquer/Utiliser inconsciemment des "choses" qui ont déjà un nom et sont clairement définies (TDD pour faire un exemple simple ou utiliser un Design Pattern sans savoir qu'il s'agit d'un Design Pattern)

Je n'ai, malheureusement, pas la prétention de révolutionner le développement d'applications informatiques du haut de mes 2 longues années d'expériences professionnels (huhu, bientôt 3, wouaaa). Donc, pardonne moi, mais je continuerai à me documenter et à demander des retours d'expériences. D'ailleurs, il me semble que c'est à ça que sert ce topic.

Yann

[Garulfo]

donc en gros, tant qu'on a les méthodes, on peut ne pas avoir les hommes finalement.

C'est flippant comme la gestion de projet n'a aucune reconnaissance de la valeur du travail.[...]

C'est pas à moi que tu réponds là ? Parce que je ne vois pas où j'ai dis quoique ce soit qui ressemble à ça.

[el_slapper]

(.../...)
Je n'ai utilisé auucne méthodolgie de ce style. MAIS mon approche a toujours été d'une part dans ce sens, parce que j'ai toujours eu profondément conscience que l'informatique n'était qu'un outil pour l'utilisateur, sans plus, et d'autre part justement par le biais de "l'ergonomie des logiciels".

J'y reviendrais plus tard, et je développerais . (peut-être demain) (pas le temps aujourdh'hui).

En très bref, je suis 100% pour une approche centrée sur l'utilisateur, et pour des "méthodes" souples. Mais n'importe quelle "méthodologie", y compris Scrum ou Xp ou autre, est forcément à ne pas suivre à la lettre. Et je crois que c'est fondamentalement l'écueil de tout ce qui arrive sur le marché : croire qu'une "méthodologie", formulée et "didactique", est une solution. Je répète ce que j'ai déjà dit ailleurs : l'industrie informatique (et les théoriciens) ont l'illusion que la création de leur produit est une chose "modélisable" et reproductible. Il n'y a rien de plus faux. Ce que nous faisons c'est de l'artisanat.(.../...)

analogie militaire : l'important n'est pas la stratégie, c'est son exécution. En 1940 quand il s'est agi de bloquer les Allemands en Belgique, le plan était le meilleur possible : un glacis mobile de défenses(appuyé sur la Maginot) pour ralentir puis stopper l'Allemand là ou il attaquerait. Compte tenu de ce que l'on sait aujourd'hui des forces en présence, Il est difficile de prévoir meilleur plan. Mais l'execution a été désastreuse, parceque l'ensemble de la chaine de commandement pensait en termes de guerre de position, là ou il fallait penser mobile. Résultat : une réaction tardive et molle face à la perçée des Ardennes, et un ennemi qui lui applique son plan(pourtant pas excellent, et très risqué) avec rigueur et efficacité. On connait la suite.

Retour à l'informatique. Ou la problématique est la même : on met en place des plans magnifiques sans tenir compte des problématiques locales. Par exemple, on forme tous les cadres d'une boite à SCRUM(mais pas les grouillots, ni les utilisateurs), et on met en place parralèllement un nouveau système de requêtes à la production ou le délai passe officiellement à 10 jours pour toute action, même pour faire tourner une chaine en intégration.....vachement réactif comme système. J'ai même connu des endroits ou la livraison en intégration tournait le lundi à 10 heures, j'avais fini mes cas-tests et anomalies à 11 heures, le programmeur avait corrigé à midi.....et on était bon pour attendre le lundi suivant pour repasser les tests!!!

En bref, je suis partisan des méthodes agiles(codifiées ou pas, c'est juste une question de style) dans l'absolu, mais il est à mon sens contre-productif d'y passer si l'ensemble de la chaîne n'est pas dans le circuit : exploitation, études, homologation, spécification, utilisateurs(quelles que soient les appellations de ces domaines, et qu'ils soient unifiés ou pas). Si l'utilisateur final ne s'implique pas, tout est foutu. Pareil si l'exploitation ne joue pas le jeu(et ou je suis, ça n'en prend pas le chemin). Pareil si une partie des études n'est pas impliquée. On a eu un projet internet en "démarche agile" l'an dernier, mais il avait des impacts sur des applis(dont la mienne) qui elles marchaient à l'ancienne, avec planification, et tout. Bizarrement, la première mouture du projet a fini en coquille vide, avec des petites mains qui resaisissent les demandes du client derrièrre la belle vitrine.....

[B.AF]

C'est pas à moi que tu réponds là ? Parce que je ne vois pas où j'ai dis quoique ce soit qui ressemble à ça.

Non c'est une somme de pensées qui me sont venues en relisant certains topics, et surtout en regardant mes mails avant d'aller entamer ma nouvelle journée.

Rien d'intuitu personae.


Pour agile, les fondamentaux sont :
Individuals and interactions over processes and tools
(Personnes et interaction entre les personnes avant les process et les outils)
Agile remet clairement le développeur et l'équipe au coeur du principe, partant du principe que dans sa construction et dans sa gestion, les process et les outils seront utilisés comme support d'amélioration plutôt que comme base de travail.

Working software over comprehensive documentation
(Produit efficient prioritaire à une documentation)
La culture du résultat est plus important que la documentation

Customer collaboration over contract negotiation
(Collaboration client plutôt que négociation commerciale)
Culture du fair deal, le résultat n'est pas le fruit d'un engagement contractuel mais d'une relation avec le client.

Responding to change over following a plan
(Adaptation aux changements plutôt que Suivi de plan projet)
Croire davantage à la capacité d'adaptation de l'organisation qu'à la capacité de l'organisation à gérer un projet.

Agile, c'est une philosophie de développement orienté client et résultat.
Etre agile, cela veut dire avoir une vision globale du projet et de l'utilité du projet pour le client; se poser en tant qu'acteur et assumer sa responsabilité dans l'avantage compétitif que peu apporter le projet au client.
Baser sur cela, l'organisation de l'équipe se fait autour de personnes impliquées, responsable en ayant recours au débat d'idées et en mettant en oeuvre un environnement dans lequel les développeurs peuvent atteindre leurs objectifs.
Cela mis en place, l'équipe doit être capable de détecter les ajustements ou les changements à réaliser pour améliorer la productivité, en faisant la promotion de la simplicité (efficience over convention).
Le travail constant entre les experts métiers et les développeurs, doivent permettre aux développeurs de pouvoir faire évoluer et améliorer constamment le design et l'architecture et réduire les temps d'adaptation aux évolutions.
La seule mesure d'éfficacité est un soft qui fonctionne.

On peut choisir de réaliser un cycle en V en étant Agile, à partir du moment ou la philosophie est respectée et appliquée.
Mais à partir du moment où les ressources sont identifiées à priori des hommes, ce n'est déjà plus "Agile" compliant.

[souviron34]

J'élaborerais ma réponse plus ou moins complète à vos derniers messages cette nuit, mais voici un parfait exemple de la bêtise ... à ne surtout pas faire, mais qui est malheuresuement faite trop régulièrement...

Posté aujourdhui même dans le forum Emploi -> Salaires:

J'ai fini un stage de 6 mois dans une banque prestigieuse en AMOA et informatique décisionnelle. Je viens d'être diplômé d'un M2 d'info gestion à Dauphine.

(http://www.developpez.net/forums/m3969746-158/

Il y peut rien, le pôv... Mais malheur à ceux qui l'engagent....

Et à ceux qui pensent qu'on se forme en AMOA, et qu'en plus on s'y forme en "6 mois de stage"...

[B.AF]

aïe....

Enfin en même temps, c'est un peu aussi la responsabilité du système :
Quand tu passes 5 ans à apprendre des tas de choses, dont des cours de gestion de projet avec des écoles qui aujourd'hui font des classements de premier salaire et de taux de placement (suffit de voir la page d'accueil...), ça me parait plutôt légitime d'y croire.
Je ne pense pas que la responsabilité soit uniquement celle des candidats...

C'est vrai que pour nos métiers, l'alternance est une bonne solution, mais bon...

[Garulfo]

analogie militaire : l'important n'est pas la stratégie, c'est son exécution. En 1940 quand il s'est agi de bloquer les Allemands en Belgique, le plan était le meilleur possible[...]

sauf qu'un bon plan prend en compte ses failles. La défense française a été mal exécuté, certains généraux étaient aussi peu motivés, mais le plan n'était pas parfait non plus. Il n'avait pas pris en compte ce que les guerres d'Espagne et de Pologne avait enseigné. Il ne regardait que la WWI. Les doctrines d'emploi des armes, desquelles découle le plan étaient aussi mauvaise. Une bonne défaite bien logique donc.

Bon maintenant, Je suis d'accord avec toi cependant pour l'idée de ce que tu dis. Si on a la meilleure méthode du monde mais qu'elle est mal appliquée, ça ne sert à rien.