2010-10-26 38 views
3

Je travaille à la création d'un premier jeu d'user stories pour un nouveau projet, et j'utilise MSF Agile pour la première fois. J'ai environ 100 histoires d'utilisateurs, et je les ai toutes assignées à des zones et des itérations, mais la prochaine étape pour moi est d'assigner toutes leurs valeurs de risque, de points d'histoire et de rang de pile. Cependant, je trouve que j'attribue presque des valeurs opposées de miroir pour le risque et les points de l'histoire, c'est-à-dire toutes les histoires à 1 risque élevé sont 3 points d'histoire, et toutes mes histoires à 3 risques faibles sont 1 points d'histoire.MSF Agile: risque vs points d'histoire?

La documentation MSDN définit ces domaines en tant que tels:

"Story Points:. Une unité subjective de mesure qui capture la taille d'une histoire d'utilisateur Si vous attribuez plus de points à une histoire d'utilisateur, vous indiquez que plus de travail est nécessaire pour l'implémenter. "

« Risque: Une évaluation subjective de l'incertitude relative autour du succès de l'histoire de l'utilisateur Vous pouvez spécifier les valeurs suivantes:. 1 - Elevée, 2 - Moyen 3 - Faible »

Je trouve que ceux-ci vont difficilement à peu près toutes les situations que j'ai rencontrées. Selon votre expérience, quels sont les exemples d'histoires à haut risque valant seulement quelques points d'histoire, ou les histoires à faible risque valant beaucoup de points?

J'ai besoin d'aide pour raisonner différemment. Comment devrais-je penser à ceux-ci?

Répondre

1

Cela ne devrait pas être du tout comme ça.

Il est possible de mettre en œuvre une grande partie de l'histoire sans risque du tout. Le risque ne signifie pas que cela prendra beaucoup de temps, mais plutôt la chance que cela prendrait plus de temps que vous ne le pensez.

Un exemple d'histoire 3 risque 1 peut être un ensemble d'interfaces graphiques qui doivent être méticuleusement positionnées et validées par le client. Vous savez que cela prendra du temps, mais vous ne vous attendez pas à plus d'une ou deux itérations par écran.

Exemple d'histoire 1 risque 3 peut être l'interfaçage avec un serveur Web que vous PENSEZ connaître l'API pour. Probablement trivial, potentiellement ennuyeux (et s'il y a un cookie méchant que vous devez imiter ou quelque chose - juste en faire ça, pas personnellement un web dev).

Histoire 1 risque 3 seront plus rares parce que vous devriez probablement les examiner plus en profondeur et réduire un peu le risque, mais dans certains cas, au moment où vous avez fait cela, vous auriez pu l'implémenter. ..

+0

"C'est la chance que ça prendrait plus longtemps que ce que vous pensez" Cela m'a aidé un peu. Grande clarification. Donc, fondamentalement, les points de l'histoire sont la quantité de temps que je pense prendra, et le risque est de savoir comment je comprends le contenu de l'histoire, fondamentalement. Vous êtes vraiment sur votre exemple, aussi - je prévois de saisir les données météo de l'API wunderground, par exemple, mais je ne suis pas non plus un développeur web, donc c'est nouveau pour moi. Cependant, je l'avais marqué une histoire avant parce que je tenais compte de la recherche dans mon point de vue. Après avoir lu ceci, il devrait probablement être une histoire 1 risque 3, comme vous dites. Merci! – bwerks

1

Juste pour clarifier cet autre pour les futurs lecteurs ...

Story Points sont des estimations de taille et de la complexité de toute histoire caractéristique/utilisateur donné. De plus, ces valeurs sont relatives, c'est-à-dire quelle est la taille et la complexité de la caractéristique A, comparée à la caractéristique B. C'est une discussion complètement différente, mais «Estimation et planification agiles» par Mike Cohn serait un bon point de départ.

Le risque doit être associé à votre estimation de la possibilité de problèmes liés à la caractéristique donnée. Donc, par exemple, vous pouvez avoir une fonctionnalité qui nécessite beaucoup de travail «d'âne» ... c'est-à-dire beaucoup de travail acharné, mais pas très difficile ou en dehors du domaine de la connaissance. Ce serait un élément à faible risque.Cependant, si vous avez ce qui peut sembler être une simple fonctionnalité/petite fonctionnalité, ajoutez une authentification basée sur un formulaire à votre application Web. Il peut s'avérer plus risqué, car un grand nombre de problèmes de sécurité liés à l'application Web peuvent devoir être traités, ou personne de l'équipe n'a d'expérience dans l'implémentation de l'authentification basée sur les formulaires, etc. Ainsi, ce qui peut sembler fonctionnalité pour ajouter un nouveau type d'écran de connexion & authentification à la fin peut s'avérer plus délicate. Le risque que quelque chose ne va pas ou qu'il manque quelque chose est plus élevé.

Espérons que cela aide à clarifier la différence entre les points de l'histoire et le risque.

+0

Très utile en effet, merci. – bwerks