« Agile est un cancer », pour Erik Meijer

Agile est un buzzword, ça c'est sur!

Ma boite est "partenaire" de conférences "agiles".

Bon, on pourrait se dire qu'ils poussent l'agile en interne alors?

Hé ben non. Les rares fois où l'on fait des trucs qui se rapprocheraient de l'agile, c'est à l'encontre des directives que l'on avait reçu.

Pire, le seul mec que je connaisse dans la boite qui a été envoyé en formation agile à echoué lors des certifications à la fin de la formation. Mais c'est pas grave hein, il est quand même envoyé parler lors des conférences agiles... et n'intervient jamais sur les projets de la boite.

Alors oui, Agile, c'est malheureusement devenu un buzzword commercial, comme le bigdata, et les entreprises qui le vendent, tout comme celles qui l'achètent, ne comprennent pas qu'il y a vraiment des concepts et des nuances derrières ces mots.

C'est dommage, mais c'est aussi et avant tout la faute des clients qui se laissent baratiner et qui n'ont plus la connaissance et la compétence requise pour gérer leurs propres SI.

Citation:

---

Envoyé par Carhiboux

C'est dommage, mais c'est aussi et avant tout la faute des clients qui se laissent baratiner et qui n'ont plus la connaissance et la compétence requise pour gérer leurs propres SI.

---

Pourquoi fais-tu appel à un garagiste pour entretenir et réparer ta voiture ?
Parce que tu n'as pas les compétences pour le faire toi même.

Pourquoi fais-tu appel à un plombier quand tu as une fuite ?
Parce que tu n'as pas les compétences pour le faire toi même.

Pourquoi fais-tu appel à un couvreur quand tu as un problème de toiture ?
Parce que tu n'as pas les compétences pour le faire toi même.

...

On peut continuer comme ça longtemps car ça fonctionne avec tout, y compris avec l'informatique, y compris auprès du monde professionnel
Les décideurs dans les entreprises sont des personnes comme tout le monde et comme tout le monde, ils sont sensibles aux discours marketing
Ce qui fonctionne pour une pub de céréale à la TV, fonctionne aussi auprès des entreprises avec le discours des SSII

Les choses changent tout doucement auprès des clients qui commencent à internaliser leur SI
Mais ça prend du temps et ça se fait très lentement, et pas partout

L'Agilité ne résous pas tout mais je pense que cela peux aider grandement la réalisation de projet de conception (informatique ou autres).
C'est déjà une façon de penser différente plus qu'un outil ou une méthode miracle.

Déjà, c'est un état d’esprits où le développeur n'est plus là pour "pisser du code", mais de comprendre et répondre un besoin d'un utilisateur.
Tout ce liens besoins/réalisation est extrêmement important dans une organisation agile.
On ne réalise pas un "projet informatique" mais un produit, vendu, qui répond à des besoins réels d'utilisateurs que l'on peut rencontrer.
Et ces utilisateurs ont le droit de changer d'avis, de ne pas être claire dans la description de leurs besoins: il faut donc régulièrement se parler pour vérifier que le chemin que l'on prend est toujours le bon.

Citation:

---

Ayons l'honnêteté de reconnaître que l'approche TDD est très coûteuse :
- Il faut du temps pour écrire les tests (Les devs sont deux fois plus lents)
- Il faut du temps pour ré-écrire les tests quand le code change (ce qui arrive souvent dans les 6 premiers mois du projet)
- Même avec un bon taux de couverture, le test reste attaché à une ligne de code, donc lié à l'implémentation, et ne prévient pas un défaut de conception.

---

Pas faut, réaliser des tests est un coût.
Mais combien coûte la découvert d'un bug de régression survenu suite à une amélioration plusieurs année après?
Personnellement, je préféré devoir écrire des tests en même temps que je développe une nouvelle fonctionnalité, avec le nez dans les critères d'acceptante de ma "user story" que de devoir me replonger plusieurs mois après dans une fonctionnalité ancienne à cause d'un effet de bord d'un nouveau développement.
Avoir confiance dans un "vieux" code, ça n'a pas de prix pour moi.

