Discussion :

[Stéphane le calme]

Les développeurs sont ils condamnés à ne jamais respecter leurs cahiers des charges ?
un entrepreneur estime que les temps prévus doivent être multipliés par trois

Dans une ère où le numérique occupe une place de choix dans les cultures du monde entier, les métiers du génie logiciel bénéficient de la forte demande en applications de toutes sortes.

Les jeux vidéo et autres applications sont le résultat d’un dur travail en interne qui nécessite rigueur et discipline. Avant de se lancer dans la tâche, les ingénieurs doivent procéder à une analyse de projet pour établir un cahier des charges où il sera fait mention entre autre des besoins, des exigences et des contraintes.

Michael Wolfe, un investisseur américain dans de nombreuses start-ups (Vontu, Kana, I/PRO, Pipewise), pense que les développements logiciels prennent régulièrement deux ou trois fois plus de temps que prévu.

Avec une analogie assez amusante, il prend l’exemple d’une randonnée sur la côte de San Francisco à Los Angeles pour rendre visite à ses amis à Newport Beach. Tout est méticuleusement préparé sur la carte, les horaires sont déjà prévus d’avance ; la distance totale faisant 400 miles, le nombre d’heure de marche par jour est estimé à 10 à raison de 4 miles par heure soit 10 jours de marche au total.

Mais voilà que sur le terrain il y a plein de contours imprévus qui rallongent encore la route de 100 miles. Un coup de fil est passé aux amis pour repousser un peu le jour d’arrivée. À cause du sable, de la fatigue, la vitesse est plus lente que prévue ; 2 miles par heure, la moitié de la performance envisagée. Un autre coup de fil pour repousser. Une tempête s’abat le lendemain rendant toute marche impossible. Un enchaînement d’évènements qui rendent le voyage plus long et plus pénible que « sur le papier ».

Source : Quora

Et vous ?

Qu’en pensez-vous ? Les délais doivent-ils systématiquement être repoussés ?

[moldavi]

Bonjour.

J'ai souvent remarqué que le délai de développement été connu seulement une fois le développement terminé...

[martopioche]

2 remarques :
- l'analogie avec la côte de SF et la rando a déjà été utilisée, intéressant de la ressortir...
- Dans cette ordre de Grandeur, Kirk a eu la puce à l'oreille que Scotty devait sa réputation de faiseur de miracles en multipliant systématiquement ses évaluations par 4.

Sinon, tout développeur rebondit là dessus sur les thèmes "Méthodes Agiles", "Scrum", tout ça... Moi je rebondirai sur le TedxUCSD talk de Guy Kawazaki sur ce qu'il a appris de Steve Jobs et tout particulièrement le point "Real enterpreneurs ship" et son observation de comment ça se passe à la Sillicon Valley : on livre, puis on débeug... Et ça converge avec le point de vue de développeur. On a beau avoir le projet final, on prendra du retard, mais l'objectif devrait être d'avoir quelque chose de livrable à une date T et d'arrêter de se focaliser sur un projet complet, de toutes façons, il est mal définit.

[Traroth2]

2 remarques :
- l'analogie avec la côte de SF et la rando a déjà été utilisée, intéressant de la ressortir...
- Dans cette ordre de Grandeur, Kirk a eu la puce à l'oreille que Scotty devait sa réputation de faiseur de miracles en multipliant systématiquement ses évaluations par 4.

Sinon, tout développeur rebondit là dessus sur les thèmes "Méthodes Agiles", "Scrum", tout ça... Moi je rebondirai sur le TedxUCSD talk de Guy Kawazaki sur ce qu'il a appris de Steve Jobs et tout particulièrement le point "Real enterpreneurs ship" et son observation de comment ça se passe à la Sillicon Valley : on livre, puis on débeug... Et ça converge avec le point de vue de développeur. On a beau avoir le projet final, on prendra du retard, mais l'objectif devrait être d'avoir quelque chose de livrable à une date T et d'arrêter de se focaliser sur un projet complet, de toutes façons, il est mal définit.

Ca ne marche quand dans une certaine mesure. Dans tout projet logiciel, il y a un "coeur" de fonctionnalités essentielles sans lesquelles le logiciel est inutilisable. De manière saisissante, il est rare que les projets hiérarchisent les fonctionnalités entre les points indispensables et les autres. Il faut dire que quand on discute avec les commerciaux, on voit bien qu'ils ne savent pas eux-même le plus souvent. Dans un projet récent, un site web avec un moteur de recherche, l'autocomplétion du champ de recherche par une frappe prédictive est ainsi devenu un point bloquant sans lequel il était impensable de mettre en production. En tant qu'utilisateur de sites web, vous trouvez ça absolument indispensable, vous ?

