Discussion :

[echapiro]

Bonjour,

Je suis actuellement développeur sur un projet agile. Mais quelque chose cloche. Je ne comprends pas si cela vient de moi ou si du projet. Toujours est-il que je n'arrive pas à étre motivé.

Je ne cherche évidemment pas de coupables mais seulement à être mieux dans mon travail.

Il y a plusieurs choses que je n'aime pas. Commençons par le Product Owner. C'est un monsieur fort sympathique à priori. Le problème, c'est que je ne comprends fichtrement rien à ce qu'il me raconte. Pour m'expliquer quelque chose, il se croit dans l'obligation d'utiliser un jargon informatique, comme si c'était le seul language que je puisse comprendre.

Par exemple, voici le genre de choses qu'il pourrait m'expliquer EN JARGON INFORMATIQUE :

Bon ben quand tu crée un enregistrement dans la table "TralalaItou", utilise la fonction "YOUKALDI", prends le resultat de la fonction et stocke dans la colonne SCHTROUMPF de la table "TuLasDansLeBaba". Ensuite fais un INSERT en SQL. Après chaque fois que tu clique sur le bouton "Machin Truc" de la page "Chose Chouette", appelle le script "Tirelipimpon" en affectant le paramètre "SurLeChiOuaOua" de la requête HTTP en method "GET". Dans le script "Tirelipimpon" récupère le paramètre "SurLeChiOuaOua" et va chercher l'enregistrement SCHTROUMPF2 correspondant. Ensuite, recopie certaines colonnes dans l'enregistrement que tu as trouvé dans une zone mémoire (et là il me balance une liste de cinquante colonnes aux noms tous plus ésotériques les uns que les autres). Ensuite il faut que tu appelle la fonction "YOUKALDA" qui se trouve dans le module "JeSaisPasQuoi". Par contre, je ne sais pas sur que la fonction s'appelle "YOUKALDA" ni même que le module s'appelle "JeSaisPasQuoi". Demande à Tartenpion, il doit savoir. C'est lui qui a fait le truc. Ah oui, où en étais-je ? Ah oui, appelle la fonction SCHTROUMPF3 et récupère le résultat de la fonction dans un entier. Ensuite, tu reprends tout les valeurs de la zone mémoire que je t'ai donné tout à l'heure. Tu réaffectes tout la table SCHTROUMPF et tu fais un INSERT. Etc. Etc. C'était clair ?

Et encore, là j'ai simplifié la version jargon informatique. Pourtant la même chose EN VERSION FRANCAISE donnerait à peu prés ceci :

"Un numéro d'authenfication d'un certificat de conformité n'est connu que lorsque celui-ci est validé. A la création, on lui attribue un numéro temporaire."

Il s'exprime comme un informaticien. Probablement parce que c'en est un.

Les users stories qu'il écrit dans le backlog sont de la même qualité. il fait des références à un système externe que lui seul connait. Nous travaillons sur une refonte d'un système existant. Donc parfois on a des stories du genre "Il faut faire exactement come sur l'ancien systeme". Merci pour ceux qui ne connaissent pas l'ancien système. J'ose même pas lui demander comment c'était sur l'ancien système car la réponse sera probablement du même acabit.

Parfois, les entités du système externe ne sont pas nommés comme sur notre système à nous. On a un décalage des représentations ce qui ne facilite pas la compréhension. Quand je travaille sur une user story, je ne comprends pas ce que je suis en train de faire, où je vais dans quelle étagère.


On continue ensuite avec l'équipe. J'ai rarement vu une équipe être aussi réfractaire aux tests automatisés. Je passe pour quelqu'un de bizarre parce que je suis le seul à écrire des tests. Dernièrement, ils se sont lancés dans un débat pour essayer de réduire les tests sur le serveur d'intégration continu parce qu'il est tout le temps orageux. Mais moi je trouve franchement débile. Suis-je vraiment bizarre ? Est-ce normal un projet agile sans aucun tests ?

