Discussion :

[CaféFort]

On demande aux décideurs quel pourcentage de leurs projets a échoué, connu un succès mitigé ou réussi et ce sur les trois critères : fonctionnalités, coût et délais. Aucune raison d'avoir 100% de réussite.

Mais quels sont les décideurs dont tu parles ? (client d’un prestataire ? DSI ? « client » interne du service informatique ? Chef de projet ? …)

Il y a peu de temps, dans une très grande entreprise, un chef de projet qui m’a demandé « C’est quoi l’analyse ? ». L’échec était prévu d’avance, 4 personnes qui ne savent pas comment démarrer le projet … et la suite non plus. Ce fut un (gros) échec. Pourtant ce n’est pas la méthode agile qui était à remettre en question …

Est-ce que les critères de réussite/échec sont établis quelque part ? On peut faire dire ce qu’on veut aux chiffres, surtout quand on est dans un contexte imprécis et attention aux biais.

[Marco46]

Concernant la métaphore. C'est plutôt la tienne qui me semble assez irréelle. N'oublions pas que la finalité est de créer un produit logiciel qui sera stable. Alors autant amener cette stabilité le plus tôt possible, puisque de toute façon, stabilité il y aura (je ne pense pas que ton code s'auto-modifie). Et ce n'est pas du tout contradictoire avec le fait que l'application devra pouvoir évoluer ensuite, mais pas à 100%, ni à 50%, ni à 30 %, ni à ... etc.

Il s'agit de livrer un périmètre fonctionnel.

Le principe du développement à l'ancienne c'est de définir un périmètre fonctionnel, d'analyser, de concevoir, de développer, de recetter puis de livrer.
Le client arrive en bout de course lors de la livraison.
Ça produit ce que l'on appelle l'effet tunnel.

Le principe du développement agile, c'est de développer sur des cycles courts et de faire contribuer le donneur d'ordre à chaque fin de cycle (les fameux sprints). Le produit de chaque fin de sprint est livrable, fait l'objet d'une démo, et peut être mis en production à la demande du client (le product owner).

Cela permet de corriger, d'affiner le périmètre fonctionnel en court de route.

Si tu veux poursuivre dans ton sens, il faudrait déjà remettre ton message dans la bonne discussion et que tu énumères les causes de dérives auxquelles tu penses parce que j'aimerais vraiment en savoir plus sur "les vents, les courants ou tout avarie ou anomalie" que tu énonces dans le cadre du développement d'un produit qui au final, sera stable (à moins que tu adores les modifications en exploitation avec changement de structure de la base de données, conversions de formats, ... et qui coûtent extrêmement cher !! Qui peut se permettre cela ?).

Un de tes clients ne t'a jamais changé le périmètre fonctionnel en cours de développement ?
Le client ne s'est jamais trompé en exprimant son besoin ?
Tu n'as jamais mal compris ce que le client t'as demandé ?

Ton quote indiquerait que tu réponds "non" à chaque question. Ce qui fait littéralement de toi un extraterrestre.

Les réponses à ces questions étant systématiquement "oui", l'agile permet de répondre à ces problématiques.

Donc ton analogie avec un point de départ et un point d'arrivée avec une route bien tracée n'existe jamais dans le réel.
L'analogie avec la navigation en bateau est tout à fait pertinente.

Je redonne le titre de la discussion : "Une gestion de projet agile, rend-elle l'entreprise agile ?"

C'est encore un autre sujet. Il faudrait déjà que tu comprennes ce qu'est l'agile.

[CaféFort]

« Le client arrive en bout de course lors de la livraison. »

C’est plutôt caricatural … Comme ce qu’on me donne comme infos sur les méthodes agiles, mais dans le sens positif bien sûr .

« développement à l'ancienne », « les fameux sprints » …

hum, ça prédit déjà un fort manque d’objectivité.

« Un de tes clients ne t'a jamais changé le périmètre fonctionnel en cours de développement ?
Le client ne s'est jamais trompé en exprimant son besoin ?
Tu n'as jamais mal compris ce que le client t'as demandé ?

Ton quote indiquerait que tu réponds "non" à chaque question. Ce qui fait littéralement de toi un extraterrestre. »

Ok. Alors on va aller sur le terrain juridique, on avancera peut-être un peu. Tu parles de client, donc parlons du contrat. Quelles sont exactement les obligations du prestataire dans le cadre d’une prestation agile ?
Est-ce que j'aurai une réponse ... ???

« Donc ton analogie avec un point de départ et un point d'arrivée avec une route bien tracée n'existe jamais dans le réel.
L'analogie avec la navigation en bateau est tout à fait pertinente. »

Alors, déjà, mes propos ont une nouvelle fois été transformés et exagéré !!! Cela devient lassant.
Donc l’agilité, c’est pour vous (désolé, mais comme vous y tenez) « je ne sais pas quel est l’objectif, d’ailleurs il n’existe pas et on démarre sans rien connaître (relire les autres posts), toute l’équipe avance dans la nuit, le brouillard et la tempête qui ont été créé par d’autres personnes et en grande partie par le client, que l’agilité considère comme un « tas de … brouillard ». Cette fois c’est bon ?

Bah, mon point de vue est : « l’objectif existe, il n’est pas écrit mais il existe bien, d’ailleurs c’est la version finale que sera livrée » (relire + haut) et je gère les risques en amont du projet, je contractualise dans ce contexte sur de vrais engagements. Il y a aussi des changements en cours de route, aucun problème à cela. Et chacun engage sa responsabilité, ce qui d’ailleurs juridiquement est conforme (un détail ) et permet réellement de parler de réussite de projet.

Sans objectif, réussite = 0%.

« Une gestion de projet agile, rend-elle l'entreprise agile ?"

C'est encore un autre sujet. Il faudrait déjà que tu comprennes ce qu'est l'agile. »

Oui, comme à chaque fois que la question est à la fois fondamentale et montre que l’agilité n’y répond pas, je n’ai pas de réponse. Les big five s'intéressent beaucoup à cette question et elle est fondamentale ...

Résumé : Toujours la même rengaine et strictement aucun avis sur le thème de la discussion, comme d'hab quoi !!

[Marco46]

C’est plutôt caricatural … Comme ce qu’on me donne comme infos sur les méthodes agiles, mais dans le sens positif bien sûr .

[...]

hum, ça prédit déjà un fort manque d’objectivité.

Développement en cascade puis cycle en V. C'est ça le développement à l'ancienne. Non pas que ça soit pas pertinent dans certains cas mais juste que c'est les plus anciennes méthodes.

Tu es un modèle d'objectivité, je m'incline.

Ok. Alors on va aller sur le terrain juridique, on avancera peut-être un peu. Tu parles de client, donc parlons du contrat. Quelles sont exactement les obligations du prestataire dans le cadre d’une prestation agile ?
Est-ce que j'aurai une réponse ... ???

Quel rapport ? C'est comme si tu demandais quelles sont les obligations du prestataire dans le cadre d'une prestation de développement en java. La question est totalement hors de propos.

Alors, déjà, mes propos ont une nouvelle fois été transformés et exagéré !!! Cela devient lassant.
Donc l’agilité, c’est pour vous (désolé, mais comme vous y tenez) « je ne sais pas quel est l’objectif, d’ailleurs il n’existe pas et on démarre sans rien connaître (relire les autres posts), toute l’équipe avance dans la nuit, le brouillard et la tempête qui ont été créé par d’autres personnes et en grande partie par le client, que l’agilité considère comme un « tas de … brouillard ». Cette fois c’est bon ?

Non tu as faux. C'est pas lié à l'agile. C'est lié à la réalité des projets. Tu as déjà fait du développement professionnel ? L'agile est une réponse possible à ces problèmes.

Je redis autrement :

Ce n'est pas parce que le projet est développé en agile qu'on ne connait pas le point d'arrivée. C'est parce que l'on ne connait pas le point d'arrivée dans beaucoup de cas que l'on peut utiliser l'agile pour répondre à cette problématique.

Bah, mon point de vue est : « l’objectif existe, il n’est pas écrit mais il existe bien, d’ailleurs c’est la version finale que sera livrée »

La version finale diverge la plupart du temps par rapport à l'objectif initial. Tu parles comme un livre.

(relire + haut) et je gère les risques en amont du projet, je contractualise dans ce contexte sur de vrais engagements. Il y a aussi des changements en cours de route, aucun problème à cela. Et chacun engage sa responsabilité, ce qui d’ailleurs juridiquement est conforme (un détail ) et permet réellement de parler de réussite de projet.

Sans objectif, réussite = 0%.

La question du contrat n'est pas liée à l'usage de l'agile. Tu peux avoir plein de variétés de contrats. A commencer par le dev en régie ou au forfait. Quel rapport avec la manière de gérer le projet ?

Oui, comme à chaque fois que la question est à la fois fondamentale et montre que l’agilité n’y répond pas, je n’ai pas de réponse. Les big five s'intéressent beaucoup à cette question et elle est fondamentale ...

Résumé : Toujours la même rengaine et strictement aucun avis sur le thème de la discussion, comme d'hab quoi !!

L'agilité d'une entreprise ça n'a rien à voir avec le développement logiciel. Si tu veux absolument une réponse à ta question alors la réponse est non (à mon avis). Si une entreprise a des process rigides elle peut embaucher tous les scrummasters qu'elle veut ça n'y changera rien car elle n'est structurellement pas agile.

[pseudocode]

Bah, mon point de vue est : « l’objectif existe, il n’est pas écrit mais il existe bien, d’ailleurs c’est la version finale que sera livrée » (relire + haut) et je gère les risques en amont du projet, je contractualise dans ce contexte sur de vrais engagements. Il y a aussi des changements en cours de route, aucun problème à cela. Et chacun engage sa responsabilité, ce qui d’ailleurs juridiquement est conforme (un détail ) et permet réellement de parler de réussite de projet.
Sans objectif, réussite = 0%.

Un objectif est défini pour les deux types de méthode, mais il n'est pas du même ordre.

Comme tu le décris toi-même, l'objectif dans les méthodes structurées (waterfall, V, W...) est l'état final du PRODUIT (version finale). Généralement c'est une liste de critères évaluables sur le produit: délai de livraison du produit final, cout total du développement , fonctions présentes dans le produit final... Ca implique donc d'avoir défini tous ces critères AVANT de commencer le développement (définition contractuelle = Cahier des charges).

L'objectif dans les méthodes agiles est l'état final du PROJET. Les critères évaluables sont la charge totale consommée (Function/Story Points), le nombre/rythme des livraisons effectuées, la charge consommée par livraison... La aussi, ca implique d'avoir défini ces critères AVANT de commencer le développement (définition contractuelle = Prestation fournie).

En gros, les méthodes structurées visent une garantie de résultats alors que les méthodes agiles visent une garantie de moyens.

Sur le papier, la garantie de résultats semble un bien meilleur objectif. Mais dans les faits, on a rarement une définition complète et immuable du produit avant de commencer le développement. Donc soit on accepte la faible probabilité d'atteindre le résultat, soit on revoit périodiquement la définition du produit... Dans les deux cas ca va passer par des avenants au contrat, souvent douloureux et sources de conflit. C'est tellement habituel qu'on a créé des méthodes pour gérer ces deux cas (itération/convergence, change-management...)

Dans les faits, la garantie de moyen est plus appropriée pour de la prestation de service. Il est plus facile pour le client et le prestataire de définir les moyens qui sont demandés/fournis (budget, Jour*Homme, compétences). En contrepartie on accepte que le "résultat" (produit final) ne soit pas contractualisé.

[CaféFort]

La question du contrat n'est pas liée à l'usage de l'agile. Tu peux avoir plein de variétés de contrats. A commencer par le dev en régie ou au forfait. Quel rapport avec la manière de gérer le projet ?

(...)

L'agilité d'une entreprise ça n'a rien à voir avec le développement logiciel.

Les contrats ont bien évidemment une grande importance. Sans objectif précis, il ne peut pas y avoir de notion de réussite dont l’agilité « se gargarise » ... sans résultat attendu .

Pas d’objectif => pas de réussite, c’est pourtant simple non ? (comme dans un livre ) !!

C’est le contrat qui permet de savoir s’il y a une réussite.
En régie, on vend du temps, pas d’objectif lié au projet, pas de notion de réussite.
Par contre, au forfait, on vend un résultat.

Alors l’agilité, c’est régie ou forfait ? (et donc ... ).

Par ailleurs :

Beaucoup d’entreprises sont du secteur tertiaire et donc leur efficacité et leur réactivité est très dépendante de leur informatique.
Si l’informatique ne peut pas évoluer, l’entreprise ne sera pas agile. La question de la discussion est en fait fondamentale. C'est même l'un des grands thèmes des big five.
J’aurais aimé avoir l’avis des « agiles » mais pas ce que je lis en permanence : « tu n’y connais rien », « on fait ce qu’il y a de mieux », « on n’a que des réussites », … peu crédible tout cela et surtout très inutile !!

C'est dommage.

[CaféFort]

Merci pour ta contribution, pour ta clarté et pour la modération de tes propos qui me semblent très justes et correspondent à la réalité et à ce que je pense.

D'ailleurs, il y a longtemps dans cette discussion, j'évoquais que je comprenais très bien pourquoi les méthodes agiles sont apparues.

De là à dire que tout est super dans l'agile, qu'il n'y a que des avantages, que des réussites, en démarrant dans le brouillard et en affrontant les tempêtes et que c'est toujours un grand succès ... heu c'est tout sauf réaliste, limite agaçant !

Je ne l'ai jamais entendu de tels propos de la part des autres méthodes, pourtant il y a de grandes réussites ...

A mon avis, l'idéal se trouve certainement dans un mix des deux démarches.

[Marco46]

Alors l’agilité, c’est régie ou forfait ? (et donc ... ).

Le développement orienté objet c'est régie ou forfait ? Voilà le genre de question que tu poses.

Beaucoup d’entreprises sont du secteur tertiaire et donc leur efficacité et leur réactivité est très dépendante de leur informatique.

On est d'accord.

Si l’informatique ne peut pas évoluer, l’entreprise ne sera pas agile.

Évidemment mais ce n'est pas une condition suffisante. Ça répond à ta question initiale ?

[pseudocode]

De là à dire que tout est super dans l'agile, qu'il n'y a que des avantages, que des réussites, en démarrant dans le brouillard et en affrontant les tempêtes et que c'est toujours un grand succès ... heu c'est tout sauf réaliste, limite agaçant !

Ces commentaires élogieux sont compréhensibles si on se place uniquement du point de vue du développement logiciel (binaire). Et cela pour la bonne raison qu'il est difficile d'avoir la définition complète et immuable du "logiciel seul". Le logiciel est habituellement une partie d'un produit plus gros (un appareil, un service, ...).

(Note: je prêche pour ma paroisse, l'architecture système )

Dans les méthodes structurées, la définition du logiciel ne peut donc apparaitre qu'après avoir fini la définition/analyse/conception de ce produit plus gros. Mais pour réduire les délais, on veut souvent commencer les développements logiciels avant d'avoir intégralement fini la conception du produit.




Les méthodes agiles contournent ce problème en incluant de fréquentes itérations de compréhension du produit (user story) et d'adaptation du logiciel déjà codé (refactor).

Les méthodes agiles sont donc bien plus adaptées à la problématique rencontrée par les équipes de développement logiciel, surtout lorsqu'on compare avec les méthodes structurées qui partent du principe que tout le travail préparatoire (définition/analyse/conception du produit) a été intégralement fait alors que c'est rarement le cas.

Pour répondre à la question initiale "Une gestion de projet Agile rend-elle l’entreprise agile ?", je dirais NON car l'entreprise est un ensemble de métiers et chaque métier a ses propres problématiques. La méthode Agile résout les problématiques du développement logiciel, mais pas forcément celle du développement produit et encore moins celles des métiers transverses au développement (marketing, RH, finance, ... )

[Luckyluke34]

En gros, les méthodes structurées visent une garantie de résultats alors que les méthodes agiles visent une garantie de moyens.

Pas d'accord. Ce n'est pas du ressort d'une méthodologie logicielle de fixer le niveau de garantie du contrat passé entre un éventuel client et un éventuel prestataire (qui n'existent pas toujours), ce sont deux choses distinctes.

C'est cette façon même de présenter les choses qui fait que les méthodes agiles sont souvent vues comme non professionnelles ("on fait ce qu'on peut"). C'est une idée reçue.

Rien n'empêche le donneur d'ordre de demander à l'équipe de développement de s'engager sur le résultat de la réalisation d'une ou plusieurs fonctionnalités, sur des critères définis (tests d'acceptance) et au moment le plus responsable, en début d'itération, quand a une idée suffisamment claire du détail des fonctionnalités et du rythme de croisière de l'équipe pour pouvoir estimer ce qu'elle va réaliser.

