Bonjour à tous,
Je m’intéresse de plus en plus à l’approche agile, et plus précisément à la méthode Scrum.
Au-delà des lectures que j’ai pu glaner ici et là sur le web, des bouquins et des formations, qui expliquent parfaitement l’approche et les méthodes, j’ai beaucoup de mal aujourd’hui à trouver des ressources et retours d’expérience sur la manière de facturer les prestations en agile.
Si quelqu’un a des conseils ou retours d’expérience sur ce sujet, je suis preneuse !
Merci d’avance !
Bonjour @emelineB,
Il a plusieurs façon d’aborder la question, mon expérience personnelle est qu’en agile, la modalité la plus simple pour facturer est de facturer au temps passé (on dit aussi au réel), à la fin de chaque sprint (ou mensuellement).
Tout est question de négociation commerciale, et facturer au temps passé est assez difficile sur un marché français habitué à des contrats au forfait avec une facturation calée sur des livrables définis. Facturer au temps passé suppose une forte confiance, et sauter le pas n’est pas toujours simple pour un nouveau client. Il faut faire de la pédagogie sur la méthodologie et mettre en place des éléments qui renforcent la confiance, en calant un process de suivi et de livraison très clair.
Parmi les aspects clés d’un point de vue opérationnel :
Ces deux points sont critiques pour la facturation et le paiement des prestations. Si on veut élargir et ouvrir un peu la question initiale, la question de la facturation ouvre à mon avis le sujet de la contractualisation, il existe des trames de contrat pour des projets en agile, celui-ci est assez intéressant : http://www.contrat-agile.org/
Lisez le chapitre sur les conditions financières, et les annexes afférentes, c’est une bonne trame de départ.
Notamment, cette trame propose une révision de l’évaluation initiale à la fin du Sprint 0 d’initialisation du projet, avec un intervalle plancher et plafond défini au départ dans le contrat, ce qui a vocation à rassurer le client dont la principale inquiétude est de dépasser le budget estimé au départ. Il reste difficile pour le client de vraiment intégrer qu’en agile, la flexibilité est sur le périmètre et non sur le budget. Il continuera à avoir le réflexe de penser en mode forfait, dans 90% des cas (les projets aux forfaits ont théoriquement un périmètre fixe, un budget fixe et concrètement dans la réalité ce sont les délais qui bougent - et aussi les marges du prestataire mais c’est un autre débat).
Cela explique dans les projets agiles qu’on définisse souvent un MVP (en anglais Minimum Viable Product) qui est en quelque sorte un périmètre minimal acceptable pour le client.
Il est assez simple de définir QUAND il faut facturer, c’est à la livraison de chaque fonctionnalité (qui répond à une user story).
Par contre, il est difficile de donner un devis global avant le démarrage du travail.
Pour cela nous découpons de la façon la plus atomique possible les users story (un post-it par tâche), et les estimons avec la méthode du planning poker.
Pour notre part, nous évaluons les tâches suivant les puissances de 2.
1 (tâche la plus courte), 2, 4, 8 et 16 (tâche la plus longue).
Cela ne correspond pas à des heures, mais vraiment à des notions approximatives de « c’est court » « c’est un peu plus long » c’est très long"…
Finalement, avec l’expérience, nous constatons que nos dev, en moyenne, tournent à 5 « unités » par jour et par dev (en 7 heures par jour). Cela intègre le temps qu’ils passent à préparer les tâches, à échanger avec l’équipe, les retours de bugs…
C’est vraiment au global, la somme quotidienne d’unités d’évaluation des post-it qui avancent du back log vers la colonne « prêt à entrer en production » divisée par le nombre de dev sur le projet.
Nous pouvons ainsi déduire le nombre de jours / homme du projet, et faire un devis relativement précis.
On le fait par user story, et on demande le paiement à la livraison de chacune (avec une avance de 25% au commencement).
Si une user story est trop vaste (« faites moi une application de commerce en ligne ») ou qu’elle donne une estimation de temps supérieure à 3 semaines, nous la découpons (« d’abord il faut pouvoir créer un compte », ensuite « ajouter des produits à vendre » ensuite « ajouter les produits au panier »…)
C’est la méthodes des story points ? Qui marche avec la vélocité ?
Effectivement, comme presque toutes les équipes agiles, nous avons un peu dévié du concept « pur » de base pour nous approprier une version plus adaptée à nos besoins.
Mais jusque là, cela ne donne lieu à des erreurs que de l’ordre de plus ou moins 15%, ce qui est relativement précis (quand on voit que certains projets sont régulièrement au double du temps initialement annoncé…). Quand on sait les incertitudes des développements logiciels, cela est je trouve plutôt performant !
Mais il est important d’avoir un certain recul pour que les estimations de l’équipe technique soit efficace, et que la vélocité moyenne calculée soit significative.
Wow Chapeau 
Pour le reste je n’aime pas la facturation au temps car cela n’aligne pas les intérêts du client et du presta.
Pour ma part (graphisme et comm) j’essaye surtout de réduire la taille des lots vendus mais de proposer un forfait sur chaque lot avant de l’attaquer.
Je n’ai jamais vu cette façon de pratiquer ça me paraît assez difficile de facturer à la complétion d’une user story, d’autant plus qu’on traite rarement une seule user story à la fois, sauf à n’avoir qu’un développeur sur un projet et quand bien même cela reviendrai à facturer plusieurs fois par semaine à moins que vos story ne soit des épiques et alors vous avez plusieurs story pour une épique la règle étant de toujours découper les épiques en unité de travail suffisamment petite pour que l’estimation tienne la route.
La logique reste quand même de facturer à la fin d’un cycle de développement complet, et aussi testable car sinon comment le client (est-ce le client final dans votre cas ?) peut-il l’accepter ? Bien souvent une story dépend d’une ou plusieurs autres pour être testable. Vous pouvez développer une fonctionnalité mais celle-ci n’a pas d’UI par exemple.
Je suis encore une fois curieux de savoir quel client accepte de signer sans avoir une estimation (même si celle-ci comprend une fourchette basse et haute). C’est la pratique du métier… Estimer n’est pas simple mais un professionnel sait estimer en explicitant ses hypothèse et en affinant en posant les bonnes questions à un client pour affiner. Confirmer l’estimation à la fin du Sprint zéro est à mon sens une bonne pratique.
Si le client n’a pas de backlog délimité au début, il y a un problème de méthodologie et c’est la garantie d’aller dans le mur…
Concernant la vélocité elle est propre à une équipe donnée, et un projet donné. On peut avoir des points de repère mais c’est après quelques sprint qu’on a une véritable vision de la vélocité moyenne sur un projet et qu’on peut lever un warning auprès du client si la vélocité projetée ne permet pas de résoudre les story qui sont dans le MVP.
le dev est vraiment une autre problématique au niveau facturation.
Je me dis que facturer au forfait, c’est pas agile, tout simplement 
edit: lecture pour les profanes http://blog.neoxia.com/story-points-5-minutes-pour-comprendre/
http://scrummethodology.com/scrum-effort-estimation-and-story-points/
C’est surtout que ça ne correspond à aucune réalité en terme de livraison pour le client et c’est un vrai risque financier pour le prestataire.
Ca ne veut pas dire que cela n’existe pas. Ce que j’ai constaté depuis 10 ans c’est que les grosses SSII et presta sont de plus en plus en mode agile en interne, mais contractualisent et facturent au forfait avec les grands comptes (ces derniers, de par la logique qui les gouverne, ont du mal à accepter une contractualisation agile). Ils font du « watergile » (waterfall + agile) donc de l’itératif mais avec un périmètre fixe et des livrables définis au départ.
Il y a des exceptions, mais cela reste la règle. Ils peuvent le faire car ils ont la surface pour assumer le risque, ça n’est pas le cas des « petits ».
@davidmolliere En fait nous sommes globalement d’accord :
Je ne me pose pas la question de savoir quel client accepte de signer sans estimation, je pense que ça n’existe pas
Cette citation est prise hors contexte du post, dans lequel je dis qu’effectivement c’est difficile, mais à la suite, j’explique comment nous avons dépassé cette difficulté pour quand même faire un devis systématique !
Pour le reste :
Oui, d’ailleurs, c’est bien ce que j’avais indiqué dans mon post suivant :
[quote=« Eric, post:4, topic:1847 »]
Mais il est important d’avoir un certain recul pour que les estimations de l’équipe technique soit efficace, et que la vélocité moyenne calculée soit significative.[/quote]
Enfin concernant la facturation par user story, c’est pourtant très courant, à la façon du constructeur de maison qui débloque les paiements à chaque étapes clés du chantier (terrassement, fondations, toiture…), nous le faisons en déterminant les users story qui débloquent une tranche de paiement supplémentaire. Cela plutôt sur les projets importants, sinon on fait par bloc d’users stories testables pour faire un paiement en n fois (n dépendant de l’ampleur du projet).
Les problématiques sont vraiment différentes entre un petit/gros client/projet/budget et un petit prestataire.
Moi, dès que c’est un projet qui dépasse le truc simple, je ne fais plus de forfait, si le client ne peut pas comprendre/adhérer à la démarche, je ne le fais pas Je suis seul, et je n’ai pas de quoi amortir une manière rigide « à l’ancienne » de travailler/deviser/facturer.
Par contre, je m’engage sur les fonctionnalités (user story), j’essaye d’estimer la livraison, et évidemment j’essaye de m’y tenir, après la communication et le sérieux étoffent la relation de confiance, mais c’est pas évident au début.
C’est plus un choix de mode de fonctionnement qui est (ou pas ) dans l’adn de l’activité ou l’entreprise.
De mon côté je facture uniquement au temps passé (depuis 2005).
Je peux tout à fait aider le client à évaluer et estimer une charge (pour ceux qui le demandent, c’est à dire pas tous), mais le temps passé pour faire ces évaluations, analyses et estimations est payé également « au temps passé » (je propose alors un volume « à vue de nez » pour faire ce travail). Avec ce type d’analyse j’arrive à des précisions de l’ordre de 10% sur des chantiers de taille moyenne.
D’autres clients veulent de l’agile mais en me bookant « en régie », c’est à dire que je suis une ressource disponible X heures par semaine, et ils m’affectent à ce qu’ils souhaitent (et on peut aussi évaluer des fonctionnalités dans ce mode, ou travailler davantage « au feeling »).
Plus ça va plus je vois des clients qui aiment avoir ce deuxième mode: régie, mais avec des petites itérations, des livraisons fréquentes, des évaluations rapides sur les gros chantiers, des spikes pour les features vraiment expérimentales, du backlog bien géré, sans forcément que ça soit du « watergile » sur la tête du prestataire qui doit « valider des sprints » pour se faire payer (chose que je refuse catégoriquement).
Dans tous les cas: les évaluations sont indicatives, best-effort, et je n’ai pas d’obligation de résultat, je fais juste de mon mieux. Voir mes slides sur la partie estimation, je couple notamment Acunote et Freckle (il manque le son sur les slides mais ça donne déjà une idée!).
A la question « comment faire accepter ce mode opératoire », ma réponse est simple: je me débrouille pour avoir le choix, par 1/ un pilotage fin de ma trésorerie pour savoir réellement si je peux perdre tel ou tel contrat sans souci (ce qui me donne une sérénité pour donner mes conditions, simplement) et 2/ en créant de la crédibilité en ligne (talks à des conférences, articles, compte twitter fourni etc).
Ces deux points me mettent dans une position où je peux fixer mes conditions (sans faire la « diva » pour autant).
Par ailleurs, j’ai été certifié Scrum Product Owner une année également (avec Mike Cohn), et du coup ça développe aussi l’argumentaire pour savoir expliquer pourquoi ce mode opératoire est bénéfique pour les deux (je n’ai jamais de souci de mon côté - maintenant je travaille toujours en direct, jamais via les SSII!).
En espérant que ça soit utile
Tu viens de résumer l’ensemble de ce que j’aimerai faire dans ma vie de freelance, et que j’ai commencé cette année (j’ai déjà été freelance, gérant de sarl …) mais jamais avec cet état d’esprit, ça à complètement changé mon mode de boulot en bien.
Donc je plussoie.
Et oui pour le mode régie, c’est souple, intelligent et les clients s’y retrouvent.
Oui mais… Quand vous travaillez au temps passé vous devenez une « commodité », presque un salarié !
Si c’est de la régie plein temps pour un client unique sur la durée, effectivement (d’ailleurs cela pose un problème juridique pour les clients avec le risque de requalification du contrat), mais on peut facturer au temps passé sans rentrer dans ce modèle 
Tout est une question indépendance…
Je pensais plus à la question de la valeur créée et de son partage… Vaste sujet ! (et comme dit plus haut l’alignement des intérêts)
Ca surprend souvent mes clients, mais en tant que freelance j’aime les relations de longue durée. C’est plus agréable de travailler avec des gens qu’on connaît bien, et c’est bon pour le cash-flow aussi.
Côté commodité, pas de risque: je fais attention de me former en permanence (y compris en dehors de la technique pure, donc devops, agile, branding/SaaS, UX, front, back, traitement de données), et je ne facture jamais en dessous de 100€ HT de l’heure (c’est mon « ancien tarif » d’ailleurs), donc le risque d’être perçu comme une commodité est inexistant.
Il faut se forcer à toujours chercher la valeur pour le client, que ça soit côté fiabilité, « épine dans le pied enlevée », technique pure etc, et du coup les intérêts sont parfaitement alignés.
Salut, je te contredis totalement là dessus.
Lorsque l’on contracte un forfait, théoriquement à la signature les intérêts du client et du fournisseur (freelance, agence, etc.) divergent :
A l’inverse, sur un fonctionnement au temps passé, les intérêts convergent, client et fournisseur sont alignés sur le degré de qualité, d’avancée, etc. L’agilité implique une communication plus fréquente entre client et fournisseur afin de faire des choix en fonction des désirs, budgets, etc.
Au sujet de comment convaincre un client de payer au temps passé, je sais que @thibaut_assus propose un essai satisfait ou remboursé. A voir avec Thibault s’il confirme mes dires.
En tant que client récurrent de différents dév/agences, quand j’ai besoin de travailler avec un développeur freelance ou une agence je préfère la facturation au temps passé. En revanche, ça me demande un peu plus de suivi, et c’est ce que je souhaite.
Et si je souhaite une estimation du temps, je paye ce temps d’estimation comme l’a décrit @thibaut_barrere.
En théorie les intérêts sont bien alignés :
Dans les deux cas, plus de valeur créée pour les deux parties !
En revanche quelqu’un de payé au temps n’a aucun intérêt à en faire moitié moins (par exemple si le scope était trop large d’un point de vue business ou opérationnel) ou à doubler sa productivité en améliorant ses pratiques.
Bien-sûr ça permet de (largement) améliorer les choses mais la logique reste de corréler la rémunération au temps passé. Alors que le temps passé n’a aucun lien naturel avec la valeur offerte !!
En tant que Client personne n’achète du travail. On achète du capital. Si le fabriquant de ce capital est payé en fonction du temps passé, et non en fonction de la valeur que va dégager le capital, il y a une forme de « prolétarisation » (à défaut de « commoditisation » ^^).
In fine je comprend que le code est un business très complexe, avec beaucoup d’incertitude.
Ces remarques sont pour un monde idéal et un « cap »/vision. Je n’imagine pas que ce soit 100% applicable dans tous les cas de figure et pour tout le monde dès aujourd’hui.
Le sujet s’est largement élargi
Ceci étant dit voilà un fil de discussion dense et qualitatif !
Je partage assez cette vision. Chercher la valeur pour le client, c’est un état d’esprit et aussi ce qui fait la force des bons freelance et pourquoi ils sont valorisés sur le marché. Ca n’est pas simplement une capacité de réalisation, un savoir faire mais aussi l’écoute du client, la volonté de satisfaire le besoin dans le respect des règles de l’art et des bonnes pratiques.
Je lis trop peu souvent cela mais la fierté de faire un travail de qualité (un côté artisan ?) est un moteur du freelance et parfois la raison de quitter le salariat car justement les contraintes économiques prédominantes (surtout dans le cadre des projets au forfait… sic) ne lui permettent pas de travailler comme il souhaiterai le faire. J’y mettrai aussi la volonté d’aller toujours plus loin dans ses compétences et faire (à son échelle) progresser les bonnes pratiques elles-même.
Facturer au temps passé est bien souvent aussi plus adapté qu’au forfait car un forfait suppose que le client a un besoin explicite qu’il est capable de formuler et qui ne comporte pas d’aléas (ou alors, il sait dès le départ que son budget devra être révisé et l’accepter).
Pas tout à fait d’accord ici, cela voudrait dire que le prestataire a une vision court termiste et exclusivement financière, mais je pense que ceux qui arrivent à vendre au temps passé on d’une part su savoir construire une confiance qui permet de travailler sur ce mode, d’autre part il a un intérêt bien concret à être le plus productif possible car c’est précisément ce qui lui permet de travailler à nouveau avec son client mais également de pouvoir mieux défendre ses tarifs
Encore une fois il y a pas une approche meilleure dans l’absolu, le forfait a eu et a encore ses heures de gloires car il permet d’avoir une maîtrise budgétaire qui reste l’argument n°1 des grandes entreprises et le mode contractuel prédominant (même si au final, il y a des changes request qui viennent étendre le budget, de même que ce type de projet est quasi systématiquement livré avec retard ). Et encore il faut nuancer car aux US par exemple, les choses sont assez différentes. Je n’aurai aucun problème à travailler en mode forfait sur un projet à faible niveau de complexité ou on a déjà plusieurs expériences du même type de projet (et encore il faut border le piltoage au plus serré) mais force est de constater que les applications et sites web sont rarement dans ce cas de figure dès qu’un projet atteint une certaine dimension (intégration avec des services tiers, mutli devices… etc). Il faut donc nuancer et tout est question de contexte mais dans la majeure partie des cas le forfait est un risque supporté par le prestataire.
D’une manière générale on trouve moins de mauvais prestataires qui facturent au temps passé qu’au forfait, tout simplement parce que le client a une vision très claire de la valeur du service qu’il achète. Il valorise celui qui porte la compétence, alors qu’au forfait il valorise le résultat souhaité.