Entreprise Agile en france

Bonjour,
je recherche des informations sur toutes les techniques agiles qui voient le jour en France. Les grosses boites américaines l’applique depuis longtemps.

J’aimerai donc savoir s’il existe des liens, des vidéos, ou tout médias pour parler des techniques agiles.
J’ai cherché en vain des reportages sur google par exemple. A part “google fait-il peur” qui parle très vite de la gestion de projet chez google j’ai rien trouvé.

Existe des grands noms d’entreprise Agile en France ?
Je sais que Thales, Orange ont changé leur chevaux de batailles pour changer leur façon de développer un logiciel. Mais la encore j’ai l’impression que c’est chasse gardée, les informations sont inexistantes ou bien gardées.

Voila si des gens ont des liens vers quoi m’orienter.
Bonne journée

je comprends meme pas ce que tu cherches :smiley:

je reviens de 6 mois de boulot aux USA jamais entendu parlé de technique agiles ^

Des informations sur l’eXtreme programming, le Lean, scrum. En d’autres termes les pratiques d’ingénieries utilisées dans le développement logiciel plus particulièrement.

C’est utilisé chez microsoft, google etc. Plus ou moins bien d’ailleur.

Pour ceux que ça intéresse : fr.wikipedia.org…

Agile est utilisé dans la majorité des gestions de projet informatique… donc bon comme blackvoice… tu cherches quoi ? t’as pas l’air très conscient du monde réel … Y a pas que les grosse boites américaine qui le font et chaque boite adapte les méthodo à leur besoins metier… (un peu le principe justement de cette méthodo)

Je recherche des informations sur le sujet et des noms d’entreprises françaises qui pratiquent les techniques agiles en vue d’une recherche d’emploi ciblée.

blackvoice>bah quand même, t’es has been pour le coup :ane:

Dans ma boite, c’est impossible à mettre en place, on est CMMI 3, CMMI5 en cours donc pas du tout compatible.
J’en ai parlé avec startide et il se trouve qu’il bosse comme ça dans sa boite, ça réussit pas mal mais il faut être dans une structure et avoir des gens compétents pour mettre les specs à jour au fil de l’eau.

C’est encore à cause du Département de la Défense américaine qu’en France on travaille encore avec des méthodes comme ça, ou le très populaire cycle en V.

Ce que je comprends pas du tout d’ailleurs. KarLKoX tu soulèves l’un des points les plus importants : Comment dans un projet ou les technologies avancent vites, on peut encore passer 4 mois à faire des spécifications ! Il faut des spécifieurs (je sais pas si ça existe) expérimentés, mais quand même ça reste un peu absurde.

KarLKoX tu peux expliciter pourquoi dans ta boite c’est impossible à mettre en place ?

Et c’est parce que je connais pas bien le monde réel que j’essaye de me renseigner au près de personnes qui le peuvent. Parce que entre ce qu’on apprend à l’école et ce que l’on pratique en entreprise, le gouffre est réel.

J’ai appris récemment que 80% des projets logiciels utilisant le cycle en V, n’aboutissaient pas. Soit parce qu’ils étaient tout simplement pas terminés, soit parce qu’ils demandaient au moins un avenant au contrat. Est ce que ses chiffres sont justes ?
Parce que c’est tout un ensemble de métiers, la gestion de projet !

Bonne journée et merci pour vos réponses.
Edité le 07/06/2010 à 22:03

Concernant le CMMI, le cahier des charges CMMI est tellement contraignant qu’il impose de lui même une façon de gérer un projet qui suit des normes, pré-établies : cela commence dès les specs.
Dès lors, sachant qu’en dev agile, les specs, tu les fais évoluer au fil de l’eau, impossible dès le départ.
Cela, ce n’est qu’une goute : rien qu’en CMMI 3, on a une palanqué de process à suivre, cela va du management, à la qualité jusqu’au design de notre code.
Je ne vois pas comment tu peux incorporer tout cela sachant qu’en dev agile, tout bouge, tout le temps.

Concernant ta question sur le fait de passer des mois sur les specs, je suis plutôt oldschool et un projet se pense bien en amont puis se réalise : je considère le projet comme une problématique, je le couche donc sur papier, je “jette” mes idées, je les organise, j’anticipe les problèmes/solutions au mieux et j’implémente.
Evidemment, on ne peut penser à tout mais le prototypage permet déjà d’avoir une base seine et solide.

Le dev agile, c’est bien mais pour des projets de faibles envergures et limite dans des boites à tendance geek mais sur des projets où tu as des clients qui ne laissent rien au hasard, vu les couts, tu n’as juste pas le choix, surtout quand ils t’imposent eux même comment tu dois faire (ils imposent leur propre framework sur certains projets).

Bref, c’est une méthode comme une autre mais qui n’a pas sa place partout :jap:

Développement agile est donc limité à de petit projet.
Mais par exemple chez google ou microsoft comment ça marche ? Il ont quand même des projets de taille.
Microsoft se revendique agile, alors qu’ils font du scrum un peu bizarre, mais ça reste de l’agile. Mais google par contre développe vraiment en mini cycle itératifs incrémental.

