Nous utilisons actuellement JIRA pour suivre nos travaux de développement. Ma direction souhaite formater et catégoriser tout comme «User Stories», y compris les tâches liées au développement non logiciel. Par exemple:

"En tant que gestionnaire de tests, puis-je effectuer des tests de l'application en utilisant uniquement des tests automatisés et aucun test manuel afin de pouvoir tester l'application aussi efficacement que possible?

Critères d'acceptation: 1. Convertir 50 tests manuels existants en tests entièrement automatisés 2. Les tests doivent s'exécuter en moins d'une heure "

Je veux me faire une idée de la communauté s'il est judicieux d'utiliser des «user stories» pour des travaux qui prennent en charge le processus de développement logiciel, ne sont pas effectués par les programmeurs et n'aboutissent pas directement à du code livrable. Ou doit-il être traité / classé différemment (par exemple, dans JIRA)?

Mis à jour le 6/7/2011 - Question reformulée pour se concentrer sur le terme "user story".

Oui

toute partie prenante, toute fonctionnalité qui améliore le système

[que les votes de puriste commencent!]

«Ma direction souhaite utiliser Agile pour tout, y compris pour les tâches non liées au développement logiciel.»

Cela ne signifie pas écrire des user stories pour chaque fonctionnalité.

Si vous voulez écrire des user stories pour chaque fonctionnalité, vous n'êtes pas nécessairement Agile. Vous écrivez simplement des user stories pour chaque fonctionnalité.

User Stories! = Agile.

Les User Stories sont un moyen de rassembler et de comprendre les exigences. Ils peuvent être utilisés de manière parfaitement cascade, si vous le souhaitez. Certaines personnes font ça.

Agile est un moyen de gérer des projets. Vous pouvez utiliser ou non les User Stories dans un projet Agile.

Les User Stories pour gérer la dette technique et les tâches internes - encore une fois - n'ont rien à voir avec l'agilité.

Beaucoup de gens sont parfaitement heureux d'ajouter des fonctionnalités "techniques" ou "d'assistance" dans un sprint sans perdre de temps à écrire une fausse "user story" pour des utilisateurs purement internes, à valeur ajoutée limitée et sans participation.

Si le contrôle qualité n'obtient pas leur histoire, combien de pertes commerciales réelles y a-t-il?

Si les véritables parties prenantes ne reçoivent pas leurs histoires, l'entreprise en souffre vraiment.

Cela n'a aucun sens pour moi. Une `` User Story '' est essentiellement cela, une histoire d'utilisateur, pas une histoire de chef de projet, pas une histoire de développeur, pas une histoire d'ingénieur d'assurance qualité.

Sur cette note, le logiciel est:

1. Définissable
2. Testable

Les améliorations de processus sont ouvertes et généralement subjectives.

Critères d'acceptation: 1. Amélioration du test 1 (par x / y)

Comment mesurez-vous l'amélioration des tests? Il n'y a pas de contrat définissable pour cela.

Et sur une note non liée, j'espère sincèrement que votre exemple donné ci-dessus,

En tant que gestionnaire de test, puis-je effectuer des tests de l'application en utilisant uniquement des tests automatisés et aucun test manuel afin de pouvoir tester l'application aussi efficacement que possible?

... n'est qu'un exemple, car il y a tellement de mal à cela que je ne peux même pas commencer à le décrire.

La dette technique pourrait être gérée de la même manière qu'une histoire d'utilisateur, mais cela peut parfois devenir assez laid. Par exemple, pour avoir une histoire comme, "En tant que développeur, je veux avoir des tests unitaires de travail afin que je puisse avoir confiance dans les tests pour valider si d'autres changements cassent quelque chose", n'a pas beaucoup de valeur pour le propriétaire du produit mais cela pourrait bien être une bonne idée pour l'équipe de le faire dans le cadre de sa propre refactorisation qui fait partie du travail dans un sprint.

J'aime l'idée d'avoir des tâches distinctes des histoires d'utilisateurs, car les tâches ne seront pas quelque chose que vous montreriez à un utilisateur final d'un système, mais pourraient aider à améliorer la maintenance et le temps qu'il faut pour développer une nouvelle fonctionnalité. Selon le nombre de tâches, en termes de totaux de points globaux, car certaines tâches peuvent durer 2 minutes et d'autres peuvent durer 2 semaines, cela peut être ce qui détermine si l'équipe prend un sprint et ne met pas de nouvelles fonctionnalités mais fonctionne sur les tâches de nettoyage des choses que j'ai vu à quelques reprises où je travaille.