Citation:

---

Perso nous avons essayé dans ma boîte d'en retirer les grandes lignes, notamment l'implication du client final. Mais ce dernier point est resté très difficile à appliquer, d'autant plus encore qu'un développement "trop" agile est parfois bien difficile quand il s'agit de gérer un budget et un planning

---

Je ne sais pas ce que veux dire "trop" agile, par contre toutes méthodes agiles n'est pas forcément adaptées à tout les types de projets. Et cela tombe bien, il en existe plusieurs (Scrum, XP, Kanban, DSDM, ...)

Justement l'agile peut permettre aussi de gérer un budget.
En effet, comme on veux avoir des retours rapide de nos utilisateurs, la meilleur solution est de leur fournir régulièrement un "bout" de logiciel fonctionnel dans lequel on aura ajouté les dernières fonctionnalités désirées (codées, testées, contrôlées, documentées ... enfin vraiment terminées).
Et bien si notre client a un budget précis ou une livraison a une date précise: et bien il suffit de s’arrête quand cette limite est atteinte.
Notre client aura alors son logiciel avec l'ensemble des fonctionnalités qu'il aura priorisées (et vraiment terminées) pour sa mise en production.
Et en plus, plus sa limite approche, plus il se fera une réel idée du "contenu" de son logiciel à la livraison finale. A lui alors de communiquer sur les éventuels manques.

Sans cette approche, avec un cahier des charges initial difficilement changeable, vous aurez extrêmement de difficulté à pouvoir gérer l'imprévu et respecter alors les délais et les coût.
Ou alors, vous vous octroyez des grosses marges de dépassement (au cas où) quitte à ne pas les utiliser.
Mais dans ce cas, êtes vous toujours sur que le cahier des charges initial colle toujours avec les besoins du moments des utilisateurs?

Citation:

---

Envoyé par Laurent 1973

Justement l'agile peut permettre aussi de gérer un budget.
En effet, comme on veux avoir des retours rapide de nos utilisateurs, la meilleur solution est de leur fournir régulièrement un "bout" de logiciel fonctionnel dans lequel on aura ajouté les dernières fonctionnalités désirées (codées, testées, contrôlées, documentées ... enfin vraiment terminées).
Et bien si notre client a un budget précis ou une livraison a une date précise: et bien il suffit de s’arrête quand cette limite est atteinte.
Notre client aura alors son logiciel avec l'ensemble des fonctionnalités qu'il aura priorisées (et vraiment terminées) pour sa mise en production.
Et en plus, plus sa limite approche, plus il se fera une réel idée du "contenu" de son logiciel à la livraison finale. A lui alors de communiquer sur les éventuels manques.

---

D'expérience, c'est cet aspect là qui a le plus de mal à passer auprès des clients.
Les clients ont du mal à comprendre qu'à budget égal et à planning égal, ils auront moins de fonctionnalités mais celles-ci seront mieux adaptées aux besoins réels.

Pendant des années, ça a été la courses à l’échalote dans les réponses aux appels d'offres où chaque prestataire proposait non seulement moins cher mais aussi plus de fonctionnalité que son voisin.
Ce changement de discours est assez radical.
Normal que ça prenne un peu de temps à se diffuser.

Citation:

---

Envoyé par Laurent 1973

Justement l'agile peut permettre aussi de gérer un budget.
En effet, comme on veux avoir des retours rapide de nos utilisateurs, la meilleur solution est de leur fournir régulièrement un "bout" de logiciel fonctionnel dans lequel on aura ajouté les dernières fonctionnalités désirées (codées, testées, contrôlées, documentées ... enfin vraiment terminées).

---

C'est clair, sauf peut être pour le degré de complétion. Car si tu prévois des séances de validation c'est bien que t'es d'accord d'entrer en matière si le bonhomme te dit que ça va pas. Et là c'est une phase de négociation qui intervient entre les deux parties.

Citation:

---

