Discussion :

[gangsoleil]

Je suis entierement d'accord avec toi, a un detail pres :

Ce raisonnement illustre toute la difficulté qu'on a aujourd'hui à penser "hors du cadre". L'agilité ne marche pas si on reste dans le cadre contractuel et de gestion de projet traditionnel que tu sous-entends puisqu'elle consiste précisément à dépasser ces contraintes classiques.

Mon soucis, c'est que la hierarchie (le haut-management comme on dit) n'est pas pret a lacher tout ca, du moins pas dans les boites que j'ai vu. SSII ou pas, il y a plein de suivi dans tous les sens (pourri le plus souvent), avec des remontees d'informations pourries, de mauvais echanges, des ecrans de fumee a chaque etage, des reunions inutiles,... tout ce que tu veux, mais l'argent coule a flot (enfin suffisamment pour que les hauts gradés soient content). Et comme on sait ce qu'on quitte mais pas ce qu'on aura, ils veulent bien faire de l'Agile (buzz-word) tant que tu veux, vendre cette Agilité aux clients, faire 2 changements pour les grouillots de base, et c'est tout. Pas question de lacher du pouvoir, deleguer (ouh le vilain mot), ne plus pouvoir se retourner contre quelqu'un (ni coupable ni responsable), ...

C'est malheureusement ce que je vois. Je ne dis pas que c'est pareil partout, mais j'ai l'impression que c'est ce qui se dessinne actuellement : on applique Agile/Scrum parce que c'est a la mode et que c'est vendeur, mais surtout sans rien changer au dessus, ce qui ne peut pas fonctionner. Et on obtient un truc pourri qui ne fonctionne pas. Mais comme l'equipe technique est celle qui se fait taper dessus en cas de probleme, elle se debrouille pour que ca fonctionne quand meme.

[el_slapper]

+1 avec la dernière intervention de Gangsoleil.