À mon humble avis, oui, vous pouvez utiliser des user stories pour des projets de développement non logiciel, pas seulement des tâches d'amélioration de processus. Prenez par exemple, il y a 3 ans, j'étais le meilleur homme au mariage de mon ami et j'ai utilisé la méthodologie Agile et les histoires d'utilisateurs pour planifier le mariage. Toutes les tâches que nous devions accomplir ont été écrites sous forme de user stories avec une personnalité, une intention, une justification et des critères de réussite pour chaque user story. Toutes les parties concernées ont pris part à notre mêlée quotidienne pour discuter de ce que nous avons fait la veille et de ce que nous ferions ce jour-là. Tout le monde était géographiquement dispersé, c'est pourquoi nous avons organisé des conférences téléphoniques pour nos réunions de mêlée quotidiennes, la planification du sprint, les rétrospectives, la rédaction d'histoires et les séances d'estimation ... vous l'appelez, nous l'avons fait. Nous avons eu 6 sprints au total (3 mois) et le mariage a été un succès étonnant sans aucune pierre non retournée.

Vous avez un problème profond lorsque vous mettez des "user stories" internes dans le mélange avec des user stories réelles.

Veuillez relire autant de définitions de «partie prenante» que vous pouvez en trouver.

http://en.wikipedia.org/wiki/Scrum_(development )

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

Lisez-les très, très attentivement afin de voir la différence entre les poulets et les porcs.

Les «user stories» internes sont écrites par des poulets.

Les histoires d'utilisateurs réelles sont écrites par des cochons.

Vos user stories "orientées poulet" ne sont pas très importantes. Peu importe à quel point la direction veut les suivre comme s'il s'agissait de véritables user stories avec une valeur réelle, ce ne sont pas de vraies user stories et elles ne créent pas de valeur de la même manière.

Au bord flou de l'argument se trouve la question de l'assurance qualité. L'AQ est importante et sans elle, rien ne fonctionne.

Cela ne fait pas par magie de l'AQ soudainement un cochon. Cela les rend toujours non parties prenantes. Ils fournissent un support, une infrastructure et une base essentielle pour le reste du travail. Mais ce sont des «user stories» qui sont essentiellement différentes des vraies user stories des vrais utilisateurs.

Si le contrôle qualité ne montre pas une amélioration des tests, personne ne fait faillite. L'argent n'est pas perdu.

Si l'utilisateur ne peut pas exercer ses activités en premier lieu, vous êtes en faillite. L'argent est perdu. Toute l'opération est un échec total.

Ne confondez pas les parties prenantes internes («poulet») et réelles («porc»).

Le commentaire "poulets et cochons" manque le propos. Les parties prenantes internes sont des poulets en ce qui concerne le produit en cours de développement (à moins qu'il ne soit développé pour eux), mais ce sont des porcs en ce qui concerne le processus de développement.

La question que vous posez est de savoir si la formule de phrase "En tant que , J'aimerais pouvoir _ , afin que je puisse __ "serait utile pour définir et améliorer les processus métier où les améliorations ne nécessitent pas d'écrire de nouveau code logiciel. Je suis tombé sur ce fil parce que je pense faire la même chose et que je recherche les meilleures pratiques, mais ma forte intuition est que la réponse à votre question est "oui". Le but de la structure de la phrase est vraiment de forcer l'écrivain à abstraire des solutions qu'il / elle pourrait déjà avoir à l'esprit et à se concentrer sur ce que l'utilisateur - dans ce cas, l'utilisateur du processus - veut pouvoir le faire. Je ne vois aucune raison pour laquelle la user story ne serait pas utile lorsqu'elle est appliquée au processus.

Le point sur les critères d'acceptation est bon, mais n'a pas besoin d'être dogmatique à ce sujet (qui est Agile de toute façon). C'est un bon exercice lors de la conception d'un processus métier de demander: "Comment saurai-je si le changement de processus a atteint mon objectif?" Il est vrai que vous ne pouvez pas toujours exécuter un test automatisé pour répondre à cette question, mais ce n'est pas une raison pour disqualifier la user story en tant qu'outil.