Et bien si notre client a un budget précis ou une livraison a une date précise: et bien il suffit de s’arrête quand cette limite est atteinte.
Notre client aura alors son logiciel avec l'ensemble des fonctionnalités qu'il aura priorisées (et vraiment terminées) pour sa mise en production.
Et en plus, plus sa limite approche, plus il se fera une réel idée du "contenu" de son logiciel à la livraison finale. A lui alors de communiquer sur les éventuels manques.
(...)

---

C'est ce qui est vachement dur à faire intégrer justement. Dans le milieu si tu réponds à un appel d'offre on va te demander combien ça coûte. Je n'ai pas encore eu la chance de tomber sur une personne qui me dise "on vous paie X mois homme" et vous faites le mieux possible durant ce délai. Généralement on me demande combien et pour quand, 80% de la décision risque de ne se baser que sur ces 2 choses. Et comme tu le sens sûrement, si tu veux être "trop" agile tu risques de te retrouver seul à assumer du retard et des surcoûts, en te faisant incendier.
Donc souvent, lorsque je chiffre, je fais un gros travail d'analyse en prévoyant des "trous" et malgré ça j'ai souvent sous-estimé ce que le fonctionnement agile avec validation itérative impliquait. Je suis tout à fait persuadé qu'on obtient de meilleurs résultats avec du pas à pas si le client accompagne tout au long du projet, mais faut des clients d'accord de bosser comme ça, et il y a des limites à poser sur ce que tu peux accepter comme feedback et jusqu'à quel point ça peut contredire ton analyse de départ.
Bref tout cela n'est jamais documenté dans les manuels, mais on s'y casse des dents très vite.

Citation:

---

Envoyé par _skip

Donc souvent, lorsque je chiffre, je fais un gros travail d'analyse en prévoyant des "trous" et malgré ça j'ai souvent sous-estimé ce que le fonctionnement agile avec validation itérative impliquait. Je suis tout à fait persuadé qu'on obtient de meilleurs résultats avec du pas à pas si le client accompagne tout au long du projet, mais faut des clients d'accord de bosser comme ça, et il y a des limites à poser sur ce que tu peux accepter comme feedback et jusqu'à quel point ça peut contredire ton analyse de départ.
Bref tout cela n'est jamais documenté dans les manuels, mais on s'y casse des dents très vite.

---

Au niveau contractuel, pour pouvoir faire de l'Agile, il ne doit y avoir aucun détail des fonctionnalités de l'applications.
Le contrat doit être assez vague sur le but du programme à réaliser.
Il doit uniquement y avoir un détail de l'équipe mise à dispo pendant un temps donné.

Si tu as ça, qui est à mon sens la base pour faire de l'Agile, tu peux accepter toutes les demandes du client.
Chaque feedback est chiffrée en nombre de point et il a été déterminé le nombre de point disponible pour chaque sprint.
Autrement dit, c'est le client qui est maître de son périmètre et s'il estime qu'il doit cramer 50 points pour une fonctionnalité sur un sprint calibré à 60 points, c'est son choix et sa responsabilité.
Le tout est de toujours avoir un livrable disponible à chaque fin de sprint.
Ca facilite pas mal la gestion du client je trouve

Citation:

---

Envoyé par Saverok

Au niveau contractuel, pour pouvoir faire de l'Agile, il ne doit y avoir aucun détail des fonctionnalités de l'applications.
Le contrat doit être assez vague sur le but du programme à réaliser.
Il doit uniquement y avoir un détail de l'équipe mise à dispo pendant un temps donné.

Si tu as ça, qui est à mon sens la base pour faire de l'Agile, tu peux accepter toutes les demandes du client.

---

100% d'accord si tu peux obtenir de ton client d'accepter de bosser comme ça.
Mais je te le dis franchement. Je pensais que cette façon de travailler c'était presque de l'ordre du mythe, à part peut être pour du consulting.

Citation:

---

Envoyé par Carhiboux

Agile est un buzzword, ça c'est sur!

Ma boite est "partenaire" de conférences "agiles".

Bon, on pourrait se dire qu'ils poussent l'agile en interne alors?