Mais je la reformulerait autrement(parceque j'aime revenir à la théorie, parfois) : c'est une question de pouvoir. Entre le pouvoir et l'efficacité, voire entre le pouvoir et l'argent(qui vient de l'efficacité), le décideur aura une tendance lourde à choisir le pouvoir. C'est parceque je préfère l'efficacité que je me suis attiré des inimitiés à droite-à gauche.

Le concept d'agile, c'est que le produit est issu de la collaboration entre le grouillot du client(interne ou externe) et le grouillot de l'équipe de dev(SSII ou interne). Le concept classique, c'est que les grands chefs règlent leurs comptes entre eux, et que la piétaille doit suivre. Sans renacler. Aveuglément. Et qu'elle est forcément coupable si elle marche dans une ornière creusée par les grands chefs.

Imaginons que je sois grand chef. Qu'est-ce qui serait le plus confortable pour moi? Laisser les grouillots faire en priant pour que ça marche, ou décider tout seul et mener ce petit monde à la baguette?

[xelab]

Imaginons que je sois grand chef. Qu'est-ce qui serait le plus confortable pour moi? Laisser les grouillots faire en priant pour que ça marche, ou décider tout seul et mener ce petit monde à la baguette?

En fait c'est les 2, mais dans cet ordre: "décider tout seul, mener ce petit monde à la baguette et laisser les grouillots faire (= se démerder) en priant pour que ça marche".

[souviron34]

Ceux qui me connaissent savent que j'ai déjà exposé mon point de vue à de nombreuses reprises mais je vais recommencer spécifiquement sur ce thread, pour une fois

Mais alors pourquoi cet échec ? Une dérive, une incompréhension ou encore un abus serait à l’origine de l’échec, selon celui-ci.

Agile est en premier lieu un état d’esprit mettant au centre de la scène le développeur,

Ceci est totalement faux

Agile est en premier lieu un état d'esprit mettant au centre des humains... que ce soit le développeur, le chef, le client, les analystes, la hiérarchie... ce n'est pas plus centré sur le développeur que le client ou ce qu'on veut...

De plus, comme je l'ai mentionné à de nombreuses reprises, Agile est effectivement un état d'esprit et PAS une méthodologie.. La tendance informatique à tout vouloir mettre sous forme de processus, de méthodologie, est ANTINOMIQUE de l'agilité (Scrum, XP, Rup, etc sont des aberrations par rapport au Manifeste).

Les rôles par exemple, je l'ai déjà dit aussi de nombreuses fois, sont - au vu des offres d'emploi et des définitions qu'on peut trouver des compétences - considérés comme des GRADES ou des titres, alors qu'en fait le terme est bien un ROLE....


Sauf que cet état d'esprit ne peut PAS s'obtenir sans que les gens concernés s'estiment, soient déjà pas mal pros dans leurs domaines respectifs.... Je l'ai déjà dit, l'Agilité concerne normalement des gens EXPERIMENTES.... En informatique comme dans la menuiserie ou le batiment ou la conduite de navire ou d'avion, c'est PARCE QUE les gens sont expérimentés qu'ils peuvent se passer des règles strictes : quand le pilote a fait poser son avion sur l'Hudson il y a quelques années, il avait débranché le pilote automatique, qui lui disait que l'avion se crasherait. C'est parce que il était excellent qu'il a pu le faire et poser l'avion en douceur.

C'est la même chose.. Là on l'a appliqué à toutes les sauces, comme un remède miracle, avec n'importe qui, dans n'importe quel contexte, en figeant les dynamiques et produits ou étapes, etc, ....

ça me met en rogne (réellement) quand je vois les gaspillages et les abêtissements qu'on fait de choses pourtant simples (mentionnées dans la première page : le bon sens)...


Donc les raisons de l'échec (si échec il y a) est d'avoir voulu en faire des méthodologies, encadrer la pratique alors que le Manifeste est totalement vague (à dessein), l'appliquer à n'importe qui alors que c'est fait pour des gens expérimentés (regardez la carrière des auteurs du manifeste au moment où ils l'écrivent), et enfin figer des grades au lieu d'avoir des équipes dont les rôles évoluent au cours du temps.. Mais tout ceci suppose d'avoir confiance , d'avoir des gens qui s'estiment chacun dans leurs rôles, et donc des gens TOUS compétents et pas remis en cause par les critiques éventuelles des uns ou des autres.. En gros, tout le contraire de ce qui se fait généralement, et encore plus en France...



Bon, ma rogne ne dure pas, mais quand même, ce que je m'évertue à longueur de threads ici ou dans la section Débats à proclamer, c'est que c'est tout ce qu'on veut SAUF une méthodologie....

Une méthode de travail n'est pas une méthodologie, et elle dépend de chacun... Mais si on a affaire à une équipe d'experts dans leurs domaines, chacun a sa méthode, et les liaisons et/ou décisions et/ou synchronisations se font de manière "évidente"... Sur d'autres threads je me suis fait traiter d'élitiste pour dire ça.. Et bien oui..... Vous laisseriez pas votre vie dans un 747 aux mains du mec qui fait le tour de son aérodrome le dimanche, ni conduire une F1 au gars qui n'a fait que rouler sur le périph à 70, ou dans sa campagne pour aller faire ses courses... Ben c'est pareil... C'est fait pour les pros, et même les BONS, voire uniquement les EXCELLENTS pros...


Mais ça ça a du mal à passer dans une société où on proclame que tout le monde peut tout faire, et que en particulier tout le monde est bon... et doit avoir des diplômes...

[el_slapper]

(.../...)Mais ça ça a du mal à passer dans une société où on proclame que tout le monde peut tout faire, et que en particulier tout le monde est bon... et doit avoir des diplômes...

D'accord avec tout le reste(encore que j'ai vu des débutants sauver des projets plantés par des mecs ayant 10 ans de bouteille, mais passons). Mais ça, et fait, je ne suis pas tout à fait d'accord. L'important n'est pas que tout le monde puisse tout faire en suivant le petit manuel(ça, c'est juste une conséquence). L'important est que chacun reste à sa place(ça, c'est la cause).

