Discussion :

[Michael Guilloux]

Un développeur estime qu’Agile est un « loup déguisé en agneau », le Waterfall 2.0
Qu’en pensez-vous ?

Agile a été applaudi dans la communauté des développeurs avec ses promesses garantissant un processus de développement conduit par les ingénieurs plutôt que par l’entreprise. Mais quelques années plus tard, Agile fait de moins en moins l’unanimité au sein des développeurs. Le concept semble avoir manqué le but initialement annoncé au vu des témoignages d’un nombre croissant de développeurs y compris des célèbres.

En janvier dernier, Erik Meijer, un développeur de l’écosystème .NET, qui s’est notamment fait remarquer par la création de LINQ et ses travaux sur le langage C#, Visual Basic, Volta et le framework Reactive Extensions (Rx), a ouvertement fustigé Agile lors d’un événement. Pour ce dernier, « Agile est un cancer que nous devons éliminer de l’industrie ».

En mai dernier, Andy Hunt, l’un des 17 co-auteurs du Manifeste Agile en 2001, a rejoint les rangs de ceux qui pensent que la pratique d’Agile n’a pas atteint ses promesses. Il s’est indigné de la manière dont le concept Agile s’est détourné du droit chemin et a donc proposé une nouvelle méthode pour corriger cela. Bref ! Il y a de quoi se demander si Agile, dans la pratique, permet de corriger les problèmes connus dans les méthodes traditionnelles dites en cascade (Waterfall).

D’après le développeur Amir Yasin, cofondateur et CTO de June (société US spécialisée dans le recrutement des professionnels seniors de l’IT), Agile ne résout pas du tout les problèmes du modèle Waterfall. Pour lui, Agile n’est rien d’autre le Waterfall 2.0, la nouvelle version du modèle de développement en cascade, et peut s’avérer encore pire que les méthodes traditionnelles. « Agile est devenu tout ce que le modèle Waterfall était pour les développeurs, et pire. C’est un loup déguisé en agneau », a écrit Yasin dans un billet de blog.

Agile a fait des promesses impressionnantes, comme un développement conduit par les ingénieurs, afin que les décisions importantes ne soient pas prises sans les développeurs. Mais selon le CTO de June, dans la réalité, Agile et Waterfall partagent la même idée du développement conduit par l’entreprise. Les décisions techniques sont pilotées par la direction et imposées aux développeurs. « Le résultat final est le même Waterfall. Seul le nom a changé », explique-t-il. Il ajoute encore qu’Agile est plus toxique que les méthodes en cascade, car il rend le développeur beaucoup plus responsable du résultat sans lui donner l’autorité qui va avec sa responsabilité.

« Agile est un marteau » et « vous êtes le clou », poursuit Amir Yasin en s’adressant aux développeurs. Il pense qu’Agile n’est seulement profitable qu’aux sociétés de conseil, qui doivent faire un prototype rapide pour un client qui ne sait pas vraiment ce qu’il veut, et qui facturent sur une base temporelle. Ces dernières sont ainsi prêtes à accepter n’importe quelle idée avec laquelle vient le client, étant donné que cela signifie un délai plus long, donc plus de revenus.

Il s’insurge aussi contre le fait que les sociétés de conseil « Agile » se cachent derrière ce concept pour vendre du Waterfall dans un nouvel emballage sans être pointées du doigt en cas d’échec. Si le projet s’est bien passé, tant mieux. Mais si « votre projet a échoué ; ce n’est pas Agile, c’est vous. Vous l’avez juste mal appliqué, et vous auriez gagné en le faisant bien », explique Yasin, pour décrire la réalité.

Agile semble en effet beaucoup plus facile en théorie. A cet effet, Amir Yasin estime qu’Agile n’est pas agile. Il pense donc que vous deviendrez plus agiles en commençant par vous débarrasser de tout ce qui vous lie à ce concept considéré comme une alternative au modèle Waterfall. C’est-à-dire votre scrum master, votre coach Agile ou encore la société de conseil qui essaie de vous rendre plus Agile.

Il suggère que les équipes de développement suivent leur propre voie avec des méthodes qui font participer tout le monde, mais qui n’accordent pas la priorité au délai dans les discussions. Il insiste sur le fait que tout le monde doit participer, et si des personnes doivent être exclues, il faut exclure les gestionnaires. Il suggère également de livrer le logiciel seulement quand il est prêt, ni avant, ni après. Le coût de livraison du mauvais produit est beaucoup plus élevé que le coût de prolongement des délais pour livrer le bon produit, rappelle-t-il.

