Discussion :

[jogrey]

Bonjour, les méthodes agiles, c'est pas mal, c'est même bien :

Côté client final, on a participé, on est impliqué, le produit plait !
Côté développement, on évolue avec le produit, on évalue, on ré-évalue, on évite les dérapages, l'ambiance de travail est bonne!

Mais, comment les vendre ses méthodes ? Quand le client veut comparer les 2 offres, quand il veut un chiffre en bas, quand il comprend que les méthodes agiles c'est bien, mais qu'il ne choisira pas forcement la méthode, ni le résultat mais un prix, sachant que le résultat est cadré contractuellement ?

Comment ne pas être plus précis en amont avec un travail de spécifications, pour avoir un chiffrage plus fin ? Sachant que justement, le travail fin sera effectué pendant le développement.

En gros dans le cas ou le client sous-traite son cahier des charges, comment lui faire une proposition sérieuse tenant compte des méthodes agiles, sachant que justement son cahier des charges est par expérience soit incomplet, soit trop lourd à digérer.

Comment faire participer le client à ré-exprimer son besoin, comment lui dire non, ce n'est pas dans ton budget, cette fonctionnalité indispensable n'est pas dans ton cahier des charges ?

Je suis entièrement novice en méthodes agiles, je papillone, je vois ici et la pas mal de retour positifs pour les groupes de développeurs, mais ce que je ne trouve pas ce sont des retours d'experiences du travail en amont, et de la proposition !

Auriez-vous des retours, dans votre entreprise comment avez-vous positionnés vos offres "agiles" par rapport à d'autres classiques ? Contractuellement, avez vous obligés vos clients à faire partie intégrale de l'équipe (une non implication du client/produit pendant le développement signerait l'échec des méthodes agiles) ?

Enfin je ne doute pas du réel gain de l'application de méthodes agile, mais je me pose des questions quant à leur mise en place dans les échanges commerciaux de propositions, et dans le calcul des charges, des coûts.

[Bruno Orsier]

voir peut-être le livre blanc http://valtech.developpez.com/articl...actualisation/ ?

Bruno

[jogrey]

Interresant, mais si vous avez des retours concrets je serais très curieux d'avoir votre ressenti !

Merci pour le lien

[Bruno Orsier]

Interresant, mais si vous avez des retours concrets je serais très curieux d'avoir votre ressenti !

Je n'ai pas d'expérience directe sur la question - je travaille pour un éditeur de logiciels et nous ne vendons donc pas directement à des clients. Je ne peux donner que des conseils théoriques !

Pour vendre, voici une piste possible que l'on m'avait indiquée lors de ma formation de scrummaster : commencer par trouver des clients pour lesquels un projet traditionnel s'est très mal passé ! Un client qui a connu la douleur d'un tel projet sera en général assez réceptif à une proposition de projet agile... Il comprendra facilement le bénéfice de travailler avec des itérations etc. Reste bien sûr la question délicate du coût total du projet - difficile de savoir à l'avance combien on va faire d'itérations, d'autant plus que cette manière de travailler va permettre au client d'affiner ses besoins, et même de changer d'avis. Une approche possible consiste à proposer au client de faire un essai - avec une, deux ou trois itérations par exemple. Un client qui a connu la douleur devrait accepter cette idée de faire un essai.

L'avantage pour le client est qu'il peut arrêter à tout moment. Au bout de quelques itérations, la confiance créée par le fait de produire du logiciel qui marche, la visibilité, la transparence devraient permettre de se mettre d'accord sur un contrat.

Bruno

[souviron34]

je répéterais ici encore une fois que je n'ai pas vraiment utilisé de "méthodes" agiles, mais une approche plutôt "ergonomique"..

Et, malheureusement, en général, la meilleure manière de faire accepter l'implication des utilisateurs est .. l'échec... Une rupture de contrat, une engueulade, une perte du marché, un flux ininterrompu de Bug Reports, etc... finira par faire admettre au Chef de Projet ou à la Direction la plus stricte qu'elle a un gros problème avec sa manière de fonctionner..

Et c'est réciproque... La meilleure manière de faire accepter l'idée qu'il faut que des utilisateurs participent à l'équipe est "Etes-vous satifaits de ce qui vous a été livré jusqu'à maintenant ? Non ? Ben la seule manière de le changer c'est de venir vous-même dans l'équipe"..


Mais c'est mon expérience...

[Bruno Orsier]

Comme lien supplémentaire, ce billet de A. Boutin : http://www.agilex.fr/2008/10/contractualisation-agile/ qui mentionne un groupe de travail qui vient de démarrer sur la question des contrats agiles.

+ un article sur infoq qui mentionne également ce groupe de travail, plus mentionne d'autres liens sur la question (voir notamment les 10 approches recensées par Alistair Cockburn).

Bruno

[wiztricks]

Bonjour,

Les méthodes agiles supposent une gestion du changement dans le cours du projet qui s'accomodent mal avec les engagements au forfait plus classiques.

Les deux articles ci dessous pointent les écueuils à éviter:

• Succeeding with "Agile Fixed Price" projects Part 1: The Price is right!
• Succeeding with "Agile Fixed Price" projects Part 2:"Do you want agility with that?"

Bonne lecture,
-W

[souviron34]

et j'ajouterais (ce que pointent d'ailleurs ces 2 articles) qu'encore une fois on est dans une approche agile, pas forcément une méthode ..

(et que, comme il est dit dans la fin du papier 2, "Every rule can be changed")

