« Agile est un cancer », pour Erik Meijer

« Agile est un cancer », pour Erik Meijer
qui estime qu’il doit être banni une fois pour toutes


Erik Meijer, un développeur célèbre de l’écosystème .NET, qui s’est notamment fait remarquer par la création de LINQ et ses travaux sur le langage C#, Visual Basic, Volta et le framework Reactive Extensions (Rx), a fait des déclarations acerbes contre Agile, lors d’un événement.

Les méthodes agiles sont de plus en plus adoptées par les équipes de développeurs. Elles se positionnent comme une meilleure alternative au cycle de développement en cascade, qui ne répond plus aux exigences des organisations qui évoluent rapidement. Elles sont donc considérées comme une recette pour accélérer le processus de développement, tout en réduisant le taux de bogues dans les applications.

Les méthodes agiles sont unies par le Manifeste agile qui doit son succès à la description de 4 valeurs essentielles, facilement compréhensibles pour les développeurs, à savoir :

• Les individus et leurs interactions priment sur les processus et les outils.
• Du logiciel qui fonctionne prime sur une documentation exhaustive.
• La collaboration avec les clients plutôt que la négociation contractuelle.
• L’adaptation au changement prime sur le respect des plannings.

Cependant, l’agilité ne fait pas l’unanimité auprès des développeurs. Lors d’une conférence en Finlande, Erik Meijer a eu des propos très durs envers Agile. « Agile est un cancer que nous devons éliminer de l’industrie », a déclaré celui-ci.

Meijer critique surtout le fait que l’application de l’agilité dans des projets fait « beaucoup plus parler sur le code, que d’écrire le code ». Erik Meijer s’en prend particulièrement à la méthode Scrum, qui entraine des « interruptions inutiles ».

Selon celui-ci, les « Scrum Meeting » sont des interruptions ennuyeuses, au mieux des mécanismes de contrôle subtil utilisés par les gestionnaires pour conduire une équipe, en donnant l’illusion d’un leadership partagé. « Nous devons cesser Scrum et Agile. Nous sommes des développeurs. Nous devons écrire du code », a affirmé Meijer.


Meijer continue sa diatribe en s’attaquant aux TDD. « C’est tellement ridicule. Pensez-vous que vous pouvez modéliser les échecs réels qui se produisent pendant la phase de production ? », s’est interrogé Meijer, avant de répondre. « Non. » Il préconise un cycle où le logiciel est déployé, et les erreurs fixées lorsqu’ils sont découverts.

Il faut noter que le créateur de Ruby On Rails, David Heinemeier Hansson, s’était aussi attaqué aux TDD, en affirmant que les tests unitaires n’étaient pas bénéfiques.

Au-delà de ces remarques, Meijer s’insurge également par rapport au fait que le terme « Agile » a été détourné et est désormais dénué de tout sens. Il a fini sa présentation en citant Dave Thomas, l’un des signataires du manifeste agile : « Le mot ‘Agile’ a été détourné au point ou il est devenu vide de sens. Et ce qui passe pour une communauté agile est devenu une arène pour les consultants et les entreprises qui veulent vendre leurs produits et services »

Sur ce point, il a été rejoint par un autre conférencier. Nic Ferrier architecte dans une entreprise de développement qui utilise Agile, a affirmé qu’Agile est en partie victime de son succès. Selon lui, lorsque les méthodes agiles ont conduit aux premiers bons résultats, les entreprises ont commencé à développer des outils qui prennent en charge ces méthodes. Dès lors, elles ont commencé à véhiculer l’idée qu’Agile est un outil que l’on peut acheter.

Un avis d’ Erik Meijer, certes tranché, mais qui reflète la frustration d’un passionné du code, qui souhaite par-dessus tout consacrer son temps à sa passion : écrire du code.


Source


Et vous ?

:fleche: Etes-vous d’accord avec le fait que le terme Agile a été détourné par les entreprises ?

:fleche: Que pensez-vous des déclarations d’Erik Meijer ? Pour ou contre ? Pourquoi ?