Par ailleurs, sur les méthodes traditionnelles, le simple fait d'évoquer (je cite) qu'"on accepte la faible probabilité d'atteindre le résultat" décrédibilise totalement l'idée de demander un engagement de résultats. Si la chance d'atteindre le résultat est si mince (c'est toi qui le dis, pas moi), je me demande pourquoi on considère ça comme un concept qui vaille encore la peine d'en parler.

[Luckyluke34]

De là à dire que tout est super dans l'agile, qu'il n'y a que des avantages, que des réussites, en démarrant dans le brouillard et en affrontant les tempêtes et que c'est toujours un grand succès ... heu c'est tout sauf réaliste, limite agaçant !

Ouais enfin en même temps personne ici ne dit ça.

Je ne l'ai jamais entendu de tels propos de la part des autres méthodes, pourtant il y a de grandes réussites ...

Je te confirme que si, des marchands de poudre de perlimpinpin il y en a partout. Malheureusement, il y aura toujours des boîtes pour survendre une méthodo pour leur propre profit.

[souviron34]

En gros, les méthodes structurées visent une garantie de résultats alors que les méthodes agiles visent une garantie de moyens.

Comme LuckyLuke, je suis d'accord avec le reste de ce que tu dis mais pas avec ça..

Pas d'accord. Ce n'est pas du ressort d'une méthodologie logicielle de fixer le niveau de garantie du contrat passé entre un éventuel client et un éventuel prestataire (qui n'existent pas toujours), ce sont deux choses distinctes.

