Discussion :

[j.mathieu]

Bonjour,

Je m'intéresse de plus en plus aux méthodes agiles et en particulier à SCRUM.
Une question me tourmente :
Comment chiffrer précisément un projet, à l'aide de SCRUM, avant le début de sa réalisation ?

Je vois bien l'utilité du PlanningPoker par exemple, pour estimer la complexité des différentes fonctionnalités, ensuite rapporté au calcul de vélocité. Cela peut permettre effectivement de piloter globalement les releases et sprint.
Néanmoins, l'essence même de SCRUM : son adaptativité empêche une estimation précise dès le départ.

Ainsi, si ces méthodes agiles me paraissent très intéressantes pour des projets internes, cela est beaucoup moins clair pour des projets externes où les clients attendent un devis clair net et précis avant le commencement du projet.
Par "devis" j'entends budget et date.

Quelles sont vos expériences par rapport à ça ?

[Heziva]

La vrai question que tu pose, c'est :

Comment chiffrer précisément un projet, avant le début de sa réalisation ?

Pour moi la réponse est simple : c'est impossible. Le mot "précisément" est de trop. Scrum propose l'approche suivante : nous allons chiffrer grossièrement votre demande. Puis, nous développerons 1~3 mois ensemble. Ensuite, nous réévalurons chaque mois vos priorités.

Chiffrer précisément un projet revient à fixer d'avance les couts, les délais et le périmètre de celui ci. Les méthodes agiles expliquent que ce n'est pas souhaitable de fixer ces trois paramètres des mois et des mois en avance.

Sur le sujet de la contractualisation dans les méthodes agiles, tu touches un point complexe. Je n'ai pas réellement de réponses sur ce sujet. Mais les éléments ci-dessus peuvent te donner une base de reflexion. J'ai pu voir passer des contrats nommés "win-win" : nous parions sur cette durée pour ce périmètre et ce coût. Si on est en avance, nous partagerons le bénéfice, et si nous sommes en retard nous partagerons le surcoût.

Bonne recherche,
Jonathan

[j.mathieu]

Comment chiffrer précisément un projet, avant le début de sa réalisation ?

Je préciserais juste en disant que ma vraie question est :
Comment chiffrer un projet, à l'aide de Scrum, avant le début de sa réalisation ?

nous allons chiffrer grossièrement votre demande. Puis, nous développerons 1~3 mois ensemble. Ensuite, nous réévalurons chaque mois vos priorités.

J'imagine déjà la tête des clients
Même si c'est très juste, ça ne fait pas "sérieux", ça fait un peu marchand de tapis. Car il ne faut pas oublier que le client lui, ne connait pas forcément les méthodes agiles !

J'ai pu voir passer des contrats nommés "win-win" : nous parions sur cette durée pour ce périmètre et ce coût. Si on est en avance, nous partagerons le bénéfice, et si nous sommes en retard nous partagerons le surcoût.

Sur le papier c'est une bonne idée. Par contre je nuancerais le "win-win" car dans ce cas de figure c'est davantage le client qui gagne :

Côté fournisseur :
Si on a de l'avance : la facture finale sera moins élevée => alors qu'on aurait pu gagner un peu plus "en ne faisait rien".
Si on a du retard : on a mal évalué au départ et au final on ne gagne que 50% sur le surplus.

Côté client :
Si le projet a de l'avance : Youpi, je fais des économies
Si le projet a du retard : Mon fournisseur a mal évalué au départ, au final je gagne 50% de réduction sur le surplus.

[montesq]

J'ai pu voir passer des contrats nommés "win-win" : nous parions sur cette durée pour ce périmètre et ce coût. Si on est en avance, nous partagerons le bénéfice, et si nous sommes en retard nous partagerons le surcoût.

Mais au final, le problème est toujours présent sur l'estimation du périmètre avant contractualisation, non? Que se passe-t-il si le périmètre évolue fortement au cours du process de développement?

Un projet agile en mode régie (ou idéalement en interne) me paraît plus légitime même si dans ce cas le business perd la visibilité budget?