Quand tu parles d'expertise - technique ou fonctionnelle - ça n'a de sens que si les experts ont un pouvoir de décision. Or ils ne l'ont pas. Les grands chefs préfèrent des drones photocopiés qui transmettent aveuglément les ordres, et des grouillots tout aussi photocopiés qui les appliquent aveuglément. C'est plus confortable pour eux. Imagine : si un "expert" prend une décision, ils pourraient être amenés à l'expliquer devant le conseil d'administration alors qu'ils ne connaissent même pas le sujet! L'angoisse. Il est bien plus confortable(et bien moins efficace, mais ils ne sont pas payés pour être efficaces) d'avoir une chaine de commandement de type militaire qui applique la méthodologie garantie par le comité théodule qui ne peut échouer que si les exécutants ont failli.

A ce titre, l'application bête et méchante d'une méthodologie(agile ou pas) par des diplomés(talentueux ou pas) n'est qu'une conséquence, pas une cause. Quand on veut faire du travail sérieux, on est agile dans le choix de la méthodologie. On fait du waterfall là ou ça a un sens(le réglementaire et certaines migrations techniques), du XP là ou c'est pertinent(besoin fonctionnel complexe, changeant, et besoin de faire monter en compétence les développeurs), du cowboy là ou c'est pertinent(un truc jetable, à utiliser une fois dans trois jour, puis plus jamais), du mathématiquement prouvé là ou c'est pertinent(le pilotage d'une sonde spatiale).....

Mais c'est quand on veut faire du boulot sérieux, ça. Si on cherche juste à monter les échelons de la Grande Compagnie, alors la "méthodologie" agile, appliquée par des robots au cerveau délavé, très à la mode, convient parfaitement.

[Luckyluke34]

De plus, comme je l'ai mentionné à de nombreuses reprises, Agile est effectivement un état d'esprit et PAS une méthodologie.. La tendance informatique à tout vouloir mettre sous forme de processus, de méthodologie, est ANTINOMIQUE de l'agilité (Scrum, XP, Rup, etc sont des aberrations par rapport au Manifeste).

Je suis d'accord et pas d'accord. Les créateurs des deux premières méthodes que tu cites, et d'autres, faisaient partie des signataires du manifeste agile. Il me parait hasardeux de dire qu'ils auraient contribué à la création d'un texte considérant leurs propres process comme des aberrations. La volonté était plutôt de trouver un cadre commun à des méthodologies certes légères (lightweight) mais il s'agissait bien de méthodologies.

Il est vrai que, pris tel quel, le manifeste agile est un peu comme une classe abstraite : une liste de valeurs et principes pas implémentés. Mais l'étape suivante consiste à choisir des pratiques, une discipline, une méthode et ce n'est pas antinomique de l'agilité, c'est juste la suite logique. L'agilité ne dit pas "pas de process ni d'outils", elle dit "les humains et les interactions avant les process et les outils".

Concernant l'excellence technique, même si c'est un constat que tu fais et que je suis par ailleurs d'accord que c'est une des clés du succès, il n'y a rien dans l'esprit du manifeste agile qui en interdise l'accès aux débutants. On parle plutôt d'individus motivés et l'accent est mis sur l'amélioration continue. Après tout, un expert est juste un ancien novice qui n'a cessé de progresser.

[souviron34]

Quand tu parles d'expertise - technique ou fonctionnelle - ça n'a de sens que si les experts ont un pouvoir de décision.

Mais il me semble que cela va de pair avec le Manifeste...

Quand on veut faire du travail sérieux, on est agile dans le choix de la méthodologie.