Les contrats ont bien évidemment une grande importance. Sans objectif précis, il ne peut pas y avoir de notion de réussite dont l’agilité « se gargarise » ... sans résultat attendu .
...
C’est le contrat qui permet de savoir s’il y a une réussite.

Tout dépend de quel point de vue on se place...

Si tu te places du point de vue d'une boite "traditionnelle" qui n'en a rien à foutre de ces cochons de clients qui n'ont qu'à payer, oui..

Si tu te places du point de vue du client, pas du tout...

Je vais te donner un exemple :

J'ai été 8 ans prestataire (à mon compte, équivalent auto-entrepreneur) du Gouvernement Fédéral du Canada, pour faire un logiciel national, critique (avec fermetures d'aéroports, évacuations d'usines, etc). Pourquoi ai-je été pris, alors qu'ils avaient déjà des contrats avec de grosses sociétés de service ??

Simplement parce qu'ils en avaient ras-le-bol (et que c'était les sous du contribuable) que le jour marqué dans le contrat, negocié 2 ans plus tôt, la boîte disait "bon ben voilà. C'est fini. Maintenant si vous voulez des modifs vous devrez payer". Parce que ces boîtes-là marchaient au forfait, mais en mode V. L'analyse faite 18 ou 24 ou 36 mois plus tôt ne correspondait pas exactement à la demande, même si celle-ci n'avait pas évolué, simplement parce que n'étant pas en contact constant avec les utilisateurs, les analystes n'avaient fait qu'interviewer les différents partenaires... Et qu'en interviewant, on oublie plein de choses, des choses automatiques, des choses qui pour l'utilisateur sont tellement usuelles qu'il ne les remarque plus, que ce soit des calculs, des a-priori, des séquences dans le travail, etc etc..