[Heziva]

Encore une fois, je ne suis pas le bon interlocuteur pour vous parler de la contractualisation. Je vais tenter de répondre tout de même à vos remarques...

Même si c'est très juste, ça ne fait pas "sérieux", ça fait un peu marchand de tapis.

Dans tous les cas, tu ne souhaites pas faire de méthodes agiles avec un client qui ne veut pas s'impliquer. Ces méthodes demandent une présence beaucoup plus grande du client. Pour XP, tu as un client sur site. Pour Scrum, tu as une démo par mois. Alors certes tu peux adapter, prendre un représentant du client, mais il est impératif que tu ais un engagement fort du client final.
Par ailleurs, c'est un peu comme ça que fonctionne la régie. C'est donner à ton fournisseur une obligation de moyen, et non de résultats. Il est clair que c'est faire beaucoup plus confiance au fournisseur que dans un forfait classique, où le fournisseur doit remplir une spécification et non un besoin client évolutif.
Enfin, après plusieurs avenants, la relation client/fournisseur en arrive souvent à un point très similaires. Les avenants se font de plus en plus courts, et le contrat liant fournisseur et client se tourne vers la maintenance...

Par contre je nuancerais le "win-win" car dans ce cas de figure c'est davantage le client qui gagne

Davantage que quoi? Que le contrat classique ? Celui où :
Côté fournisseur :
On est en retard, je paye tous les pots cassés
On est en avance, je temporise pour justifier ma vente initiale
Côté client :
On est en retard, youpi je vais leurs mettre des pénalités
On est en avance... ah ? Ca n'arrive jamais ?

Mais au final, le problème est toujours présent sur l'estimation du périmètre avant contractualisation, non?