Non justement, je crois que là tu te trompes... Le fond de tout dév est du cycle en V... (et c'est justement à mon avis l'erreur majeure de la mode Agile et de ce qui s'en est suivi d'ignorer consciemment ou inconsciemment, ceci)..

Quand on veut faire du travail sérieux, on pense cycle en V, et on arrondi les angles / on shunte telle ou telle partie...

L'agilité consiste justement à se passer de telle étape, de telle hiérarchie, de tel document, mais tout en gardant en mémoire la manière "normale" (cycle en V) dont ça devrait se passer..

C'est à mon avis la raison principale de l'échec constaté par cet article... (et il suffit de voir des commentaires réguliers de participants à ce forum) : on a confondu agilité avec "nouveau", et souvent "la rache"...


Et c'est aussi la raison pour laquelle c'est à mon avis réservé à des expérimentés (au minimum au niveau des pivots essentiels) : il faut dominer son sujet (le cycle) pour pouvoir le court-circuiter quand on le souhaite/peut...

Je suis d'accord et pas d'accord. Les créateurs des deux premières méthodes que tu cites, et d'autres, faisaient partie des signataires du manifeste agile. Il me parait hasardeux de dire qu'ils auraient contribué à la création d'un texte considérant leurs propres process comme des aberrations. La volonté était plutôt de trouver un cadre commun à des méthodologies certes légères (lightweight) mais il s'agissait bien de méthodologies.

Je crois qu'ils se sont pris à leur propre jeu travaillant dans un milieu qui ne reconnait pas l'individualité, ils se sont dit que il fallait que, au delà du Manifeste, il ressorte quelque chose à appliquer à "tous", un "manuel"..

Mais c'est en gros en contradiction avec le fond de leurs constats et recommandations..

Concernant l'excellence technique, même si c'est un constat que tu fais et que je suis par ailleurs d'accord que c'est une des clés du succès, il n'y a rien dans l'esprit du manifeste agile qui en interdise l'accès aux débutants. On parle plutôt d'individus motivés et l'accent est mis sur l'amélioration continue. Après tout, un expert est juste un ancien novice qui n'a cessé de progresser.

Je suis d'accord avec toi, mais cependant le dernier point de ma réponse à el_slapper devrait éclairer mon point de vue : on ne peut se passer des guides QUE lorsqu'on possède suffisamment son métier pour pouvoir le faire..

Or là on s'occupe du développement d'un logiciel, et de son cycle de vie... Un novice n'a par définition pas la vraie "possession" de ce qui est entraîné par telle ou telle étape, de ses écueuils, de ses forces ou de ses faiblesses, ni, de même, de l'importance relative à accorder à telle ou telle critique, à telle ou telle requête hiérarchique... Il n'aura de plus pas de poids ni de légitimité pour faire avancer son point de vue , voire tenir tête ou dire non, à ses niveaux supérieurs. Ce qui est pourtant fortement implicite dans le Manifeste, où les délais ou priorités ou parties mises en service ne seront pas forcément dans l'esprit/la planification des instances supérieures...

Dans un des projets dans lequel j'ai travaillé, il m'a fallu aller faire 5 présentations successives, 5 mois d'affilée, au Conseil d'Administration, il m'a fallu me faire virer pendant 1 mois 1/2, puis de nouveau 3 présentations au CA... Simplement parce que je refusais de me plier aux exigences "traditionnelles"...

C'est strictement impossible à faire si tu es novice. Et là j'étais CP. Mais c'est la même chose en fonction du "découpage en compétence" de l'équipe... Si le mec qui s'occupe de la BD est novice, ou celui qui s'occupe de l'IHM, ou celui qui s'occupe des algos, il aura du mal à faire accepter un choix technique qui impacte les autres...

Il y a donc d'une part une certaine "expertise" ou "expérience" à avoir pour que son avis soit pris en compte, et deuxièmement une certaine expérience à posséder pour que, par exemple, le mec qui s'occupe de la BD puisse se passer de faire une conception détaillée, ou bypasser une étape de tests, ou de doc... : car pour ça il faut qu'il soit au courant de ce qu'il devrait faire NORMALEMENT...