Avec moi, le contrat était une obligation de résultat, au forfait, MAIS avec la garantie que je serai dans les locaux en permanence et en contact permanent (et en tests permanents) avec les utilisateurs..

Résultat : 8 ans de contrat, et le logiciel a été utilisé opérationnellement pendant 14 ans dans tous les bureaux de météo du Canada avec la satisfaction totale des utilisateurs, et du donneur d'ordre.



Autre exemple, dans le médical : des groupements hospitaliers, avec le gouvernement, définissent un Cahier des Charges. Une société de service est choisie, applique le cycle en V. 12 ans plus tard, une grève des médecins et des infirmières est en cours parce que ils ne veulent même pas tester le logiciel tellement c'est merdique... L'architecture (indépendante de la fonctionalité demandée, uniquement décidée par l'informatique) ne permet pas de remplir la fonctionalité de la manière attendue.. Oui elle la remplit, mais absolument pas de la manière de faire usuelle.. Par exemple, une prescription compliquée qu'un cardiologue mettait 12 minutes à faire à la main il lui faut 45 minutes avec le logiciel... Cette équipe "en V' contenait 60 personnes et avait travaillé 12 ans..

En un an avec 6 personnes, mais en contact permanent avec les utilisateurs, nous avons réussi à faire un prototype couvrant 70% de la fonctionalité que les médecins et infirmières voulaient acheter (alors que ce n'était que le prototype).

Voila 2 exemples où, malgré l'agilité utilisée, le contrat était bien une obligation de résultat (dans le médical c'était que la prescription fasse réellement gagner du temps à toutes les professions pouvant prescrire), une obligation de délai, et une obligation de coût..

Et pourtant les contrats des boîtes "en V" auraient pu être qualifiés de "réussite", puisqu'ils s'étaient conclus... Simplement le client n'était pas satisfait...



Encore une fois, l'agilité est un moyen.... Les contrats et ce qu'ils contiennent n'ont rien à voir... C'est simplement le moyen le plus efficace pour garantir la satisfaction du client le plus rapidement possible, sans risquer de fortes mésententes ou backlash plus tard..

C'est une manière de gérer l'équipe, le temps, et la demande du client au mieux, pas de se passer de docs ou autre..

Bien entendu c'est d'autant plus efficace comme différence avec le V que le projet est gros (comme mes exemples ci-dessus)....



Quant à la question titre, la réponse dépend de quel type d'entreprise tu parles : si c'est une entreprise de manière générale, la réponse est non ; si c'est une entreprise de logiciel "à taille humaine" (sans doute jusqu'à 50-100 personnes) la réponse est sans doute oui (pas plus que 5 à 10 personnes en administratif) ; au delà la réponse est bien évidemment non... C'est une méthode de gestion de projet informatique... Ca s'arrête là...

