J'ai été administrateur de Jira et de Bugzilla dans des emplois antérieurs et j'ai souvent eu des utilisateurs de demander la capacité d'avoir plus d'un cessionnaire par numéro. P>
Je sais que c'est possible à Jira, mais à mon esprit, cela n'a jamais de sens; Un problème devrait représenter un travail, et une seule personne peut faire un travail de travail (au moins dans des logiciels, je n'ai jamais utilisé de suivi de suivi pour une équipe Bobsled 2-Man ;-)) Un grand travail sera impliquer évidemment plus d'une personne, mais je pense que dans ce cas, il devrait être divisé en sous-éléments pour permettre une déclaration de statut précise. P>
Quelqu'un a-t-il des cas d'utilisation où il est valide pour avoir plusieurs cessionnaires? P>
8 Réponses :
Que se passe-t-il si John est attribué une tâche et ne peut pas la terminer, et il est déplacé vers la liste de Jane parce que John était un fainéant? P>
Vous êtes d'accord avec la perte d'histoire de qui il a été attribué à l'origine et les heures qui ont été dépensées / facturées dessus? P>
Ce n'est pas le cas dont je parle. Il est courant de réaffecter une question à différentes personnes avant sa fin, mais je vous demandais s'il est toujours approprié d'attribuer une question à deux personnes ou plus en même temps.
Vous ne perdez pas l'histoire de Jira, il est visible (si vous voulez) qui était la question précédemment assignée.
Ce n'est pas seulement à propos de l'histoire, mais aussi de pouvoir voir clairement qui a contribué à un travail particulier. Si l'utilisateur A a fait 90% du travail, puis réaffectée à l'utilisateur B pour terminer les 10% du dernier, je préférerais qu'en un coup d'œil, il n'apparaît pas que l'utilisateur B est le gars / Gal sur le problème.
Le champ des cessionnaires signifie beaucoup de choses à beaucoup de gens. Un meilleur nom pourrait être "utilisateur responsable". Je discute de trois cas avec mes clients: P>
a. Nombre de cessionnaires = 0 Jira a une option de problèmes autorisée, mais je décourage l'utilisation de cela, car si un élément de travail n'est pas propriétaire de personne, il a tendance à être ignoré par tout le monde. P>
b. Nombre de cessionnaires = 1 L'affaire par défaut p>
c. Nombre de cessionnaires> 1 Qui est responsable de l'élément de travail représenté par la question? Le meilleur cas que j'ai vu pour cela est que lorsqu'un problème peut être traité par une seule personne d'une équipe, alors avant le triage, le problème n'est attribué à tous les membres de cette équipe. Je pense qu'une meilleure approche consiste à créer un utilisateur JIRA avec une adresse électronique qui envoie à toute l'équipe et l'attribue à cet utilisateur. Ensuite, un membre de l'équipe peut avoir la question qui leur est attribuée en particulier. P>
Changer le cas d'un attribué a l'historique enregistré dans l'onglet Historique. Rien n'est perdu dans ce cas. P>
Juste une note supplémentaire ici: j'aime les problème non attribué code> option plus que d'avoir un cessionnaire qui n'a pas de temps ni ne se sent responsable de cela. Il est facile de vérifier sur une base régulière que des problèmes ne sont pas attribués, puis de les travailler. Une autre option que nous avons fait dans le passé est de les assigner à un utilisateur
nn code> ou d'ajouter une étiquette / une étiquette.
Je vais souvent avoir une histoire / une fonctionnalité pouvant être divisée sur plusieurs développeurs. Ils auront des sous-tâches assignées individuellement, mais il serait logique d'attribuer au parent à toutes les personnes concernées, à moins d'un développeur principal. Je ne savais pas que je pouvais faire plusieurs assignations, alors merci pour le conseil! p>
L'autre cas que je peux penser est la programmation par paire. p>
J'aime davantage qu'une personne est globalement responsable et les sous-tâches sont ensuite affectées individuellement aux développeurs.
Je frappe sur cette question lors de la recherche de solutions pour le faire. Depuis que je veux faire cela, je suppose que mon cas d'utilisation compte comme réponse à votre question: je veux vraiment vraiment un cessionnaire dans le sens de quelqu'un qui travaille actuellement sur un problème, mais je veux suivre tout le cycle de vie d'un problème . Pour nous, cela peut signifier: p>
Tous les problèmes ne traversent pas nécessairement toutes les étapes. Certains problèmes ont plus de mesures (par exemple un examen de code entre les étapes 3 et 4). De nombreux problèmes deviendront également à l'envers entre les étapes (développeur nécessitent plus d'informations, nous passons de l'étape 3 à 1 ou 2; des taches de testeur un problème, nous allons de 4 à 3). P>
À chaque étape, une seule personne est en fait responsable de tout ce qui doit être fait. Néanmoins, il y a tout un groupe de personnes associées à la question. Les systèmes de suivi que nous avons utilisés sont heureux d'apporter des modifications faciles aux propriétaires précédents du problème (indiqués comme une liste), mais j'aimerais idéalement faire une étape supplémentaire, le propriétaire revenant automatiquement au bon fonctionnement précédent en fonction du Statut de la question. À l'étape 6, la personne de soutien initiale de l'étape 1 doit idéalement contacter le client. À l'étape 7, la personne OPS de l'étape 5 serait idéalement le cessionnaire. P>
En d'autres termes, alors que je ne veux pas de multiples cessionnaires pour une étape donnée, je veux qu'il y ait un "assignateur de support", un "cessionnaire de développeur", un "cessionnaire de test", etc. p>
Nous pouvons le faire avec des sous-tâches et nous pouvons le faire en sélectionnant manuellement les propriétaires précédents lors de la modification des statuts, mais non plus idéal et je pense que la situation ci-dessus est une fois que plusieurs cessionnaires auraient un sens. P>
Dans un scénario d'apprentissage en ligne, il est logique d'avoir un problème attribué à plusieurs utilisateurs. Voici ce que je veux faire: J'ai une scénario que je veux attribuer à 3 personnes en même temps - les animateurs, les artistes enregistrants et les graphistes. Une fois que ces personnes ont terminé leurs tâches, ils le transmettront à un criticinal commun, qui examinera et fermera la question. Graphiquement, cela ressemblerait à ceci:
Storyboard / | \ graphics animator recording \ | / reviewer | done
Dans ma compagnie, nous avons un flux de travail similaire à Nikhil. Nous travaillons dans un modèle Scrum, avec des développeurs, des testeurs et un rédacteur technique sur chaque équipe. p>
Le flux de travail d'une tâche de développement est p>
Développement -> Examen des développeurs -> Test d'assurance qualité -> Acceptation PO -> FAIT P>
Le flux de travail d'une tâche QA est p>
QA écrit un étui à tester / test automatisé -> Revue QA -> FAIT P>
Nous avons eu un outil que JIRA a remplacé qui nous a permis d'attribuer plusieurs personnes à une tâche, que nous avons trouvée très utile pour notre flux de travail. Sur une tâche QA, je pouvais facilement voir si l'autre testeur de mon équipe avait déjà fait du travail et je devais faire la prochaine étape. P>
Sans cela, je trouve difficile d'identifier rapidement les tâches écrites par l'autre testeur de mon équipe Scrum qui est prête à examiner (par rapport à celles que j'ai écrites pour lesquelles ils doivent revoir). p>
Tant de personnes ont demandé la capacité d'avoir plusieurs cessionnaires depuis au moins 2007. Ils ont des cas d'utilisation variés et valables. J'ai été déçu que l'équipe de développement de la JIRA ait annulé unilatéralement qu'ils ne l'appliqueraient pas et leur demanderaient de reconsidérer. P>
tandis que le groupe paire de travail (programmation par paire, etc.) Ce serait bien d'affecter les deux personnes à la question. P> LI>
Les tâches traversent différentes étapes via le développement (exemple: développement, révision, test). Différentes personnes peuvent être responsables de chaque étape. Même si la tâche peut être en cours d'examen ou de test, l'examinateur aura des trucs au développeur à réparer. Avoir des rôles différents à céder pour aider à organiser le travail. p> li> ol>
Dans notre équipe, nous développons généralement 1 ou 2 personnes ensemble. Ensuite, le code est examiné par environ 2-5 personnes individuellement ou par paires. Ensuite, il est testé de 1 à 2 personnes initialement, enfin testé par toute l'équipe. P>
Actuellement, notre système nous permet d'attribuer une seule personne à un moment donné. Cela limite notre capacité à suivre qui travaille sur quoi sans regarder à travers le journal de la question. Les bénifieurs de l'abeille capable d'affecter plusieurs personnes seraient bonnes pour nous. P>
obtenu cette réponse d'un partenaire Atlassien https://www.isostech.com/solutions/ et ensuite plus tard d'Atlassien P>
Objectif: Voulez-vous définir qui fait les œuvres pour chaque étape sur un problème p>
Résumé: Utilisez un plugin pour copier des valeurs à partir de champs personnalisés dans le champ des cessionnaires lorsque le problème passe à une nouvelle étape. P>
Comment: 1. Installez le plug-in Suite Utilities: Ce plug-in ajoute un tas de nouvelles fonctionnalités aux flux de travail. P>
Vous utiliserez le plug-in pour copier la valeur d'un champ personnalisé au cessionnaire: p>
Créez un champ personnalisé en tant que sélecteur d'utilisateur unique pour chaque rôle I.E., DEV, testeur, examinateur à attribuer différentes étapes de la question p> li>
ajoutez ces champs à l'écran du type d'émission p> li>
Modifiez la post-fonction sur la transition du flux de travail entre chaque étape Ajoutez une "valeur de copie à partir d'un autre champ" de la fonction et définissez-la pour copier la valeur du champ personnalisé utilisateur approprié dans le champ Assigné. p> li> ol>