Hé ben non. Les rares fois où l'on fait des trucs qui se rapprocheraient de l'agile, c'est à l'encontre des directives que l'on avait reçu.

Pire, le seul mec que je connaisse dans la boite qui a été envoyé en formation agile à echoué lors des certifications à la fin de la formation. Mais c'est pas grave hein, il est quand même envoyé parler lors des conférences agiles... et n'intervient jamais sur les projets de la boite.

Alors oui, Agile, c'est malheureusement devenu un buzzword commercial, comme le bigdata, et les entreprises qui le vendent, tout comme celles qui l'achètent, ne comprennent pas qu'il y a vraiment des concepts et des nuances derrières ces mots.

C'est dommage, mais c'est aussi et avant tout la faute des clients qui se laissent baratiner et qui n'ont plus la connaissance et la compétence requise pour gérer leurs propres SI.

---

Yep, déjà vu, un commercial qui se frottait les mains. Parce que cette année-là c'est pas du Java ou du C++ qu'il vendait, mais de l'Agile. Sémantiquement, "Agile" implique de la souplesse, et de la flexibilité. Comme qui dirait, c'est la porte ouverte à tout et n'importe quoi. Les gens prennent ce qu'ils veulent dedans, mais oublient qu'il faut respecter bon nombres de directives. Au moins avec le cycle en V, on peut s'amuser à engueuler l'équipe avale et l'équipe amont.

Citation:

---

Au niveau contractuel, pour pouvoir faire de l'Agile, il ne doit y avoir aucun détail des fonctionnalités de l'applications.
Le contrat doit être assez vague sur le but du programme à réaliser.
Il doit uniquement y avoir un détail de l'équipe mise à dispo pendant un temps donné.

---

Oui, tout le problème est de faire accepter à l'acheteur et à son juridique (qui ne connaissent parfois ni le métier "client" ni le développement informatique) que dans démarche, tu ne t'engages pas sur un résultat de livraison mais sur un processus de travail et des moyens.

Et parler à des juridiques, pas facile 8O
Mais pour cela, il existe http://www.contrat-agile.org/ qui propose un contrat agile (open source) à utiliser dans nos phases d'appels d'offres.

L'éternelle dichotomie entre engagement sur les moyens et engagement sur les résultats. Ou, pour parler le SSII, entre régie et forfait.

Effectivement, du forfait "Agile", ça me parait compliqué à contractualiser. Très compliqué.

Citation:

---

Envoyé par Saverok

Au niveau contractuel, pour pouvoir faire de l'Agile, il ne doit y avoir aucun détail des fonctionnalités de l'applications.
Le contrat doit être assez vague sur le but du programme à réaliser.
Il doit uniquement y avoir un détail de l'équipe mise à dispo pendant un temps donné.

---

- Bonjour, je viens pour vous acheter une voiture, j'ai un budget de 20 000 euro.
- Pas de soucis, pour ce prix là, on vous met un peu de designer, de l'ingenieur d'etude, des valideurs, et bien sur des constructeurs/assembleurs.
- Euh, je m'en fou, moi je veux une voiture avec ABS, ESP, et d'autres trucs en 3 lettres, 5 portes, blanches, essence, qui consomme moins de 7 l/100Km, etc etc...
- Ah bah non, on est agile, on ne peut pas définir avec vous les fonctionnalités. Par contre, la voiture que vous achetez sera conforme à la définition du dictionnaire

Ce discours très imagé sert simplement à montrer que lorsqu'un client demande un développement logiciel, il sait (plus ou moins vaguement) ce qu'il veut. Il peut avoir des difficultés à le formaliser, mais il a une idée des fonctionalités qu'il veut.
Et à partir de là, il est quasiment impossible de lui dire que oui il aura son logiciel, mais que c'est l'équipe de dev qui choisira les fonctionalités à mettre dedans en fonction de ce qui est bon ou pas. Impossible à entendre pour la plupart des clients.

Citation:

---

Envoyé par El_slapper;

Effectivement, du forfait "Agile", ça me parait compliqué à contractualiser. Très compliqué.