[pseudocode]

Pas d'accord. Ce n'est pas du ressort d'une méthodologie logicielle de fixer le niveau de garantie du contrat passé entre un éventuel client et un éventuel prestataire (qui n'existent pas toujours), ce sont deux choses distinctes. C'est cette façon même de présenter les choses qui fait que les méthodes agiles sont souvent vues comme non professionnelles ("on fait ce qu'on peut"). C'est une idée reçue.

Ca c'est ton interprétation. De mon point de vue, offrir une garantie de moyen c'est tout a fait professionnel.
C'est même parfaitement adapté au monde du travail: Prestation, CDD/CDI sont une contractualisation des moyens (capacités) à fournir et pas du résultat à atteindre.

Et ce n'est pas "on fait ce qu'on peut", mais "on fournit l'effort prévu".

Rien n'empêche le donneur d'ordre de demander à l'équipe de développement de s'engager sur le résultat de la réalisation d'une ou plusieurs fonctionnalités, sur des critères définis (tests d'acceptance) et au moment le plus responsable, en début d'itération, quand a une idée suffisamment claire du détail des fonctionnalités et du rythme de croisière de l'équipe pour pouvoir estimer ce qu'elle va réaliser.

Bien sur, on peut faire cela. Mais c'est déjà s'éloigner un peu des méthodes agiles et rentrer dans des méthodes structurées itératives (W, RUP).
Plus on est capable de définir tôt les tests d'acceptance, plus on est capable de partir en analyse/conception/implémentation.

