Combien de détails sur une user story un développeur peut-il attendre?

Le plus grand inconvénient du développement agile que j'ai connu est que les personnes non impliquées dans le développement se concentrent sur le mantra selon lequel une user story (3 à 10 jours-personne idéaux) ne doit pas contenir plus de 1 à 3 phrases comme:

En tant que client, je peux utiliser la recherche en texte libre pour trouver les produits que je recherche.

En prononçant cette phrase, les chefs de projet attendent de moi, en tant que développeur, que je m'engage sur un devis et que je développe l'histoire. Ils supposent que le développement agile signifie que des phrases comme celle-ci sont tout ce qu'ils ont à fournir aux développeurs.

Je ne leur en veux pas, car la littérature bien connue sur le développement agile donne l'impression que cela fonctionnerait réellement. J'ai lu quelque chose comme 2 pages en langage naturel par histoire dans "Planning XP", mais c'est tout. Le «logiciel de travail» étant préféré à la «documentation complète», ce sujet semble être généralement évité.

La réalité est, bien sûr, que si le développeur en a la possibilité, une entrevue avec le client fait apparaître une longue liste d'exigences que le client a à propos de l'histoire:

• Nous avons besoin d'opérateurs booléens comme AND et OR.
• Nous avons besoin d'une recherche floue et de tous les termes.
• Nous devons rechercher par mots simples ainsi que par phrase.
• Nous ne voulons pas trouver de produits répondant aux critères X, Y et Z.
• Nous voulons trier le résultat. Oh, et en passant, l'utilisateur peut sélectionner les critères de tri dans une zone de liste déroulante avec les options a, b et c.

Vous voyez donc que je ne parle pas de détails techniques ou de conception de logiciels ou même de détails d'implémentation. Ce sont des exigences pures. Plus nous parlons longtemps, plus le client se rend compte qu'il y a en fait beaucoup à dire sur ce qu'il veut.

Mais assez souvent, je me retrouve dans la situation où de telles informations ne sont pas fournies ou de manière très médiocre. Il n'est pas possible non plus que je réalise l'entretien, ni la personne qui serait en mesure de le faire ne m'en donne le résultat.

Parfois, les gestionnaires proposent même des détails techniques comme «nous voulons une recherche Lucene» mais ils ne veulent pas penser s'ils veulent trouver uniquement les noms de produits ou aussi les descriptions de produits. Parfois, je pense qu'ils sont juste paresseux;)

Pour moi, c'est le principal problème des projets dans lesquels je travaille (application web e-business, 500-2000 jours / personne par projet). J'ai résolu ce problème assez souvent, et les gestionnaires sont conscients que la plupart des développeurs ont un problème avec la situation. Mais ils croient que les développeurs sont tout simplement trop «perfectionnistes». Ils semblent ennuyés que les développeurs "veulent toujours que tout soit spécifié".

En raison du manque de chiffres généralement reconnus, il est difficile de discuter. Tout le monde sait combien de temps doit durer une itération. Mais personne ne peut dire combien d'exigences sont nécessaires pour estimer et développer une histoire.

Avez-vous une référence?

Vous manquez un peu l'agilité. Ce que vous appelez une histoire d'utilisateur, je vois au moins six: une recherche à nu et une pour chacun de vos points de balle. Par tous les moyens, faites suffisamment de plans pour éviter de vous peindre dans un coin qui va coûter cher à sortir, mais l'idée est que vous fournissez le minimum nécessaire pour offrir une certaine valeur, et faites-le assez rapidement pour obtenir une rétroaction rapide.

Lorsque vous divisez une histoire comme ça, non seulement elle est plus facile à estimer, mais elle permet au propriétaire du produit d'établir des priorités de manière plus fine. Certes, ils aiment la possibilité de trier les résultats de la recherche, mais ce n'est peut-être pas aussi important qu'un autre élément du backlog qui n'a aucun lien avec la recherche.

