Quel est le bon processus pour écrire des histoires? [fermé]

Question

Nous sommes en train de définir nos cartes d’histoire pour le prochain projet.

• Nous avons une bonne idée de ce que le client souhaite à travers des ateliers
• Nous avons un document d’exigences commerciales qui sera signé par eux.

Notre processus de définition des histoires est le suivant

1. Nous prenons une fonctionnalité que le client souhaite et écrivons une histoire
2. Nous avons une brève discussion sur la conception avec l'équipe
3. Nous déterminons ensuite une estimation pour la carte
4. Si la carte a une durée supérieure à 3 jours, nous la décomposons plus avant et nous la répétons à partir de l'étape 2
.

Malheureusement, le client souhaite obtenir une estimation du temps requis pour l'ensemble du projet. Nous devons donc définir toutes les histoires à l'avance.

Cela prend un certain temps et peut être épuisant

Quelles autres méthodes peuvent être utilisées pour définir les cartes d’histoire? Cela peut prendre Quelles autres manières de rassembler les exigences sur des cartes d’histoire?

EDIT:

1. Ce n'est pas la première fois que nous faisons cela, c'est le processus normal
2. le client est un client interne
3. Je suis intéressé par la façon dont vous écrivez les cartes contre lesquelles vous finissez par coder

Answer 1

Je suggérerais quelque chose que nous avons appelé un & "jeu de planification de publication &"; Cela ressemble beaucoup à ce que vous faites pour une itération, cependant, nous l'avons fait à un niveau supérieur. Autrement dit, nous prendrions l'ensemble des fonctionnalités ou des points de fonction que l'utilisateur souhaitait pour une version particulière et nous procéderions à une estimation en sachant que nous allions être complètement . Vous pouvez ensuite additionner toutes ces estimations pour avoir une idée approximative de la date de livraison de votre produit, en fonction de vos informations actuelles.

Cela devrait donner à vos clients une idée du moment où vous allez publier, mais vous devez quand même insister sur le fait que vous avez besoin d’un peu de marge de manœuvre car, comme vos clients, vous ne pouvez prédire l’avenir (ou du moins je peux t).

Answer 2

Vous ne pouvez pas savoir quand tout sera fait et suivez toujours un processus agile. Même si vous travaillez très dur pour tout estimer, plus le travail est grand, plus le pourcentage d'erreur est élevé. La plupart des estimations pour les projets de taille moyenne finissent par être 2x, et les plus grandes jusqu'à 10x.

Au lieu de cela, je demanderais au client une date cible fonctionnelle. La conversation se déroule comme suit:

Vous: Quand avez-vous besoin de ces fonctionnalités?

(C) client: Quand pouvez-vous les livrer?

Vous: Commençons par définir les limites. Si je présentais toutes ces fonctionnalités dans 10 ans, serait-il trop tard?

C: bien sûr.

Vous: Si je proposais toutes ces fonctionnalités demain, est-ce que ce serait assez tôt?

C: bien sûr.

Vous: Qu'en est-il dans un an?

C: C'est encore trop tard.

Vous: 3 mois?

C: C'est un peu trop tard, plutôt 2 mois. Nous devons être prêts à utiliser cela avec notre équipe de direction en janvier.

Vous (pensez): ah ah!

Vous: Nous ne pouvons pas fournir toutes ces fonctionnalités en 2 mois. Je pense que nous pourrions livrer ces 4 histoires en 1 mois et ces 3 magasins le mois prochain.

C: Nous aurons vraiment besoin de la fonctionnalité X pour janvier.

Vous: OK, si nous ajoutons la fonctionnalité X, nous devrons supprimer une fonctionnalité. Lequel n'avez-vous pas besoin?

C: Nous ne pouvons le faire qu’avec une partie de la fonctionnalité Y.

Vous: OK. Nous allons prendre cette liste et élaborer un devis plus détaillé.

C (pense): Ha! J'ai eu ce que je voulais!

J'ai découvert à maintes reprises que la raison sous-jacente des prévisions budgétaires et de la planification & "Tout &"; est-ce qu'ils veulent une promesse de livraison de quelque chose d'ici une date. Travailler à travers la date cible fonctionne beaucoup mieux parce que:

1. Force le client à contribuer aux compromis

2. expose le motif réel des estimations

