Évaluation d'une fonctionnalité de connexion

Les récits de connexion ne reçoivent presque jamais la note de 3, mais il y a toujours quelqu’un pour leur attribuer cette note.

« Ajouter une fonctionnalité de connexion » semble anodin, car toutes les personnes présentes dans la salle ont déjà mis en production une fonctionnalité de connexion, sur un autre produit, pour lequel un ensemble de décisions avait déjà été pris. Le périmètre dont vous vous souvenez est celui de la dernière fois, et non celui que vous vous apprêtez à prendre en charge. Le cas semble bien connu jusqu’à ce que quelqu’un pose l’une des questions ci-dessous, et là, ce n’est plus le cas.

Le problème, ce n’est pas que la connexion soit difficile. C’est plutôt que la discussion s’arrête avant que les compromis ne soient mis en évidence. Les ingénieurs backend s’accrochent à l’argument « nous avons une bibliothèque pour cela ». Les chefs de projet s’accrochent à la capture d’écran du scénario idéal. C’est celui qui a réellement développé le produit récemment qui brise ce faux consensus, généralement en posant une question qui ne figurait pas sur le ticket.

Ce qui se dit dans la salle

Backend : « Ce n’est que du JWT, nous disposons de la bibliothèque. »

Sécurité : « La réinitialisation du mot de passe ne se résume pas à un simple JWT. »

PM : « Faut-il mettre en place l’authentification à deux facteurs dès le premier jour, ou s’agit-il d’une mesure à prendre ultérieurement ? »

Interface utilisateur : « Allons-nous nous associer à Google et Apple, ou développer notre propre solution ? »

SRE : « Quelle est la limite de débit sur le point de terminaison de connexion ? »

Questions qu’il convient de se poser avant de voter

• Existe-t-il une procédure de réinitialisation du mot de passe, et qui est responsable du modèle d’e-mail ?
• Identité fédérée (Google, Apple, SSO) ou simplement un nom d’utilisateur et un mot de passe ?
• Stockage des sessions : JWT, session serveur, les deux, jetons de rafraîchissement ?
• Limitation du débit et verrouillage du compte au niveau du point de terminaison de connexion ?
• L’authentification à deux facteurs (2FA) est-elle désormais prise en compte, ou s’agit-il d’un « plus tard » délibéré ?
• Enregistrement dans le journal d’audit des tentatives infructueuses ?

La plupart de ces réponses sont soit « banales », soit « cela mérite un ticket à part entière ». Comptez celles de la deuxième catégorie. S’il y en a deux ou plus, vous n’avez pas encore d’histoire : vous avez un cas susceptible d’être scindé, et la note de 3 que vous vous apprêtiez à attribuer ne reflète pas la réalité.

Si votre équipe vote « 3 » lors de la connexion, la conversation n’a pas encore eu lieu. Renvoyez-la.

Dans l’article « Erreurs courantes au Planning Poker », nous abordons les problèmes pouvant survenir au cours d’une session ; l’article « Comment animer une session » présente le cycle en quatre phases. Consultez les autres exemples d’estimation détaillés, ou lancez une session gratuite de Planning Poker et suivez le déroulement de cette histoire.