[el_slapper]

Là tu m'intéresses. Je voyais Agile de loin comme une méthode à l'arrache, mais tu dis que c'est une manière de penser. J'ai un responsable qui m'a appris à éviter l'effet tunnel, par exemple livrer un projet avec 80% des fonctionnalités demandées pour maintenant, plutôt que 100% des fonctionnalités dans 2 ans.

Ben, en gros, c'est la manière de penser qui convient. Après, on peut la structurer avec des méthodes agiles, genre Scrum, qui imposent de livrer un truc à intervalles réguliers. Mais l'important, c'est bel et bien de chercher un feedback rapide, pour détecter très vite quand on fait fausse route.

Mais concrètement, et c'est là ma question car lire le manifesto ce n'est oas très parlant car théorique, est-ce que tu as, ou est-ce qu'il existe une comparaison du même projet avec la méthode en V et la méthode Agile pour que je comprenne ?

Pas à ma connaissance. C'est toute la difficulté de la démarche agile : il ne suffit pas de lire le petit manuel. C'est quelque chose qui se pratique. Du Scrum appliqué à l'aveugle, ou on suit scrupuleusement le petit manuel sans se poser de questions, ça donne de mauvais résultats aussi. Quelqu'un qui n'a aucun talent ne pourra jamais faire du bon travail. Je n'ai jamais compris pourquoi la mode était au 4-2-3-1 au lieu du 4-4-2, c'est pourquoi je ne serait jamais un bon entraineur de football.

Le truc, c'est quand même de limiter la doc au strict minimum. Exemple après le paragraphe suivant.

Sachant que même sans connaitre Agile, on n'est non plus obliger de faire un cycle en V dans les moindre recoins, c'est-à-dire éviter certains projets bureaucratique qui font certes travailler plus de gens, mais rendent risibles leur cout démesuré quelques fois.

+1000.

Tous les projets ne se prêtent pas forcément à une méthode agile, avec livraisons partielles. Spécialement, quand on fait une refonte technique, c'est en une fois : en Juillet, on passe par la vieille imprimante, en Aout, on passe par la nouvelle.

Sur ce projet-là(170 jours de mon coté, c'est-à-dire l'extraction et le formatage des données de sortie), j'avais un début, et une fin. Mais on m'a foutu la paix. On ne m'a pas demandé d'écrire à l'avance tout ce que j'allais faire. J'ai fait le strict minimum : un dessin de chaine décrivant l'architecture des composants, puis un récapitulatif des formats de sortie, avec le composants qui génère chaque donné.

Tout le reste, est dans le code. Nulle part je n'ai documenté le calcul de la taxe d'assurance pour les contrats automobiles. Ou le montant maximal permettant l'émission d'un TIP. Ce genre de documentation coute cher, se perd, est très vite obsolète. Le code ne peut pas se le permettre : si il est faux, on le corrige.

Quand je me suis aperçu que j'avais besoin d'un outillage pour pouvoir tester mes valeurs(en comparant les anciennes valeurs aux nouvelles), j'ai demandé un mois. On me l'a donné, alors qu'il n'était pas planifié. Résultat : 1,5% de dépassement de budget, une livraison à la date prévue, et une seule anomalie en production.

Pourtant, on était dans un espèce de cycle en V : j'ai fait le reverse engineering(le code avait 36 ans d'âge, autant dire non documenté), la MOA en a tiré des specs, j'ai codé les specs, j'ai testé unitairement, l'homologation est passée derrière, et j'ai livré en prod. Mais c'était souple. A tout moment, on pouvait dire "tiens, ça c'est faux, il faut corriger", et ça prenait 15 minutes. La présence d'un outillage de tests automatique permettait de valider en masse, et de detecter immédiatement les regressions.

La méthode était linéraire, mais la démarche était agile. Donc c'était plus facile et moins cher. La seule documentation était celle indispensable : le dessin de chaine(pour comprendre ce qui se passe tous les mois), et la liste des données et leur programme de calcul(tiens, cette donnée est fausse, ou diable est-elle calculée). Ca n'était pas du cowboy, dans le sens ou on suivait ce qui se faisait. Et quelqu'un qui devait reprendre pouvait le faire, avec ce qu'il faut. Et surtout pas plus.

