de mon point de vue, l’élément vraiment différentiant avec un projet au forfait est la capacité en continu à aligner le produit aux évolutions du besoin métier.

Le métier (et non pas la MOA) est donc en continue présent sur le projet et souvent sur des longues années, ce qui n’est bien sûr pas le cas dans un projet au forfait, le CDC étant l’entrant intangible de ce type de projet.

Or le besoin étant souvent dynamique (à part pour quelques cas exceptionnels de projet très techniques ou éloignés du core business du client), il est quasi impossible, sur des gros projets, d’avoir un produit livré en fin de projet qui satisfasse le métier en partant d’un CDC établi bien longtemps avant.

Le fait donc de s’aligner en continue avec le besoin est donc réellement la clef du succès des projets agiles. Ce qui induit mécaniquement l’utilisation d’itérations courtes permettant cette abilité à s’adapter.

En fait, la démarche par itération est simplement une conséquence de ce principe

Bien sûr, la démarche par itération n’est pas innovante en soi et cette démarche peut très bien être menée dans le cadre d’un projet au forfait standard. Mais elle n’aura pas du tout les mêmes effets.

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

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.

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

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

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

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

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

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 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.

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…)

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…

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…

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 ?

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…