[el_slapper]

Mais il me semble que cela va de pair avec le Manifeste...

Certes, mais ça n'est presque jamais appliqué. A chaque fois que j'ai utilisé mon expertise, j'ai du le faire CONTRE l'organisation. Et j'en ai fait quelques unes

Non justement, je crois que là tu te trompes... Le fond de tout dév est du cycle en V... (et c'est justement à mon avis l'erreur majeure de la mode Agile et de ce qui s'en est suivi d'ignorer consciemment ou inconsciemment, ceci)..

Pas toujours. Quand le client ne sait pas ce qu'il veut, le plus efficace, c'est de tenter un truc, et d'attendre la réaction. Ca m'est arrivé plusieurs fois. Ca marche bien. Mais, évidemment, il faut que le contexte s'y prête.

Quand on code une nouvelle interface, le client, généralement, ne parvient pas à imaginer ce que ça peut lui apporter. Alors il affabule. Ca n'est aps de sa faute - il est humain, après tout. Par contre, quand il peut manipuler, son imagination ne tourne plus à vide, et il commence à faire des remarques pertinentes. Après un nombre raisonnable de cycles(souvent 20 ou 30), on a des produits vraiments optimisés. Ca n'a rien de cycle en V, c'est du pur itératif, le feedback d'un développement est la spec du développement suivant. Et ça peut aller jusqu'à 9 versions en un seul samedi.

Après, dans de nombreux cas, ça ne s'applique pas. Mais, parfois, c'est très, très efficace. Et pour moi c'est ça, l'agile : on a besoin d'itératif? De waterfall? D'autre chose? eh bien pas de chichis, on prend ce dont on a besoin.

Quand on veut faire du travail sérieux, on pense cycle en V, et on arrondi les angles / on shunte telle ou telle partie...

C'est vrai souvent. Mais pas toujours.

Par contre, connaitre chacun des systèmes est un gros plus. Pour avoir fait un peu des deux, et un peu de rache aussi, je pense avoir assez de recul pour choisir le plus adapté.(NB : la rache ne convient que si la spec complète tient en un phrase ou deux, et n'a pas de complication technique). C'est sans doute là ou l'expertise, dont tu parles tant, est utile.

L'agilité consiste justement à se passer de telle étape, de telle hiérarchie, de tel document, mais tout en gardant en mémoire la manière "normale" (cycle en V) dont ça devrait se passer..

pas seulement, mais c'est effectivement essentiel de savoir faire ça quand le cycle en V s'impose.

C'est à mon avis la raison principale de l'échec constaté par cet article... (et il suffit de voir des commentaires réguliers de paticipants à ce forum) : on a confondu agilité avec "nouveau", et souvent "la rache"...(.../...)

ouéééééé!!!! pas de speeeeeecs!!!! tu as hélas 100% raison sur ce point-là.

[Luckyluke34]

L'agilité consiste justement à se passer de telle étape, de telle hiérarchie, de tel document, mais tout en gardant en mémoire la manière "normale" (cycle en V) dont ça devrait se passer..

Pour moi l'agilité n'est pas un cycle projet traditionnel dans lequel on court-circuiterait quelques étapes parce qu'on est très fort, tout en se flagellant de ne pas avoir suivi le dogme.

L'agilité, c'est un autre état d'esprit : aller au plus simple qui fonctionne (cf les concepts de minimum viable product, YAGNI, KISS...) en gardant en mémoire la manière "toutes options" dont ça pourra se passer si le client choisit le mode "toutes options".

C'est simplement du bon sens : éviter de gaspiller du temps à faire des tâches inutiles juste parce que c'est la manière "normale" dont on a toujours fait les choses. Ca finit par venir naturellement, on ne se pose pas la question "est-ce mal de sauter l'étape X ?" mais "OK, on a fait le minimum qui fonctionne, maintenant serait-il bien d'ajouter l'étape X dans le prochain incrément ? // Oui, car le client le veut // Non, car on a découvert entretemps Y, Z et K qui nous prouvent que X n'était pas pertinent."

[souviron34]

Si tu veux, mais justement moi qui suis un parfait adepte du KISS, j'avoue que pour un truc industriel j'aurais beaucoup de mal à pouvoir l'imaginer et le faire si je n'avais pas à la base une bonne matirise de ce que sous-tend le modèle en V....

Et que ça dérive - ou peut dériver très vite - vers "la rache" ou "le brouillon" ou "le grand n'importe quoi"... si on ne l'a pas...

Et personne n'a dit qu'on se flagellait au contraire.. On se félicite d'avoir court-circuité telle étape, telle hiérarchie, tel pbe (ne serait-ce que les tests à la fin ou l 'impossible remise en cause d'une décision ou analyse ou morceau d'architecture)