Cowboy, pour moi, c'est "je fais ce que je veux et je ne documente pas". J'ai fait valider mon archi par la chef de projet(qui m'a fait corriger deux-trois petits trucs pour conformité avec les standards locaux). J'ai documenté l'essentiel. On a relu mon code(et j'ai fait 2-3 remises au standards). C'est un processus, pas du cowboy. Mais c'est léger. Et surtout, c'est mature : ça fournit le service demandé au moindre cout dans les moindres délais

[martopioche]

Ca ne marche quand dans une certaine mesure. Dans tout projet logiciel, il y a un "coeur" de fonctionnalités essentielles sans lesquelles le logiciel est inutilisable. De manière saisissante, il est rare que les projets hiérarchisent les fonctionnalités entre les points indispensables et les autres. Il faut dire que quand on discute avec les commerciaux, on voit bien qu'ils ne savent pas eux-même le plus souvent. Dans un projet récent, un site web avec un moteur de recherche, l'autocomplétion du champ de recherche par une frappe prédictive est ainsi devenu un point bloquant sans lequel il était impensable de mettre en production. En tant qu'utilisateur de sites web, vous trouvez ça absolument indispensable, vous ?

Exemple très intéressant car ce type de qualification (point bloquant ou non) devrait être définit par l'Usex... Ou la priorité par le marketing. Finalement, est-ce que les clients (donc les commerciaux) se sont investi dans la réalisation ? Car si ils reviennent avec un NoGo à cause du choix d'avoir une autocompletion, le "dev" a fait son job. Et à mon sens, là c'est une erreur commerciale : en attendant, le site n'est pas en ligne, il ne gagne pas en notoriété, la boite continue de perdre de l'argent (ou de ne pas en gagner) alors que la mise en ligne n'aurai pas empêché d'améliorer et faire un upgrade. We ship, then we test...

[Traroth2]

Exemple très intéressant car ce type de qualification (point bloquant ou non) devrait être définit par l'Usex... Ou la priorité par le marketing. Finalement, est-ce que les clients (donc les commerciaux) se sont investi dans la réalisation ? Car si ils reviennent avec un NoGo à cause du choix d'avoir une autocompletion, le "dev" a fait son job. Et à mon sens, là c'est une erreur commerciale : en attendant, le site n'est pas en ligne, il ne gagne pas en notoriété, la boite continue de perdre de l'argent (ou de ne pas en gagner) alors que la mise en ligne n'aurai pas empêché d'améliorer et faire un upgrade. We ship, then we test...