---

Indépendamment des SSII, énormément de logiciels sont fabriqués au forfait.

Citation:

---

Envoyé par gangsoleil

Ce discours très imagé sert simplement à montrer que lorsqu'un client demande un développement logiciel, il sait (plus ou moins vaguement) ce qu'il veut. Il peut avoir des difficultés à le formaliser, mais il a une idée des fonctionalités qu'il veut.
Et à partir de là, il est quasiment impossible de lui dire que oui il aura son logiciel, mais que c'est l'équipe de dev qui choisira les fonctionalités à mettre dedans en fonction de ce qui est bon ou pas. Impossible à entendre pour la plupart des clients.

---

C'est totalement possible et c'est même ce qui arrive tout le temps.
Heureusement que le client a une idée des fonctionnalités qu'il désire avoir dans son application : c'est grâce à cela que l'on va pouvoir budgétiser le projet, dimensionner l'équipe et en définir les profils qui la composeront, définir la taille des itérations et leur nombre.

Ensuite, ce n'est pas l'équipe de développement qui choisi, c'est le client.
C'est le client qui construit son périmètre au fur et à mesure de l'avancé du projet
C'est le client qui spécifie les détails de chaque fonctionnalité au fur et à mesure de l'avancé du projet.
Et surtout, le grand avantage de l'Agile, le client peut changer d'avis et revenir sur une fonctionnalité développée lors d'un sprint précédent pour la modifier.

Autrement dit, si le client à une liste de fonctionnalités indispensables, c'est à lui de les prioriser soit en débutant par cela, soit en mettant une par sprint pour se laisser du mou.

En Agile, le client est membre de l'équipe.
Il ne se contente pas de passer une commande et d'attendre d'être livré.

Pour reprendre ton exemple, c'est un peu comme si tu commandais une voiture avec les principales indications mais qu'ensuite, tu vas à l'usine et tu suis la voiture sur la chaîne de montage et qu'à chaque étape, on te demande ton avis et de faire des choix. Avec à tout moment, la possibilité de revenir en arrière pour modifier.
Note : l'exemple de la voiture a ses limites car pour le parallèle avec l'Agile, il faudrait que la voiture soit en état de sortir à chaque étape de montage...

Citation:

---

Envoyé par gangsoleil

- Bonjour, je viens pour vous acheter une voiture, j'ai un budget de 20 000 euro.
- Pas de soucis, pour ce prix là, on vous met un peu de designer, de l'ingenieur d'etude, des valideurs, et bien sur des constructeurs/assembleurs.
- Euh, je m'en fou, moi je veux une voiture avec ABS, ESP, et d'autres trucs en 3 lettres, 5 portes, blanches, essence, qui consomme moins de 7 l/100Km, etc etc...
- Ah bah non, on est agile, on ne peut pas définir avec vous les fonctionnalités. Par contre, la voiture que vous achetez sera conforme à la définition du dictionnaire

---

Citation:

---

Envoyé par Saverok

C'est totalement possible et c'est même ce qui arrive tout le temps.
Pour reprendre ton exemple, c'est un peu comme si tu commandais une voiture avec les principales indications mais qu'ensuite, tu vas à l'usine et tu suis la voiture sur la chaîne de montage et qu'à chaque étape, on te demande ton avis et de faire des choix. Avec à tout moment, la possibilité de revenir en arrière pour modifier.
Note : l'exemple de la voiture a ses limites car pour le parallèle avec l'Agile, il faudrait que la voiture soit en état de sortir à chaque étape de montage...

---

Oui, tout dépend si on veux un logiciel générique:
- je veux un traitement de texte, je choisi MS-Word, LibreOffice, ... et j'aurais tel ou tel fonctionnalités.
=> je veux une voiture 5 portes avec ABS, ESP, ... je choisi une Peugeot, une Audi ou une Mercedes ... avec tel ou tel différences.

