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.
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.
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.
Bof, Zuckerberg d'aujourd'hui 2012, à la limite, qui a maintenant une vraie expérience de CEO de grosse entreprise et qui s'est largement imprégné de l’expérience de ses conseillers, des cadres de son entreprise et du milieu...
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...
De toutes façons self-made man c'est spécial, c'est des gens qui ont réussi grâce à leur bébé et qui sont toujours restés à la fois MOA et MOE, client et patron, en ayant pour seules contraintes que celles qu'ils s'imposaient eux-mêmes finalement.
Donc il faut voir le contexte, Zuckerberg dans une entreprise n'aurait sans doute jamais percé vu les problèmes qu'il avait visiblement avec les notions de "client", de maîtrise d'ouvrage et d'autorité (avant de bosser sur facebook il avait failli se faire virer d'Harvard quand meme...)
Bref,pour moi pisser des lignes de codes et manager un projet c'est vraiment deux choses différentes, dans un cas il faut des qualités relationnelles, de meneur d'hommes, de négociateur et d'anticipation, il faut savoir prévoir les difficultés avec plusieurs coups d'avance comme aux échecs, savoir tenir la barre quand on est dans la tempête, fixer les bonnes priorités, et savoir s'affirmer autant devant la MOA que devant son équipe ... dans l'autre il faut plutôt un savoir-faire technique, des capacités cognitives et une appétence adéquate ... donc autant un jeune nerd geek no-life peut exceller dans la deuxième catégorie, autant il ne sera certainement pas the right man at the right place dans la première...
(bon j’arrête là les lieux communs et l'enfonçage de portes ouvertes...)
Là il y en a : http://past.is/sPLr
Et la vidéo qui va avec : http://past.is/sPfr
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...
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.
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)
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 !
A ben j'en parlais à l'instant...
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é
Voyons voir....
Tu cherches à appliquer la dichotomie MOA/MOE, pourtant Franco-Française, à la carrière d'un entrepreneur Américain. Peut-être as-tu du mal à te projeter en dehors de ton cadre de formation.
Tu dis que Zuckerberg n'a(vait) pas le sens du client--pourtant il n'a pas perdu de procès et s'est enrichi massivement. C'est peut-être toi qui n'a pas comprit que le but d'une entreprise, c'est de s'enrichir, pas d'enrichir le client, et que la seule obligation envers le client c'est l'engagement légal. Personne n'a dit qu'il fallait être moral dans les affaires.
Tu dis que tu ne ferais pas confiance à une personne à un moment de sa carrière où elle a dégagé une valeur ajoutée phénoménale. Tu ne donne donc pas d'importance aux indicateurs de performance.
Tu craches sur la technique. Tu te lances dans un dythirambe sur le manager tout en dévalorisant les techniciens/ingénieurs. Pourtant les meilleurs managers savent que le respect doit être mutuel.
Tu abuses de la métaphore et du lieu commun plutot que de détailler ton point de vue. Tu coures donc le risque de passer pour un "baratineur" sans substance.
En bref, d'après ton post, je ne pense pas que je te ferais confiance pour un poste à responsabilités, quels que soient ton âge ou ton expérience
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.
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.
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.
Entièrement d'accord. D'ailleurs, et là je suis conscient d'ouvrir la porte à un débat brulant, mais après tout, il ne faut pas avoir peur de ses opinions, même lorsque celles-ci pourraient nous mettre en porte-à-faux vis à vis de l'opinion publique. Ne peut-on pas affirmer que finalement, "La Rache" peut être considérée comme de l'Agile 2.0 ?
Je sais bien que ça peut choquer, mais après tout, il ne nous reste que moins d'une année pour pouvoir répondre à certaines de ces questions indispensables à la survie de l'humanité. Par ce que oui, j'affirme que "La Rache" est probablement, LA méthode la plus a même de nous permettre d'éviter le drame annoncé du 21/12/2012.
Il faut avoir le courage de lire et ne pas prendre seulement les dates de parution des méthodes dont on pense qu'il sont les seuls agiles.
Je ne te dis pas d'aller loin il faut juste visiter Wikipedia,voici un exemple d'extrait
http://fr.wikipedia.org/wiki/M%C3%A9thode_agileEn 1986 également, Hirotaka Takeuchi et Ikujiro Nonaka publient « the new new product developpement game » dans la Harvard business review. Leur article présente un modèle de développement basé sur l'aptitude au changement, l'auto organisation, l'imbrication des phases de développement, et l'itération (on y fait d'ailleurs mention du mot scrum par analogie au rugby).
J'ai bien dis l'esprit d'agilité ,je n'ai pas précisé les méthodes agiles célèbres connus actuellement
La manière dont on amplifie les manager en France ce n'est pas comparable dans le monde. C'est vraiment à la française !
Il y a des exemples que je ne veux pas les citer ici, des jeunes manager dans le monde et dans l'histoire qui ont eu du succès et qui ont réussi à faire la différence.
Alors je vous dis que maintenant on suit la logique et on respecte les anciens qui sont déjà là et mieux expérimentés mais cela ne veut pas dire que l’expérience montre que si on donne le boulot du manager a un jeune ça abouti à l'échec.
Par honnête intellectuelle ayez le courage de dire que j'avais tort en disant ceci et répondez moi:
Imaginez un jeune qui a franchi les étapes et devenu un chef de projet dans une société X,vu son talent et son esprit de génie, le moment où certains développeurs,plus âgés que lui dans d'autre société, se battent pour relever les défi de développement ,lui avec son esprit frais de jeune, il se bat sur les méthodologies de travail et comment organiser les projets. Alors peut-on parler d'âge? Après 4 ans qui sera le plus expérimenté et qui aura l'esprit ferme sur le domaine, qui sera plus reconnu?
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.
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 !
"É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
Partager