:fleche: Agile freine-t-il l’écriture du code ?

Je comprends sa réaction. Je me demande aussi s'il existe des études qui relèvent les méthodes agiles utilisées en entreprise et qui mesurent le taux de satisfaction client après la réalisation du produit ? Histoire de comparer ce qui se dit Agile, ce qui l'est en pratique et les résultats derrière.

Ce sujet tombe bien car je me demande de plus en plus quelque chose a propos d' Agile.

Est ce que cette methologie est devenue un autre bvuzzword parmi tant dautres dans l' ÍT ? comme ''Big data'' ou ''cloud'' ou ''virtualisation''

Je ne parle pas de ses bons / mauvais cotes , mais plus du fait que beaucoup de boites disent adopter et suivre ces methologies , mais en fait , connaissant la culture de certaines entreprises , je vois deja ce que cela donne avec les frameworks comme ITIL , Prince 2 ou Cobit dans la realite ou les bouquins , certaines boitent appliquent de maniere efficace tandis que dautres , en manque de perormances , recuperent un truc dont un font une grosse blague qui y ressemble vaguement , avec plein de gens pour se donner des titres pompeux alors quils ne font pas 1/3 du travail qui devrait etre fait.

Je me dis que beaucoup dequipes ne font que suivre ce que le manager a decide et qui souvent seloigne dagile et le travail final nen est pas plus qualitatif.

Car


Ais je tort ?

Il faut voir aussi de quelle manière les scrum masters de ces Mossieurs de "Microfault" gère l'Agile dans leur société.

D'une société à une autre, tout est différent. Partant des mêmes méthodes, méthodologies, outils, logiciels, ..., nous aurons deux résultats différents pour deux entreprises identiques. Savez-vous pourquoi ? Le facteur "humain" est ce qui fait varier le plus les choses.

Je considère qu'il est important de faire un minimum de réunion pour suivre l'évolution au jour le jour des tâches, user story, projets, produits...
Oui, il s'agit d'un leadership partagé dans l'équipe. Mais un leadership responsable qui suit son projet comme l'évolution et l'éducation de ses enfants. De manière responsable, engagée, avec amour et investissement.

Il faut arrêter de critiquer les méthodologies parce que les résultats ne sont pas là. Je trouve cela idiot de dire "on fait un produit" et seulement en phase de préproduction "on le teste ?!". Non ! Pour ma part, le TDD intervient pour réduire drastiquement les coûts liés à la correction de bugs.
Doit-on prévenir le mal en l'anticipant dès le départ, ou en l'ignorant jusqu'au dernier moment ?

