user stories écriture pour les tâches techniques internes [clos]

StackOverflow https://stackoverflow.com/questions/1707080

Était-ce utile?

La solution 

AS A [person/role]
I NEED TO [do something] 
SO THAT [provides business value].

Pour votre exemple une histoire d'utilisateur pourrait ressembler à ceci: 

AS A user of the XYZ application
I NEED TO get reports of ABC faster
SO THAT we can increase our conversion rates.
ACCEPTANCE CRITERIA - The database reliably completes transactions on average in 2 seconds.

J'ai ajouté un critère d'acceptation parce que sans cela, vous ne saurez jamais quand le travail est fait. Maintenant, à ce stade, vous avez une analyse de rentabilisation pour la mise à niveau de la base de données. Cette histoire serait décomposée en une histoire où le rôle est le service informatique ou DBA, comme suit: 

AS AN administrator for the database server
I NEED TO upgrade to the latest version of FancyDB 11.7
SO THAT we can improve the average transaction time for XYZ users to 2 seconds.
ACCEPTANCE CRITERIA - the new version starts successfully, the XYZ developers sign off on the test installation of 11.7, data migration is successful, we have cut over to the new db

Lors de la décomposition de l'histoire est ajouté à votre boîte d'outils, l'histoire doit commencer par là où l'utilisateur est une partie réelle de l'entreprise, et « de sorte que » conduit à une réelle valeur commerciale. Puis décomposer l'histoire en une ou plusieurs histoires où les utilisateurs internes font des choses « afin que les » vrais utilisateurs obtiennent les avantages qui en ont besoin.

Voici quelques articles qui parlent de l'histoire de décomposition:

http://jpattonassociates.com/the_shrinking_story/

http://old.cognitive-edge.com/wp-content/uploads/1999/11/56-1999-11-Paradox-of-Story.pdf

Autres conseils

Scrum est pas très normatif et il est rien Scrum qui vous oblige à utiliser des histoires d'utilisateurs pour vos articles de backlog de produit (PBIS). Vous pouvez certainement faire Scrum sans la saisie des besoins / fonctionnalités comme des histoires d'utilisateurs, des histoires de l'utilisateur ne sont qu'un moyen de le faire. En fait, les histoires fonctionnent pour de nombreuses équipes, notamment des équipes de développement web, mais cela ne veut pas dire qu'ils travaillent dans tous les cas et sur tous les projets (de nombreux projets sont le développement Web, mais pas tous, comme dans votre cas). Il n'y a pas de consensus sur l'utilisation des histoires.

Cela dit, le modèle recommandé pour les histoires de l'utilisateur est en fait En , je veux de sorte que . Je ne veux pas être difficile mais, si vous choisissez d'utiliser des histoires, je vous suggère vivement de l'utiliser tel quel, sans enlever une partie. Tout d'abord, en utilisant un rôle AIDENT (un même utilisateur / personne peut avoir plusieurs rôles) pour découvrir des histoires. Puis en spécifiant les avantages est vraiment important d'exposer la valeur commerciale d'une histoire afin de les hiérarchiser bien. En ce qui concerne la valeur, vous devez penser comme utilisateur final / client ( « mettre des lunettes de clients » --Mary Poppendieck). Il est vraiment pas toujours facile d'exprimer les avantages, mais certains outils peut aider et mon préféré est un 5 pourquoi (qui est utilisé pour l'analyse des causes fondamentales).

Dans votre cas, cela pourrait conduire à quelque chose comme: Comme le service informatique, je veux la base de données à être mis à jour afin que les utilisateurs peuvent bénéficie des dernières fonctionnalités de l'application et [faire un meilleur travail | une meilleure expérience utilisateur ] (pas très satisfaisant si, utilisez les 5 pourquoi).

Mais personnellement, je ne trouve pas que les histoires d'utilisateurs sont le meilleur moyen de tâches techniques, même si elle est clairement

Mise à jour la base de données peut être l'une des tâches liées à la mise en œuvre une autre histoire qui apporte une valeur directe à l'utilisateur, par exemple I en tant que utilisateur peut ajouter une nouvelle foo à mon bar .

Si vous ajoutez un foo bar nécessite une base de données mise à niveau dans les coulisses, vous comprendrait que le travail dans la mise en œuvre de cette histoire d'utilisateur.

histoires de l'utilisateur sont ainsi formulées pour assurer que tout travail bénéficie directement à l'utilisateur final d'une certaine façon.

arrive à l'avant-garde des raisons pour lesquelles des histoires d'utilisateurs sont si grands.

Quel avantage mettre à jour votre base de données à l'utilisateur donne final? Aucun? Alors ne passez pas le temps et d'argent à le faire. Passez temps et d'argent fournissant quelque chose qui donnera la valeur à votre utilisateur final.