En outre, sur l'idée que les programmeurs ont besoin de tout ce qui est spécifié, essayez de le considérer du point de vue du client. Souvent, c'est comme si vous alliez acheter une voiture, et le vendeur demande quelle couleur vous voulez pour le bouton d'essuie-glace. Un grand nombre de détails que nous pourrions trouver importants ne sont absolument pas pertinents du point de vue du client. J'ai travaillé là où les exigences sont très sur-spécifiées, et croyez-moi, ce n'est pas très amusant. Le genre de latitude dont vous vous plaignez, beaucoup de programmeurs aimeraient en avoir.

On dirait que le premier problème est que vous n'êtes pas censé appliquer des estimations de temps aux user stories. Vous êtes censé prendre une histoire et appliquer des "points d'histoire", qui sont une estimation générale de la complexité de 1 à INFINITY. Les points d'histoire sont souvent exécutés quelque chose comme 1,2,3,5,8,13,20 ... (Chaque organisation a ses propres règles.) Ils appliquent généralement quelque chose comme:

1 - Vous pouvez le faire dans votre sommeil et cela ne vaut guère la peine d'être mis en œuvre. 2 - Vous comprenez cela et pouvez le faire rapidement avec peu de risques de dépassement. 3 - Vous comprenez cela, mais il pourrait y avoir une surprise ou deux. 5 - Cela va faire un peu de recherche et a un peu de risque. 8 - C'est une tâche importante, a besoin de beaucoup de recherches et peut ne pas tenir dans un sprint. 13 - C'est énorme et ne rentrera certainement pas dans un sprint. Il y a un risque énorme. etc.

En règle générale, toute histoire d'utilisateur de 8 ou plus doit être décomposée en histoires plus petites.

Si vous n'avez pas les informations pour le faire, vous devez certainement les renvoyer au gestionnaire de projet et dire que vous avez besoin de plus d'informations.

Vous ne devriez vraiment estimer le temps qu'une fois que vous avez accepté l'histoire dans le sprint, mais même alors, l'accent y est moins mis. L'idée est qu'une fois que votre équipe s'est habituée au processus de pointage, vous pouvez mesurer sa production approximative par sprint en points d'histoire et planifier de cette façon. Vous ne voulez pas planifier sur une échelle de temps plus courte que le sprint. L'idée ici est que si vous décomposez les tâches correctement afin que les multiples histoires s'inscrivent dans un sprint et soient dans la plage de 1 à 5 points, cela signifie qu'elles sont suffisamment bien définies.

De plus, il semble que les PM de votre entreprise ne comprennent pas ce qu'est une «histoire». Une partie critique d'une «user story» est le critère de sortie. Le critère de sortie est une ou deux phrases courtes qui décrivent sans ambiguïté comment il peut être démontré que ce stockage est terminé. Idéalement, cela devrait être quelque chose que vos gars de l'AQ ont dit "oui, nous pouvons tester cela". Le point important est que les PM doivent comprendre qu'une histoire d'utilisateur est complète lorsque le logiciel répond aux "critères de sortie". "Mais nous ne voulions pas cela" ne le coupe pas. S'ils ne voulaient pas ce qui a été livré, mais que cela correspondait aux critères de sortie, ils doivent saisir une nouvelle histoire.

Il y a certainement ici un élément de «formation des PM». Ils doivent apprendre que les histoires vagues entraînent de grands points d'histoire et que s'ils définissent l'histoire de manière ambiguë pour obtenir ce qu'ils veulent, ils doivent le refaire.

De toute évidence, si les parties prenantes ne collectent pas suffisamment d'informations, vous devez le faire, et si vous le devez, cela représente beaucoup plus de travail, n'est-ce pas? Bien avant mes jours agiles, j'ai eu du succès en donnant de très grandes estimations et en disant explicitement que les estimations étaient si grandes pour tenir compte du risque causé par le manque d'informations. Je devais supposer le pire des cas pour toutes les questions, et estimé en fonction de ce pire cas. J'ai trouvé que les gestionnaires étaient plus disposés à donner plus de détails quand ils l'ont vu, ce qui a entraîné une baisse des estimations.