Je trouve aussi que le reste de l'équipe n'a pas de forte capacité d'abstraction. Un projet agile est sujet à beaucoup de changement.
Ils n'écrivent pas de code souple et maintenable. Ils appliquent beaucoup d'anti-patterns, un peu comme s'ils codaient en procédural. Les exceptions ? Connait pas ! On préfère renvoyer des codes erreurs dans les fonctions. Ils ne savent même faire modéliser en objet. Je ne veux pas les dénigrer, j'aurai vraiment aimé apporter mon point de vue en Pair Programming. Mais malheureusement, on n'en fait pas !

Ils ne croient pas à la collectivité du code. Dans ce projet, chacun fait son truc dans son coin. Je n'ai pas l'assurance que le code que je produis puisse être repris en cas d'absence (et réciproquement). J'ai déjà cotoyé pas mal de développeur qui pondent du code sans se soucier qu'il soit maintenable par les autres ou pas. Moi je n'ai jamais pensé comme ça. Et pourtant c'est le cas de tous ces rigolos.

Pour je ne sais quelle raison, cette équipe ADORE les réunions qui durent des heures. Elles n'apportent jamais rien de concret, la discussion va dans tous les sens et je m'ennuie comme c'est pas possible. Le matin, on ne fait jamais de "Stand Up Meeting"

J'ai l'impression d'être aux antipodes avec ces énergumènes. Je reste poli avec eux comme avec n'importe quel collegue d'ailleurs. Mais qu'est ce qu'ils m'enervent !!! J'essaye de faire en sorte que ça n'handicape pas le projet mais c'est pas facile ! J'ai l'impression que je dois me mettre au diapason avec eux. Par exemple, j'en suis réduit à ne plus écrire de tests et je vis ça comme une régression.

Quand au Scrum Master, il est gentil mais il ne m'aide pas beaucoup et je le trouve plutôt jeune (jeune d'expérience agile bien sûr. J'ai déjà vu d'autres jeunes beaucoup plus expérimentés sur le sujet). Ce qui est marrant, c'est que tout le monde l'appelle "le Chef De Projet".

Un autre délire que j'ai pu constater (si c'en est un). Notre application a un coeur, c'est la partie la plus importante de toute l'application. Si j'ai bien compris, on dit que c'est là qu'il y a le plus de "valeur métier". Bizarrement, l'implémentation du coeur a débuté à partir de la 5ème (ou la 6ème) itération. Les premières itérations ont servis à créer une espèce de librairie censé répondre à tous les besoins de ce fameux coeur. Franchement cette partie m'a ennuyée à mourir. C'était tellement technique qu'on ne pouvait pas en faire la démo à la revue de sprint. N'aurait-il pas été plus judicieux de commencer directement par le coeur et d'incrémenter, adapter cette librairie au fil de l'eau ?

Très sérieusement, je dois me forcer pour aller travailler. Pourtant je crois aux vertus de l'agilité. Pourquoi je ne suis pas motivé ? Le problème vient-il de moi ? Suis-je trop exigeant ? Ou est-ce les sociétés qui ne savent pas encore l'appliquer correctement ?

Est-ce qu'on peut dire qu'un développeur soit fait pour l'agilité et un autre pour le cycle en V ? Serais-je fait pour le cycle en V ? Parce qu'en plus je deteste le cycle en V !

[el_slapper]

Bonjour.

pré-scriptum ; je n'ai jamais officiellement travaillé en agile. Mais parfois, c'en était proche - et nettement plus efficace. Mais, dans le détail :

(.../...)Il y a plusieurs choses que je n'aime pas. Commençons par le Product Owner. C'est un monsieur fort sympathique à priori. Le problème, c'est que je ne comprends fichtrement rien à ce qu'il me raconte. Pour m'expliquer quelque chose, il se croit dans l'obligation d'utiliser un jargon informatique, comme si c'était le seul language que je puisse comprendre.(.../...)

Il s'exprime comme un informaticien. Probablement parce que c'en est un.

C'est un défaut fréquent. On m'en a fait le reproche hier. J'essaye de me corriger.