Si elle fait? Alors pensez à ce sujet dans l'autre sens. Peut-être que vous ne pouvez mettre en œuvre une nouvelle fonctionnalité lorsque vous avez la version x de votre logiciel de base de données? Dans la dépendance de l'histoire, vous pouvez mentionner que la mise à niveau de base de données nécessaire pour fournir cette fonctionnalité.

tl; dr Ne vous contentez pas de mise à niveau pour le plaisir. Pounds vous apporte une valeur ajoutée tangible à vos clients.

En général, les tâches techniques dans le PB sont mal vus car ils très rarement directement offrir une valeur commerciale au client. Voilà pourquoi Histoires d'utilisateurs sont très populaires, car ils vous obligent à réfléchir à la valeur commerciale de l'histoire, et qui il est livré à.

Alors, pourquoi vous mettez à niveau la base de données? Pouvez-vous identifier la valeur commerciale dans la mise à niveau, et pourquoi le propriétaire du produit d'accord pour vous permettre de mettre à jour la base de données au lieu de construire de nouvelles fonctionnalités?

Est-ce à cause d'une nouvelle fonctionnalité qui va permettre ou le rendre plus facile à faire quelque chose dans votre application? Dans ce cas, que quelque chose devrait être l'élément PB, et la mise à niveau de base de données devrait être une tâche dans cette histoire. Si vous avez déjà des histoires sur le PB qui pourraient bénéficier de la mise à niveau, alors vous devriez augmenter les estimations pour un ou plusieurs de ces histoires, et d'ajouter la mise à niveau comme une tâche technique à l'histoire.

Est-ce parce que le vendeur de la base de données est de couper une ancienne version de soutien? Dans ce cas, vous pourriez avoir la mise à niveau comme l'histoire; quelque chose comme, « En tant que chef de service, je veux être sûr que nous avons le soutien de tous les logiciels afin que la continuité de l'entreprise ne risque pas si quelque chose se passe mal ». Même que ça pousse, cependant. En général, ce genre de raison n'est pas vraiment partie d'un projet, à moins que le projet est en cours depuis si longtemps le logiciel du système se déclenche soutien.

est-il pour la performance? Ensuite, l'histoire devrait être sur un aspect de la performance de l'application qui doit être amélioré pour offrir une valeur commerciale. Quelque chose comme, « En tant que CSR je dois être en mesure de récupérer les informations client dans un délai raisonnable afin que les clients au téléphone sont satisfaits de notre service ». Ensuite, la mise à niveau devient une tâche dans cette histoire.

Est-ce pour une raison tout à fait technique? Si vous ne pouvez pas déterminer comment la mise à niveau va offrir une valeur commerciale, alors pourquoi le feriez-vous? Pourquoi le propriétaire du produit choisir pour un sprint?

Il est tout simplement « Mise à jour la base de données » ou peut-être « Lorsque la nouvelle version est installée, il doit y avoir un moyen de migrer la base de données existante ». Si vous savez déjà plus de détails sur cette étape, puis les inclure. Mais l'histoire existe la plupart du temps pour vous assurer que quelque chose ne soit pas oublié; il est de ne pas être détaillé.

Plus tard, quand vous arrivez à mettre en œuvre cette histoire, vous pouvez la prépare (qui tables, avons-nous besoin d'un ou plusieurs sauvegardes, est-il une chute, scénario, etc.).

OTOH, si le projet est plus complexe, cela peut devenir un « tag », comme un post-it avis qui doit être attaché à beaucoup d'histoires. Cela signifie que vous devez inclure cela comme une « histoire sous » à toutes les histoires qui changent la base de données. Comme vous pouvez le voir, ces « histoires » couvrant projet sont un peu difficiles à suivre avec des méthodes agiles.

histoires d'infrastructure ne ont pas besoin de suivre le modèle de l'histoire prescrit. Il suffit d'écrire ce qui doit être fait et estimer en conséquence

Que diriez-vous:

En tant que personne de support d'application Je veux être sur la dernière version de base de données , car il est plus fiable / plus sûr / whatever .

Vous pouvez même phrase refactorisation comme ça:

développeur d'applications Je veux que tous les classes de données dans un module pour que je puisse ajouter de nouveaux champs à l'application très rapidement .

  1. Qui bénéficie
  2. Qu'est-ce que vous voulez faire
  3. Qu'est-ce que l'avantage est

Idéalement, vous ne voulez pas toutes les histoires d'avoir 1 développeurs être, mais un peu du sens (aiguiser votre hache au lieu d'abattre des arbres et tout cela).

Non affilié à StackOverflow
scroll top