Par ailleurs, sur les méthodes traditionnelles, le simple fait d'évoquer (je cite) qu'"on accepte la faible probabilité d'atteindre le résultat" décrédibilise totalement l'idée de demander un engagement de résultats. Si la chance d'atteindre le résultat est si mince (c'est toi qui le dis, pas moi), je me demande pourquoi on considère ça comme un concept qui vaille encore la peine d'en parler.

Bah oui, c'est malheureux mais c'est souvent comme cela. Pour les projets dans des domaines très réglementés (Chimie, Aéronautique, Médical, Énergie...) qui nécessitent une certification du produit, les autorités demandent (et même imposent) qu'on suive une méthode structurée pour le développement du logiciel (généralement le V-Model). Et pourtant, il suffit de regarder la presse pour voir que nombre de ces projets sont généralement en retard de livraison, en dépassement du budget, en limitation de fonctionnalités, ....

Alors pourquoi les utiliser si elles ne fonctionnent pas (très) bien ? Je dirais sans doute car on a maintenant une certaine expérience de ces méthodologies. Les industriels savent comment les définir/gérer et les autorités savent comment les auditer/contrôler. Expliquer au CEA que le logiciel principal de surveillance du coeur de l'EPR a été développé avec une methode Agile, c'est s'exposer a un refus de mise en production.

[Luckyluke34]

Ca c'est ton interprétation. De mon point de vue, offrir une garantie de moyen c'est tout a fait professionnel.
C'est même parfaitement adapté au monde du travail: Prestation, CDD/CDI sont une contractualisation des moyens (capacités) à fournir et pas du résultat à atteindre.

On est bien d'accord. J'ai bien dit "les méthodes agiles sont souvent vues comme..." Je ne faisais que refléter l'état d'esprit et les dires qui constituent hélas encore la majorité chez les décideurs aujourd'hui. L'obligation de résultat reste encore ancrée dans les esprits comme étant la seule solution vraiment sécurisante. De plus, opposer résultats et moyens dans la même phrase fait peur.

Bien sur, on peut faire cela. Mais c'est déjà s'éloigner un peu des méthodes agiles et rentrer dans des méthodes structurées itératives (W, RUP).

Ben non, pourquoi ? Justement c'est de la cuisine contractuelle ou politique interne, c'est indépendant de la méthodologie.

Bah oui, c'est malheureux mais c'est souvent comme cela. Pour les projets dans des domaines très réglementés (Chimie, Aéronautique, Médical, Énergie...) qui nécessitent une certification du produit, les autorités demandent (et même imposent) qu'on suive une méthode structurée pour le développement du logiciel (généralement le V-Model). Et pourtant, il suffit de regarder la presse pour voir que nombre de ces projets sont généralement en retard de livraison, en dépassement du budget, en limitation de fonctionnalités, ....

Alors pourquoi les utiliser si elles ne fonctionnent pas (très) bien ? Je dirais sans doute car on a maintenant une certaine expérience de ces méthodologies. Les industriels savent comment les définir/gérer et les autorités savent comment les auditer/contrôler. Expliquer au CEA que le logiciel principal de surveillance du coeur de l'EPR a été développé avec une methode Agile, c'est s'exposer a un refus de mise en production.

+1000. Mais ça évolue tout doucement. Le Department of Defense aux Etats-Unis commence par exemple à se tourner vers les méthodes agiles.

[el_slapper]

Le fiasco du F35 leur a sans doute mis du plomb dans la tête(oui, je sais, pour des militaires, c'est du très mauvais humour. C'est voulu). Maintenant, dans un paniers de crabes de taille galactique comme le DoD, que ça soit réellement agile et qu'en plus ça marche, j'ai des doutes. Mais au moins, ils essayent d'avancer.