Les users stories qu'il écrit dans le backlog sont de la même qualité. il fait des références à un système externe que lui seul connait. Nous travaillons sur une refonte d'un système existant. Donc parfois on a des stories du genre "Il faut faire exactement come sur l'ancien systeme". Merci pour ceux qui ne connaissent pas l'ancien système. J'ose même pas lui demander comment c'était sur l'ancien système car la réponse sera probablement du même acabit.

Problème fréquent aussi. Il est souvent très difficille de rétro-documenter un système existant. J'ai eu à le faire lors d'une refonte. Au final, c'est un outil de tests massif(fait à la main) qui comparait l'ancien système au nouveau automatiquement qui m'a permis d'avoir une compréhension complète de l'ancien système.

As-tu accès à l'ancien système? Moi, j'avais accès à ses sources et pouvait le faire tourner librement, ça m'a permis de m'en sortir.

Parfois, les entités du système externe ne sont pas nommés comme sur notre système à nous. On a un décalage des représentations ce qui ne facilite pas la compréhension. Quand je travaille sur une user story, je ne comprends pas ce que je suis en train de faire, où je vais dans quelle étagère.

Classique aussi, hélas. Rien à voir avec l'agile, les micro-jargons sont une plaie systématique. Dans mon ancien métier, la plasturgie, la "carotte" désigne officiellement le bout de plastique qui ne fait pas partie de la mièce et qui est perdu à chaque moulage. Là ou j'ai fait mon stage, ça désignait la pièce mécanique en acier située entre la vis d'injection et la partir du moule ou on a la carotte "officielle". De quoi alimenter bien des quiproquo...

On continue ensuite avec l'équipe. J'ai rarement vu une équipe être aussi réfractaire aux tests automatisés. Je passe pour quelqu'un de bizarre parce que je suis le seul à écrire des tests. Dernièrement, ils se sont lancés dans un débat pour essayer de réduire les tests sur le serveur d'intégration continu parce qu'il est tout le temps orageux. Mais moi je trouve franchement débile. Suis-je vraiment bizarre ? Est-ce normal un projet agile sans aucun tests ?

un projet sans tests, agile ou non, automatisés ou non, est voué à un sort funeste.

Je trouve aussi que le reste de l'équipe n'a pas de forte capacité d'abstraction. Un projet agile est sujet à beaucoup de changement.
Ils n'écrivent pas de code souple et maintenable. Ils appliquent beaucoup d'anti-patterns, un peu comme s'ils codaient en procédural. Les exceptions ? Connait pas ! On préfère renvoyer des codes erreurs dans les fonctions. Ils ne savent même faire modéliser en objet. Je ne veux pas les dénigrer, j'aurai vraiment aimé apporter mon point de vue en Pair Programming. Mais malheureusement, on n'en fait pas !

Le procédural peut être parfaitement maintenable si bien pensé. Tout le monde n'aime pas les exceptions, y compris quelques cadors. Et, de mon point de vue, pour du code purement métier, l'objet a autant d'inconvénients que le procédural(pour l'affichage, c'est différent).

Ils ne croient pas à la collectivité du code. Dans ce projet, chacun fait son truc dans son coin. Je n'ai pas l'assurance que le code que je produis puisse être repris en cas d'absence (et réciproquement). J'ai déjà cotoyé pas mal de développeur qui pondent du code sans se soucier qu'il soit maintenable par les autres ou pas. Moi je n'ai jamais pensé comme ça. Et pourtant c'est le cas de tous ces rigolos.

ça, par contre, c'est catastrophique.

Pour je ne sais quelle raison, cette équipe ADORE les réunions qui durent des heures. Elles n'apportent jamais rien de concret, la discussion va dans tous les sens et je m'ennuie comme c'est pas possible. Le matin, on ne fait jamais de "Stand Up Meeting"

le stand up meeting est juste une manière de faire, il y en a des dizaines d'autres. Par contre, la réunion ou 2 gusses parlent et 8 roupillent, c'est une catastrophe.

