Discussion :

[la.lune]

Mais certainement pas le Zuckerberg de 2003 qui a doublé les freres Winklevoss et leur a piqué Facebbook en leur mentant et leur envoyant des compte-rendus bidons sur ce qu'il était sensé développé pour eux...

ça c'est du vrai management !

[Cyrilange]

Le simple faite de débatre de la "méthode Agile" montre que l'on en a pas. C'est comme débatre de l'UML ou autre méthode de schématisation. Moi je pense qu'il serait temps de passer à la "méthode Agir". Si l'on passe notre temps à réfléchir aux méthodes de travail plutôt qu'au travail lui même on continuera à perdre notre temps.
Le développement de logiciel est un art qui ne saurait avoir une méthode. C'est l'artiste qui compte pas le model. Zuckerberg, Jobs, Gates et bien d'autres en sont de brillants exemples.

[singman]

La méthode "Agile" me fait doucement rigoler. Je pense même qu'elle a été introduite subtilement par des clients incapables de définir leur besoins dès le départ de leur projet et qui ne voulaient pas exploser leur budget
En réalité et du moins en France quand on travaille avec de gros clients, elle n'est pas du tout adaptée car le client y voit surtout une occasion d'obtenir plus avec moins (de dépenses). Coté SSII, ça fait très tendance mais une étude approfondie montre clairement une explosion des délais / dépenses / stress quand on emploie une méthode dite "Agile".
Clairement, a réserver a des projets très précis. Et de toute façon, ce n'est JAMAIS au client d'exiger une méthode de développement, il doit venir avec ses besoins et laisser la SSII le soin de réfléchir à la meilleure solution suivant son expérience.
C'est du moins mon avis.

[singman]

J'ai bien dis l'esprit d'agilité ,je n'ai pas précisé les méthodes agiles célèbres connus actuellement

La Rache est l'ancêtre de toute méthode Agile, arrêtons les faux-semblant sur des réflexions à la con comme quoi Agile serait une création spontanée. C'est tellement évident que je m'étonne de ce débat.

[Luckyluke34]

La méthode "Agile" me fait doucement rigoler. Je pense même qu'elle a été introduite subtilement par des clients incapables de définir leur besoins dès le départ de leur projet et qui ne voulaient pas exploser leur budget

Pour moi la méthode Agile c'est surtout du business !
Cet article l'illustre bien! Des gourous qui font du marketing!

Quelles est le pourcentage des projets "agiles" finis dans le respect des délais et du budget ?
Quelles sont les mesures de satisfactions clientèle ?

Evidemment, dans cette article les chiffres sont absent aussi. Parce que c'est à l'esprit d'agilité

Ca me fait un peu mal de lire des trucs comme ça.

Le pire, c'est que vous avez raison si on regarde la période actuelle. On en est arrivé à un point où agile ne veut plus rien dire puisque tout le monde utilise le mot à tort et à travers et les SSII vendent de l'agilité comme des paquets de lessive.

Pourtant, à l'origine, le mouvement vient plutôt de la "base". Un groupe de 17 développeurs, architectes et testeurs qui ont réfléchi à ce qui ne tournait pas rond dans les projets logiciels et à des solutions pragmatiques.
Pas des marketeux à la recherche du buzz du siècle. Pas des commerciaux prêts à vendre n'importe quoi. Pas des clients désireux de se comporter en dictateurs vis-à-vis de leur prestataire de service. Pas des dirigeants de boîte entichés d'un concept qui leur pemettrait de presser leurs employés comme des citrons avec un bénéfice maximal à la clé.

Parfois, j'aimerais bien qu'on prenne la peine de dépasser la forêt d'imposteurs sévissant à l'heure actuelle pour (re)découvrir l'arbre d'origine caché derrière

[singman]

Je suis d'accord avec toi, "à l'origine" c'était une bonne idée (même si je pense que ce n'est qu'une tentative de rationaliser les méthodes "libres").
Mais actuellement, le client demande, exige même un développement "Agile". Et cette méthode n'est pas transposable sur tout type de dev. Mais le client ne voit que son avantage : projet qui démarre vite, sur lequel il peut se permettre de faire des "erreurs", pour lequel il va moins "préparer" donc qui lui coûtera moins cher... au départ. Et sur ce segment, en faisant valoir des arguments parfois limite, beaucoup de SSII se sont engouffrées, surfant sur l'effet de mode, sans trop chercher a comprendre la méthode et savoir si c'est rentable. Si c'est à la mode et que tout le monde le fait, ça devrait marcher non ?
Bref, vivement la prochaine mode, que les "imposteurs" changent de direction, et qu'on sache vraiment ce que le développement Agile a apporté à l'informatique. Mais il y aura de la casse, c'est certain.

