Discussion :

[zecreator]

Bonjour,

Comme est maîtrisé le budget lorsque l'on met en place la méthode Agile dans un projet client ?

Travailler par itération est très séduisant, surtout pour s'assurer de la bonne marche du projet et de la satisfaction du client. Mais dans ma boite, tous les temps sont chargés. Entendez par là que la moindre minute passée sur le projet est facturée au client (donc déduit du budget). Et chez nous, le budget est définit en amont et est fixe.

Du coup, comment peut-on éviter le dépassement de budget avec Agile ? Comme assurer au client qu'il ne paiera pas plus que ce qui était prévu dans notre offre initiale ?

Zecreator.

[Marco46]

En gros tu travailles au forfait, c'est à dire qu'on te donne un budget, un périmètre figé et que tu as une obligation de résultat, peu importe le temps que tu y passes. C'est tout à fait contraire à l'esprit de l'agile parce que ça fige le périmètre alors qu'en agile le but est justement de pouvoir le faire varier (priorisation, descopage et ajout de fonctionnalités). On peut aussi éventuellement faire varier le budget, les dates, etc ...

Je te suggère de faire une simple recherche Google sur les mots clets "forfait" et "agile" et tu verras qu'il y a pas mal d'articles sur le sujet.

Par exemple.

EDIT :

Du coup, comment peut-on éviter le dépassement de budget avec Agile ? Comme assurer au client qu'il ne paiera pas plus que ce qui était prévu dans notre offre initiale ?

La seule solution c'est de faire varier le périmètre. Si le périmètre et le budget ne sont pas variables, alors tu ne peux tout simplement pas faire de l'agile. C'est antinomique.

[zecreator]

En gros tu travailles au forfait, c'est à dire qu'on te donne un budget, un périmètre figé et que tu as une obligation de résultat, peu importe le temps que tu y passes. C'est tout à fait contraire à l'esprit de l'agile parce que ça fige le périmètre alors qu'en agile le but est justement de pouvoir le faire varier (priorisation, descopage et ajout de fonctionnalités). On peut aussi éventuellement faire varier le budget, les dates, etc ...

C'est exactement ça. On répond à un appel d'offre, on fourni une proposition commerciale avec un coût fixé qui ne bougera pas jusqu'à la livraison finale. Nous avons l'obligation de définir un budget initial qui doit être accepté par le client. Ce budget couvre un certain nombre de jour/homme. C'est ce qui définit notre chargeabilité et notre rentabilité au sein de la boite. Chaque temps passé sur le projet est décompté du budget. Quand il n'y a plus de budget, on devrait refacturer le client pour du temps supplémentaire, ce que l'on fait rarement. Dans ce cas, une partie du projet est développé hors budget (sans surcoût pour le client donc).

Pour maîtriser le budget, on s'assure de faire valider les fonctionnalités par le client avant développement, avec une marge de modification très restreinte après livraison.

Bon, je rassure tout le monde. Nous développons des modules e-learning, pas de gros système IT. Les projets sont moins techniques et moins imposants. De plus, nos clients ne sont absolument pas au fait des méthodes Agile (voir des méthodes de gestion de projet). On a des DRH, ou des responsables de formation qui n'ont absolument pas de temps chaque jour à consacrer à des décision de fonctionnalités. On est un peu en roue libre, et on prévoit juste des phases de validation à des dates précises.

Cependant, je me demande comment peut-on s'inspirer d'Agile dans un tel contexte. Peut-on prendre une partie de la méthode, et l'adapter ?

Zecreator.

[Luckyluke34]

Je plussoie Marco46 sur l'impossibilité d'avoir un budget fixe en Agile si tu fixes aussi le scope.

La manière typique de maîtriser son budget dans les contrats agiles est de se ménager des clauses de sortie régulières ou libres avec sprints de pénalité.

Ex :
- contrat "à tiroirs" par lots de 4 sprints renouvelables
- contrat pour 12 sprints avec clause de sortie libre qui entraine le paiement de 2 sprints de sécurité

L'idée, c'est de favoriser une sortie propre à la confrontation comme on la connait dans des projets à coût et périmètre fixes, qui peuvent s'embourber quand il y a un conflit. Les méthodes de développement agiles par tranches fonctionnelles (à la fin de chaque sprint, on est censé livrer un incrément logiciel qui marche et prêt à être déployé) garantit que le client aura au moins un pan de logiciel entièrement fonctionnel en cas de sortie.

[Marco46]

Cependant, je me demande comment peut-on s'inspirer d'Agile dans un tel contexte. Peut-on prendre une partie de la méthode, et l'adapter ?

En fait l'agile découle de deux constats (entre autre je suis pas un spécialiste, je t'explique les choses telles que je les ai vécues en tant que dev) :