Cela ne m'étonne pas que des échecs internationaux comme Vista et 8.1 on vu le jour s'ils ne testent qu'à la toute fin. S'ils avaient employé Agile de manière responsable et adaptée (d'où le nom Agile), ils auraient eu toute la souplesse de voir arriver que Vista était un Windows 98 de 7 Go lourd, moche et buggé ou même que l'interface Métro était un changement trop bouleversant pour une communauté de consommateurs habitué au bon vieux desktop.

Touche ironique pour terminer : "Laissons le soin aux consommateurs de tester notre application pour que les bugs remontent à nous ...". Oui, et la marmotte, elle met le chocolat dans le papier d'alu. Voilà pourquoi cela fait bien longtemps que je ne paie plus de licence pour des produits de ce genre. C'est fou que des entreprises se gangrenent par la flemmardise de corriger leurs bugs. Un commentaire de consommateur coûte-t'il moins cher qu'un fix anticipé pour un bug découvert en production et qui coûterait 1 M€ ?

Les méthodes agiles, pratiquées sérieusement et honnêtement, ça peut sans doute donner des bons résultats. Cela dit, je ne saurais être vraiment affirmatif : dans toutes les boites que j'ai pu voir où on prétendait faire de l'agile, ce n'était qu'un prétexte pour ne pas faire de specs, pour permettre à la maitrise d'ouvrage de changer constamment d'avis ("embrasser le changement", ok, mais en principe, c'est que le besoin a réellement changé, pas simplement que le client n'est pas foutu de savoir ce qu'il veut !), ne pas documenter le code, coder à l'arrache (KISS mal compris), etc.

Le problème de fond, c'est que les principes agiles mal compris permettent de justifier énormément de mauvaises pratiques ancestrales du monde informatique. Et ils ne s'en privent pas !

A chaque méthode ses défauts.

Personnellement j'ai rencontré plus de soucis avec les méthodes non Agiles en industrie, ou on ne corrigeait pas les bugs/lenteur non bloquant simples avant des mois.

Cela donnait des utilisateurs mécontent.

en gros ces histoires sont souvent liée au process ( Parfois une application non critique utilise les mêmes process de dev qu'une application vitale).

Il ne faut pas qu'un process lourd nuise à la qualité et la réactivité d'un SI.

De plus limiter le turn-over permet d'avoir des développeurs qui connaissent mieux leur contexte métier et l'entreprise, cela limite drastiquement les impacts, mais c'est sur en embauchant plus 70% de dev "jetables" c'est pas facile...


De plus Microsoft qui sort une beta de Visual Studio toute les 3 semaines doit surement utiliser beaucoup les méthodes agiles, et VS est plutôt bon.

Le problème, c'est que "Agile" est une manière de penser, pas une méthode.

Les gens qui n'ont pas cette manière de penser et qui appliquent la méthode, fatalement, ont de mauvais résultats.

Un autre cas peut être destructeur : certains dans la structure sont agiles, tandis que d'autres sont restés à l'ancienne méthode. Résultat, tout le monde doit se plier à l'agile sans être prêt, et on casse tous les projets(vécu).

Citation:

---

Ce sujet tombe bien car je me demande de plus en plus quelque chose a propos d' Agile.

Est ce que cette methologie est devenue un autre bvuzzword parmi tant dautres dans l' ÍT ? comme ''Big data'' ou ''cloud'' ou ''virtualisation''

---

Tu as malheureusement parfaitement raison. L'Agile est devenu un argument de vente, aussi bien en BTC qu'en BTB. Les SSII vendant des services Agile ne se compte plus, et j'ai pu voir en interne un chef d'équipe (particulièrement mauvais) faire passer l'échec de son projet sur le dos de la méthode de développement et ... TADA ! On passe en Agile et vous allez voir ce que vous allez voir ! (le projet fut bien évidemment un échec complet)

Mon avis personnel sur l'Agile est que cette méthode est une amélioration, une grosse amélioration, mais qu'une amélioration : si l'on a une équipe de bras cassés ou de personnes non formées ou peu impliquées, le projet sera un échec quelque soit la méthode employée.

@zaza576 : ton post est très intéressant, je me permets d'y répondre point par point.

Citation:

---

Il faut voir aussi de quelle manière les scrum masters de ces Mossieurs de "Microfault" gère l'Agile dans leur société.

---

A priori, je dirais par mal vu qu'ils doivent utiliser TFS qui est un excellent produit ! :P

Citation:

---

D'une société à une autre, tout est différent. Partant des mêmes méthodes, méthodologies, outils, logiciels, ..., nous aurons deux résultats différents pour deux entreprises identiques. Savez-vous pourquoi ? Le facteur "humain" est ce qui fait varier le plus les choses.

Je considère qu'il est important de faire un minimum de réunion pour suivre l'évolution au jour le jour des tâches, user story, projets, produits...
Oui, il s'agit d'un leadership partagé dans l'équipe. Mais un leadership responsable qui suit son projet comme l'évolution et l'éducation de ses enfants. De manière responsable, engagée, avec amour et investissement.

---

100% d'accord !

Citation:

---

Il faut arrêter de critiquer les méthodologies parce que les résultats ne sont pas là. Je trouve cela idiot de dire "on fait un produit" et seulement en phase de préproduction "on le teste ?!". Non ! Pour ma part, le TDD intervient pour réduire drastiquement les coûts liés à la correction de bugs.
Doit-on prévenir le mal en l'anticipant dès le départ, ou en l'ignorant jusqu'au dernier moment ?

---

Encore une fois, 100% d'accord. Le seul bémol, c'est qu'il faut faire comprendre ça à des gestionnaires / comptables / chefs de projet non techniques (genre parachuté / j'ai-vu-de-la-lumière-je-suis-rentré). Et là, c'est dans les faits quasi-impossible :(

Citation:

---

Cela ne m'étonne pas que des échecs internationaux comme Vista et 8.1 on vu le jour s'ils ne testent qu'à la toute fin. S'ils avaient employé Agile de manière responsable et adaptée (d'où le nom Agile), ils auraient eu toute la souplesse de voir arriver que Vista était un Windows 98 de 7 Go lourd, moche et buggé ou même que l'interface Métro était un changement trop bouleversant pour une communauté de consommateurs habitué au bon vieux desktop.

---

Autant je suis d'accord pour Vista, autant tu exagères pour 8.1 et Metro. Là, c'est plus une mauvaise orientation commerciale qui croyait trop au tout tactile (trop en avance sur son temps ?). De plus, Windows Phone 8.1 est une vraie réussite.

Pour ton dernier paragraphe, voir mon commentaire précédent sur les gestionnaires ! :(

Cette méthode aide énormément et je trouve que l'on devrait l'adopter à partir du moment où l'on fait du développement en équipe (plus de 1 développeur).

-J'ai un PO qui rédige des US parfaite (Mais au début ça n'était pas le cas, nous avons corriger le tir pour obtenir du PO ce que nous avions besoins pour développer c'est ça aussi la méthode AGILE, ce remettre en question)

-J'ai un SM qui sait ce faire oublier mais qui est là quand on a une question. On est un peu tous SM (Scrum Master je précise parce que je lis dans tes penses gros dégoutant) finalement dans l'équipe

-Le daily scrum du matin c'est bien mangés en ;-) franchement discuter tous les matins 2 minutes/personne des problèmes de la veille et des choses à faire dans la journée, je trouve qu'on gagne en clarté, en efficacité et sa force la cohésion d'équipe et l’entraide car si y'en a un qui galère sur un truc les autres sont force de proposition pour l'aider à trouver des solutions ou on peut aussi faire du "Pair programming" ce qui une fois de temps en temps ne fait pas de mal et permet de débloquer certaine situation ou/et aussi de former une nouvelle personne.

Bref j'ai développé pendant 10 ans tout seul et j'aimais ça.
Et maintenant ça fait 3 ans que je suis dans l'équipe à Gilles ;-)
Etant plutôt solitaire de nature je préfère développer en solo mais la vie ne nous laisse pas toujours le choix et finalement j'ai appris à aimer la méthode AGILE.

Donc merci à lui

Si sa passion c'est de pisser du code H24, grand bien lui fasse, mais je ne crois pas que ce soit de cette façon qu'on obtienne de bons logiciels.
La méthode Agile comme n'importe quelle autre a ses défauts, mais je ne comprends pas qu'on puisse reprocher aux développeurs de passer du temps à réfléchir sur leur code et à en discuter. Ca me parait bien mieux que de foncer tête baissée et d'avoir un codeur qui reste dans sa bulle.

Maintenant je le rejoins un peu sur les TDD, je ne comprends pas cette méthode de travail.

Erik Meijer, c'est le genre de personnes qui pour moi sont un cancer pour une entreprise.

J'ai vu ce que ça donnait les cycles en V. Plus jamais. A chaque fois, j'y ai vu un manque de respect pour l'utilisateur final des solutions. Car c'est un cadre qui n'est pas dedans qui va décider à sa place.

Au moins, dans l'agile, dès qu'on voit un bug, on le corrige. Dès qu'on a une question ou une remarque, on appelle la personne concernée, plutôt que de passer par 3 intermédiaires pour qu'au final la question se perde.

Le matin, on prend 5/10 minutes pour discuter avec le chef de projet pour indiquer où l'on en est, ce qu'on a fait, et parler de l'ordre du jour. Autrement c'est quoi ? Des chiffres dans un logiciel de BugTracking, des indicateurs abstraits ?

L'agilité est là aussi pour se corriger ou corriger rapidement le tir. Et je ne parle pas que pour les développeurs mais aussi pour les demandeurs, qui parfois aussi se plantent. Et elle n'empêche pas de faire de bonnes spécifications. Elle permet de les modifier rapidement c'est tout. Et après, on vérifie tout et donne (si elle n'y est pas déjà) une cohérence à tout ça.

Evidemment comme dit plus haut, "Agile" ne fait pas tout. Il faut que le personnel ait le concept "agile" dans la peau, qu'il soit impliqué dans ses projets, qu'il s'entende,... On peut se planter tout autant en "Agile" qu'autrement si l'équipe, et surtout son Chef, est mauvaise.

Bref, je m'arrête là, mais tout ce que j'ai fait en agile et forfaitaire a toujours beaucoup mieux fonctionné que les fameux trucs contractuel et figés. Je me suis d'ailleurs fait virer à cause d'une grosse baisse de charge due à des contractuels qui avaient mal anticipé la charge et les demandes...
Si on avait été en agile, on aurait au moins pu continuer à corriger des bugs, ajouter des fonctionnalités souhaitées par les utilisateurs au lieu d'attendre les ordres venant d'en haut (et qui ne sont pas venus...)

Peut-être qu'avec une méthode agile appliquée de façon efficace, on aurait pu éviter le bug de l'an 2000. Je suis sûr qu'il a dû être signalé dans plusieurs entreprises, dont les décideurs n'ont pas tenu compte...

Citation:

---

Envoyé par sebbod

Bref j'ai développé pendant 10 ans tout seul et j'aimais ça.
Et maintenant ça fait 3 ans que je suis dans l'équipe à Gilles ;-)

---

Donc si je comprends bien, en terme de méthodologie de développement en équipe, tu ne connais que Agile, tu n'as jamais vraiment pratiqué d'autre méthode de développement ? Si c'est le cas, tu peux effectivement donner ton retour d'expérience sur Agile, mais tu ne peux pas dire que c'est mieux, ou moins bien, qu'autre chose.

Pour ma part, j'ai connu une équipe avec un vrai bon chef, technique, qui a construit son équipe en choisissant les membres, et qui arrivait à vraiment en tirer parti, sans avoir besoin d'Agile.
Et j'ai aussi connu des équipes avec méthodologie mal ou pas appliquées, et dans ce cas ça vire toujours au n'importe quoi.

Mais à l'inverse de toi, je n'ai pas encore fait d'Agile, mais ça ne saurait tarder, donc je verrai bien ce que ça va donner. En tout cas, il est certain que c'est un argument commercial -- et si en plus l'entreprise du Big Data dans le cloud, tu as le tiercé gagnant dans l'ordre, et les commerciaux sont aux anges.

Je comprends plus ou moins les frustrations du mec.

Je pense que cette situation est similaire à celle où, on est entrain d'utiliser un outil/framework de dév, et que lorsqu'on rencontre des problèmes avec, on commence à le critiquer.

Parfois c'est pas l'outil qui fait défaut, mais notre façon d'intégrer et utiliser le truc qui nous fait souffrir.

Dans le cas de Agile, effectivement je pense qu'on lui attribut des descriptifs, des rôles, des responsabilités, des capacités et des pouvoirs qu'elle n'est/n'a/ pas/jamais.

Pour moi Agile n'est pas une méthodologie, n'est pas un standard, n'est pas un outil. Agile c'est un esprit/attitude/framework organisationnel, propre à chaque projet, et à chaque entreprise. par nature elle n'est pas standarisable car pas toujours forcément liée à des indicateurs ou données mesurables. C'est propre au contexte.

Un acteur peut paraitre ridicule si on lui demande de jouer un rôle qui n'est pas le sien. C'est le cas de Agile.

Citation:

---

Envoyé par gangsoleil

Donc si je comprends bien, en terme de méthodologie de développement en équipe, tu ne connais que Agile, tu n'as jamais vraiment pratiqué d'autre méthode de développement ? Si c'est le cas, tu peux effectivement donner ton retour d'expérience sur Agile, mais tu ne peux pas dire que c'est mieux, ou moins bien, qu'autre chose.

---

c'est effectivement le cas c'est pour cela que je ne fait qu'un retour d'expérience.

mais j'essaye d'appliquer la méthode AGILE à la maison pour parler au moins une fois par jour de ce qui va et de ce qui ne va pas avec ma compagne ce qui me fait 2 expériences avec la même méthode :mouarf:

Citation:

---

Envoyé par santana2006

Un acteur peut paraitre ridicule si on lui demande de jouer un rôle qui n'est pas le sien. C'est le cas de Agile.

---

Evidemment, mais normalement ça ne doit pas être le cas.

A part si tu es un vrai hargneux dans la vie, je ne pense pas qu'avoir la possibilité de demander aux clients des précisions sur ce qu'ils veulent ou les inviter à se poser des questions sur certains aspect n'est en décalage avec le rôle d'analyste programmeur. Pour les personnes moins à l'aise, elles peuvent tout d'abord en faire part à leur chef de projet ("SCRUM Master" pour les puristes) qui passe le coup de fil, en ta présence.

Quand on est "Ingénieur Etude et Developpement" à BAC + 5, je trouve très réducteur d'être réduit à l'état d'ouvrier qui pisse du code H24 comme dit précédemment. Et ça me plaît beaucoup de discuter avec les utilisateurs en live, pour m'adapter à leurs besoin, les satisfaire, ou leur faire part d'un besoin qu'ils n'ont pas anticipé.

On travaille sur un forfait. C'est à dire qu'on a des délais malgré tout !

Si on est passionné par son travail, tout le monde est gagnant. Le client paye une somme pour avoir le meilleur possible par rapport à sa demande, le "développeur" se sent plus concerné car il peut participer et moins frustré parce qu'il a le droit de corriger des bugs avant la prochaine version qui sera dans 2 ans, ou signaler des pb de specs.

Citation:

---

Envoyé par Hinault Romaric

:fleche: Etes-vous d’accord avec le fait que le terme Agile a été détourné par les entreprises ?

---

Oui, c'est devenu un terme marketing galvaudé.
Par contre, ce n'est pas l'Agile qu'il faut critiqué pour cela, c'est les entreprises.
Sur ce coup Erik Meijer se trompe de cible.

Citation:

---

Envoyé par Hinault Romaric

:fleche: Que pensez-vous des déclarations d’Erik Meijer ? Pour ou contre ? Pourquoi ?

---

Erik Meijer ne critique pas vraiment l'Agile, mais plutôt la façon dont il est mis en place dans la plupart des entreprises et je partage, sur cet aspect, plutôt son avis.
Par contre, je suis en total désaccord avec son expression "écrire du code"
Le job d'un développeur est bien plus que cela
Je dirai plutôt que je job d'un développeur est de concevoir et développer des fonctionnalités
Cela est bien plus large que se limiter à la phase de réalisation (l'écriture du code)
Les phases d'analyse et de conception sont ultra importantes et ne doivent pas être négligées

De plus, je ne partage pas du tout son point de vue sur les réunions d'équipe
Je trouve que c'est un point essentiel et il est important qu'une équipe se parle et se coordonne d'autant plus que ça peut créer une ambiance conviviale qui est bien plus agréable pour travailler.

Citation:

---

Envoyé par Hinault Romaric

:fleche: Agile freine-t-il l’écriture du code ?

---

Pas du tout
On écrit aussi vite que par les autres méthodes
Par contre, on écrit moins car on se pose plus la question du quoi et pourquoi
Je ne trouve pas que ce soit mal car on développe l'essentiel, le réellement utile

Partir bille en tête pour développer des dizaines et des dizaines de fonctionnalités pour qu'au final, seule une poignet sera utilisée, c'est déprimant et c'est du temps perdu pour rien
Autant concentrer les efforts sur le réellement utile pour l'utilisateur final.

Citation:

---

Envoyé par santana2006

Pour moi Agile n'est pas une méthodologie, n'est pas un standard, n'est pas un outil. Agile c'est un esprit/attitude/framework organisationnel, propre à chaque projet, et à chaque entreprise. par nature elle n'est pas standarisable car pas toujours forcément liée à des indicateurs ou données mesurables. C'est propre au contexte.

---

Le problème aujourd'hui, c'est que beaucoup d'entreprises veulent appliquer une méthode Agile comme on exécute une recette de gateau : on reproduit point par point ce qui a été fait à côté, avec un coach Agile bien sur, et hop, ça fait des chocapics (ou de la choucroute si on préfère).

Je ne vois que peu d'entreprises qui cherchent à voir quelle méthode appliquer (Scrum, XP, autre, peu importe), quelles sont leurs limites, pourquoi elles iront bien ou non, comment les équipes vont réagir, est-ce que ça s'applique à eux, ...

Prends une équipe dans laquelle il y a beaucoup de caractères forts et indépendants, et essaye d'imposer XP avec le codage à deux : il y a de fortes chances pour que ça passe mal, chacun voulant tirer la couverture à soi. De même, les réunions de 10 minutes le matin lorsque tu as des gens qui arrivent à 7h et d'autre à 10h, ce n'est pas forcément super productif...

Or c'est bien ce qui se passe dans la plupart des entreprises que j'ai vu.

Citation:

---

Envoyé par sebbod

mais j'essaye d'appliquer la méthode AGILE à la maison pour parler au moins une fois par jour de ce qui va et de ce qui ne va pas avec ma compagne ce qui me fait 2 expériences avec la même méthode :mouarf:

---

Et quand tu as oublie de faire la vaisselle , vider les poubelles ou sortir le chien tu fais un sprint ??

Citation:

---

Envoyé par Bono_BX

chefs de projet non techniques (genre parachuté / j'ai-vu-de-la-lumière-je-suis-rentré). Et là, c'est dans les faits quasi-impossible :(

---

La ou je suis jpasse jen ai vu plein des comme ca , manager , TL , ou CDP ( un mec qui en 6 ans de carriere change 4 fois de boites , passe un pseudo MBA et devient manager , un autre qui etait admin windows senior ya meme pas un an et est devenu manager dune quarantaine de personnes , un mec qui etait second dans un resto qui est reparti faire ses etudes et est devenu SDM , un mec du helpdesk qui en deux ans est devenu team leader et qui est passe manager car le manager sest fait vire etc ....... )

Mon prefere , cest mon ancienne TL , qui ne connaissait rien a exchange , je crois quelle bossait dans un kindergarden avant dentrer a ibm , elle a occupe un poste de quality analyst pendant un an avant detre mute au poste de team leader . Quand je lui ai demande en quoi consistait son poste de quality analyst , elle m'a repondu '' ben j'analysait la qualite " -> parachutage et copinage font bon menage chez bigblue

Du coup je me marre quand je vois les profils requis pour certains postes , et meme si je ne cale pas a 100% je tente quand meme car generalement ce poste sera surement file a un/une touriste , alors autant me le donner : quelqu un de motive sera a ce poste , ca me feras avancer ma carriere et au moins jaurais un challenge intellectuel .

Mon objectif pour les prochaines annees : apprendre a vendre du vent et faire de la politique

Citation:

---

Envoyé par Bono_BX

Mon avis personnel sur l'Agile est que cette méthode est une amélioration, une grosse amélioration, mais qu'une amélioration : si l'on a une équipe de bras cassés ou de personnes non formées ou peu impliquées, le projet sera un échec quelque soit la méthode employée.:

---

Ok , donc pour agile , cest pareil que de donner un piano Steinway a Kristina Hu (alias the UnsungHeroine) , Beethoven , David Guetta ou un Chimpanze , cela restera toujours un piano , avec lequels ils feront de la merde , du bruit ou un chef doeuvre

Citation:

---

Envoyé par Bono_BX

Mon avis personnel sur l'Agile est que cette méthode est une amélioration, une grosse amélioration, mais qu'une amélioration : si l'on a une équipe de bras cassés ou de personnes non formées ou peu impliquées, le projet sera un échec quelque soit la méthode employée.

---

Je suis entièrement de ton avis pour cela. Une méthodologie ne reste qu'une extension de soi-même pour accomplir une tâche et réussir un objectif. Comme un katana n'est que l'extension du bras d'un samouraï, et un outil pour en faire son métier.

Citation:

---

Envoyé par Bono_BX

Encore une fois, 100% d'accord. Le seul bémol, c'est qu'il faut faire comprendre ça à des gestionnaires / comptables / chefs de projet non techniques (genre parachuté / j'ai-vu-de-la-lumière-je-suis-rentré). Et là, c'est dans les faits quasi-impossible :(

---

Je te rejoins sur l'aspect commercial / financier / non technique / manageurial. Toutefois, des entreprises ont su surmonter ce point avec la "communication", compétence qui reste la seule richesse interne réelle sur laquelle toutes les teams / départements / services devraient compter. Quand un technicien A dit à un non-technicien B, je vous suggère d'utiliser le produit X car le produit Y coûte cher, est buggé, ne répond pas au besoin, B devrait aussi écouter A plutôt que de se baser que sur les déclarations d'autres non-techniciens. En quelques mots : confiance, écoute et communication. D'où l'utilité des réunions. Et pas seulement des réunions de MOE ou de MOA, mais aussi mêlant les deux afin d'avoir un avis le plus vaste possible. L'objectif étant de réduire les risques de faire dériver le projet de A à Z.

Citation:

---

Envoyé par Bono_BX

Autant je suis d'accord pour Vista, autant tu exagères pour 8.1 et Metro. Là, c'est plus une mauvaise orientation commerciale qui croyait trop au tout tactile (trop en avance sur son temps ?). De plus, Windows Phone 8.1 est une vraie réussite. Pour ton dernier paragraphe, voir mon commentaire précédent sur les gestionnaires ! :(

---

Ok, j'ai été un peu vache sur W8.1 sachant que s'était innovant mais totalement bête de proposer cette idée à un public trop fermé sur leurs anciennes habitudes de l'OS Windows. Encore une fois, un problème de communication de leur part qui leur a coûté un bras ?!

Les consommateurs, trop ancrés dans leurs habitudes, ne sont que peu enclins à accepter le changement technologique quand il s'annonce majeur / révolutionnaire ... (Preuve avec AngularJS v2, Windows 8.1 et son interface Metro, le framework Symfony v2 non rétrocompatible, ...).

Une souris et un clavier... tu leur retire cela, tu perds tes clients. Pourquoi ? Car la courbe d'apprentissage générationnelle d'un produit doit être progressive et s'intercaler avec les autres courbes d'apprentissages d'autres équipements / produits / logiciels / matériaux ...

Donne une kalash' à un enfant de 5 ans et il t'en fera un petit train ...

Citation:

---

Ok , donc pour agile , cest pareil que de donner un piano Steinway a Kristina Hu (alias the UnsungHeroine) , Beethoven , David Guetta ou un Chimpanze , cela restera toujours un piano

---

Ha non, il faut comparer ce qui est comparable, et ne pas déformer ce que j'ai dis (en plus, je suis un ancien pianiste :massacre: ).
La méthodologie ne fait ni l'application, ni le développeur ; exemple, le mien actuellement : je suis obligé de travailler (pour des raisons comptables et de choix du client :calim2: ) sur un site PHP, alors que je ne connais pas ce langage ; je fais ce que je peux, mais je n'ai pas les connaissances nécessaires pour faire du bon travail (par exemple du code bien optimisé, je ne peux faire que du code très basique). Et là, agile ou cycle en V, la méthode ne m'apportera pas les connaissances. Je gonfle mes chiffrages afin d'inclure le temps d'auto-formation, mais c'est tout.
Ton analogie est toutefois intéressante : sais-tu que Debussy aimait jouer sur des pianos de différentes qualités, parfois assez délabrés ou non accordés, car cela faisait parti de leurs histoires et leurs donnait un son différent ?