[phpXpress]

Amusant de voir la disparité des remarques. Etrange de constater que si peu d'agiliste y réponde.
Je fais de l'agile depuis 4 ans et je dois dire que c vraiment génial. g fait du cycle en V pdt 20 ans: y'a pas photo.
Ce qui peu faire échouer :
faire de l'agile sans en faire (que des bouts de ci de là)
ne pas etre soutenu par sa direction.
Ne pas mettre des gens impliqués aux metiers clefs (P.O, scrummasters, devs)
Ne pas prévoir d'entrée un expert meme 1 à N jrs / semaine
croire que l'agilité c'est "vite et pas cher"
Ne pas tous partager les memes valeurs.
Sinon les ecueils que l'on a rencontré:
Un outillage adapté au contexte. (trop lourd, mal adaptés)
des carcants trop rigides pour pouvoir faire de l'agile. (il a fallu batailler)
Un P.O. pas assez impliqué. (A recadrer)
Une tendance du business à vouloir tout passer en Agile (puisque ce qui marche fini par se savoir)

[JeitEmgie]

Le pire, c'est que vous avez raison si on regarde la période actuelle. On en est arrivé à un point où agile ne veut plus rien dire puisque tout le monde utilise le mot à tort et à travers et les SSII vendent de l'agilité comme des paquets de lessive.

C'est le cycle habituel des méthodologies :

une méthodologie émerge pour débloquer des situations car les anciennes ne conviennent plus au "nouveau monde", elle se propage, devient populaire, des intermédiaires y voient l'opportunité de monter un business sur le concept proposé, plus le temps passe plus de nouveaux intermédiaires de moins en moins "scrupuleux" apparaissent et les principes de bases se diluent et la méthodologie "s'empâte" et les concepts finissent par ne plus être en accord avec le monde tel qu'il a évolué, les détracteurs avancent les mêmes arguments qui ont permis à cette méthodologie d'émerger face aux anciennes pour la critiquer à son tour (ce n'est que du business, il y a autant d'échecs que de réussites, quand il y a échec il coûte plus cher que si l'on avait fait autrement, elle ne tient pas compte des nouveaux paramètres, elle est trop liée à con contexte d'origine, …)
il est alors temps qu'une nouvelle méthodologie émerge… et le cycle recommence.

Phénomène sans doute intrinsèquement lié et amplifié par le fait que l'IT est un secteur qui a le pouvoir de s'auto-alimenter.

[Serguei_TARASSOV]

beaucoup de SSII se sont engouffrées, surfant sur l'effet de mode, sans trop chercher a comprendre la méthode et savoir si c'est rentable.

Certainement, "agile" en forfait c'est le suicide.
Si le client impose "agile" il doit payer pour chaque itération sans engagement du résultat final dont le client ne peut pas définir comme le périmètre.
Sinon c'est SSII qui payera de sa poche pour "le système est presque prêt mais..."

[Jojo K-ri]

Bon, j'arrête le hors-sujet. Personnellement je ne pretends pas avoir une vue d'ensemble de l'état de l'Agilité en France ou ailleurs donc je n'ai malheureusement pas grand chose à dire là-dessus.

Si c'est pour faire du hors-sujet en étant agressif en plus, ce n'est vraiment pas la peine de me quoter... vous êtes un troll politicien qui a déjà été banni et qui est revenu avec un nouveau pseudo.
C'est pour cela que je ne réponds pas à vos messages (et malgré tout vous me quotez quand même, en bon troll...)

[gangsoleil]

Amusant de voir la disparité des remarques. Etrange de constater que si peu d'agiliste y réponde.
Je fais de l'agile depuis 4 ans et je dois dire que c vraiment génial. g fait du cycle en V pdt 20 ans: y'a pas photo.