- il est impossible que les estimations correspondent avec le consommé réel parce qu'il est impossible de savoir à l'avance la réalité concrète de l'implémentation. C'est tout simplement trop complexe, il a trop de variables et trop de facteurs exogènes.
- le périmètre peut évoluer entre le moment où il est fixé dans le contrat et le moment où on livre (les clients changent souvent d'avis, parfois à tord (besoin mal défini) et parfois à raison (évolution du besoin)), le livrable ne correspondra donc plus au besoin.

C'est une simple constatation : fixer un périmètre à l'avance est inefficace (effet tunnel), et c'est un mensonge. Ca suppose également de mettre un terme à cette stupidité qui est : la date de livraison. En développement logiciel, la seule partie qui devrait être fixe et non négociable c'est la qualité du code.

A partir de là comment faire ?

Dans le cadre d'un forfait c'est mort sauf si on ouvre la possibilité de faire des avenants au contrat au fil du développement. Je ne sais pas si c'est ce que Luckyluke appelle des "clauses de sortie régulières ou libres" mais j'ai déjà travaillé de cette manière. Enfin c'est pas moi qui gérait j'étais simple dev mais ça fonctionnait assez bien apparemment.

[Luckyluke34]

@Marco46 Ce n'est pas exactement ça, car pour faire un avenant à un contrat, il faut que les deux parties soient d'accord à ce moment précis. Cela ne donne pas toute la tranquilité d'esprit nécessaire au client car le fournisseur peut refuser l'avenant (ou vice versa) et on rentre dans de longues tractations pour savoir si le refus est de bonne foi ou pas, on se tire dans les pattes en se cherchant des motifs de reproches, etc. ; c'est ce qui peut arriver dans les gros projets au forfait qui se passent mal.

Ce dont je parle se décide dès le début et donne juridiquement le droit à une des deux parties d'agir - par opposition à quelque chose qui se négocierait selon le bon vouloir des acteurs au sein d'un contrat long et rigide. C'est

• Soit une clause qui dit par exemple "une des deux parties a le droit de sortir du contrat quand elle veut en payant 2 sprints de pénalité".
• Soit un contrat "à options" qui de base prévoit seulement quelques sprints mais avec une clause qui précise le coût d'itérations optionnelles à activer en cours ou en fin de contrat.
• Soit carrément un "forfait au sprint" avec plein de mini contrats qui s'enchaînent.

@zecreator : ta question d'origine est comment est maîtrisé le budget (côté presta) ? L'approche agile bouleverse cette question en posant comme premier postulat qu'on ne peut connaître le scope exact du besoin en début de projet. Dès lors, la seule réponse valable est :

en n'indiquant pas de budget précis au départ.

La seule chose connue dès le début est le coût d'une itération. Au fur et à mesure du projet, deux choses s'affinent : les besoins métier (+ leurs priorités relatives) et la charge de travail qui peut être abattue en une itération par l'équipe (en unités-besoin).

Le client qui partait un peu dans l'inconnu en début de projet (mais c'est pour ça qu'on fait des contrats courts ou des clauses de sortie) va peu à peu prendre confiance en ce que l'équipe de réalisation peut produire et mieux cerner le coût de chaque pan fonctionnel. Au bout de quelques itérations, l'équipe est complètement apte à s'engager sur les fonctionnalités qui vont sortir en bout de sprint et c'est là que le client va enclencher les itérations optionnelles ou continuer sans faire jouer sa clause de sortie.

En tout cas, l'agilité ne peut se mettre en place correctement sans l'accord et l'implication totale du demandeur (client externe ou interne).

[zecreator]

Donc Agile ne semble pas être mise en place ailleurs que dans un contexte de régie ? C'est vraiment une méthode spécifique à ce monde. Il faut oublié Agile à partir du moment où le client souhaite savoir à l'avance ce qu'il va payé (comme moi avec mon artisan qui s'occupera de ma terrasse). S'il y a "devis", Agile ne peut pas fonctionner car tout est fixé avant chantier.

Merci pour vos infos.

Zecreator

[Marco46]

L'agile a été créé parce que fixer à l'avance le budget et le périmètre ne fonctionne pas dans 70% des cas.

Je te laisse méditer sur cette assertion

[Luckyluke34]

Donc Agile ne semble pas être mise en place ailleurs que dans un contexte de régie ? C'est vraiment une méthode spécifique à ce monde. Il faut oublié Agile à partir du moment où le client souhaite savoir à l'avance ce qu'il va payé (comme moi avec mon artisan qui s'occupera de ma terrasse). S'il y a "devis", Agile ne peut pas fonctionner car tout est fixé avant chantier.

Dans l'esprit, c'est exactement ça. Dans la pratique, le concept de forfait n'est pas aussi rigide qu'on pourrait le penser. C'est un engagement de résultat, mais, comme je le disais, on peut jouer sur l'objet de ce résultat, la durée, ajouter des clauses qui l'assouplissent, etc.

Il y a des tentatives (apparemment réussies) de forfait agile :

http://agiletour-montpellier.fr/atmp...I-ATM-2014.pdf
http://www.aubryconseil.com/post/200...demarche-agile
https://jfallet.wordpress.com/2013/09/03/forfait-agile/

Il convient de distinguer l'approche méthodologique (agile, waterfall, etc.) et la forme de contractualisation, ce sont deux variables qui ont des interactions entre elles mais indépendantes.

[zecreator]

Merci tous pour ces éclaircissements