Pourquoi les projets agiles ne peuvent pas (vraiment) être menés au forfait
En matière de sous-traitance du développement logiciel, la pratique contractuelle la plus fréquente est celle dite du projet au forfait. La notion de forfait n’a, en principe, pas de rapport avec le processus de développement ou les pratiques d’ingénierie utilisée dans la réalisation du projet. Il s’agit simplement, dans l’esprit des contractants, de fixer les contours exacts de leur relation commerciale, et de définir leurs obligations mutuelles – en terme de coûts, de délais, de mode de paiement et de livraison. Dans un État de droit, et pour autant qu’elles ne soient pas abusives, ces dispositions contractuelles ont force de loi, et protègent efficacement les parties prenantes.
A bien y regarder cependant la neutralité du forfait vis à vis du processus de développement est moins évidente. Conçu historiquement pour satisfaire aux exigences de mise en concurrence des fournisseurs du Département de la Défense américain, le contrat au forfait est né du même substrat que le processus de développement en cascade – initialement décrit en 1970 par Winston W. Royce dans Managing the developpement of large software systems.
Ce processus de développement est aujourd’hui fortement remis en question, sous le constat empirique de son échec relatif, et sous l’impulsion des méthodes agiles. Je pense quant à moi que la « cascade » sera perçue dans quelques années comme l’aveuglement juvénile d’une industrie encore adolescente, à la recherche de son identité.
La question qui nous intéresse ici est de savoir si le projet au forfait survivra à la cascade. Autrement dit s’il est possible de mener au forfait un projet agile sous-traité. Certains le pensent, et certains intégrateurs proposent au demeurant de tels contrats. J’entends quant à moi démontrer ici que l’agilité et le forfait reposent sur des logiques financières radicalement antinomiques, qui les rendent difficilement conciliables.
Un petit tour du côté de l’étymologie devrait alerter les adeptes du forfait. Forfait vient du vieux français fors faire qui signifie… faire du mal !
Dans un contrat au forfait, le client définit ce qu’il souhaite sous la forme d’un cahier des charges. En retour, le fournisseur doit s’engage à livrer ce qui est décrit pour un coût et dans un délai fixes – les deux faisant l’objet d’une négociation initiale ou d’une mise en concurrence.
Ce contrat n’est pas franchement équitable : il est conçu pour protéger le client et fait porter très fortement le risque sur le fournisseur, qui doit s’engager sur un délai, sur un coût et sur un périmètre (fixé par le cahier de charges). L’efficacité réelle de cette protection reste cependant en grande partie illusoire : il n’est pas rare que le déploiement d’une application relève de l’intérêt vital d’une organisation et que l’abandon suivi d’un contentieux judiciaire ne soit pas une véritable option, quels que soient les recours légaux qu’autorise le contrat.
De leur côté, et très schématiquement, les méthodes agiles reposent sur un mode de développement que l’on dit incrémental. Le développement est réalisé en cycles courts, de durée fixe, au terme desquels un logiciel partiel mais opérationnel est livré. Le périmètre de chaque cycle est déterminé au début du cycle, ou peu avant. Les autres fonctionnalités sont maintenues dans un Product Backlog qui est par principe ouvert au changement. En d’autres termes, si au cours du projet certains besoins apparaissent, changent ou disparaissent, ces modifications sont intégrées dans le Product Backlog, et potentiellement implémentées dans le cycle suivant. La réalisation incrémentale permet en outre une gestion des priorités : les fonctionnalités les plus importantes (celles qui ont le plus de valeur) sont placées en haut de la liste, et implémentées en premier. Ce pilotage par la valeur, couplé au caractère incrémental de la réalisation est au cœur de la logique financière des projets agiles – nous y reviendrons.
En somme, pour adhérer aux paradigmes des méthodes agiles, l’un des termes du contrat forfaitaire classique doit être abandonné : le périmètre fixe, généralement incarné par des spécifications techniques et fonctionnelles détaillées.
C’est cet abandon qui me semble improbable.
Pour bien comprendre en quoi cet abandon est incompatible avec un contrat forfaitaire, un petit détour par la la micro-économie est nécessaire.
Le développement incrémental permet de produire en premier lieu les fonctionnalités ayant la plus grande valeur d’usage pour le client (c’est lui qui fixe les priorités). Cette caractéristique renvoi à ce que les économistes appellent l’utilité marginale décroissante.
Le concept d’utilité marginale décroissante est classiquement illustré par le phénomène de la soif : lorsque vous êtes assoiffé, la première gorgée d’eau vous procure une très forte satisfaction (une très grande utilité, donc). A mesure que vous vous désaltérez, chaque nouveau verre vous apporte une satisfaction moindre que le précédent. Si vous devez payer chaque verre, vous cesserez de boire dès que le coût du verre vous semblera excessif en regard de la satisfaction de le boire. Si le verre est gratuit, vous boirez jusqu’à étanchement total de la soif – c’est-à-dire jusqu’au stade où un verre supplémentaire vous causerait du désagrément (il faut vraiment arréter, sinon il est possible d’en mourir !).
Le développement incrémental produit le même phénomène : les fonctionnalités à plus forte valeur ajoutée sont produites en premier. Il est donc naturel que la valeur ajoutée des cycles successifs diminue.
Le graphique suivant illustre schématiquement ce principe d’utilité marginale décroissante :
A chaque cycle, la valeur totale du logiciel augmente, mais la variation de valeur entre deux cycles successifs (c’est-à-dire la valeur marginale) diminue.
Cette vision est bien sûr très stylisée (j’ai utilisée un fonction linéaire de l’utilité marginale pour construire le graphe). Dans la réalité, la valeur marginale est nettement plus variable : au cours du développement, certains besoins à forte valeur ajoutée peuvent émerger ; ils seront intégrés au cycle suivant, augmentant sensiblement son utilité marginale. Symétriquement, certaines fonctionnalités déjà développées peuvent se révéler décevantes : leur valeur d’usage est moindre que celle escomptée – ce qui réduit d’autant la valeur acquise.
Ajoutons qu’au même titre que la satisfaction marginale du buveur d’eau, la valeur marginale du développement peut devenir négative : en effet, toute fonctionnalité une fois développée et déployée possède un coût de possession intrinsèque (ressources, maintenance, supervision, etc.) qui peut dépasser sa valeur propre. Une fonctionnalité inutile dans un logiciel possède typiquement cette caractéristique (il suffit d’être utilisateur des dernières versions de Microsoft Office pour se faire une idée précise de ce phénomène).
En micro-économie, la notion d’utilité marginale décroissante est utile pour expliquer le fonctionnement élémentaire des marchés. Si vous devez payer vos verres d’eau, vous cesserez de boire – et donc de payer – dès que le prix d’un verre vous semblera supérieur à son utilité marginale.
Le même principe est en oeuvre dans un projet agile : le développement devrait prendre fin lorsque le coût d’un cycle supplémentaire excède sa valeur marginale.
Or avec un forfait, ce moment n’arrive jamais !
Je m’explique, vous allez voir, c’est très simple.
Dans un forfait, le prix total est négocié frontalement, et peut donc être considéré en théorie comme un invariant. A contrario, les dépenses totales du fournisseur augmentant avec le temps, sa marge est directement dépendante de la durée des développements (et de ses coûts journaliers).
S’il applique un processus de développement incrémental, il se trouve dans la situation décrite par ce graphique (pour simplifier, on suppose que chaque cycle implique la même dépense que le précédent) :
A chaque nouveau cycle, la dépense totale du fournisseur augmente, et sa marge totale baisse en proportion. Au-delà d’un certain seuil, sa marge devient négative, et il travaille à perte. Pour sa survie, il est indispensable que le projet prenne fin avant le franchissement de ce seuil fatidique.
Logiquement, lorsque la valeur totale du logiciel atteint le prix du forfait, le projet devrait s’interrompre (cet événement a lieu après le 8ème cycle dans notre modèle). A ce moment, la marge du fournisseur est positive, et le client a obtenu une valeur d’usage à hauteur de son investissement. Malheureusement, rien n’incite dans ce modèle le client à déclarer le projet achevé. En effet, ici, le coût marginal d’un cycle est nul – réaliser une itération supplémentaire n’impute pas le budget total. Le client est donc incité à prolonger les développements aussi longtemps que la valeur marginale d’une itération est positive, poussant virtuellement le fournisseur à boire le calice jusqu’à la lie.
Le seul moyen pour le fournisseur de maîtriser ce risque est de définir en amont – contractuellement – le périmètre de sa production logicielle. Il demande au client de s’engager dès le départ sur des spécifications détaillées du logiciel, et protège ce périmètre en le plaçant sous un strict contrôle du changement – chaque évolution faisant l’objet d’un juteux avenant. Dès lors le changement devient un coût pour le client, qui a le choix entre le refuser (au risque de mécontenter ses utilisateurs) ou le payer (au risque de voir son budget exploser de façon incontrôlée). L’un des principes cardinaux des méthodes agiles, l’acceptation du changement, devient tout simplement impraticable.
Dans sa dynamique financière, le contrat au forfait s’avère donc incompatible avec les prédicats du développement incrémental – la glaciation des spécifications est intrinsèque à la gestion du risque par le fournisseur, et c’est en facturant au prix fort le changement qu’il optimisera sa marge. Cette aversion au changement est intrinséquement contradictoire avec les principes agiles.
Il reste bien sûr possible de bricoler quelques dispositions contractuelles offrant un terrain plus favorable aux méthodes agiles dans un projet au forfait. Mais aucune ne pourra effacer véritablement l’incompatibilité fondamentale entre un contrat focalisé sur le coût, et une pratique de développement incrémentale et adaptative.
Cela ne signifie évidemment pas que les méthodes agiles sont incompatibles avec la notion de contrôle budgétaire ou de maîtrise des coûts, bien au contraire. Mais il est indispensable, pour assurer le succès des méthodes agiles dans un contexte de sous-traitance, de repenser la façon dont sont conçues les relations contractuelles entre les parties. Cet aspect fera l’objet d’un très prochain article.
Depuis que je consulte ce blog je me demandais comment pouvait t-on contractualiser des développements itératifs. Je m’imaginais des itérations faisant l’objet de contrats à chaque fois : des mini-forfaits en quelque sorte.
Et la BAM ! ce 04/02 2 news qui m’apportent 2 réponses … contradictoire
Ce billet ci qui propose une analyse VRAIMENT intéressante.
Celui ci qui affirme que cela est possible : http://www.journaldunet.com/developpeur/algo-methodes/analyse/par-nathalie-lopez-saussier-valtech-technology-la-contractualisation-agile-une-affaire-de-bon-sens/par-nathalie-lopez-saussier-valtech-technology-la-contractualisation-agile-une-affaire-de-bon-sens.shtml (me semble difficilement réaliste tout de même vu les conditions nécessaires). Le top serait d’avoir des retour d’expériences …
En tout cas merci Guillaume Bodet et Xebia, ce sujet est passionnant
Le sujet est intéressant, puisque tous ceux qui se lancent dans des méthodes agiles se retrouvent confrontés au problème de la facturation.
Le verrouillement des contrats évoqué dans la dernière partie me semble valable quel que soit le mode de gestion de projet : même en cascade, il faut inscrire dans le contrat précisément ce qui devra être livré et à quelle date, pour ne pas se retrouver à devoir travailler gratuitement à cause d’imprécisions.
Une approche consiste à faire du forfait au niveau de la fonctionnalité : chiffrer le prix de chaque fonctionnalité demandée par le client. Le client connaît donc le coût total du développement (la somme du prix de toutes les fonctionnalités) et ce qui lui sera facturé à chaque fonctionnalité livrée. Et il peut toujours rajouter des fonctionnalités supplémentaires par la suite en mode agile. Elles devront être chiffrées à leur tour.
En revanche cela ne répond pas à la question des délais puisqu’en mode agile, si une fonctionnalité n’est pas finie, on la reporte au sprint suivant. On peut toujours faire des rustines, en s’engageant sur des délais pour certaines fonctionnalités critiques, en cravachant en cas de retard, mais on comment à s’éloigner des méthodes agiles…
Merci pour ce sujet qui fait preuve d’une grande lucidité.
Cela mets une fois de plus le doigt sur le choix entre un développement orienté budget (type forfait) qui assure une maitrise budgétaire pour le client parfois au dépend du résultat et un développement orienté produit qui assure la conformité avec le besoin réel du client et sa satisfaction.
Il est souvent difficile de militer pour les méthodes Agiles quand on les confronte au besoin de contractualisation, de mise en concurrence … avec toute le lot de méfiance improductive qui en découle.
Vivement le prochain article.
Sans aucun doute le plus gros frein à l’adoption des méthodes agiles.
Chez les grands comptes essayez donc d’expliquer l’agilité au département achat qui ne veut entendre parler que de forfait standardisé pour comparer et faire baisser le plus possible les coûts sans aucune préoccupation pour la qualité.
Et le forfait n’est pas prêt de disparaître. Imaginez-vous à un poste de responsabilité dans une grande boite, vous préférez être à la tête d’un gros projet au forfait de 10M d’euros ou juste responsable d’un petit projet agile de n * 200 000 euros ?
Article intéressant. En effet, le forfait est selon moi totalement opposé à la pratique de méthodes agiles. N’est-ce pas dérangeant qu’un mode de contractualisation influe sur les méthodologies projet utilisables ? Le « découplage » entre ces deux aspects est-il impossible à atteindre ? C’est d’autant plus dommage que sur certains marchés (notamment publics) le mode forfait est obligatoire.
@Frederic
Votre avis me semble très orienté lorsque vous indiquez :
un « développement orienté produit assure la conformité [...] et la satisfaction du client »
Pour moi qui ne travaille qu’en mode forfait je peux dire qu’il n’est pas si difficile de livrer un produit conforme et de satisfaire le client. D’ailleurs, une des grandes sources de satisfaction est bien évidemment la maîtrise du budget. Ensuite si les méthodes Agiles « assurent » la satisfaction du client je dit « c’est où qu’on signe » ?
@Waddle
Je suis d’accord que le mode de contractualisation devrait être « découplé ». Cela serait idéal : le contrat rédigé par le service juridique, le projet géré par les informaticiens. Je sens dans vos propos + un informaticien qui parle qu’un juriste…
@Thibaud
En effet, c’est l’informaticien qui parle
Je trouve très gênant de devoir gérer mon projet d’une façon différente que celle que je pense être la meilleure simplement à cause du mode de contractualisation.
Pour ce qui est de la livraison d’un produit conforme et satisfaisant le client, je pense qu’on confond souvent mode forfait et personne incompétente (dans l’étude du besoin client). Je m’explique : les problèmes concernant le périmètre rencontrés dans un projet au forfait sont presque tout le temps dû à un mauvais recueil du besoin et à une expérience trop faible du ou des personnes en charge de cet aspect. Du coup, on génère des conflits (argument souvent repris dans ce blog et plus généralement dans le discours des « agile evangelists »). Personnellement, j’entends cet argument car dans la grande majorité des cas, les personnes en charge du recueil du besoin dans un projet au forfait sont réellement sous-qualifiées dans ce domaine : recueil trop rapide, les bonnes questions ne sont pas posées, les termes métiers ne sont pas compris, les questions qui fâchent sont mises sous le tapis, les compte-rendus sont baclés, la rédaction a lieu bien trop longtemps après le recueil du besoin, etc.
Ainsi, on associe mode forfait à : conflit, dépassements en tout genre, avenants, etc.
Le mode forfait est très bien, s’il est correctement mené, mais clairement, beaucoup de sociétés de service n’en ont pas une grande expérience, ca ne peut forcément que mal se passer.
Je comprends que pour vous, il ne soit pas « si difficile de livrer un produit conforme » mais malheureusement, les SSII sont peuplées de personnes bien moins compétentes…
L’écueil principal dans le mode forfait vient à mon avis de ce paradoxe :
Un client est incapable de valider une application qu’il ne voit pas fonctionner. Or on lui demande de la valider « sur plan » comme pour une maison sauf que les plans font des dizaines voir centaines de pages.
Les SSII se blindent grâce aux specs fonctionnelles et ensuite la notion de conformité varie entre le client et le prestataire : l’application est conforme aux spécifications mais l’application n’est pas conforme aux besoins => client insatisfait mais n’a aucun recours (Vous les avez pourtant signée les specs !).
Après si l’agilité est présentée par les évangéliste comme un recours pour palier l’incompétence de certains on marche sur la tête.
Nous à partir d’un certain stade on pousse le client à découper son besoin quitte souvent à réduire le montant du projet. On préfère être rentable sur des projets plus petits (c’est rare qu’on dépasse 6 mois), satisfaire le client (qui commandera la suite normalement) que s’embarquer directement sur tout le périmètre et être submergé (en même temps on a pas de commerciaux payés à la com’, ça aide peut-être…)
Selon moi, il est tout à fait possible de cerner le besoin du client et d’aider le client à préciser son besoin. C’est même selon moi ce qui différencie un bon consultant (ou un chef de projet) d’un moins bon.
Je ne voulais pas dire que les évangélistes présentent la chose sous cet angle, mais que les arguments qu’il avancent ne sont souvent vrais qu’à cause de l’incompétence de certains. Qu’ils en soient conscients, je ne le pense pas, en tout cas pas la plupart des évangélistes (qui au passage se situent à mon avis encore dans le « Peak of Inflated Expectations » du hype cycle…)
Je suis en tout cas totalement d’accord avec votre attitude vis à vis des périmètres délirants et des projets démesurément grands. Mais comme vous le soulignez, certains facteurs « exterieurs » au projet (commerciaux payés au CA, peur de perte des budgets chez le client, politique politicienne interne au client, etc.) peuvent compliquer la mise en place de ces bonnes pratiques.
Était-il nécessaire de passer par la micro-économie pour constater que forfait == périmètre fixe ? Je pensais que c’était un postulat de base. Également, toutes les méthodes agiles ne sont pas à périmètre variable ; par contre elles sont itératives et incrémentales. Non ?
Comme le souligne Waddle, parfois le flou dans l’expression du besoin vient de la SSII, parfois du client qui peine à exprimer clairement (dans un langage informatique) son besoin. On le voit bien quand on reçoit certains cahiers des charges… Il n’empêche qu’une méthode incrémentale, basée sur un proto initial, une levée des risque très en amont, l’intégration très tôt, etc… permettent de gérer quelques uns des problèmes relevés dans l’article et les commentaires. Est-ce de l’agilité ?
Je suis censé dire que c’est d’abord du bon sens, mais même certains fan de l’agilité (en tout cas ceux qui sont honnêtes et réalistes) rappellent que beaucoup des paradigmes de l’agilité ne sont en réalité que du bon sens.
Cela fait des années que je travaille dans un cadre forfaitaire et sur tous mes projets, les risques sont identifiés et suivis à la loupe, des protos sont réalisés quand cela est nécessaire, l’intégration est continue, etc.
Il y a beaucoup de commentaires, donc je vais répondre un peu en vrac.
L’unique objet de cet article est d’établir les termes du syllogisme suivant : un projet agile doit tolérer les variations de périmètre ; or un projet au forfait implique le gel du périmètre ; donc un projet agile ne peut pas être mené au forfait.
Le détour par la micro-économie permet d’expliquer l’équivalence forfait-périmètre fixe (en faisant du gel des spécifications la principale protection du fournisseur).
Je suis sans ambiguité possible un adepte convaincu des méthodes agiles. Xebia réalise en sous-traitance des projets agiles. Mais pas au forfait (je vous expliquerai tout ça dans un prochain article).
Je sais d’expérience que le succès d’un forfait (donc de la cascade) repose précisément sur la capacité du client à exprimer correctement ses besoins dès le démarrage du projet. Je ne dis pas que c’est impossible. J’affirme par contre qu’une telle situation est l’exception plutôt que la règle (@Waddle : ne pensez-vous pas que la difficulté à capturer les exigences en amont est davantage une propriété intangible du développement logiciel – les utilisateurs ne savent pas ce qu’ils veulent – qu’un problème de compétence ?). Le forfait entend vendre un projet de développement spécifique (donc une création originale) comme une automobile : on décrit le modèle, la couleur, la carburation et les options. Le concessionnaire propose un prix et un délai. On négocie un peu et on signe un contrat de vente. Si ça dérive un peu, on fait les gros yeux. Si ça dérive beaucoup, on obtient une ristourne. Si ça dérive passionnément, on règle ça au tribunal.
Le problème, c’est qu’un logiciel spécifique n’est pas une voiture. La comparaison réviendait plutôt à s’adresser à un constructeur automobile pour lui commander un modèle original, destiné à un usage très spécialisé… Et on comprend bien que les dispositions contractuelles liant les parties dans un tel projet ne peuvent pas prendre la forme d’un forfait (au demeurant, ce type de partenariat est fréquent dans l’industrie, notamment dans l’automobile et l’aérospatiale).
Bref, je n’ai jamais vu fonctionner le forfait que sur des projets minuscules, adressant des problématiques très stables et faiblement critiques. L’exception, pas la règle, donc.
Les gros projets au forfait, représentant, disons, plus de 10 années-hommes d’effort (budget supérieur à 1M€), tournent presque systématiquement à la bérezina, et ce quelle que soit l’expérience du fournisseur (je vous renvoie au controversé Chaos Report du Standish Group, ou aux études répétées du Gartner Group sur le sujet).
Reste le problème d’ego, relevé par Aurélien : on sera vraiment sorti d’affaire quand la mesure de la compétence d’un responsable de projet sera non pas le coût du projet mais ce qu’il a rapporté… Sans rire, dans quel autre domaine que l’informatique la performance opérationnelle est-elle mesurée à la capacité à dépenser de l’argent ?
Les utilisateurs ne savent jamais ce qu’ils veulent, c’est en effet une tautologie
Mais ce n’est à mon sens pas si grave docteur. Simplement, des chef de projets expérimentés et compétents arriveront toujours a extraire la substantielle moelle de son besoin, quitte à aider le client à se comprendre lui-même si je puis dire.
Votre comparaison avec la voiture est un peu osée je trouve. Ce que vous dites est vrai quand l’évaluation de la charge est mauvaise dès le départ. Mais encore une fois, une analyse allant plus loin que la simple lecture du cahier des charges évite ce genre d’écueil. Combien d’AO reçoivent des réponses de la part de SSII qui n’ont même pas posé une question au client…
Pour ce qui est des gros projets au forfait, je ne me prononce pas, je n’ai jamais personnellement participé à un projet au forfait de plus de 500K€. Mais comme j’ai coutume de dire, un projet a 300K peut parfois être 5 projets a 60K. Je ne suis pas pour tirer une ligne définissant le possible de l’impossible.
En tout cas, on sent bien au vu des commentaires que le sujet est complexe, sensible et que donc votre série d’articles tombe à pique
[...] les projets Agile ne peuvent pas être vraiment menés au forfait http://blog.xebia.fr/2009/02/04/pourquoi-les-projets-agiles-ne-peuvent-pas-vraiment-etre-menes-au-fo... RSS Classé dans: Java Tags: [...]
Bonjour Guillaume, je constate que ton article fait beaucoup couler d’encre encore, j’avais déjà pu constater les effets de ta session lors de USI 2008, on avait reçu pas mal de retour client à l’époque
, tu apportes un œil nouveau sur le sujet.
« Comment vendre un projet en agiles ».
Question ? Ne risques tu pas de révéler les secrets de Xebia
Pour ton dernier commentaire, je l’adore « Sans rire, dans quel autre domaine que l’informatique la performance opérationnelle est-elle mesurée à la capacité à dépenser de l’argent ? »
Je trouve ta remarque scandaleusement vrai, c’est très triste en meme temps…
Comme toi j’ai attaqué une série de blog sur le sujet dans le cadre de la pratique du Lean dans nos projets.
Si tu prouves que le mode forfait est incompatible avec la notion de maitrise des couts, et la valeur rapportée par le logiciel.
J’enfonce le clou, la cascade institue l’incompétence, et l’inexpérience de l’équipe en cachant les défauts sous un stock de spécifications fonctionnelles, de développements, de recettes, et d’anomalies.
Je me pose une question simple @Wadle, tu dis que certains projets en cascade reussisent grâce aux capacités exceptionnelles d’un chef de projet.
Cela veux dire que la réussite d’un projet en cascade de plusieurs centaines de milliers d’euros repose sur la capacité d’un seul individu, je trouve ceci peu acceptable en tant que chef d’entreprise, vu l’importance de IT dans la stratégie de l’entreprise.(mais c’est une réalité)
C’est l’équipe qui doit être hautement qualifiée, avec des procédures standardisées et des outils adaptes et efficaces, et qui recherche en permanence à les maximiser leur efficacité, par l’amélioration continue.
)
Je pense meme la comparer à une équipe chirurgicale.
Il y a un manga actuellement intitule « Team médical dragon » qui résume bien le concept(petit clin d’œil
Sinon je vous invite a lire mes articles de blog.
En tout cas Guillaume j’aimerai beaucoup discuter de ces sujets avec toi vraiment!!
J’ai 2 autres articles en court……
Voici les liens.
http://www.neoxia.com/blog/index.php/2008/12/11/83-lean-stock
http://www.neoxia.com/blog/index.php/2009/01/14/90-reduire-les-stocks-pour-livrer-au-plus-tot
Salut
J’aimerai rebondir sur la critique de Bruno, qui d’ailleurs correspond au thème que je voulais aborder :
« Il n’empêche qu’une méthode incrémentale, basée sur un proto initial, une levée des risque très en amont, l’intégration très tôt, etc… permettent de gérer quelques uns des problèmes relevés dans l’article et les commentaires. Est-ce de l’agilité ? »
Je suis entièrement d’accord avec cette remarque : qu’est ce qui empêche de faire un projet au forfait basé sur des itérations courtes ? Sera t il Agile pour autant ?
Perso, je pense que l’Agilité se résume surtout à prendre le dessus sur les incertitudes du développement logiciel, dont on sait que chaque projet est unique. Et là toute la différence avec un forfait, c’est les Scrum Meeting et tout le processus de réévaluation permanente, avec le client, du progrès, des encours et des difficultés.
Le postulat qui semble se dégager de cet article « Agilité = itérations courtes » est pour moi bien insuffisant.
Ceci dit, cela n’enlève rien à la problématique du chiffrage des projets agile et des engagements contractuels.
++
joseph
*
Pour moi Guillaume ne souhaite pas rentrer sur le chemin du forfait, pour une raison simple, le forfait en terme de contrat a été totalement assimilé au processus de développement aujourd’hui.(Alors qu’il ne le devrait pas)
Les clients ne perdront pas leurs habitudes du jour au lendemain.
*
« Lorsque tu écris « L’itération me parait bien insuffisant ».
Comment doit on le comprendre.
En tout cas je pense que c’est la pierre angulaire de l’agilité.
C’est une révolution en soi.
Nous passons d’une approche de stocks (Spec,Dev,Test) à la construction d’une application en mode flux.
En baissant nos stocks, nous révélons les problèmes cachés dans la fabrication de l’application.
Pour moi l’itération est indispensable.
Bonsoir Karim
pour ma part, j’avais entendu parler de projets en itérations courtes bien avant d’entendre parler de méthodes agiles. De même, rien n’interdit à mon sens des forfaits conçus autour d’itérations courtes.
Cela ne veut pas dire que les itérations courtes ne sont « rien » à l’approche Agile, mais plus prosaïquement que les itérations sont nécessaires et non suffisantes à une approche agile.
L’approche en « flux » au lieu de « stock » a d’ailleurs bien peu à voir avec les itérations, elle n’en dépend guère « en soi ». Par contre, à mon sens, elle est déjà plus significative des avancées permises par la réflexion autour de l’agilité.
Comme dit auparavant, je pense que le plus important de l’approche agile est cette capacité d’adaptation dictée par la réalité du développement logiciel. C’est là je trouve toute la révolution agile, cesser de croire à une possibilité de planification amont « de haut » et à l’existence de projets finis à 95%.
En somme, face à un tel processus non prédictif, seul des contrôles au plus près et permettant des décisions souples et rapides permettent de s’adapter au mieux.
++
joseph
Je ne dis pas que le forfait et des itérations courtes sont incompatible du tout sur le principe, mais dans la réalité, il en est tout autre, d’où la démonstration de Guillaume, pour moi elle me parait claire.
Ensuite je ne vois de quoi tu parles « planification en amont » et a « l’existence de projet finis à 95% », à aucun moment je ne discute sur ces sujets, sorry.
Personnellement j’évite le mot planification, qui est une mauvaise traduction du mot planning, l’un est figé, l’autre est en mouvement perpétuel.
Tu ne vois pas la corrélation entre itération et flux.
En fait les processus agiles existent dans l’industrie depuis plus de 50 grace à Toyota.
De son expérience on en a tiré une demarche appelé Lean Manufacturing
L’un des fondement même pour fabriquer un produit juste, de bonne qualité, et sans défaut, et de réduire les cycles de fabrication, or cette pratique dans le logiciel s’appelle itération courte.(Le modèle Toyota), l’intérêt du flux est de répondre à la demande, il me semble, donc de s’adapter
Je t’invite a lire mon article sur le lien que j’ai fourni précédemment.
Tres cordialement Karim
Bonjour Karim,
J’ai du mal à voir le parallèle entre le développement informatique dans le cadre d’une prestation client/fournisseur et Toyota (et j’ai lu avec beaucoup d’attention vos billets sur le sujet et la livraison de fonction en 245 jours).
Pour ma part (dev informatique) : 1 produit = 1 client
Pour toyota : 1 produit = 1 000 000 clients. La phase de conception est en amont du processus de fabrication (même elle inclue le processus de fabrication). Toyota ne passe pas de contrat avec ses clients sur un périmètre.
Comment peut-on adapter ce modèle puisque nous devons effectuer une phase de conception à notre processus de fabrication et qu’il n’est pas possible de la mutualiser sur plusieurs clients. Ou alors on est un éditeur de logiciel (là je peux voir le parallèle mais ça n’a plus de lien avec le sujet) ? Il y a un moment où on doit avoir du recul sur le besoin, une vision d’ensemble de la problématique du client et de sa stratégie pour proposer une réponse adaptée. Livrer systématiquement une fonctionnalité au plus tôt peut s’avérer contre productif surtout si le client ne sait pas précisément ce qu’il veut.
Je n’ai pas trouvé de réponse à cette question dans votre article. Peut-être que je suis vraiment trop « old school » (ça me ferait mal à 26 ans)
Pour rebondir sur ce que dit Guillaume, il reste possible d’adapter le périmètre sur un contrat au forfait. Contractuellement on fait un avenant. Parfois il peut même s’avérer nul financièrement pour le client si les modifications n’ont pas d’impact sur la charge globale (ce qui suppose de l’avoir estimé en amont) et si la SSII est honnête.
@Thibaud
Il est effectivement possible de changer le périmètre sur un projet au forfait à l’aide d’avenants. Mais les avenants ne sont jamais « nuls financièrement ». A supposer que la modification n’a pas d’impact sur la charge globale , il reste toujours le coût de transaction, lié à la contractualisation de l’avenant à proprement parler. Ajoutons que l’absence d’impact reste de toutes façons l’exception, dans la mesure où les avenants sont un puissant levier de profit pour les prestataires, hors de toute contrainte concurrentielle (impossible pour le client de s’adresser à une autre société). Ce n’est pas de la malhonnêteté, juste un comportement rationnel encouragé par le système du forfait…
Il y a pourtant une solution exposée par Claude Aubry ici qui s’appelle la clause « Money for Nothing » …
http://www.aubryconseil.com/post/Gagnant-gagnant
Le client peut arrêter les développements à tout moment s’il estime avoir assez de valeur. Il doit alors payer le fournisseur au pro-rata du temps passé, plus 20% du reste (par rapport au prix fixé au départ).
Le fournisseur a alors intérêt à finir plus vite, et le client aussi (ce qui le pousse également à s’impliquer au maximum).
Une autre façon de contractualiser est de fixer le prix et les incréments, mais pas le périmètre : http://www.aubryconseil.com/post/2008/04/14/401-contrat-au-forfait-et-demarche-agile
Bien évidemment, aucune de ces solutions n’est parfaite, et la confiance mutuelle est essentielle dans le processus. Mais le fait de pouvoir arrêter à tout moment pousse normalement le fournisseur à justifier cette confiance.
Cordialement,
Nicolas
[...] La deuxième partie de la soirée sera consacrée à la mise en place de Scrum par Guillaume Bodet de Xebia. Quels sont les obstacles que l’on peut rencontrer ? Quels sont les effets de la mise en place de Scrum ? Basé sur son expérience du terrain, Guillaume nous présentera comment adapter la mise en place d’une méthode Agile à notre environnement, à notre biotope. Il est intervenu à plusieurs reprises sur TV4IT, ainsi que sur le blog de Xebia France : “Pourquoi les projets agiles ne peuvent pas (vraiment) être menés au forfait ?“. [...]
Bonjour,
Je débute en Agile donc je vais probablement tomber à côté du sujet. Votre article me fait penser à un des paradoxes de Zénon, en l’occurrence « La pierre lancée vers un arbre », qui n’en finit pas de se rapprocher de sa cible sans jamais l’atteindre (cf. lien Wikipédia http://fr.wikipedia.org/wiki/Paradoxes_de_Z%C3%A9non). L’objectif du Product Owner (représentant légitime du client), est bien d’obtenir un produit fini dans un temps fini, en adoptant une approche priorisée et itérative des fonctionnalités à implémenter. Si comme la pierre, il n’en finit pas de se rapprocher du produit final, c’est que soit (1) la cible s’est significativement déplacée de sa position de départ (il s’agit d’un tout autre produit que celui décrit lors du premier backlog et la pierre repart en mode acquisition-poursuite, c’est plus de l’agile mais de l’équilibrisme ou de l’écartèlement), soit (2) la distance a considérablement augmenté (problème de mesure de la valeur par le Product Owner, donc mauvaise priorisation et la pierre fait des détours inutiles, ça manque de coaching agile). Dans le cas d’un projet, agile de surcroît, la pierre a une conscience (et une mémoire) qui doit lui permettre de réagir et s’adapter… Par exemple, la mise en oeuvre forfaitaire d’une application donne toujours lieu à un budget projet et un budget maintenance. L’équipe étendue (dont fait partie le Product Owner) doit par exemple décider (arbitrage) de basculer (sacrifice) une partie des fonctionnalités dans le backlog de la maintenance évolutive de cette application. C’est d’autant plus facile si les règles du jeu ont été annoncées dès le départ dans le contrat agile du projet.
Cordialement, Fabrice
[...] http://blog.xebia.fr/2009/02/04/pourquoi-les-projets-agiles-ne-peuvent-pas-vraiment-etre-menes-au-fo... [...]