Estimation d'une intégration de paiement

Le ticket indique « ajouter Stripe ». Le document mentionne « la moitié d’un quart ».

Les paiements disposent d’une interface API publique qui tient sur une seule page et d’une interface de décision privée qui, elle, ne tient pas. Le choix d’un prestataire représente un pic de travail d’une journée. La mise en place du parcours de paiement « happy path » prend quelques jours. Tout ce qui vient ensuite (le processus de remboursement, la politique de réessai des webhooks, les clés d’idempotence, le rapport de rapprochement comptable que le service financier demandera au cours du deuxième mois) constitue la fonctionnalité proprement dite, et rien de tout cela ne figure sur le ticket.

La « story » intitulée « intégrer Stripe » est rarement celle qui fait l’objet de l’estimation. La « story » estimée est en réalité : « nous pouvons encaisser de l’argent, le rembourser, prouver que nous l’avons bien encaissé et faire face à un litige concernant un prélèvement ». Tant que l’équipe n’a pas voté sur ce périmètre, le chiffre ne représente qu’une estimation portant sur un tout autre sujet.

Ce qui se dit dans la salle

Backend : « Le fonctionnement de la sandbox est simple. La bibliothèque se charge de l’essentiel. »

SRE : « Les webhooks doivent être idempotents. Quelle est notre stratégie de réessai si Stripe effectue une nouvelle transmission ? »

Finance : « Comment les remboursements sont-ils comptabilisés ? Qu’en est-il des remboursements partiels ? »

Conformité : « Traitons-nous des numéros de carte ou restons-nous au niveau SAQ-A ? »

PM : « Que dit l’e-mail signalant un paiement non abouti, et qui le rédige ? »

Questions qu’il convient de se poser avant de voter

• D’abord uniquement en environnement de test, ou les clés de production seront-elles prises en compte dès le premier jour ?
• Remboursements et remboursements partiels : via l’interface utilisateur, l’API ou réservé aux administrateurs ?
• Idempotence des webhooks et gestion des nouvelles tentatives : à qui appartient la table de déduplication ?
• Champ d’application de la norme PCI : respectons-nous les exigences du SAQ-A en ne touchant jamais au PAN ?
• Rapprochement : qui établit le rapport, et par rapport à quelle source de référence ?
• Expérience utilisateur en cas d’échec : les cartes refusées, les cartes périmées et les défis 3DS sont-ils tous concernés ?

Dans le cas d’un cas comme celui-ci, la bonne approche consiste souvent à le diviser. « Encaisser de l’argent » constitue un cas ; « rembourser de l’argent » en est un autre ; « rapprocher les comptes » en est un troisième. Si vous les considérez comme un seul et même cas, l’intégration sera livrée dès la troisième semaine, mais le service financier vous demandera où en est le rapport dès la huitième semaine.

Votez pour « prouver que nous avons reçu l’argent et que nous avons surmonté le litige », et non pour « appeler l’API de paiement ».

À ce sujet : erreurs courantes au Planning Poker concernant la division des stories trop tardive ; techniques d’estimation pour un travail aussi flou. Consultez les autres exemples d’estimation concrets, ou lancez une session gratuite de Planning Poker lorsque le raffinement sera prêt.