Avez-vous exactement le meme contexte dans les deux cas : des gens formes a ces deux types de conception, des outils adaptes, des gens partageant les memes valeurs, etc ?

Ou bien etait-ce du "faux" cycle en V, comme on en trouvait partout il n'y a pas si longtemps, et comme on trouve du faux agile aujourd'hui ?

[souviron34]

Une chose me dérange dans ta réaction, c'est qu'elle assimile Agile à certaines implémentations particulières. C'est assez typique à vrai dire mais je pense que cela a fait beaucoup de torts aux méthodes agiles.

De plus, le discours "La méthode Agile, c'est formidable !" commence un peu à saouler ...

Une méthodologie de travail ne vaut que si elle est bien appliquée ET adaptée à une problématique.

La manière dont on amplifie les manager en France ce n'est pas comparable dans le monde. C'est vraiment à la française !

Amusant de voir la disparité des remarques. Etrange de constater que si peu d'agiliste y réponde.

Phénomène sans doute intrinsèquement lié et amplifié par le fait que l'IT est un secteur qui a le pouvoir de s'auto-alimenter.

Je ne répondrai que succintement à l'ensemble et au thread en général :

Je pense qu'effectivement il y a un "retard" en France, mais que il est dû, en - très grande - partie à la mentalité générale et au cadre industriel : on en a déjà discuté ailleurs, mais la France et les boîtes voient d'un mauvais oeil "ce qui est petit".. D'autre part nous sommes un des rares pays où les grandes SSII sont aussi grandes (dont 2 filliales d'ue 2 gands groupes mondiaux dans d'autres secteurs), avec un système d'assurancs/banques aussi concentré et fort, faisant en fait quelques "parties fines" avec des partenaires privilégiés..

Alors on compense en créant des modes et des "méthodologies" plus ou moins strictes où d'un seul coup ça devient le buzz-word ..

Je l'ai déjà dit plusieurs fois ici-même..

J'ai toujours développé "en Agile", mais sans "méthodologie".. Et je trouve que les formalisations sont un travesti de la volonté de départ..

Le Manifeste n'est simplement que le constat d'échec des cycles en V, et l'énoncé de grandes règles (de bon sens) pour éviter les écueils courants..

Le mot important ici est "grandes"...

Avoir voulu en déduire des "petites" règles et processus détaillés est à mon avis aussi source d'échec que les détails qui ont fait l'échec du cycle en V.

Maintenant, il est évident que les pays anglo-saxons sont plus ouverts aux petites structures, que ce soit en termes de création, de support, de "croyance" dans les capacités, etc etc.

Il est donc tout à fait normal et évident que les chiffres en France soit proportionnelement plus faibles qu'aux US ou dans les autres pays anglo-saxons..

Il suffit de regader les annonces d'emploi : cherchez des annonces de "SCRUM-MASTER" aux US... Ici c'est, comme le reste, un titre.. Là-bas c'st une fonction....

[rad_hass]

+1 souviron34

Je penses que beaucoup de personne ont avancé un avis sur l'Agilité sans vraiment connaître et surtout sans donner de réel fondement à leur position... Et c'est ça qui est dommage.

Maintenant, on peut vouloir faire autre choses, mais si ici on parle de mouvement agile dans l'ensemble, il faut me dire qu'est ce qu'il y'a de faux dans :
- Qu'il faut essayer d'obtenir de la valeur le plus rapidement possible avec les éléments les plus prioritaires ?
- Qu'il faut communiquer et intégrer la vision client dans l'équipe projet ?
- Que des feedbacks réguliers permettent de batir un outil plus proche du besoin utilisateur ?
...

Après effectivement, ce sont des règles de bon sens et mal appliqué ne donne pas de bon résultat... Personne n'a dit que c'était une méthode miracle.

[souviron34]

je suis bien d'accord avec toi..

Malheureusement notre métier (et sa variante française, qui est ultra-concentrée et "caricaturale" au possible, avec justement les "titres" et les positions "attachées"), aime d'une part les modes (qui permettent de vendre à prix d'or des sevices soi-disant nouveaux et miracles), et d'autre part un découpage taylorien (iste ?) des divers pans, ce qui est en relative opposition avec la notion centrale du Manifeste (et qui correspond à mon expérience) que cela repose sur un aspect humain .. Qui n'est pas fixe. Un "chef" , "master", ou autre, dans telle situation ne sera pas bon dans tel autre contexte...