Par contre, si je veux un logiciel sur mesure, je vais voir une SSII
- je défini une liste de fonctionnalités souhaitées et priorisées. Et je suis en liens avec l'équipe sur le développement pour affiner ce que j'aurais avec mon budget et mon délai
=> je veux une voiture pour faire les 24h du mans, j'ai un budget pour financer une équipe d'ingénieurs pour qu'il me la réalise avant le début de la course avec tel ou tel caractéristiques.

Que ce soit en logiciel ou en construction automobile, on peux aussi concevoir un projet en Agile.
La grosse différence, c'est que la compilation (+gravure du CD) prend moins de temps que la fabrication du prototype automobile.
En faite, dans le cas de la voiture, notre "livrable" potentiellement "shipable" ne serait pas la voiture, mais les plans (=~ les sources) pour la réaliser.

@Laurent 1973
Merci ;)
Tu as parfaitement précisé mon propos et tu es nettement plus claire que moi :aie:

Dans le cas de la voiture de course, le livrable peut être la voiture et elle sera testée sur circuit et renvoyée au garage à chaque fois pour modification / ajustement.
Exactement comme pour le logiciel à chaque présentation utilisateur

Eric Meijer a travaillé chez Microsoft pendant 13 ans, avant de partir fonder sa propre boîte en 2013. Ce qu'il y a fait en tant que concepteur de langage (travail sur C#, Linq, etc.) est digne de respect, mais il pourrait avoir au moins l'honnêteté d'expliquer que "l'agilité" qu'il décrit est celle pratiquée chez Microsoft. Or on le sait, ce n'est pas la boîte la plus souple, décentralisée et hiérarchiquement simple du monde. Aussi brillant soit le monsieur, on peut difficilement descendre en flammes une approche de manière aussi violente en se basant sur une expérience réellement vécue, qui plus est chez un mastodonte qui ne se prête pas forcément le mieux du monde aux méthodes agiles.

Je pense que la slide "Enterprise is a Finite State Machine" (vers 24:00 dans la vidéo) est emblématique du déséquilibre son raisonnement. C'est une vision tronquée et excessivement techno-centrique. Non, l'entreprise n'est pas qu'une machine à états. C'est aussi des hommes, et, contrairement à ce qu'il affirme, une somme d'anecdotes, de sentiments, de réflexes humains. Baser tout son raisonnement sur une vision scientifique de l'entreprise en tant que système, c'est mettre aux oubliettes des décennies d'études neurologiques, psychologiques et sociologiques sur ce qui est au coeur des équipes, les êtres humains et leur cerveau, et tout une branche de la gestion de projet apparue au 21ème siècle (agile, management 2.0, etc.) et qui tient compte de ces aspects.

S'il appliquait son raisonnement jusqu'au bout, il prouverait dans sa démonstration, études scientifiques à l'appui, que l'agilité ne marche pas, que TDD est une farce, que le modèle hiérarchique de l'église et de l'armée sont la meilleure forme d'organisation et appliquables à toutes les entreprises, que le modèle en couches strict est la meilleure façon d'architecturer une application quelle qu'elle soit. Où sont ces preuves ?

En leur absence, cette présentation n'est ni plus ni moins que du brassage de vent, des élucubrations de café du commerce à propos de tout et n'importe quoi, sans autre ligne directrice que l'agacement d'un homme qui est sans doute tombé sur le mauvais environnement et en a conclu que tout ce qui est étiqueté "agile", et tout un tas d'autres choses sans grand lien, étaient mauvaises.

Citation:

---

Envoyé par Saverok

Au niveau contractuel, pour pouvoir faire de l'Agile, il ne doit y avoir aucun détail des fonctionnalités de l'applications.
Le contrat doit être assez vague sur le but du programme à réaliser.
Il doit uniquement y avoir un détail de l'équipe mise à dispo pendant un temps donné.

---

Hum, je ne comprend pas. Je n'ai pas réellement pu pratiquer, mais il me semble que la contractualisation en Agile se fait par l'intermédiaire du "Product Backlog". Celui ci décrit l'ensemble des fonctionnalités METIER de l'application.

