Discussion :

[macgile]

Pour moi la méthode Agile c'est surtout du business !
Cet article l'illustre bien! Des gourous qui font du marketing!
Des gourous en ce moment il y en a partout.

Dans mon entreprise on nous impose des méthodes de gestion du stress, des méthodes pour améliorer la communication entre chacun etc...

Tous ceci à coup de formation a des prix exorbitant, malheureusement ce coût il faut l'amortir bien sur.

Comment ? en augmentant la productivité en augmentant la pression et bien sur le stress, et qui dit stress dit agressivité, parfois des conflits D'OU les formations

Je ne dis pas qu'il ne faut pas de méthode de développement mais surement pas à travers une application rigide de la dite méthode mais y voir juste une source d'inspiration pour améliorer celle acquise par l'expérience ou celle des autres.

Une équipe de foot ne fonctionne pas s’il y a un mauvais entraîneur ou si celui-ci n'a pas réussi à créer un esprit d'équipe.Une équipe ne fonctionne pas si les joueurs ne s'apprécient pas, si ils n'ont pas réussi à être souder.

Et pourtant ils suivent tous la même règle du jeu.

[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.

[DonQuiche]

Cela dit, je n'ai pas l'impression qu'aux États-Unis, la programmation par binôme ou le planning poker soient si répandus que ça...

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.

Agile == développement itératif souple en interaction avec le client pour mieux le satisfaire.
Agile != deux fois plus de développeurs pour la même quantité de travail (binômes), deux fois plus de code à écrire pour le même budget (TDD), etc.

La dernière forme trollesque est ici justifiée : le manifeste agile en lui-même va au moins susciter un vague intérêt du commercial ou de l'exécutif de base. Alors que telle ou telle implémentation qui implique des coûts plus élevés en promettant un retour sur investissement pas évident à première vue (tout le monde n'est pas d'accord sur le sujet) est pour le moins plus délicate à vendre. Et ça vaut aussi côté développeur : les meetings quotidiens et les binômes peuvent créer du mécontentement et d'autres entendent "bureaucratie" quand on leur dit "TDD".

Pour quelqu'un qui semble attaché au droit d'aînesse, tu meconnais ton histoire. Linus Torvalds a ecrit le noyeau Linux à 22 ans, et le language LISP, inconnu à l'époque, a été implementé sur PDP-1 par un gamin de 12 ans à peine...ce ne sont que deux exemples, mais heureusement que personne ne t'a demandé ton avis, sinon l'informatique aurait eu bien du mal à décoller.

A la décharge de Jojo K-Ri, j'ai pensé à peu près la même chose. Mais il ne faut pas forcément le prendre au pied de la lettre : si demain je vois un gamin de seize ans postuler avec le code d'un OS en portfolio, je vais essayer de l’embaucher, on trouvera sans doute à en faire quelque chose. Mais si à la place il vient me proposer ses services de consultants à 7300€ HT la journée, il a quand même intérêt à avoir un discours en béton et plus d'un projet en référence.
En l’occurrence, l'âge est difficile à estimer depuis une photo mais celle-ci donne l'impression, peut-être fausse, d'un CV encore un peu court, c'est un fait.

[Traroth2]

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.

L'agilité se cp,crétise par un certain nombre de pratiques. Celle que j'ai cité en font partie. Je ne vois pas en quoi il y a débat.

Agile == développement itératif souple en interaction avec le client pour mieux le satisfaire.
Agile != deux fois plus de développeurs pour la même quantité de travail (binômes), deux fois plus de code à écrire pour le même budget (TDD), etc.

Tu me fais dire ce que je n'ai pas dit. Quand je dis que la programmation en binôme n'est peut-être pas si répandu que ça, c'est une critique, hein. Je ne suis pas en train de dire que c'est une bonne chose de ne pas le faire. La programmation en binôme a un coût, c'est clair, mais peut apporter beaucoup si elle est pratiquée comme il faut.

[romatou18]

Pardonnez moi les accents (clavier qwerty).

Ou sont les chiffres ?? "Les entreprises en France" mais de quelle taille ? Qui ? dans quel secteur ? sur quel type de projets ? En quelles proportions ?

Moi j'ai seulement 26 ans et ce mec en a pas bcp plus, je veux pas faire de la discrimination mais vu la teneur de ses propos, ca sent la publicité a plein nez point barre.

Ce mec ne connait rien a rien, pour bosser Chez Cadence une grosse boite de 5000 developpeurs environ, et bosser sur des projets complexes dont la durée de vie excede les 20 ans, l'Agile n'est pas la saint Graal, et meme si il pourrait améliorer certaines choses, n'est pas indispensable.

Aussi pour avoir bosser dans des petites boites par le passé prétenduement utilisant des méthodes agiles, la clé réside surtout dans la bonne application des méthodes agiles. Par la j'entends, prendre que ce qui se prete bien a une entreprise, une équipe voir un groupe, ne pas foncer tete baisser en se disant que ca va marcher. Ca peut etre contre productif si l'équipe ou groupe en question se sent brusqué, comprends mal la méthodologie ou si certaines regles sont appliquées de maniere aveugle.


Pour rappel les méthodes agiles sont un receuille d'experience sur le terrain qui ont bien marchées dans un certains nombres de cas, et qui ont été mises sur le papier de maniere formelle, pour partager une experience. Mais ca veut pas dire que c'est une solution ou une fin en soit, juste une boite a outils, ou comme toujours pour l'artisan le plus important c'est de bien les utiliser.

Un mauvais plombier avec un fer a souder de course, qui ne sait pas l'utiliser reste un mauvais plombier...

[Jay13mhsc]

Ou sont les chiffres ??

Là il y en a : http://past.is/sPLr
Et la vidéo qui va avec : http://past.is/sPfr

[Grimly_old]

Les méthodes agiles demandent non seulement un effort des développeurs mais aussi des entreprises clientes pour définir les besoins et leur faire comprendre que ça ne peux pas changer en plein milieu d'une itération si on veux quelque chose qui tourne.

De plus, tous les projets n'ont pas besoin du bazooka Agile.

[Jay13mhsc]

Pour rappel les méthodes agiles sont un receuille d'experience sur le terrain qui ont bien marchées dans un certains nombres de cas, et qui ont été mises sur le papier de maniere formelle, pour partager une experience. Mais ca veut pas dire que c'est une solution ou une fin en soit, juste une boite a outils, ou comme toujours pour l'artisan le plus important c'est de bien les utiliser.

Un mauvais plombier avec un fer a souder de course, qui ne sait pas l'utiliser reste un mauvais plombier...

Non, ça ça n'a strictement rien avoir avec l'Agilité
Le recueil de bonnes pratiques, c'est ITIL, et CMMI à la limite.
L'Agilité est bien plus qu'une boîte à outils.
Les pratiques sans les principes ne valent rien, et les principes sans les valeurs, ne valent pas grand chose non plus...

Et alors comparer l'Agile au fer à souder est totalement hors de propos...

[Luckyluke34]

il devient préoccupant de voir la France conserver son retard dans le domaine des méthodes Agile

J'ai lu l'article d'origine (fort court) et rien ne vient prouver ou étayer cette affirmation. Pas un chiffre n'est cité, pas une statistique ni même l'ombre d'un témoignage d'entreprise ou d'analyste. Juste une vague impression.

Pourtant pour moi, la France n'est pas en reste en la matière.

• La communauté agile est une des plus actives d'Europe et du monde. Les initiatives locales se multiplient comme les Scrum User Group et leurs déclinaisons régionales (Scrum Café, Scrum Pastis...) ou encore le Club Agile Rhône-Alpes. Des événements nationaux sont organisés comme le Scrum Day, XP Day, et l'Agile Tour qui draine chaque année une masse de participants assez considérable et je crois implique un nombre de villes inégalé dans le monde (12 villes en 2011)...

• Nous avons aussi des experts reconnus et influents au niveau mondial comme Laurent Bossavit qui siège au board de l'Agile Alliance et a fondé l'Institut agile.

• Le tissu économique est également vivace et en plein développement, que ça soit boîtes de consulting ou SSII autour de l'agilité, coaches indépendants, etc.

• Les universités suivent avec plusieurs IUT ou écoles d'ingénieurs qui ont fait apparaitre à leur programme un enseignement sur les méthodes agiles ces dernières années.

Alors c'est sûr qu'il y a encore une marge de progression énorme. La législation et les traditions françaises autour des contrats d'affaires notamment sont des freins énormes à une relation client/fournisseur qui s'inscrirait dans une démarche agile. On fait également face à une résistance au changement au sein des entreprises qui ralentit l'adoption des méthodes agiles, peut-être un peu plus que dans d'autres pays. Peut-être.

Donc "La France conserve son retard"... oui et non, ça dépend de quoi on parle, par rapport à qui (si c'est pour la comparer aux USA, forcément...). Et encore, pour le conserver, il s'agirait déjà de prouver que retard il y a.

Article très mal documenté en tout cas.

[Jay13mhsc]

J'ai lu l'article d'origine (fort court) et rien ne vient prouver ou étayer cette affirmation. Pas un chiffre n'est cité, pas une statistique ni même l'ombre d'un témoignage d'entreprise ou d'analyste. Juste une vague impression.

Si je viens de mettre les liens de l'étude du French SUG, la seule actuellement valable (en attendant peut être ce que va faire Laurent à l'institut sur le sujet)

• La communauté agile est une des plus actives d'Europe et du monde. Les initiatives locales se multiplient comme les Scrum User Group et leurs déclinaisons régionales (Scrum Café, Scrum Pastis...)

TROP BIEN !! Mon Scrum Pastis !!
Je pensais pas en entendre parler jusque là !!
Remarque, vu ton pseudo, je t'ai déjà certainement croisé là bas !

• Nous avons aussi des experts reconnus et influents au niveau mondial comme Laurent Bossavit qui siège au board de l'Agile Alliance et a fondé l'Institut agile.

A ben j'en parlais à l'instant...

Alors c'est sûr qu'il y a encore une marge de progression énorme. La législation et les traditions françaises autour des contrats d'affaires notamment sont des freins énormes à une relation client/fournisseur qui s'inscrirait dans une démarche agile. On fait également face à une résistance au changement au sein des entreprises qui ralentit l'adoption des méthodes agiles, peut-être un peu plus que dans d'autres pays. Peut-être.

Alors voilà ! On y vient ! Justement le sentiment général est que l'agilité se heurte à une culture différente que dans les pays scandinaves par exemple.
Si on peut avoir des chiffres américains, scandinaves, grands-bretons, allemands, ça serait intéressant

Mais la culture MOA/MOE et le contrat est très franco-français. Or on sait pertinemment que le forfait est un frein à l'agilité

[Drawingrom]

Mais la culture MOA/MOE et le contrat est très franco-français. Or on sait pertinemment que le forfait est un frein à l'agilité

Entièrement d'accord. Conservons les emplois en MOE et ne faisons pas d'agilité .

Plus sérieusement : l'engouement pour les projets au forfait qui font porter le risque (à première vue) sur le prestataire est toujours d'actualité. Vouloir faire de l'agilité sur une base forfaitaire avec une MOE en face qui veut un scope fixe, des délais fixe et un coût fixe est une mauvaise idée.
Cependant, les pratiques proposées par les différentes "méthodes" agiles sont intéressantes pour suivre le projet et rechercher une meilleure qualité de livrables.
Je pense aux réunions quotidiennes, aux brundown charts mais aussi au TDD, l'intégration continue et développement en binôme.

Le but de l'agilité est de pouvoir ce permettre de changer de voie facilement pour la construction d'une appli. Cela passe par moins de doc (en tout cas, moins de redondances entre les docs), de la couverture de test pour s'affranchir des régression.

La gestion des changements, qu'on soit sur de l'agile ou du cycle en V, on doit toujours en faire.

Le challenge d'aujourd'hui est de savoir s'approprier ces pratiques pour les appliquer à un contexte projet donné sans forcément chercher à faire, par exemple, du scrum stricto sensu.

[gangsoleil]

Bonjour,

Je pense qu'il a raison : des projets faits rigoureusement avec une methode Agile seront moins chers et mieux faits que sans.

Mais c'est aussi vrai avec n'importe quelle methode qui ne soit pas la Rache, c'est juste ce qu'il oublie de dire.

[tontonnux]

Bonjour,
Mais c'est aussi vrai avec n'importe quelle methode qui ne soit pas la Rache, c'est juste ce qu'il oublie de dire.

A voir quand même. Par ce que La Rache est quand même la méthode la plus facile à mettre en place en entreprise. Les coups de nonformation sont bien moins contraignants.

[atanalban]

Et il est évident qu'elle revient moins cher au client final, mais surtout qu'il est satisfait
J'ai repris des projets que de bien plus grosses boites que la mienne (méthode traditionelle) n'ont pas été capable de mener au bout où cela s'est terminé en procès, le cahier des charges n'étant pas respecté !
Fini avec la méthode agile, on ne parle plus de cahier des charges, mais vous devez être prêt à aller plus loin que la demande client , avoir donc une bonne expertise métier et une bonne compréhension du besoin !

[Serguei_TARASSOV]

Et il est évident qu'elle revient moins cher au client final, mais surtout qu'il est satisfait

"Évident" cela veut dire "facilement prouvé"

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é

Une bonne expertise métier sert à éviter les itération nombreuses et fréquents par rapport des équipes dont l'expertise métier est quasi nul.
80% demandes sont spécifiques du domaine métier et 20% au plus sont spécifiques du client.

La spécialisation sur les domaines métiers permet réutiliser les architectures fonctionnels et techniques. Par contre, il faut les avoir, ces architectures. Il faut savoir les réutiliser. Savez-vous faire MDA/MDD au moins pour cumuler les connaissances des experts ? Comme cela votre société peut avoir la maturité seulement.

Mais je pense que les méthodes "agiles" sont pertinents en 2 cas :
- le service informatique interne ou externe en temps de développement de courte termes
- l'équipe qui ne sais rien sur les domaines métier du projet courant et qui ne pense pas s'en spécialiser et réutiliser ce projet après

[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.

[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.

[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..."