« Agile est un cancer », pour Erik Meijer

Bonjour,

Citation:

---

Envoyé par kilroyFR

a/ les equipes auto gerées se generent aussi d'elles memes du boulot (l'agilité se traduit souvent par un refus de tout ce qui ne provient pas de l'equipe ! c'est plutot de la rigidité).

b/ lorsqu'un client exprime un besoin (ex: technique), l'equipe de dev en fait souvent plus (et donc deroule des heures pas forcement vendues). Un peu comme si c'etait un test technique qu'il fallait relever. resultat vecu : on nous demande d'implementer une interface selon 2 protocoles => au final 5 protocoles techniques sont implementés (derive des devs qui se sont faits plaisirs). Le client est content certes car on lui en donne plus que prevu; par contre nous on bouffe la culotte en consommant des heures non vendues.

---

Ce n'est pas parce que vous appliquez mal agile que la méthode est pourrie.

Pour la demande client, il est normal, et même souhaitable, que l'équipe se pose la question suivante : est-ce utile prendre un peu plus de temps pour faire une interface générique qui nous permettra de supporter d'autres protocoles ou non. Si la réponse est oui, alors il faut l'implémenter.
Mais ça ne veut pas dire implémenter d'autres protocoles.

Ont-ils livré dans les temps, et en respectant les coûts ? Si oui, pas grand chose à redire. Si non, il faut analyser pourquoi, et corriger.

Citation:

---

Envoyé par gangsoleil

Ce n'est pas parce que vous appliquez mal agile que la méthode est pourrie.

---

+1.. Et c'est là que beaucoup d'équipes se vautrent. Mettre en place un backlog, des sprits et des daily ne suffit pas à faire de l'agilité... L'agilité est à la base, des concepts. En découle des méthodes et des outils pour valoriser ces concepts. En théorie, deux équipes différentes ne peuvent appliquer strictement la même méthode suivant les affinités des membres de l'équipe, des clients, des projets..

Beaucoup se leurrent dans l'idée qu'appliquer la méthode scrum permettra rapidement à être plus performant. L'agilité est un état d'esprit, une manière d'aborder les projets.

Citation:

---

Envoyé par kilroyFR

<zip>

---

Je ne vois rien d'inputable aux méthodes agiles dans tout ça.

Agile préconise au contraire une collaboration quotidienne avec le demandeur métier responsable du retour sur investissement du logiciel. C'est à peu près l'inverse de "les devs font ce qu'ils veulent".

Sur l'aspect "jouer avec des technos" et le turnover, ça peut arriver sur n'importe quel type de projet.

Pour le TDD je suis en désaccord complet, pour le reste ce monsieur a plutôt raison. L'agile mal appliqué est un cancer.

Citation:

---

Envoyé par -

Pour le TDD je suis en désaccord complet, pour le reste ce monsieur a plutôt raison. L'agile mal appliqué est un cancer.

---

Peu importe la la méthode et le sujet, lorsque c'est mal appliqué, c'est le bordel.
Du coup, on peut écrire exactement le même type d'article à propos des travers du cycle V est d'une application merdique de celui-ci.

Citation:

---

Envoyé par Saverok

Peu importe la la méthode et le sujet, lorsque c'est mal appliqué, c'est le bordel.
Du coup, on peut écrire exactement le même type d'article à propos des travers du cycle V est d'une application merdique de celui-ci.

---

Les énormes travers du V ?
Les effets Tunnel avec les MOA qui jouent de la balalaika avec les utilisateurs, livrent leurs specs la veille de la mise en recette mais "on repousse pas la MEP".
Les MOA qui veulent pas entendre parler de "lignes", "colonnes", "fonctions" car "je suis pas technique"
Les chefs de projet qui oublient de prendre en compte des contraintes commes des livraisons de serveur
Les équipes de production qui se sentent mal-aimées des développeurs et vice et versa.
Les développeurs geek qui oublient qu'on développe par pour faire du code, mais pour créer des fonctionnalités qui seront utilisées par des utilisateurs, à terme.

Et vous savez quoi ? Des problèmes surviendront aussi en agile tant qu'on n'arrivera pas à communiquer entre équipes.

Il ne faut pas confondre TDD et les tests unitaires, au sens classique, qui eux sont indispensables car ils servent à mesurer le pourcentage de couverture du code.
Ecrire des tests unitaires avant d'écrire le code est tout simplement de la foutaise.