Ce n'est pas jouer avec le système ... c'est parfaitement valable. Si vous ne savez pas si c'est "A" ou "B", vous estimez en fonction de ce qui donne la plus grande estimation pour couvrir votre cul.

D'après mon expérience, de nombreux changements ou projets sur lesquels je travaille traitent de cette chose. Custom X veut quelque chose et ils ont une idée de ce qu'ils veulent, mais ils ne vous donnent qu'un petit e-mail d'exigences. C'est principalement parce que le client ne sait pas «exactement» ce qu'il veut. C'est pourquoi la majeure partie du travail de notre service client consiste à étoffer ces demandes des clients et à filtrer les informations nécessaires tout en prédisant ce que le client va VRAIMENT vouloir ou ce dont il a vraiment besoin.

Supposons qu'un client (pour moi) souhaite qu'une section de notre application Web lui renvoie une liste de tous les numéros de téléphone. Ils ne précisent jamais s'ils signifient physiques, logiques, attribués à une personne ou à un lieu, etc. Ils veulent simplement tous les numéros de téléphone. En tant que développeur, je peux m'asseoir là et penser à une douzaine de questions ou plus que je devrais poser au client, tout comme vous. Mais, comme vous le dites, ce n'est pas possible. C'est pourquoi avoir un bon service client qui connaît le produit et le client est inestimable.

Lorsque ce type d'appel arrive à nos représentants clients, ils sont en mesure de le développer avec le client, sachant ce qu'ils doivent leur demander pour obtenir les bonnes questions. Ils ont également la prévoyance de savoir ce que le client a demandé dans le passé et ils en savent assez sur les systèmes que nous développons pour pouvoir dire oui ou non à quelque chose sans même demander au client.

Bien sûr, vous aurez de nombreux cas où le client aura toujours besoin d'autre chose que vous et les services clients avez manqué, mais cela se produira toujours. Votre objectif et celui des services à la clientèle devraient être de minimiser le délai entre le développement de quelque chose et le retour du client avec les modifications à apporter. Et cela se résume à la communication et à la formation avec vos services clients.

Ce n'est peut-être pas aussi faisable pour vous que là où je suis, mais avoir une bonne ligne de communication et de confiance avec les représentants de vos clients vous aidera presque toujours par degrés, et cela réduira votre frustration et augmentera la satisfaction du client. En outre, vous pouvez plus facilement donner un calendrier pour vos projets plutôt que de hausser les épaules et de dire "Je ne connais pas toute la portée du projet, donc je ne sais pas combien de temps cela prendra". Nous avons le même problème ici, et une meilleure communication et formation est ce qui nous aide à créer des délais raisonnables et à les respecter de manière cohérente.

Client

Je souhaite rechercher des produits

Chef de produit J'ai analysé l'histoire du client et trouvé les exigences suivantes. Chaque exigence a été enregistrée comme une user story distincte.

• Rechercher des produits
• Trier le résultat
• Filtrer les résultats de recherche

Développeur J'ai reçu des témoignages d'utilisateurs d'un chef de produit. J'ai analysé chaque user story et trouvé une liste de tâches pour chaque user story.

• Rechercher des produits
  1. Tâche 1: modifications de la base de données
  2. Tâche 2: modifications côté serveur
  3. Tâche 3: modifications du frontal

Le client, le chef de produit et le développeur sont tous parties prenantes dans ce processus. Ils doivent tous contribuer au processus d'analyse avant le début des travaux. Veuillez noter qu'il s'agit d'un exemple très simplifié.

Nos user stories sont analysées et affinées dans l'ordre suivant (avec quelques variantes bien sûr):

Help Desk -> Product Owner -> Product Manager -> Lead Leads (développeurs seniors, qa leads, etc) -> Developers

Une fois que toutes les parties prenantes concernées ont contribué au processus d'analyse, nous pouvons estimer le temps qu'il nous faudra pour livrer l'histoire. Le processus d'estimation que nous suivons est basé sur la vitesse et l'expertise des développeurs individuels.

Je ne dis pas que c'est une façon correcte de faire les choses, mais cela fonctionne vraiment bien au sein de notre organisation.