Le problème avec les buzzwords, c'est qu'il y a une manière perverse de les employer non pas pour populariser et répandre les idées qu'ils désignent, mais comme argument conclusif de discussion pour convaincre un décideur ou un groupe d'adhérer à quelque chose de tout à fait différent. Par exemple :
"Mes chers amis, en tant que chef de projet j'ai une bonne nouvelle : Nous allons pratiquer la nouvelle méthode Agile de développement.
Je n'ai pas besoin de vous expliquer Agile, il y a la wikipedia pour ça.
Bien entendu, dans un premier temps et pour respecter les deadlines, nous allons nous contenter de certaines pratiques et exclure les choses qui font perdre du temps inutilement comme le codage par pair (pas besoin de mettre 2 personnes sur un même code) et les tests automatisés (on ne va pas perdre du temps à installer et écrire une suite de test, je vous fais confiance pour faire du bon code qui marche du premier coup n'est-ce pas ?) et plutôt que de faire du refactoring, on va bien concevoir notre architecture de classe dès les début pour prévoir tous les cas.
Oh, et aussi, toutes les communications avec le client passent par moi, et le cahier des charge, les specs fonctionnelles et les specs techniques ont été établies préalablement par un cabinet de consultant.
[^] # Re: Rire jaune
Posté par Bastes . En réponse au journal Linuxfr en J2EE. Évalué à 10.
"Mes chers amis, en tant que chef de projet j'ai une bonne nouvelle : Nous allons pratiquer la nouvelle méthode Agile de développement.
Je n'ai pas besoin de vous expliquer Agile, il y a la wikipedia pour ça.
Bien entendu, dans un premier temps et pour respecter les deadlines, nous allons nous contenter de certaines pratiques et exclure les choses qui font perdre du temps inutilement comme le codage par pair (pas besoin de mettre 2 personnes sur un même code) et les tests automatisés (on ne va pas perdre du temps à installer et écrire une suite de test, je vous fais confiance pour faire du bon code qui marche du premier coup n'est-ce pas ?) et plutôt que de faire du refactoring, on va bien concevoir notre architecture de classe dès les début pour prévoir tous les cas.
Oh, et aussi, toutes les communications avec le client passent par moi, et le cahier des charge, les specs fonctionnelles et les specs techniques ont été établies préalablement par un cabinet de consultant.
Messieurs, au travail."