J'ai l'impression d'être aux antipodes avec ces énergumènes. Je reste poli avec eux comme avec n'importe quel collegue d'ailleurs. Mais qu'est ce qu'ils m'enervent !!! J'essaye de faire en sorte que ça n'handicape pas le projet mais c'est pas facile ! J'ai l'impression que je dois me mettre au diapason avec eux. Par exemple, j'en suis réduit à ne plus écrire de tests et je vis ça comme une régression.

Ne cède pas à la tentation. Garde tes bonnes habitudes. Testes unitairement chaque sourcil que tu codes - idéalement de manière automatique. Ne laisse pas le coté obscur de la farce t'envahir.

(.../...)Un autre délire que j'ai pu constater (si c'en est un). Notre application a un coeur, c'est la partie la plus importante de toute l'application. Si j'ai bien compris, on dit que c'est là qu'il y a le plus de "valeur métier". Bizarrement, l'implémentation du coeur a débuté à partir de la 5ème (ou la 6ème) itération. Les premières itérations ont servis à créer une espèce de librairie censé répondre à tous les besoins de ce fameux coeur. Franchement cette partie m'a ennuyée à mourir. C'était tellement technique qu'on ne pouvait pas en faire la démo à la revue de sprint. N'aurait-il pas été plus judicieux de commencer directement par le coeur et d'incrémenter, adapter cette librairie au fil de l'eau ?

YAGNI est un concept qui a ses limites. Mon beau-frère, lead developper chez un éditeur de logiciel, m'a affirmé avoir codé un composant 11 ans après l'avoir prévu dans l'architecture.

Par contre, c'est ridicule de faire une démo avec ça.

Très sérieusement, je dois me forcer pour aller travailler. Pourtant je crois aux vertus de l'agilité. Pourquoi je ne suis pas motivé ? Le problème vient-il de moi ? Suis-je trop exigeant ? Ou est-ce les sociétés qui ne savent pas encore l'appliquer correctement ?

+1 pour te dire qu'il y a sans doute de toi aussi. L'humilité est une vertu fondamentale dans notre métier.

Mais les aspects de réunionnite, d'antitesting, et de confiscation du code que tu cites me font penser que tout n'est pas de ton coté. Loin s'en faut. Tu est sans doute trop exigent sur certains détails(exceptions vs codes retours, objet vs procédural), mais tester intégralement son code est infiniment plus important que toutes ces querelles religieuses.

Est-ce qu'on peut dire qu'un développeur soit fait pour l'agilité et un autre pour le cycle en V ? Serais-je fait pour le cycle en V ? Parce qu'en plus je deteste le cycle en V !

On peut faire du cycle en V "agile". Quand les spécificateurs n'ont aucune idée de ce qu'ils veulent, et attendent de voir ce que la programmation donne pour "affiner les specifications". Ca marche très bien et c'est très rigolo. Hélas, ça n'est jamais planifié comme tel.

Variante : on est tellement en retard qu'il est parfaitement assumé que les specs sont bourrées d'erreur dans leur version 1 - là aussi, on fait plein d'itérations qui ne veulent pas dire leur nom, et ça marche très bien aussi(et j'ai adoré ça). Manque de pot, ça n'est pas non plus prévu de faire comme ça en temps normal.

[Luckyluke34]

C'est un fake ou il y a vraiment des équipes comme ça qui osent se qualifier d' "agiles" ?

Ou est-ce les sociétés qui ne savent pas encore l'appliquer correctement ?

A ce niveau c'est même pas qu'elles ne savent pas l'appliquer, c'est qu'elles ont juste mis une étiquette "Agile" sur un cycle en V (j'ai rien contre, mais il faut assumer) et des pratiques techniques des années 90 sans changer le contenu.

J'ai envie de dire, change de boîte ou prépare ton costume de superman pour essayer de changer graduellement cette organisation en partant peut-être de ce qui marche déjà bien (apparemment vous faites déjà de l'intégration continue, des user stories).