Source : Medium

Et vous ?

Qu’en pensez-vous ?

Forum ALM

[transgohan]

Je ne serai pas autant catégorique, cela dépend de comment on applique les méthodes Agile.
Si seuls les développeurs sont impliqués dans l'Agile en effet ce n'est pas la bonne chose à faire (et c'est malheureusement majoritairement appliqué ainsi).

[Bono_BX]

Il pense donc que vous deviendrez plus agiles en commençant par vous débarrasser de tout ce qui vous lie à ce concept considéré comme une alternative au modèle Waterfall. C’est-à-dire votre scrum master, votre coach Agile ou encore la société de conseil qui essaie de vous rendre plus Agile.

Il suggère que les équipes de développement suivent leur propre voie avec des méthodes qui font participer tout le monde, mais qui n’accordent pas la priorité au délai dans les discussions. Il insiste sur le fait que tout le monde doit participer, et si des personnes doivent être exclues, il faut exclure les gestionnaires.

Oh que oui ! La programmation est l'affaire ... des programmeurs. Combien de projets échouent à cause de gestionnaires qui n'y connaissent rien et nous mettent des bâtons dans les roues ?
Par contre, ce n'est pas Agile qu'il faut remettre en cause : quelque soit la méthode choisie, les mêmes personnes produiront les mêmes problèmes. Ce que soulève Amir Yasin est très juste, mais il se trompe de cible : ce sont les compétences des participants au projet à remettre en cause, pas la méthodologie.

De part mon expérience, je peux affirmer qu'une bonne équipe arrivera à un bon résultat quelque soit la méthode choisie, et une équipe de bras cassés ira toujours dans le mur même avec la meilleure méthode au monde.
Personnellement, je préfère Agile, mais je ne cracherai pas sur le Waterfall qui a aussi connaît de gros succès.

[Traroth2]

En fait, je suis plutôt d'accord, malheureusement. Dans la pratique, l'agilité ne sert à rien si c'est toujours la direction ou le marketing qui font les plannings.

[Traroth2]

Oh que oui ! La programmation est l'affaire ... des programmeurs. Combien de projets échouent à cause de gestionnaires qui n'y connaissent rien et nous mettent des bâtons dans les roues ?
Par contre, ce n'est pas Agile qu'il faut remettre en cause : quelque soit la méthode choisie, les mêmes personnes produiront les mêmes problèmes. Ce que soulève Amir Yasin est très juste, mais il se trompe de cible : ce sont les compétences des participants au projet à remettre en cause, pas la méthodologie.

De part mon expérience, je peux affirmer qu'une bonne équipe arrivera à un bon résultat quelque soit la méthode choisie, et une équipe de bras cassés ira toujours dans le mur même avec la meilleure méthode au monde.
Personnellement, je préfère Agile, mais je ne cracherai pas sur le Waterfall qui a aussi connaît de gros succès.

Je ne pense pas que ça soit les compétences dont il parle, mais bien les intentions. Tant qu'on continuera à imposer les délais aux équipes techniques, l'agilité sera plus nuisible qu'utile, et malheureusement, ça n'est pas près de changer.

[Bono_BX]

Je ne pense pas que ça soit les compétences dont il parle, mais bien les intentions. Tant qu'on continuera à imposer les délais aux équipes techniques, l'agilité sera plus nuisible qu'utile, et malheureusement, ça n'est pas près de changer.

Mais justement, imposer des délais aux équipes techniques, ça n'a rien à voir avec l'Agile, ça se fait aussi en Watrefall, avec les mêmes conséquences. Si tu penses aux itérations de 2 - 3 semaines (j'extrapole sur ce que tu dis ), les users stories doivent être suffisamment concises pour rentrer dans une itération, sinon on les redécoupe ; il n'y a donc pas vraiment de délais imposé.

[Traroth2]

Mais justement, imposer des délais aux équipes techniques, ça n'a rien à voir avec l'Agile, ça se fait aussi en Watrefall, avec les mêmes conséquences. Si tu penses aux itérations de 2 - 3 semaines (j'extrapole sur ce que tu dis ), les users stories doivent être suffisamment concises pour rentrer dans une itération, sinon on les redécoupe ; il n'y a donc pas vraiment de délais imposé.

C'est exactement ce que dit l'article. Le problème est que l'agile ne peut pas avoir d'effet positif dans ces circonstances.

[Saverok]

Il suggère également de livrer le logiciel seulement quand il est prêt, ni avant, ni après. Le coût de livraison du mauvais produit est beaucoup plus élevé que le coût de prolongement des délais pour livrer le bon produit, rappelle-t-il.

L'effet tunnel est désastreux, comment peux-tu en arriver à le justifier ?

Oui, les livraisons intermédiaires ont un coût mais c'est un coût nécessaire.
Il est important de pouvoir montrer que le projet avance et d'identifier le plus tôt possible les mauvais choix lors des spec.
Combien de fois on écrit quelque chose en théorie génial et qui s'avère désastreux une fois en pratique ?
Cela est aussi vrai pour la technique que pour les AMOA.

Tant qu'on continuera à imposer les délais aux équipes techniques, l'agilité sera plus nuisible qu'utile, et malheureusement, ça n'est pas près de changer.

Le hic c'est que c'est un peu une obligation.
Dire au client "ça sera livré quand ça sera terminé" n'est tout simplement pas possible.
Un projet informatique est rarement seul.
Derrière, il peut y avoir des tas de choses à coordonner : une campagne marketing, de la formation, etc.
Sans parler du budget...

[Traroth2]

Le hic c'est que c'est un peu une obligation.
Dire au client "ça sera livré quand ça sera terminé" n'est tout simplement pas possible.
Un projet informatique est rarement seul.
Derrière, il peut y avoir des tas de choses à coordonner : une campagne marketing, de la formation, etc.
Sans parler du budget...

Je ne saurais désapprouver plus. Quand des non-techniciens décident des délais d'un projet technique, c'est tout simplement de la pensée magique : je veux que ça soit faisable dans ce délai, donc c'est faisable dans ce délai. Les faits sont têtus : ça ne fonctionne pas. La preuve ? Les innombrables projets qui vont dans le mur.

Si la direction générale a besoin d'un délai, il faut que ça soit l'équipe technique qui le définisse, à partir d'un planning, au lieu d'essayer de faire tenir un "rétro-planning" (une aberration inutile) dans un délai défini au doigt mouillé par un peigne-cul du marketing qui n'y connait rien.

[el_slapper]

Je ne saurais désapprouver plus. Quand des non-techniciens décident des délais d'un projet technique, c'est tout simplement de la pensée magique : je veux que ça soit faisable dans ce délai, donc c'est faisable dans ce délai. Les faits sont têtus : ça ne fonctionne pas. La preuve ? Les innombrables projets qui vont dans le mur.

Si la direction générale a besoin d'un délai, il faut que ça soit l'équipe technique qui le définisse, à partir d'un planning, au lieu d'essayer de faire tenir un "rétro-planning" (une aberration inutile) dans un délai défini au doigt mouillé par un peigne-cul du marketing qui n'y connait rien.

Ben, quand tu as un projet d'ordre réglementaire(notre quotidien, dans le médical, sur la partie comptable), c'est inévitable. Si le jour J on est pas prêt, on a plus qu'à mettre la clef sous la porte. Et le délai est imposé par des gens dans des bureaux du ministère, encore plus loin de moi que ta personne du marketing.

Et sinon, pour du fonctionnel, on peut choisir une date, et accepter de perdre des fonctionnalités en cours de route. Ça peut être parfaitement rationnel de dire que le 1 Janvier, la nouvelle version doit être prête, avec toutes les évolutions réglementaires pour 2016... et on essayera d'y mettre un maximum de vraies évolution aussi, mais ça, ça dépendra de ce qui est possible. Nous, en tous cas, on marche comme ça, et on a des fonctionnalités qui trainent dans les cartons depuis des années, que les clients réclament, mais avec nos faibles moyens et l'épée de Damoclès du réglementaire, ça doit attendre. C'est triste, mais nos concurrents ont les mêmes soucis.

[Traroth2]

Ben, quand tu as un projet d'ordre réglementaire(notre quotidien, dans le médical, sur la partie comptable), c'est inévitable. Si le jour J on est pas prêt, on a plus qu'à mettre la clef sous la porte. Et le délai est imposé par des gens dans des bureaux du ministère, encore plus loin de moi que ta personne du marketing.

Et sinon, pour du fonctionnel, on peut choisir une date, et accepter de perdre des fonctionnalités en cours de route. Ça peut être parfaitement rationnel de dire que le 1 Janvier, la nouvelle version doit être prête, avec toutes les évolutions réglementaires pour 2016... et on essayera d'y mettre un maximum de vraies évolution aussi, mais ça, ça dépendra de ce qui est possible. Nous, en tous cas, on marche comme ça, et on a des fonctionnalités qui trainent dans les cartons depuis des années, que les clients réclament, mais avec nos faibles moyens et l'épée de Damoclès du réglementaire, ça doit attendre. C'est triste, mais nos concurrents ont les mêmes soucis.

Typiquement un faux problème. Les délais pour changer le taux de TVA sont toujours largement suffisants. Sauf si l'équipe technique doit absolument faire un truc "super important" dans l'intervalle. Je ne connais pas de cas où un changement réglementaire a créé une tension dans un planning sans intervention d'abrutis bien maison qui du haut de leur ignorance ont considéré que ça pouvait attendre.

[el_slapper]

Typiquement un faux problème. Les délais pour changer le taux de TVA sont toujours largement suffisants. Sauf si l'équipe technique doit absolument faire un truc "super important" dans l'intervalle. Je ne connais pas de cas où un changement réglementaire a créé une tension dans un planning sans intervention d'abrutis bien maison qui du haut de leur ignorance ont considéré que ça pouvait attendre.

Euh, permets-moi d'être en désaccord. Une nouvelle norme comptable pour les fichiers à transmettre à la sécu, c'est très vite très compliqué. Pareil quand j'étais dans le bancaire(les normes Bale 2 et 3, tout un poème). Il ne s'agit pas juste de changer un taux dans une case, mais bel et bien de repenser la manière de comptabiliser un certain nombre d'actes médicaux. Ça a tout un tas d'effets fonctionnels assez vicieux. Et là, on en a une pour laquelle on a été prévenu à moins de 3 mois.

Je veux bien que quand tu fais un site web marchand standard, dédié à la vente au particuliers, ton réglementaire ne change pas souvent(même si il peut être compliqué). Quand tu t'adresse à des professionnels, qui ont un ministère à eux tous seuls pour leur pondre sans cesse de nouvelles normes(même hors compta, on a le Circuit de Bon Usage du Médicament qui arrive, et c'est un bouleversement des paramétrages qu'on a fait dans les hôpitaux - on a peu de code, mais énormément de travail d'adaptation sur site); c'est très différent. Et non, ce n'est pas un faux problème. Ça occupe souvent la moitié du temps de développement et de tests. Parfois plus, rarement moins. D'ailleurs, ma boite, comme certains de nos concurrents, sont des gens qui vendent un logiciel médical, et qui ont racheté un opérateur français pour la partie comptable, ce n'est pas un hasard. Ils savent qu'ils ne peuvent pas suivre sans partir sur un existant fiable(et nous, au moins, on a une intégration entre les deux qui marche, nyark nyark nyark.)

"Je ne connais pas", ça ne veux pas dire "ça n'existe pas". Joel Spolsky découpe le monde du software en 5 mondes, et je suis sur qu'il en oublie. Les gens du jeu vidéo ont assez peu de contraintes réglementaires(PEGI, peut-être?), mais des contraintes de délai souvent imposées(il faut sortir avant Noël, sinon on vendra moitié moins). Je retrouve des similitudes entre le médical et le bancaire(beaucoup de réglementaire et de compta), mais aussi des différences majeures(les banquiers ont des moyens colossaux, les hôpitaux des dettes colossales). Et ton domaine est certainement encore très différent, puisque le réglementaire y est semble-t-il limité. Donc on peut tirer des conclusions, mais gare aux généralisations trop hâtives. Moi, dans mon monde, j'ai des contraintes réglementaires fortes qui ont un impact fort sur le contenu des versions et leur date butoir de livraison. Nous ne sommes pas parvenus à passer en agile(ils ont essayé juste avant ma venue), et je ne pense pas que ça soit un hasard. Alors même qu'on a des gens de très haute qualité et très indépendants. Agile quand 50% du contenu à 6 mois est absolument figé, c'est tout de suite moins intéressant. Sans cette contrainte, ça aurait sans doute réussi.

[Saverok]

Je ne saurais désapprouver plus. Quand des non-techniciens décident des délais d'un projet technique, c'est tout simplement de la pensée magique : je veux que ça soit faisable dans ce délai, donc c'est faisable dans ce délai. Les faits sont têtus : ça ne fonctionne pas. La preuve ? Les innombrables projets qui vont dans le mur.

Si la direction générale a besoin d'un délai, il faut que ça soit l'équipe technique qui le définisse, à partir d'un planning, au lieu d'essayer de faire tenir un "rétro-planning" (une aberration inutile) dans un délai défini au doigt mouillé par un peigne-cul du marketing qui n'y connait rien.

La définition d'un planning se fait dans un échange entre le marketing et la technique.
Il y a un besoin business que le projet soit délivré à telle date.
La technique doit être en mesure de dire au marketing, pour telle date, je suis en mesure de délivrer tel périmètre sous telles conditions (jalons de spec, équipes, etc).
Et y a échange jusqu'au compromis mutuellement acceptable.

La technique seule ne peut pas définir un planning.
De même, je suis de ton avis, que le marketing ne peut pas le faire seul non plus.

[Bono_BX]

C'est exactement ce que dit l'article. Le problème est que l'agile ne peut pas avoir d'effet positif dans ces circonstances.

????? Peux-tu creuser, STP ? Si ta phrase se rapporte aux délais imposé, OK, si c'est aux user stories redéfinies, là je ne comprends pas.

La définition d'un planning se fait dans un échange entre le marketing et la technique.
Il y a un besoin business que le projet soit délivré à telle date.
La technique doit être en mesure de dire au marketing, pour telle date, je suis en mesure de délivrer tel périmètre sous telles conditions (jalons de spec, équipes, etc).
Et y a échange jusqu'au compromis mutuellement acceptable.

La technique seule ne peut pas définir un planning.
De même, je suis de ton avis, que le marketing ne peut pas le faire seul non plus.

Je suis tout à fait d'accord. Petit retour d'expérience qui s'est bien passé : pour faire face à des délais très court, nous étions arrivé à un compromis avec les équipes de production sur le fait qu'ils auraient bien les fonctionnalités demandées à temps, mais au lieu d'avoir une interface ce seraient de bonnes vieilles lignes de commande, et au lieu d'un beau reporting, un vieux csv tout basique.
Et ça a marché, nous avons pu leur implémenter "le sucre" plus tard, et tout le monde était content (happy ending).

[Traroth2]

La définition d'un planning se fait dans un échange entre le marketing et la technique.
Il y a un besoin business que le projet soit délivré à telle date.
La technique doit être en mesure de dire au marketing, pour telle date, je suis en mesure de délivrer tel périmètre sous telles conditions (jalons de spec, équipes, etc).
Et y a échange jusqu'au compromis mutuellement acceptable.

La technique seule ne peut pas définir un planning.
De même, je suis de ton avis, que le marketing ne peut pas le faire seul non plus.

Le délai nécessaire serait une négociation ? Je te conseille d'essayer ça avec la durée de gestation d'une femme enceinte, pour voir ce que ça donne...

Ce n'est clairement pas la bonne manière de penser. Parce que justement, la partie non-technique n'a rien d'autre à indiquer que la pensée magique que j'évoquais plus haut. La seule circonstance où ce que tu dis s'applique, c'est si on peut négocier sur les moyens qu'on peut attribuer au projet. Mais le plus souvent, ça ne change pas grand-chose (lire "The mythical man-month")

Et les résultats de la politique actuelle sont là, sous forme d'innombrables projets dans le fossé. De nos jours, les projets qui atteignent tous leurs objectifs dans les délais et dans le budget, c'est l'exception. C'est dire à quel point on est dans une fiction d'efficacité. Il faudrait déjà réaliser que la situation actuelle n'est pas satisfaisante avant de vouloir justifier les pratiques actuelles.

[theMonz31]

Et les résultats de la politique actuelle sont là, sous forme d'innombrables projets dans le fossé. De nos jours, les projets qui atteignent tous leurs objectifs dans les délais et dans le budget, c'est l'exception. C'est dire à quel point on est dans une fiction d'efficacité. Il faudrait déjà réaliser que la situation actuelle n'est pas satisfaisante avant de vouloir justifier les pratiques actuelles.

Excellente analyse

Ce qui tend à "prouver" que les différentes méthodologies, méthodes et autres process ne sont pas un garde fou pour la réussite d'un projet.

Je pense que, la réussite d'un projet est VRAIMENT et presque UNIQUEMENT lié à la qualité de l'équipe et à la qualité du management à tirer partie du meilleur de chacun, quelque soit les compétences de l'équipe (évidemment, si il n'y a que des novices pour un problème complexe, ça risque de créer du retard, délai...)

[Saverok]

Le délai nécessaire serait une négociation ? Je te conseille d'essayer ça avec la durée de gestation d'une femme enceinte, pour voir ce que ça donne...

Si la mère accepte que son enfant n'est ni bras ni jambe, je suis sûr qu'on peut gagner quelques semaines

Blague à part, l'analogie avec le biologique n'a pas de sens.
Un projet info a un périmètre et il est possible de jouer avec ce périmètre pour trouver un compromis.

Le post de Bono_Mx illustre parfaitement mon propos :

Petit retour d'expérience qui s'est bien passé : pour faire face à des délais très court, nous étions arrivé à un compromis avec les équipes de production sur le fait qu'ils auraient bien les fonctionnalités demandées à temps, mais au lieu d'avoir une interface ce seraient de bonnes vieilles lignes de commande, et au lieu d'un beau reporting, un vieux csv tout basique.
Et ça a marché, nous avons pu leur implémenter "le sucre" plus tard, et tout le monde était content (happy ending).

Ce n'est clairement pas la bonne manière de penser. Parce que justement, la partie non-technique n'a rien d'autre à indiquer que la pensée magique que j'évoquais plus haut.

Le besoin métier est justement l'origine du projet.
S'il n'y a pas de besoin métier, il n'y a pas de projet donc pas de développeur

Par exemple, le métier souhaite mettre en place un service d'emballage cadeau pour les fêtes de fin d'année.
Il serait totalement absurde de la part des équipes de dev de dire "on vous fait ce dev pour février car impossible pour fin novembre..."

On ne fait pas de l'informatique pour le plaisir de faire du dev logiciel.
On est là pour répondre à un besoin métier et ce besoin inclut un planning car cela a un impact business et organisationnel fort.

Maintenant, il s'agit de bien comprendre le "besoin" au delà de la demande.
Quel est l'action réellement demandée ?
Une fois que l'on a compris cela, on peut proposer des modes d'implémentations minimalistes mais qui permettent de répondre au besoin (pas d'interface graphique ou minimaliste, un reporting texte, pas de temps réel mais 1x/h, etc.).

[ZenZiTone]

Le hic c'est que c'est un peu une obligation.
Dire au client "ça sera livré quand ça sera terminé" n'est tout simplement pas possible.

N'oublions pas qu'un projet peut se résumer en trois mots :

• Coût
• Délais
• Qualité

Ces trois éléments sont dépendants les uns des autres. Réduire le délais en conservant un même niveau de qualité implique d'augmenter les coûts (ajout de ressources), réduire le coût en conservant le délais implique de réduire la qualité, etc...

Donc non, on ne peut pas promettre de livrer un produit fini de bonne qualité en moins de temps que l'équipe ne peut lui accorder. Et cela est vrais en Agile, en Waterfall ou tout autre méthode de gestion de projet.

De plus, en Agile, il existe ce que l'on appelle le planning poker. On attribut un certain nombre de "points" à une certaine fonctionnalité. Ces points correspondent à un niveau de difficulté traduisible en temps de développement. Donc si ton équipe estime qu'il faudra x jours pour réaliser x fonctionnalités, il n'y a pas de raison de vendre un délais plus court. Le problème ici n'est donc pas la gestion de projet utilisé.

[Laurent 1973]

N'oublions pas qu'un projet peut se résumer en trois mots :

• Coût
• Délais
• Qualité

Moi, j'en rajouterais un quatrième: périmètre.
En effet, suit à un problème technique, pour respecter les même délais, le même coût sans baisser la qualité on peux faire le choix de réduire le paramètre fonctionnel de ce qui sera livré.

C'est ce que nous a relaté Bono_BX:

Je suis tout à fait d'accord. Petit retour d'expérience qui s'est bien passé : pour faire face à des délais très court, nous étions arrivé à un compromis avec les équipes de production sur le fait qu'ils auraient bien les fonctionnalités demandées à temps, mais au lieu d'avoir une interface ce seraient de bonnes vieilles lignes de commande, et au lieu d'un beau reporting, un vieux csv tout basique.
Et ça a marché, nous avons pu leur implémenter "le sucre" plus tard, et tout le monde était content (happy ending).

[ZenZiTone]

Moi, j'en rajouterais un quatrième: périmètre.
En effet, suit à un problème technique, pour respecter les même délais, le même coût sans baisser la qualité on peux faire le choix de réduire le paramètre fonctionnel de ce qui sera livré.

Pour ma part, réduire le périmètre fonctionnel c'est réduire la qualité : qualité n'étant pas seulement rattaché à la qualité technique de la solution, mais aussi au nombre de fonctionnalités proposées dans la solution. La nuance que tu soulignes est néanmoins intéressantes car on parle bien de deux choses différentes.