Je ré-itère qu'à mon avis l'erreur de fond est de considérer notre (nos) métier(s) comme une industrie et pas comme de l'artisanat du vrai : avec compagnonage, réalisation d'une pièce "maîtresse", etc etc...

Pour répondre à ton poste, je pense que c'est la formalisation et la manière de découpage (voir les MOA, MOE, etc)) qui sont en problème..

Mais le sujet n'était pas là : je pense que cela a été promu en France comme "la nouvelle Source de Vie", et qu'au vu de la spécificité de l'inluence des grosses boîtes, qu'elles soient donneurs d'ordre ou SSII, c'est dévoyé en simplement un outil marketing... Mais que c'est relativement un épi-phénomène ici justement vu la situation spécifique de grosses boîtes, qui pensent toujours grosses équipes, top-down, "services", avec peut-être un input via des MOA ou MOE...

Quand on voit les posts dans l'ensemble des forums Conceptions ou Architecture, on voit qu'il manque de manière générale une appréhension globale (détachée des outils, purement de réflexion) d'une architecture et/ou d'une réalisation..

Alors je suis bien évidemment pour ces approches. Je pense cependant qu'avec la non-assimilation des notions prcédentes plus la mentalité moyenne (voir les discussions sur les formations, les emplois, les rôles, les salaires..), cela risque de prendre un temps considérable afin d'aller vers quelque chose qui soit suffisamment fiable pour que les chiffres soient clairs...

[Serguei_TARASSOV]

Avoir lu les réponses, j'ai l'impression qu'il n'existe que 2 approches extrêmes :

• waterfall/cycle en V - on veut savoir exactement ce qu'on fait
• "agile" - on ne sais pas ce qu'on fait mais on espère y arriver en plusieurs itérations