Ce qui est bizarre c'est que le scrum master ne s'aperçoive pas de tout ça. C'est lui le mieux placé pour faire changer les choses car il en a la légitimité.

[el_slapper]

C'est un fake ou il y a vraiment des équipes comme ça qui osent se qualifier d' "agiles" ?

agile c'est à la mode, donc tout le monde(sauf les dinosaures assumés pour lesquels je bosse) se prétend agile. de même qu'à un moment, la moitié des équipes du monde prétendaient pratiquer le "football total", sans même comprendre la notion(je ne la comprend pas moi non plus, hein...). C'est donc une étiquette partagée par des cycles en V et des purs "cowboys".

A ce niveau c'est même pas qu'elles ne savent pas l'appliquer, c'est qu'elles ont juste mis une étiquette "Agile" sur un cycle en V (j'ai rien contre, mais il faut assumer) et des pratiques techniques des années 90 sans changer le contenu.(.../...)

C'est même pas du cycle en V, c'est, euh, un joyeux mélange de tout, un peu de cowboy(pas de tests), un peu de cycle en V, et un peu d'agile. De préférence le pire de chaque système.

[Drawingrom]

C'est même pas du cycle en V, c'est, euh, un joyeux mélange de tout, un peu de cowboy(pas de tests), un peu de cycle en V, et un peu d'agile. De préférence le pire de chaque système.

C'est la rache avec le vocable de Scrum...

[echapiro]

Merci pour vos feedbacks. Vos remarques sur les tests automatisés m'ont vraiment rassuré car j'ai vécu ce rejet des tests par mon équipe comme un choc culturel. C'est comme dire que Dieu n'existe pas !

@ LuckyLuke34
Je peux te confirmer que ce n'est pas un fake et ça arrive bien plus souvent qu'on ne le croit.

@ el_slapper
En tant qu'informaticien, il me parait normal que tu utilise un jargon informatique . Ce que j'ai voulu dire, c'est que les utilisateurs n'ont pas voulu être impliqué dans notre projet (ou alors les managers n'ont pas voulu). A défaut, on a du prendre un développeur qui a beaucoup travaillé dans le domaine du fonctionnel qui nous intérese pour jouer le rôle du product owner. Un informaticien n'est pas le mieux placé pour jouer ce rôle. Il doit être tenu par un vrai utilisateur. Parce ce que là franchement ça ne marche pas !


Et pourquoi ? Parce que j'espère seulement que les vrais utilisateurs ne vont pas bouger leurs popotins à quelques jours précédant la release et nous fournir un feedback tellement conséquent qu'on sera obligé de travailler le week-end alors qu'ils avaient tout le temps de le faire à la fin de chaque itération. J'ai déjà vécu ça, c'est chiant et je suis sur que ça va se reproduire !!!


Quant à l'intégration continu que nous faisons, je ne sais même pas si on peut le nommer comme ça. Pour moi, l'intégration continu consiste à vérifier que le système fonctionne toujours comme prévu et qu'il n'y a pas de régression. Dans notre cas, ce n'est pas possible parce qu'il n'y a pas de tests ! Tous les efforts sont concentrés sur la normalisation du code (Des normes du genre : l'indentation doit être composé de quatre espaces). C'est peut-être intéressant mais ce n'est pas la priorité.


Il semblerait que ce soit bien de la rache qu'on fait. C'est dommage, moi je voulais faire de l'agile. Est-ce qu'on peut mettre sur son cv "j'ai travaillé sur tel projet à La R.A.C.H.E. pendant un an" ?


Heureusement, le projet devrait prendre fin à la fin de l'année (quoique je sais même pas si je vais survivre à ce projet). Je ne veux plus être impliqué à nouveau dans un projet de ce type. Mais comment et où peut-on trouver de vrais projets agiles ?


J'aurai aimé évangéliser l'agilité mais je me sens comme un borgne au royaume des aveugles. Il y a encore tellement de questions que je me pose encore sur l'agilité et la route me parait longue, mais tellement longue ! J'aurai préféré qu'un vrai Scrummaster le fasse.