Idéalement, une bonne méthode serait de faire exactement l'inverse que ce qui a été fait dans le projet dont je parle : choisir le minimum de fonctionnalité, vraiment juste ce qu'il faut pour que l'appli puisse remplir son rôle et qu'on puisse mettre en prod. Ensuite, on enrichit. Ca a l'avantage supplémentaire de permettre d'avoir du feedback des utilisateurs et de développer moins de fonctionnalités inutiles (vous savez, ces fonctionnalités sur lesquelles vous passez beaucoup de temps, et 6 mois après la mise en prod, on se rend compte que PERSONNE ne s'en sert, parce que ça ne correspond à aucun besoin...)

[lvr]

Idéalement, une bonne méthode serait de faire exactement l'inverse que ce qui a été fait dans le projet dont je parle : choisir le minimum de fonctionnalité, vraiment juste ce qu'il faut pour que l'appli puisse remplir son rôle et qu'on puisse mettre en prod. Ensuite, on enrichit. Ca a l'avantage supplémentaire de permettre d'avoir du feedback des utilisateurs et de développer moins de fonctionnalités inutiles (vous savez, ces fonctionnalités sur lesquelles vous passez beaucoup de temps, et 6 mois après la mise en prod, on se rend compte que PERSONNE ne s'en sert, parce que ça ne correspond à aucun besoin...)

Eaxctement. C'est parfois difficile de faire comprendre au client, surtout lorsqu'on a faire à des clients inexpérimentés.

Ma petite recette pour avoir des budgets pas trop foireux (et juste pour la partie développement):
- Ajouter de 10 à 20% aux estimations faites par mes développeurs,
- Ajouter 25% pour les corrections suite aux tests,
- Ajouter 10% à 20% pour absorber les changements de spécifications de la part du client pendant la phase de réalisation.

Ca donne des budgets relativement juste.
Mais cela dépend, à la base, de la capacité des développeurs à donner rapidement des estimations correctes du travail à faire, et (tout aussi rapidement) de remonter les incohérences et incomplétudes dans les spécifications.

Parfois, cependant, être hors budget est voulu, car le budget de base est trop élevé et effraye le client. On tape donc plus bas, sachant qu'on va dépasser.

[JackIsJack]

S'il suffisait de multiplier par 4 (ou un facteur quelconque déterminable), il n'y aurais plus aucun problème.

La loi de Hofstadter est plus profonde : « Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter. ». C'est ça qui est bon !

[Paul TOTH]

Bonjour.

J'ai souvent remarqué que le délai de développement été connu seulement une fois le développement terminé...

S'il suffisait de multiplier par 4 (ou un facteur quelconque déterminable), il n'y aurais plus aucun problème.

La loi de Hofstadter est plus profonde : « Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter. ». C'est ça qui est bon !

tout est dit

[arnolem]

On peut s'engager sur un périmètre ou sur un délai mais pas sur les deux a la fois.
De plus, je rencontre systématiquement le problème inverse ou les porteurs de projets me demandent d'avoir le projet toujours plus tôt. Au delà de 2 mois de délai, c'est difficile de signer un projet web.

[el_slapper]

C'est un peu toujours le même débat, avec les mêmes arguments, qui portent juste sur un aspect différent. Mais, fondamentalement, un projet informatique est un projet tordu. Une "analyse de projet pour établir un cahier des charges où il sera fait mention entre autre des besoins, des exigences et des contraintes" n'est donc pas possible, en tous cas pas sans trou, erreurs ou décalages.

En outre, l'expérience montre que le principal facteur de succès ou d'echec(hormis la taille brute, qui est un inconvénient) n'est pas la méthodologie, mais le facteur humain.

Par conséquent, un développement informatique sérieux partira sur l'idée qu'on ne fait pas de la production mais de la conception, qu'une approche adaptative est nécéssaire, et que "agile" est bien plus une manière de penser qu'une méthodologie.

A celà, on rajoutera les exigences contradictoires des donneurs d'ordre("je veux un site mieux qu'Ebay en moins de deux mois", pour reprendre la situation d'arnolem). Exemple en cours : la recette sur un projet technique important est en retard. Raison immédiate : on a trouvé des anomalies qui ont retardé la recette. Cause profonde : la direction a exigé qu'on fasse un planning "si tout va bien", parceque de toutes façons les programmeurs auront tout bien testé, et que la recette ne trouvera quasiment pas d'anomalies.....

Mon point de vue à moi c'est que l'informatique est un domaine de l'invisible. On ne sait pas ou on va, on a bien quelques techniques, mais il faut sans cesse les adapter, au contexte technique, fonctionnel, ou politique. Dans ces conditions-là, les estimations ne seront jamais plus que des estimations, ayant la même valeur que les pronostics sportifs(scoop : la Colombie va gagner la coupe du monde 1994).

[phili_b]

Par conséquent, un développement informatique sérieux partira sur l'idée qu'on ne fait pas de la production mais de la conception, qu'une approche adaptative est nécéssaire, et que "agile" est bien plus une manière de penser qu'une méthodologie.

Là tu m'intéresses. Je voyais Agile de loin comme une méthode à l'arrache, mais tu dis que c'est une manière de penser. J'ai un responsable qui m'a appris à éviter l'effet tunnel, par exemple livrer un projet avec 80% des fonctionnalités demandées pour maintenant, plutôt que 100% des fonctionnalités dans 2 ans.

Mais concrètement, et c'est là ma question car lire le manifesto ce n'est oas très parlant car théorique, est-ce que tu as, ou est-ce qu'il existe une comparaison du même projet avec la méthode en V et la méthode Agile pour que je comprenne ?

Sachant que même sans connaitre Agile, on n'est non plus obliger de faire un cycle en V dans les moindre recoins, c'est-à-dire éviter certains projets bureaucratique qui font certes travailler plus de gens, mais rendent risibles leur cout démesuré quelques fois.

[pmithrandir]

Mais concrètement, et c'est là ma question car lire le manifesto ce n'est oas très parlant car théorique, est-ce que tu as, ou est-ce qu'il existe une comparaison du même projet avec la méthode en V et la méthode Agile pour que je comprenne ?

Pour moi, la méthode agile est surtout une façon différente de penser. Elle propose plusieurs outils, mais le but est toujours le même.

Au lieu de donner une carte à un développeur en espérant qu'il sache la lire et se repérer... pour se rendre compte au bout de 6 mois qu'il est à 1000km de la destination... on revient le voir régulièrement pour lui mettre un coup de rêne à gauche ou à droite histoire qu'il continue a cheminer globalement dans la bonne direction.
Au final, il ne sera pas à la ligne d'arrivée bien sur(15 jours ca suffit pour se planter un peu) mais il devrait être a moins de quelques km de celle ci...

Après, il y a aussi une part importante qui est la responsabilisation du client... si il veut que son projet réussisse, il faut aussi qu'il s'investisse. On se rend en effet compte que c'est vraiment dans la conception d'un système qu'on en découvre les incohérence et les limites... qui sont bien plus simple à réparer tout de suite qu'une fois que tout le reste est basé dessus.

[GPPro]

Pour moi, la méthode agile est surtout une façon différente de penser. Elle propose plusieurs outils, mais le but est toujours le même.

Au lieu de donner une carte à un développeur en espérant qu'il sache la lire et se repérer... pour se rendre compte au bout de 6 mois qu'il est à 1000km de la destination... on revient le voir régulièrement pour lui mettre un coup de rêne à gauche ou à droite histoire qu'il continue a cheminer globalement dans la bonne direction.
Au final, il ne sera pas à la ligne d'arrivée bien sur(15 jours ca suffit pour se planter un peu) mais il devrait être a moins de quelques km de celle ci...

Après, il y a aussi une part importante qui est la responsabilisation du client... si il veut que son projet réussisse, il faut aussi qu'il s'investisse. On se rend en effet compte que c'est vraiment dans la conception d'un système qu'on en découvre les incohérence et les limites... qui sont bien plus simple à réparer tout de suite qu'une fois que tout le reste est basé dessus.

Euh ce n'est pas forcément le développeur qui merde hein... On peut aussi interpréter ça comme étant un moyen de s'assurer et que le client voulait aller à A et non à un B qui serait à 1000 bornes du A ! Sachant qu'en plus si le client sait qu'il veut aller à A (ce qui est déjà un petit miracle en soit) il y ait des chances qu'il ait dit A' voir C...

[martopioche]

Pour moi, la méthode agile est surtout une façon différente de penser. Elle propose plusieurs outils, mais le but est toujours le même.

Au lieu de donner une carte à un développeur en espérant qu'il sache la lire et se repérer... pour se rendre compte au bout de 6 mois qu'il est à 1000km de la destination... on revient le voir régulièrement pour lui mettre un coup de rêne à gauche ou à droite histoire qu'il continue a cheminer globalement dans la bonne direction.
Au final, il ne sera pas à la ligne d'arrivée bien sur(15 jours ca suffit pour se planter un peu) mais il devrait être a moins de quelques km de celle ci...

Après, il y a aussi une part importante qui est la responsabilisation du client... si il veut que son projet réussisse, il faut aussi qu'il s'investisse. On se rend en effet compte que c'est vraiment dans la conception d'un système qu'on en découvre les incohérence et les limites... qui sont bien plus simple à réparer tout de suite qu'une fois que tout le reste est basé dessus.

Dans la pratique, ça va dans les 2 sens, il ne s'agit pas de voir si le développeur a su lire la carte, mais aussi de vérifier qu'on a donné la bonne carte. Enfin, votre formulation laisse entendre que le plan de route est bon mais mal interprété.

La base des méthodes Agile sont surtout l'implication de chacun : dev, concepteur, chef de projet, et utilisateur (ou son représentant). Car un projet peut "foirer" à tous ces niveaux et le but est de repérer les "problèmes" très tôt afin de ne pas partir dans de mauvaises directions. Cela veut donc bien dire redonner un coup de rêne au développeur, mais c'est aussi demander au dessus si c'est bien vers là qu'il veut aller.

[Cincinnatus]

Pour moi, la méthode agile est surtout une façon différente de penser. Elle propose plusieurs outils, mais le but est toujours le même.

Au lieu de donner une carte à un développeur en espérant qu'il sache la lire et se repérer... pour se rendre compte au bout de 6 mois qu'il est à 1000km de la destination... on revient le voir régulièrement pour lui mettre un coup de rêne à gauche ou à droite histoire qu'il continue a cheminer globalement dans la bonne direction.
Au final, il ne sera pas à la ligne d'arrivée bien sur(15 jours ca suffit pour se planter un peu) mais il devrait être a moins de quelques km de celle ci...

Après, il y a aussi une part importante qui est la responsabilisation du client... si il veut que son projet réussisse, il faut aussi qu'il s'investisse. On se rend en effet compte que c'est vraiment dans la conception d'un système qu'on en découvre les incohérence et les limites... qui sont bien plus simple à réparer tout de suite qu'une fois que tout le reste est basé dessus.

Cette histoire de carte me rappelle ce post de Stephen Palmer où il compare XP et FDD (Feature-Driven Development)The Coad Letter: Modeling and Design Edition, Issue 70, Feature Driven Development and Extreme Programming. Il précise :

The enormous difference between XP and FDD is FDD's additional development of an overall domain object model. As developers learn of requirements they start forming mental images of the system, making assumptions and estimating on that basis. Developing an overall domain object model forces those assumptions out into the open, misunderstandings are resolved and a more complete, common understanding is formed.

XP uses the analogy of driving a car - driving requires continual little course adjustments, you cannot simply point the car in the right direction and press the accelerator. A domain object model is the map to guide the journey; it can prevent you from driving around in endless circles. The domain object model provides an overall shape to which to add function, feature by feature.

En gros, Palmer, dans sa comparaison, rappelle que avoir une idée (même incompléte) de l'objectif facilite le trajet...

La plupart des méthodes agiles comportent une phase de conception, de XP qui va cependant favoriser le refactoring suite au retour utilisateur, à FDD qui se base sur la modélisation. Mais Scrum, Crystal, et quantités d'autres, comportent une phase plus ou moins importante de conception. L'accent qui y est mis varie selon le niveau de la méthode (XP est plus pour les développeurs, Scrum au niveau équipe, FDD pour les grosses équipes).

[kdmbella]

En général en plus des délais calculés il faut prévoir un délai pour les imprévus c'est plus réaliste à mon avis et ça permet au moins de donner des échéanciers moins farfelus.

[Traroth2]

Là tu m'intéresses. Je voyais Agile de loin comme une méthode à l'arrache, mais tu dis que c'est une manière de penser. J'ai un responsable qui m'a appris à éviter l'effet tunnel, par exemple livrer un projet avec 80% des fonctionnalités demandées pour maintenant, plutôt que 100% des fonctionnalités dans 2 ans.

Mais concrètement, et c'est là ma question car lire le manifesto ce n'est oas très parlant car théorique, est-ce que tu as, ou est-ce qu'il existe une comparaison du même projet avec la méthode en V et la méthode Agile pour que je comprenne ?

Sachant que même sans connaitre Agile, on n'est non plus obliger de faire un cycle en V dans les moindre recoins, c'est-à-dire éviter certains projets bureaucratique qui font certes travailler plus de gens, mais rendent risibles leur cout démesuré quelques fois.

Les différentes méthodes agiles ont un certain nombre de point commun, que tu retrouves aussi dans le manifeste : développement itératif (là, on retrouve une différence fondamentale avec le cycle en V), implication de la partie fonctionnelle, ce qui permet aussi de diminuer l'effet tunnel. Mais effectivement, l'agilité, c'est d'abord une manière d'envisager un projet logiciel : la volonté d'accepter le changement, ce n'est pas un point de méthodologie ! Mais c'est une volonté qui doit être présente chez toutes les parties impliquées : le refus du changement dans les spécifications par l'équipe de développement a quand même souvent beaucoup à voir avec le refus du client de rallonger les délais et le budget...

[Nathanael Marchand]

Là tu m'intéresses. Je voyais Agile de loin comme une méthode à l'arrache, mais tu dis que c'est une manière de penser. J'ai un responsable qui m'a appris à éviter l'effet tunnel, par exemple livrer un projet avec 80% des fonctionnalités demandées pour maintenant, plutôt que 100% des fonctionnalités dans 2 ans.

Mais concrètement, et c'est là ma question car lire le manifesto ce n'est oas très parlant car théorique, est-ce que tu as, ou est-ce qu'il existe une comparaison du même projet avec la méthode en V et la méthode Agile pour que je comprenne ?

Sachant que même sans connaitre Agile, on n'est non plus obliger de faire un cycle en V dans les moindre recoins, c'est-à-dire éviter certains projets bureaucratique qui font certes travailler plus de gens, mais rendent risibles leur cout démesuré quelques fois.

Effectivement Agile c'est loin d'être La RACHE... Un exemple souvent utilisé par mes collègues formateur agiles : la bataille navale.
Essaie de jouer en Cycle en V : tu envoies une dizaine de coups sans avoir de retour si tu as touché/coulé et ton adversaire joue en agile avec un retour touché/coulé à chaque coup.
Tu me diras qui a gagné