Est ce que parce qu’ils ont de très bon ingénieurs qu’il en devient facile d’appliquer les méthodes agiles pour un gros projet ?

Je comprend pas d’ailleurs comment on peut vraiment, dans un projet de taille, anticiper avec juste des spécifications, des éventuels problèmes dans des phases comme l’intégration. A moins d’avoir des spécifications excellentes ?
Tu le sous entendais il me semble, KarLKoX, dans ta première réponse. Sans spécifieurs excellent, ça marche pas.

Et si je comprend bien c’est aussi un problème de mentalité, si les techniques agiles sont difficiles à appliquer ? Les clients s’attachants à des valeurs sures, comme les spécifications. C’est rien qu’une protection contractuelle.

Est ce que des personnes qui travaillent dans une entreprise agile peuvent m’expliquer comment marche la facturation ?

Merci pour les réponses KarLKoX :slight_smile:
Edité le 08/06/2010 à 02:54

Hello,

Ca fait 2 ans que je pratique quotidienne les techniques issues de méthodes agiles : Scrum, XP, TDD, TDR.

Ma boite est spécialisée dedans, tu peux me laisser un message privé pour que je t’en donne l’identité.


Et les réponses aux questions : [quote=""] Est ce que parce qu'ils ont de très bon ingénieurs qu'il en devient facile d'appliquer les méthodes agiles pour un gros projet ? [/quote]

Oui, dixit le premier principe du manifeste Agile : “Human over processes”. Les meilleurs ingénieurs (relationnel + technique) sauront te développer n’importe quoi dans n’importe quelles conditions. La différence, par contre, pourra être appréciée dans l’interet du résultat final. Un bon logiciel n’est pas que un logiciel sans bug.

Perso je n’ai pas bien compris la question. Agile n’implique pas zéro spécification ni anticipation : c’est à nuancer.

Contrairement à ce qui est dit, les méthodes agiles ne sont pas du tout mainstream en France. C’est une chose de mettre en oeuvre de bonnes pratiques de dev (usine logicielle, etc.), c’est une autre d’être Agile.
Donc oui, les techniques sont difficiles à appliquer, c’est pour cela que la réussite d’un tel projet dépend essentiellement de la qualité du scrum master et du lead dev.

Essaie sur google “Contractualisation agile”. C’est un sujet délicat et difficile, au regard des organisations clientes.

Oui j’en suis tout à fait conscient, je vois ça comme des spécifications qui s’adaptent aux besoins du client.
J’ai participé à l’agile tour l’année dernière et c’était très instructif. Je conseil ceux qui peuvent assister à ses conférences, de s’y rendre. Les ateliers sont très intéressant : www.agiletour.com…

Merci pour les informations, je vais lire ça de ce pas.

Bonne journée/soirée
Edité le 09/06/2010 à 03:42

Pour CMMI et agile je vois pas le souci, rien n’oblige une boite à faire une méthodo. Dans ma boite on est CMMI3, mais on fait de l’agile aussi et parfois du cycle en V (Mais c est vrai que c est plus une demande/imposition d’un client quand on a le choix suivant la taille c est agile ou cmmi). Faut pas être borné sur une méthodo et utilisé la plus adapté au besoin. Biensur ça implique d’avoir du personnel compétent sur chaque méthodo.

Concernant les dépassements systematique en V. Je suis pas convainku que en agile c est mieux. Je bosse dans la prestation de service et agile à le petit défaut que si en face le client ne connais pas ou est de mauvaise fois, ca peut vite partir en cacahouete sans une bonne gestion de projet… (tu me dira c vrai partout). Après je vois ça au nivo boite de prestat qui tourne bien et qui on des taux de réussite de projet dans les temps. J’ai aucune idée de comment fonctionne nos mauvais concurrents.

Enfin je vois pas en quoi Agile est mieux pour des petits projets ou alors faudrait définir le terme "petit ? en Semaine ? Mois ? Année ? Décénnie ?

Enfin des mois de specs ? Sur un projet de grand envergure tu peux pas attaquer sérieusement du dev sans passer un temps non négligeable en réunion avec le client pour bien définir le besoin et spécifier tous les détail, ensuite la rédaction de specs prend pas des mois non plus si on a un processe de reflexion construit entre le client et les formalisations de specs.
Enfin tu peux réduire les mois de specs avec des astuces simples comme les principes d’itérations ou les bon vieux lots.

Les méthodes agiles ne se limitent pas qu’au développement logiciel…

Enfin si tu “fais de l’agile”, je ne t’apprends rien.

C’est quand même la majeur partie du développement agile ?
Quoi que j’ai regardé Toyota semble faire pareil avec ses usines de voiture.

Oui :
Scrum : méthode agile de gestion de projet
XP : méthode agile de développement logiciel
TDD, TDR : techniques agiles de développement logiciel

Toyota, c’est -me semble-t-il- de là où vient le Lean Management.