Il ne faut pas négliger le fait que le cycle en V est du bon sens, à la base.. Simplement découpé en fines lamelles, et figé dans le béton... de la bonne et pure logique..Trop formalisé et formel, mais néanmoins du "gros bon sens"..

C'est en ça que c'est extrêmement utile de le connaitre : c'est normalement la base. Simplement l'agilité consiste à sauter des étapes quand c'est jugé pas important, à en faire en parallèle ou en concurrence, à cycler beaucoup plus vite, sur des parties théoriquement non cyclables (l'analyse et la conception préliminaire) : c'est ce qui permet de faire KISS tout en garantissant un produit de qualité...

Enfin, c'est ce que je pense, hein ?

[Njörd]

Bonjour,

J'ai beaucoup de mal à comprendre d'où vient ce mythe que le manifeste agile dit ne pas avoir besoin de faire des spécifications.
Il est clairement dit que l'on met les hommes avant les spécifications, ça ok. Mais à aucun moment il n'est écrit qu'on ne doit pas en faire.

De mon point de vue, l'étape d'analyse à chaque itération doit se solder par un document ou plusieurs documents validés et signés par l'ensemble des parties aussi bien le client que le CP. Le seul fait de poser par écrit ce que l'on souhaite avoir et débattre de cet écrit suffit déjà à amener une réflexion de la part de tout le monde pour nourrir le besoin réel du client. Ainsi, à la fin de chaque itération, on valide cette fois-ci une ou plusieurs fonctionnalités développées et on choisit de les améliorer si besoin.

La difficulté à ce niveau, c'est de bien impliquer le client afin qu'il n'abuse pas de ce pouvoir de modification. Je pense que c'est également au CP de "former" le client aux contraintes qu'il peut y avoir lorsque l'on fait de gros changements sur une application. Mais ça, quand c'est un commercial qui est chargé de la relation avec le client, c'est beaucoup plus difficile à avoir. De même, si on a affaire à un client buté qui ne veut pas s'impliquer. Dans ces cas là, autant rester en cycle V avec spécifications bien lourdes et bien chiantes vu que ça correspond à la vision projet du client.

[gangsoleil]

J'ai beaucoup de mal à comprendre d'où vient ce mythe que le manifeste agile dit ne pas avoir besoin de faire des spécifications.
Il est clairement dit que l'on met les hommes avant les spécifications, ça ok. Mais à aucun moment il n'est écrit qu'on ne doit pas en faire.

Oui, mais la, tu es deja a un niveau de reflexion assez avancee.

La plupart des mauvais managers / chefs de projets / clients, qui cherchent a diminuer les couts par tous les moyens possibles et imaginables, lorsqu'ils lisent "A est privilégié par rapport à B", ils comprennent "A, et on oublie B".

Et comme la doc est deja occultée dans pas mal de projets, ca devient vite Agile = pas de doc.