Le Product Backlog est rédigé conjointement avec le client afin de valider la compréhension du besoin. Ensuite, une durée de réalisation et un coût sont attribués à chacune de ces fonctionnalités. Les fonctionnalités sont classée suivant leurs pertinences : importance pour le client/cout que le client souhaite apporter.

Suite à cela, des "Sprints" sont définis. A chaque fin de Sptrint, le client valide et peut éventuellement apporter des modifications au Product Backlog.

Voila ma vision du fonctionnement Agile point de vue client. Car il me semble aberrant que "Le contrat doit être assez vague sur le but du programme à réaliser."...

Citation:

---

Envoyé par ZenZiTone

Hum, je ne comprend pas. Je n'ai pas réellement pu pratiquer, mais il me semble que la contractualisation en Agile se fait par l'intermédiaire du "Product Backlog". Celui ci décrit l'ensemble des fonctionnalités METIER de l'application.

---

Les product backlog sont une annexe du contrat, elles sont facultatives et non exhaustives (en nombre et en détail)
Bien évidement qu'il faut un minimum cadrer le projet, ne serait que pour le dimensionner.
L'idée est surtout de ne pas s'enfermer contractuellement dans une liste de fonctionnalités fixées à l'avance.
Sinon, à chaque changement, on passerai par le process ultra lourd des "avenants" ce qui est en total contradiction avec l'Agile (qui induit de la souplesse)

J'ai assisté à une présentation (à l'Agile Grenoble 2014, pour ne pas la cité) de la mise en place de la contractualisation agile dans le SI de La Poste.
Le responsable de La Poste nous a expliqué comment ils ont fait des appel d'offre "Agile", rédigé avec le prestataire un contrat agile et suivi des projets agiles du coté client.

Par rapport au contrat, il avait défini des règles de potentiel pénalité pour le prestataire si tel ou tel métriques du projets n'était pas respecté (vélocité moyenne, engagement de l'équipe, ...)
Au cours de leurs différents projets, plusieurs fois La Poste aurait été en position de faire jouer ces clauses de pénalité.
Mais finalement, ils ne l'ont pas fait parce que les raisons des "soucis" étaient compris et que la confiance client/prestataire était bonne.

C'est finalement ça qui est important dans ce type de relation: la confiance client/prestataire
Nous sommes en présence d'une association donnant-donnant où personnes n'a d’intérêt de "perdre":
- Le client a besoin d'un prestataire compétant pour réaliser son produit suivant ses besoins.
- Le prestataire sait que la prestation peut s’arrêter rapidement s'il ne donne pas satisfaction.
Le contrat a construit les bonnes base à un partenariat entre professionnels pour la réussite du projet.
C'est quand même beaucoup plus positif que de prévoir des "punissions" en cas d'échec.

Citation:

---

Envoyé par Laurent 1973

il avait défini des règles de potentiel pénalité pour le prestataire si tel ou tel métriques du projets n'était pas respecté (vélocité moyenne, engagement de l'équipe, ...)
[...]
C'est quand même beaucoup plus positif que de prévoir des "punissions" en cas d'échec.

---

Pourtant, c'est bien ce qu'ils ont fait : en cas de non respect des métriques, il y avait de potentielles sanctions. Je peux te citer plusieurs cas de contrats non-agile présentant des pénalités théoriques qui n'ont pas été appliquées, ça n'a rien à voir avec Agile ou pas.

Oui, je suis d'accord: appliquer tel ou tel procédure de pénalité n'est pas lié à l'agilité ou la non-agilité.

Ce que je voulais dire, c'est qu'avant tout de contractualiser une relation client-fournisseur, il est important de pouvoir établir des relations de confiance où on aura pas un des 2 "partenaires" qui fera un entourloupe à l'autre.

La relation agile où les 2 acteurs sont engagés ensemble sur le projet (l'un sur le suivi et la définition des besoins, l'autre sur la réalisation) est une solution pour cela.
Mais bien sur, et heureusement, dans beaucoup de cas non-agile (en informatique ou ailleurs), la confiance est présent du départ en partenaire commercial.