3. Réduit le nombre d'éléments à estimer.

4. Aide à identifier les fonctionnalités importantes pour chaque sprint.

Answer 3

Je ne parlerais pas de cette histoire pour la planification des sorties (ce qui semble être ce que vous voulez faire). De toute façon, la planification des versions sera moins précise (car les choses changeront avec le temps), il est donc logique d’utiliser une unité d’estimation moins précise.

Nous utilisons généralement Planning Poker, 13 ou 21 étant la valeur la plus élevée autorisée avant la division d'un article. Pour la planification des versions, nous estimons les & Quot; journées idéales . " ;, pour la planification des itérations en & "heures idéales &"; Fonctionne bien pour nous.

Answer 4

Comment envisagez-vous de diffuser l'application au client? Faites-vous des livraisons incrémentielles? Ou est-ce la planification d'un produit livrable initial?

Je suggère de décomposer le développement en sprints de deux ou trois semaines, puis d’ajouter une semaine supplémentaire pour chaque sprint dans le budget de livraison afin de gagner un peu plus de temps ... juste au cas où le client changerait d’avis sur une fonctionnalité ( ils vont). J'espère que cela facilitera l'estimation de la date de livraison finale ...

Si vous réussissez à convaincre votre client que vous devez livrer progressivement, vous constaterez que vous créerez moins d'histoires redondantes à mesure que les spécifications changent. De plus, vous n'aurez pas à faire autant de travail initial et au fur et à mesure que le développement avance, vous pouvez écrire le prochain lot d'histoires pendant que le développement est en cours.

J'espère que cela vous aidera.

Answer 5

En général, je ne demande que des titres d’histoire. J'essaie de voir si je peux les classer au moins dans un ordre de grandeur. Je donne une estimation très approximative basée sur le nombre de titres et ma vitesse estimée / titre. Je demande généralement au client de diviser les titres en (1) besoin, 2, mais il peut attendre, et (3) ce serait bien.

Je commence par aborder le groupe (1) et à fournir suffisamment d’informations pour le diviser en un ensemble de communiqués. À ce stade, je peux généralement donner une meilleure estimation en utilisant les informations plus détaillées pour fournir des estimations par titre. Je planifie seulement les histoires de groupe (1). S'il y a trop d'histoires de groupe (1) dans une publication, nous les divisons en plusieurs versions / itérations cohérentes.

Lorsque nous commençons environ un mois après le début des histoires du groupe (2), je retrouve le client (lors d’une session de planification plus ciblée, usu. en lui parlant tout le temps), pour recommencer le processus. les histoires de groupe (2).

Les histoires ajoutées au fur et à mesure de l'avancement du projet sont placées dans le bon groupe et traitées comme il convient pour ce groupe. Si la version en cours est actuelle, vous aurez suffisamment de détails pour utiliser, si plus tard, uniquement le titre en tant qu'espace réservé.

L’autre chose que je fais est de faire en sorte que le client comprenne qu’il s’agit d’un processus coopératif et que nous aboutirons à ce qu’il souhaite. Ils choisissent quand arrêter, même s'il reste des histoires au tableau. Tant que je leur donne la valeur qui leur tient à cœur, nous continuons à nous développer. Ils doivent avoir confiance que je fais ce qui leur convient et que je travaille avec diligence. Je dois avoir confiance qu'ils me fourniront la meilleure information possible sur ce qu'ils veulent le plus tôt possible.

Answer 6

Si vous essayez de rester fidèle à XP, je vous suggère de vous ici . et lisez la différence entre la planification des versions et la planification des itérations. Vous ne devriez pas effectuer d’estimation de tâche individuelle tant que vous n’êtes pas prêt à commencer à coder.

Histoires! = Tâches. Les histoires sont décomposées en tâches, que vous ferez ensuite à la & Lt; Estimation de 3 jours pour. L'estimation des articles est plus ouverte et vous devriez être capable de décider des seuils pour les estimations d'histoires qui fonctionnent le mieux pour vous et votre équipe après l'avoir fait pendant un certain temps. (IE & Lt; 1 semaine, 2 semaines, & Gt; 2 semaines, etc.)

La partie la plus importante de l’estimation consiste à faire un suivi du temps réellement passé et à ajuster votre processus d’estimation. XP est tout au sujet des commentaires.