Pourquoi personne (j'ai vu "RUP" une fois) ne dit rien au sujet des méthodes itératives dont les stades comprennent l'analyse, la conception, le dév et la stabilisation ?

Sinon que des extrémistes participent dans la discussion ?

[rad_hass]

Avoir lu les réponses, j'ai l'impression qu'il n'existe que 2 approches extrêmes :

• waterfall/cycle en V - on veut savoir exactement ce qu'on fait
• "agile" - on ne sais pas ce qu'on fait mais on espère y arriver en plusieurs itérations

Pourquoi personne (j'ai vu "RUP" une fois) ne dit rien au sujet des méthodes itératives dont les stades comprennent l'analyse, la conception, le dév et la stabilisation ?

Sinon que des extrémistes participent dans la discussion ?

Encore quelqu'un qui avance des choses sans fondement... Ou as-tu vu qu'être agile c'est "on ne sais pas ce qu'on fait mais on espère y arriver en plusieurs itérations". Ou encore qu'il n'y avait pas d'analyse, de conception et de stabilisation ?
En plus pour ta gouverne RUP n'est absolument pas incompatible avec l'agilité et il peut être totalement agile si on adopte l'état d'esprit :

http://www.ibm.com/developerworks/fo...98088#13898088

On peut ne pas aimer l'agilité, mais ceci ne doit pas nous empêcher de juger les choses pour ce qu'elles sont plutôt que de l'image qu'on en déduit

[souviron34]

Pourquoi personne (j'ai vu "RUP" une fois) ne dit rien au sujet des méthodes itératives dont les stades comprennent l'analyse, la conception, le dév et la stabilisation ?

Sinon que des extrémistes participent dans la discussion ?

Comme l'a dit rad_hass .....

En l'occurence, c'est bien toi l'extrémiste...

• Primo, RUP? est une des méthodologies , qui plus est dérivées de l'approche Agile
  
  
• Secondo, visiblement tu ne connais rien à ce qui est sous-tendu par une approche agile.
  
  
• Tertio, a priori on ne parlait pas ici de l'approche agile en tant que telle, simplement du pourquoi elle aurait moins pénétré en France qu'ailleurs..

Donc, ni RUP ni quoi que ce soit n'est LA solution miracle. Il y a des méthodologies, plus ou moins adaptées à tel ou tel type de projet, plus ou moins adaptées à tel ou tel type d'équipe, plus ou moins évolutives, plus ou moins à la mode, ayant plus ou moins de succès...

C'est un vaste sujet, sur lequel on peut longuement discuter, et il eiste tout un tas d'expériences plus ou moins contradictoires..

Si il y a une seule chose de sûre, c'est qu'il n'y a pas UNE métholodogie miracle, encore moins une IMPLANTATION d'une approche globale.....

[Serguei_TARASSOV]

Voila, voila... Cela fait 10 ans que je discute de temps en temps avec le "guru" de XP et agilité. Les arguments n'ont pas changés depuis...

Outre l’expérience subjective il existent des choses objectives. Réussite des projets en termes des correspondance de besoins et du périmètre, ressources requis, délais respectés, coût de possession et d’évolution.

Toujours pas de réponses et pas d'espoir les avoir un jour.

Comme les méthodes "waterfall" sont bouclés lors d'analyse à partir d'un certain niveaux de complexité, les méthodes "agile" sont bouclés lors du dév à partir de même niveaux.

C'est pourquoi l'argument principal est une comparaison de ces deux extrémités.
Le deuxième argument "il n'y a pas des méthodologies miracles" (merci à F. Brooks qui eux a dit cela en 1975). Mais le monde a besoin "l'adoption massive de ces méthodes Agile".
Une fois le "guru" me dit que "Scrum" est efficace parce que Toyota japonais est devenu le top-producteur dans le monde

Les gars, savez-vous que les méthodes itératives a été mis en pratique depuis les années 1980 ?

Effectivement, les méthodes XP, Scrum, Crystal etc peuvent avoir lieu. Mais il faut être conscient du périmètre de validité qui n'est pas loin de celui de "waterfall".

[souviron34]

Voila, voila... Cela fait 10 ans que je discute de temps en temps avec le "guru" de XP et agilité. Les arguments n'ont pas changés depuis...

MDR...

10 ANS ?????

Mais ça fait plus de 40 ans qu'on en discute dans les DSI et les équipes.....

Outre l’expérience subjective il existent des choses objectives. Réussite des projets en termes des correspondance de besoins et du périmètre, ressources requis, délais respectés, coût de possession et d’évolution.

Oui..

Et des chiffres parus (et publiés dans la rubrique Actualités) e pourcentage d'échec est tout aussi grand aujourdhui qu'hier...

Comme les méthodes "waterfall" sont bouclés lors d'analyse à partir d'un certain niveaux de complexité, les méthodes "agile" sont bouclés lors du dév à partir de même niveaux.

Je crois qu'il te manque une notion : les "boucles" sont itératives....

D'autre part, les "arrêts" de boucles ne sont pas du tout au même niveau, puisque interviennent dans la décision la facilité de développement et la satisfaction du client...

Le deuxième argument "il n'y a pas des méthodologies miracles" (merci à F. Brooks qui eux a dit cela en 1975).

N'importe qui ayant passé plus d'une dizaine de gros projets dans des environnements différents avec des méthodes différentes te dira la même chose...

Pas besoin d'un "grand penseur"...

Les gars, savez-vous que les méthodes itératives a été mis en pratique depuis les années 1980 ?

Mon gars, voir plus haut : ta vision de ce qui est une "boucle" est totalement erronée : les méthodes agiles sont itératives....

Effectivement, les méthodes XP, Scrum, Crystal etc peuvent avoir lieu. Mais il faut être conscient du périmètre de validité qui n'est pas loin de celui de "waterfall".

Ah bon ?

Et quel est le périmètre auquel tu prétends répondre ??

Tes notions semblent ne pas correspondre à ce qui est généralement accepté...


Le périmètre d'un logiciel est ce qu'il doit couvrir comme fonctionalités et besoins.

La manière de l'atteindre peut se faire de différentes manières : waterfall, agiles, ou autres.. Et ça c'est la manière de développer le logiciel de façon à ce qu'il atteigne le périmètre...

J'avoue être très perplexe quant à ton choix de mots et leurs signifcations...

[DonQuiche]

MDR...

10 ANS ?????

Mais ça fait plus de 40 ans qu'on en discute dans les DSI et les équipes.....

40 ans seulement que l'on parle de XP et l'agilité ? Plus encore ! Mon grand-père m'a raconté avoir vu leurs backlogs emportés par la grande crue de 1910.