Comme pour une gestion de projet en V, tu commenceras par une étude complète du projet. Tu diviseras le projet en modules, que tu estimeras en temps, en risque et en valeur client. Une fois ce travail effectué, tu peux contractualiser. Puis tu fera ta spécification (ou l'équivalent) en fonction de ces priorités. Une spec. "just in time".
Si le périmètre change, tu estime la durée de ces nouveaux besoins. Lorsque ceux ci concernent une partie non implémenté, aucun souci. Si ceux ci concernent une partie déjà codée, il faut simplement les compter comme de nouveaux développements. Et retirer du contrat le surplus.

Pour reprendre une image que j'ai vue sur une présentation, imagine toi une échelle, avec une limite au Xième barreau. Tout ce qui est en dessous ne sera fait que "si on a le temps". Ce qui est au dessus sera implémenté. Le client a toute latitude pour déplacer les briques au dessus ou en dessous de la limite, dans la mesure où le temps de réalisation reste constant. Au final, l'engagement pris initialement ne signifie que "Produire X points de tâche en X temps".

[Bruno Orsier]

Ainsi, si ces méthodes agiles me paraissent très intéressantes pour des projets internes, cela est beaucoup moins clair pour des projets externes où les clients attendent un devis clair net et précis avant le commencement du projet.
Par "devis" j'entends budget et date.

Quelles sont vos expériences par rapport à ça ?

Perso je connais que le cas de projets internes. Mais je serais curieux de savoir si les devis "clair net et précis avant le commencement du projet" sont généralement bien respectés en pratique ? C’est-à-dire sans avenants au contrat.

Je me suis laissé dire que dans certaines SSII on était considéré comme un mauvais chef de projet si l'on était pas capable d'arracher moult avenants au client. Qu'en pensez-vous ?

Bruno

[Maximil ian]

Il est clair que c'est faire beaucoup plus confiance au fournisseur que dans un forfait classique, où le fournisseur doit remplir une spécification et non un besoin client évolutif.

En effet, la confiance est un point clé des projets agiles. Comme dit l'Agile Manifesto, il faut essayer de privilégier "Customer collaboration over contract negotiation". Cela passe par une relation apaisée et de confiance entre le prestataire et le client, et là est toute la difficulté bien sûr dans un secteur et un pays ou on a plutôt tendance à cultiver cynisme et art de l'affrontement.

Un projet agile en mode régie (ou idéalement en interne) me paraît plus légitime même si dans ce cas le business perd la visibilité budget?

C'est sûr, à l'heure actuelle les habitudes et le droit autour des projets au forfait ne les désigne clairement pas comme une cible idéale pour introduire l'Agilité.

Pourtant des solutions existent et plusieurs SSII proposent des forfaits agiles à l'heure actuelle. Une forme de contrat agile (il en existe de multiples) peut être :

- contrat initial portant sur un nombre fixé d'itérations
- lots additionnels (=itérations supplémentaires) que le client pourra activer ou pas
- clause de retrait que le client peut faire jouer en cours de projet, avec paiement d'un certain nombre d'itérations à sa charge.

La société Valtech a publié un papier intéressant sur le sujet : http://valtech.developpez.com/articl...actualisation/

[j.mathieu]

Si je résume, il n'y a pas vraiment de solutions à ce problème.
Les méthodes agiles ne sont pas encore assez entrées dans les moeurs afin de pouvoir contractualiser facilement un forfait agile avec le client.

[lepinekong]

Si je résume, il n'y a pas vraiment de solutions à ce problème.
Les méthodes agiles ne sont pas encore assez entrées dans les moeurs afin de pouvoir contractualiser facilement un forfait agile avec le client.

Disons que ce sont deux aspects différents: le cadre contractuel qui est un forfait, et le cadre agile qui est un cadre de conduite de projet.

Le cadre agile peut permettre de justifier les avenants.

[lepinekong]

En effet, la confiance est un point clé des projets agiles. Comme dit l'Agile Manifesto, il faut essayer de privilégier "Customer collaboration over contract negotiation". Cela passe par une relation apaisée et de confiance entre le prestataire et le client, et là est toute la difficulté bien sûr dans un secteur et un pays ou on a plutôt tendance à cultiver cynisme et art de l'affrontement.


C'est sûr, à l'heure actuelle les habitudes et le droit autour des projets au forfait ne les désigne clairement pas comme une cible idéale pour introduire l'Agilité.

Pourtant des solutions existent et plusieurs SSII proposent des forfaits agiles à l'heure actuelle. Une forme de contrat agile (il en existe de multiples) peut être :

- contrat initial portant sur un nombre fixé d'itérations
- lots additionnels (=itérations supplémentaires) que le client pourra activer ou pas
- clause de retrait que le client peut faire jouer en cours de projet, avec paiement d'un certain nombre d'itérations à sa charge.

La société Valtech a publié un papier intéressant sur le sujet : http://valtech.developpez.com/articl...actualisation/

Le forfait est un jeu de dupe. Les deux parties le savent. Le client compte sur le rapport de force en se disant qu'il est protégé contractuellement, du côté fournisseur, c'est généralement un commercial qui négocie, il veut à tout prix décrocher le contrat, au final c'est au chef de projet de se débrouiller tant bien que mal pour motiver les développeurs pour faire une mission qui relève parfois de l'impossible (après chacun ses trucs pour refuser )

L'Esprit Agile n'est hélas pas de ce monde, il faut faire avec, donc faire de l'Agile dans un cadre forfaitaire.

[lepinekong]

En effet, la confiance est un point clé des projets agiles. Comme dit l'Agile Manifesto, il faut essayer de privilégier "Customer collaboration over contract negotiation". Cela passe par une relation apaisée et de confiance entre le prestataire et le client, et là est toute la difficulté bien sûr dans un secteur et un pays ou on a plutôt tendance à cultiver cynisme et art de l'affrontement.

Il existe des relations de confiance au niveau Opérationnel malheureusement le Management Opérationnel n'a même plus de pouvoir ne serait-ce dans certains grands comptes de choisir les sociétés avec qui elles vont travailler. Tout est dirigé par la Finance.

[apieum]

Il y a ce projet qui recense quelques informations utiles sur les contrats agiles et notamment un modèle. (dommage qu'il soit down)
http://www.coactivate.org/projects/a...tracts/summary