Je suis développeur php et je sens que ça me limite. Je suis toujours restreint aux projets en PHP et quand je regarde les offres d'emploi en PHP, très peu d'annonces mettent l'accent sur l'agilité et c'est dommage.


Pourtant, je m'en fous du langage. Ce qui compte pour moi c'est découvrir l'agilité . Je souhaite m'ouvrir sur d'autres langages pour augmenter la probabilité de trouver un VRAI projet agile. J'en vois deux que je me sens capable d'utiliser :

- le Python (langage que j'adore). J'ai essayé Django en veille une fois et j'ai trouvé ça bien.

- le Java (autre langage que j'adore). Je l'ai appris en formation, jamais pratiqué parce que j'ai pas les 10 ans d'expérience requises. Je caresse le vague espoir que les développeurs Java sont plus expérimentés. En veille, j'ai essayé le framework Play ! et je l'ai adoré !


Mais comment faire pour convaincre des recruteurs qui sont toujours trop regardants sur l'expérience du langage utilisé ?

[Luckyluke34]

Mais comment et où peut-on trouver de vrais projets agiles ?

Quelques pistes :

http://www.express-board.fr/
http://emploi.developpez.com

Les sites traditionnels d'offres d'emploi , en faisant une sélection draconienne sur la cohérence du contenu de l'annonce (en général, exit les SSII).

Les salons et événements locaux sur l'agilité où tu peux te faire des connaissances et des contacts. Je pense aux Agile Tour qui vont bientôt commencer.

- le Python (langage que j'adore). J'ai essayé Django en veille une fois et j'ai trouvé ça bien.

- le Java (autre langage que j'adore). Je l'ai appris en formation, jamais pratiqué parce que j'ai pas les 10 ans d'expérience requises. Je caresse le vague espoir que les développeurs Java sont plus expérimentés. En veille, j'ai essayé le framework Play ! et je l'ai adoré !

Deux langages dans lesquels tu ne devrais pas avoir de mal à trouver des projets agiles. Ne pas hésiter à mettre en avant ton intérêt pour ces langages et mentionner sur ton CV toute expérience en lien avec eux. C'est vrai qu'on a tendance à "ghettoïser" les développeurs PHP, il va falloir que tu prouves que tu sais faire autre chose.

Mais comment faire pour convaincre des recruteurs qui sont toujours trop regardants sur l'expérience du langage utilisé ?

Ne pas hésiter à répondre à des annonces qui demandent plus d'expérience que tu n'as. Les profils décrits dans ces annonces sont souvent des moutons à 5 pattes que les recruteurs ne trouveront jamais. En revanche, quelqu'un qui n'a pas tous les prérequis techniques mais qui a une formation solide, la volonté d'apprendre et qui l'a prouvé de par des projets perso/open source, la participation à des événements développeurs, des formations, de la veille... a ses chances.

[el_slapper]

(.../...)Deux langages dans lesquels tu ne devrais pas avoir de mal à trouver des projets agiles. Ne pas hésiter à mettre en avant ton intérêt pour ces langages et mentionner sur ton CV toute expérience en lien avec eux. C'est vrai qu'on a tendance à "ghettoïser" les développeurs PHP, il va falloir que tu prouves que tu sais faire autre chose.(.../...)

Une excellent réponse. J'aimerais toutefois nuancer sur le Java. Il y a peut-être beaucoup de bons projets java en agile. Mais il y a certainement un paquet de projets pourris en java. C'est un langage tellement répandu qu'on y trouve absolument tout, du plus corporate au plus efficace.

Python, le chef aux cheveux pointus de base ne sait même pas que ça existe, le risque est plus faible. Le marché aussi...

[Luckyluke34]

Python, le chef aux cheveux pointus de base ne sait même pas que ça existe, le risque est plus faible. Le marché aussi...

Ca me rappelle un strip ça

[lolpapa]

Après une lecture attentive de ton poste et en accord avec les autres commentaires, je peux te certifié que tu ne travailles pas du tout sur un projet Agile.

J'ai un peu de connaissance en la matière pour avoir été Scrum Master sur plusieurs projets ( un vrai, pas un chef de projet d2éguisé en SM) et pour être aujourd'hui PO sur un autre.

L'agilité demande du courage et des gens motivé pour mettre en place un certain nombre d'étapes et de manières de faire.

Là t'as deux choix :
1 - Soit tu te sens un acteur du changement et tu prônes la bonne parole là-bas
2 - Soit tu cherches un autre équipe qui bosse vraiment en Agile ( si tu veux t'essayer à cette approche)

Une petite aide simple pour que tous comprennent ce qu'est Scrum, le rôle de PO (qui ne doit pas être technique) et celui de Scrum Master ( qui doit guider l'équipe dans les pratiques Scrum et les défendre)

Ce n'est pas une pub pour pour mon blog mais j'ai essayé d'y mettre des trucs pour mieux comprendre, alors je te les files et à toi de voir si ça te va et peux te servir :

Les commandements du PO : http://agileconcombre.blogspot.ch/20...-owner-tu.html
Les commandements du SM : http://agileconcombre.blogspot.ch/20...master-tu.html
Le survol du Scrum qui est une explication de texte de l'emboitemement de tous les éléments du Scrum : http://agileconcombre.blogspot.ch/20...-du-scrum.html

Ca pourra certainement leur faire du bien et en plus ... c'est cadeau ;-)

A+

[captaindidou]

Les méthodes agiles ne sont qu'une manière de tirer plus des développeurs avec moins de moyens humains.

Si les méthodes agiles étaient une bonne idée, depuis le temps qu'elles existent, elles investisseraient tous les secteurs d'activités économiques.

Hélas, le monde du développement logiciel, tout gonflé de vanité qui le caractérise, se plait à penser qu'il est un secteur de haute technologie. C'est parfois vrai lorsque la recherche de cette discipline trouve ses applications. Mais le plus souvent, faux. La thérapie génique, la technologie du semi-conducteur, la cybernétique, les télécoms, l'aéronautique, le nucléiare, etc ... sont des secteurs de haute-technologie. Pas java ni UML, ni les applications du web. Ce n'est pas parce que c'est innovant que c'est de la haute technologie.

Cela vaut pour les méthodes agiles. Certains informaticiens croient avoir trouver le graal de l'efficacité via ces méthodes alors que la plupart des concepts sont du réchauffé et le reste relève du snobisme... D'autres, plus cyniques, profitent de la vague en vogue pour en vivre. Tout flatteur vit aux dépens de celui qui l'écoute.

Il y a de quoi se bidonner lorsqu'on visionne les conférences de ces derniers, ces scrotum masters et autres coachs et leur blabla...

quand je pense que certains n'ont jamais été impliqués sur des projets de développement d'envergure en tant que développeur ... il y a de quoi sourire sur la vanité et le toupet en ce bas monde ... ou la fable de la grenouille qui voulait se faire plus grosse que le boeuf.

Pléthore de méthodes agiles, pour se démarquer de la concurrence, les uns ayant copié les autres.

Le jour n'est pas venu où vous embarquerez dans des avions dont les logiciels de vol auront été développés avec les méthodes agiles. Cela vaut mieux pour tous les petits scrum-masters indépendants qui courent l'hexagone en avion pour évangéliser et ramasser les dividendes.

[Bruno Orsier]

Difficile de voir ce qui vous pose problème avec les méthodes agiles...

Il y a déjà des développements dans l'aéronautique. http://sogilis.com/embarque/ pour faire de la pub à une start-up française, mais aussi le Département de la Défense US demande maintenant des développements agiles http://scrum.jeffsutherland.com/2012...oes-agile.html.

Il y en a dans tous les secteurs de l'activité économique... Cela s'appelle un peu différemment : Lean Thinking, agilité des organisations http://www.grenoble-em.com/696-insti...sations-1.aspx, ...

Bruno