[jogrey]

Agile vendu dans 2 projets : Un sur du BI pour un besoin interne, et l'autre autour des technos GWT par l'intermédiaire d'un outil d'appuis des commerciaux dans leur phases de prospections, une sorte de vitrine techno.

Un projet en externe est en train de prendre la méthode qu'on a appliqué, on échappe pas à l'annonce d'un chiffre, pour que le client débloque un budget.

- Phase préparatoire, première analyse, première estimation, on applique la méthode du PMBOK (PMI), avec un poker planning pour les 3 évaluations (optimiste, prévisionnelle, pessimiste) + le calcul des risques.
- On vends donc vends un certain nombre d'itérations (incluant un certain nombre de sprints de sécurité). On accepte de livrer le produit final avant la fin des sprints initialement "vendus".
- Facturation au sprint.
- Les sprints restants a faire sont réévalués à chaque sprint.
- On identifie les stories ajoutées par le client (nouvelles exigences) et celles ajoutées par la complexité cachée du projet (plus dur que prévu ?).
- Les sprints supplémentaires non liés aux ajouts d'exigences sont facturés en tarifs préférentiels, le reste -> négociation.

Voila ça bouge !

[souviron34]

Voila ça bouge !

Et surtout voilà .. on introduit pleins de "nouveaux" mots technocrates.. voilà ça bouge pas

[jogrey]

Vous ne BI'GWT'PMI pas ? étonnant

Non l'important ici ce n'est pas les définitions, mais bien qu'on a réussi à partir sur une méthode Scrum ! Et un peu grâce à vous tous !

[souviron34]

• BI
• GWT
• PMBOK (PMI)
• poker planning
• sprints de sécurité
• la fin des sprints initialement "vendus".
• Facturation au sprint.
• sprints restants
• les stories

[jogrey]

Ok un peu obscur j'avoue mais c'est pas moi qui rédige les propositions commerciales heing

- BI : Business Intelligence, des Cubes olap, des datamarts (haha) --> du décisionel.
- GWT : Google Widget Toolkit --> Applications Web Riches.
- PMBOK (PMI) : A Guide to the project management body of knowledge : Une méthode de gestion de projet.
- poker planning : Excellent systeme d'évaluation des tâches En gros pour éviter l'effet du 1er qui annonce 1er qu'a raison je vous invite tous à vous renseigner c'est applicable partout .
- Sprints de sécurité : on calcule le risque, on ajoute X Sprints à notre estimation.
- la fin des sprints initialement "vendus" : On estime à X itérations (sprints dans la méthode agile SCRUM) et le propose au client.
- Facturation au sprint : a la fin d'un sprint un petit cheque ?
- sprints restants : Le produit est fini, et satisfait le client en moins d'itérations que ce qu'on avait initialement prévus.
- les stories : Les "user-stories", les exigences, l'expression du besoin.

[souviron34]

ma critique n'était pas dirigée contre toi

C'était sur la "mode" et le vocabulaire associé...

Et que, le but de l'agilité étant la réussite des projets ET la compréhension des utilisateurs, c'est mal barré

[Bruno Orsier]

- Phase préparatoire, première analyse, première estimation, on applique la méthode du PMBOK (PMI), avec un poker planning pour les 3 évaluations (optimiste, prévisionnelle, pessimiste) + le calcul des risques.
- On vends donc vends un certain nombre d'itérations (incluant un certain nombre de sprints de sécurité). On accepte de livrer le produit final avant la fin des sprints initialement "vendus".
- Facturation au sprint.
- Les sprints restants a faire sont réévalués à chaque sprint.
- On identifie les stories ajoutées par le client (nouvelles exigences) et celles ajoutées par la complexité cachée du projet (plus dur que prévu ?).
- Les sprints supplémentaires non liés aux ajouts d'exigences sont facturés en tarifs préférentiels, le reste -> négociation.

Voila ça bouge !

Très intéressant ce retour. Qu'est-ce qui a décidé le client a essayer ce nouveau type de contrat ? De mauvaises expériences avec des contrats "figés" ?

Sinon je suis curieux de savoir si les graphiques de "coût" dont j'ai parlé
dans ce billet ont du sens pour vous ou vos clients ?

Bonne chance pour ce projet.
B.

[rad_hass]

Au risque de répéter ce qui a été dit au dessus :

les arguments importants qu'aime entendre le client (en tout cas celui dans lequel je suis ) c'est :

1) Vous en avez assez des projets qui à la fin de l'échéance initial sont non seulement incomplet, mais il est impossible d'utiliser de manière stable au moins une partie des fonctionnalité ?

2) Vous voulez une méthode qui vous permet de voir l'évolution de votre projet ? (livraison continue ou à intervalle régulier, chaque itération est fonctionnel)

3) Vous n'avez pas encore en tête la version finale de votre projet et vous vouliez pouvoir le construire avec nous ? (la présence du client tout au long du projet est un gage de la satisfaction finale)

4) Vous en avez aussi marre des longues périodes de testes une fois le développement fini, avec un nombre trop importants d'anomalies ? (testes unitaires)

Si ton client réponds à ces critères, alors la méthode agile est faite pour lui ... Voila ma petite expérience, mon client à force d'échec à décider de se lancer dans l'agilité ...

Pour ce qui est du coût, l'agilité offre de la souplesse pour les deux partie il faut pas oublier de le signaler ...

Ceci étant dis je ne suis pas un expert des méthodes agiles ^^