¿Alguna vez tiene sentido tener múltiples cesionarios para un problema en un rastreador de problemas?

Question

He sido administrador de Jira y Bugzilla en trabajos anteriores, y a menudo he hecho que los usuarios soliciten la capacidad de tener más de un cesionario por problema.

Sé que esto es posible en Jira, pero en mi opinión nunca tiene sentido; Un problema debe representar un trabajo, y solo una persona puede hacer un trabajo (al menos en software, nunca he usado un rastreador de problemas para un equipo de bobsled de 2 hombres ;-)) Un gran trabajo será Obviamente involucra a más de una persona, pero creo que en ese caso debería dividirse en subtareas para permitir informes de estado precisos.

¿Alguien tiene algún caso de uso en los que sea válido para tener múltiples cesionarios?

Answer 1

El campo asignado significa muchas cosas para muchas personas. Un mejor nombre podría ser "usuario responsable". Hay tres casos que discuto con mis clientes:

A. Número de cesionarios = 0 JIRA tiene una opción de Permitir problemas no asignados, pero desanozo el uso de eso porque si un elemento de trabajo no es propiedad de nadie, tiende a ser ignorado por todos.

B. Número de cesionarios = 1 El caso predeterminado

C. Número de cesionarios> 1 ¿Quién es responsable del elemento de trabajo representado por el problema? El mejor caso que he visto para esto es que cuando una persona en un equipo puede manejar un problema en un equipo, por lo que antes de la triaje, el problema se asigna a todos en ese equipo. Creo que un mejor enfoque es crear un usuario de JIRA con una dirección de correo electrónico que envíe a todo el equipo y asignarlo a ese usuario. Luego, un miembro del equipo puede tener el problema asignado en particular.

Cambiar el caso cesionario tiene el historial registrado en la pestaña Historial. No se pierde nada en ese caso.

Answer 2

A menudo tendré una historia / función que se puede dividir en múltiples desarrolladores. Tendrán subtareas asignadas individualmente, pero tendría sentido asignar al padre a todos los involucrados, a menos que haya un desarrollador principal. En realidad no sabía que podría hacer múltiples tareas, ¡así que gracias por el consejo!

El otro caso en el que se me ocurra es la programación de pares.

Answer 3

Me topé con esta pregunta mientras busco soluciones para hacer esto. Como quiero hacer esto, supongo que mi caso de uso cuenta como una respuesta a su pregunta: solo quiero que un cesionario en el sentido de alguien que actualmente trabaje en un problema, pero quiero rastrear todo el ciclo de vida de un problema . Para nosotros, eso puede significar:

1. Una persona de apoyo recibe un informe de un cliente, crea un problema
2. Un problema-Wrangler revisa el problema para asegurarse de que sea válido, no duplicado, tenga todos los detalles apropiados, etc.
3. Un desarrollador implementa/soluciona el problema
4. Un probador realiza las pruebas apropiadas (en nuestro caso, extendiendo principalmente nuestra TestSuite automatizada para probar adicionalmente la función/solución)
5. Una persona de operaciones desplega la nueva versión a un entorno de prueba
6. Una persona de apoyo informa al cliente, que hace sus propias pruebas con la nueva versión en el entorno de prueba
7. Una persona de operaciones desplegue la nueva versión para la producción

No todos los problemas necesariamente pasan por todos los pasos. Algunos problemas tienen más pasos (por ejemplo, una revisión de código entre el paso 3 y 4). Muchos problemas también avanzarán entre los pasos (el desarrollador necesita más información, pasamos del paso 3 a 1 o 2; el probador muestra un problema, pasamos de 4 a 3).

En cada etapa, solo una persona es realmente responsable de lo que se haga. Sin embargo, hay un montón de personas asociadas con el problema. Los sistemas de seguimiento que hemos usado están felices de ofrecer cambios fáciles a los propietarios anteriores del problema (que se muestran como una lista), pero idealmente me gustaría ir un paso más allá, con el propietario que vuelve automáticamente al propietario anterior correcto dependiendo del Estado del problema. En el paso 6, la persona de soporte original del paso 1 idealmente debe contactar al cliente. En el paso 7, la persona OPS del paso 5 idealmente sería el cesionario.

En otras palabras, aunque no quiero múltiples cesionarios para un paso dado, quiero que haya un "asignado de soporte", un "cesionario de desarrollador", un "cesionario de prueba", etc.

Podemos hacer esto con subtareas y podemos hacerlo seleccionando manualmente a los propietarios anteriores al cambiar los estados, pero ninguno es ideal y creo que la situación anterior es una en la que múltiples cesionarios tendría sentido.

Answer 4

En mi empresa, tenemos un flujo de trabajo similar a Nikhil. Trabajamos en un modelo Scrum, con desarrolladores, probadores y un escritor técnico en cada equipo.

El flujo de trabajo de una tarea de desarrollo es

Desarrollo -> Revisión del desarrollador -> Prueba de control de calidad -> Aceptación de PO -> Hecho

El flujo de trabajo de una tarea de control de calidad es

QA escribe caso de prueba / prueba automatizada -> revisión de control de calidad -> hecho

Teníamos una herramienta que Jira reemplazó que nos permitió asignar varias personas a una tarea, que encontramos muy útil para nuestro flujo de trabajo. En una tarea de control de calidad, podría ver fácilmente si el otro probador de mi equipo ya había hecho trabajo y necesitaba hacer el siguiente paso.

Sin esto, me resulta difícil identificar rápidamente las tareas escritas por el otro probador en mi equipo Scrum que está listo para que yo revise (en comparación con las que escribí que necesitan revisar).

Muchas personas han pedido la capacidad de tener múltiples cesionarios desde al menos 2007. Tienen casos de uso variables y válidos. Me decepcionó que el equipo de desarrollo de JIRA dijo unilateralmente que no implementarán esto y les pediría que lo reconsideren.

https://jira.atlassian.com/browse/jra-12841

Answer 5

1. Mientras que el trabajo de grupo de pares (programación de pares, etc.) sería bueno asignar ambas personas al problema.

2. Las tareas se mueven a través de diferentes pasos a través del desarrollo (ejemplo: desarrollo, revisión, prueba). Diferentes personas pueden ser responsables de cada paso. A pesar de que la tarea puede estar en revisión o prueba, el revisor tendrá cosas antes del desarrollador para solucionar. Tener diferentes roles a los que asignar ayudaría a organizar el trabajo.

En nuestro equipo generalmente desarrollamos 1 o 2 personas juntas. Luego, el código es revisado por alrededor de 2-5 personas en individualmente o en pares, entonces es probado por 1-2 personas inicialmente, finalmente probado por todo el equipo.

Actualmente, nuestro sistema nos permite asignar una sola persona en un momento determinado. Eso limita nuestra capacidad de seguir quién está trabajando en lo que sin buscar el registro del problema. Los beneficios de la abeja capaces de asignar múltiples personas serían buenos para nosotros.

Answer 6

¿Qué sucede si a John se le asigna una tarea y no puede terminarla, y se mueve a la lista de Jane porque John era un flojo?

¿Estás de acuerdo con perder la historia de a quién se le asignó originalmente y las horas que se gastaron / facturaron en él?

Answer 7

En un escenario de aprendizaje electrónico, tiene sentido tener un problema asignado a múltiples usuarios. Esto es lo que quiero hacer: tengo un guión gráfico que quiero asignar a 3 personas al mismo tiempo: los animadores, los artistas de grabación y los diseñadores gráficos. Una vez que estas personas terminen sus tareas, lo transmitirán a un revisor común, que revisará y cerrará el problema. Gráficamente se vería algo así:

                   Storyboard
                 /     |     \
           graphics animator recording
                 \     |     /
                    reviewer
                       |
                     done

Los tres roles de trabajo dependen solo de un guión gráfico. La compilación de los tres tiene que ir a un revisor. Estoy acumulando mi cerebro para que esto funcione en Redmine. Todavía no he encontrado una solución.

Answer 8

Obtuve esta respuesta de un compañero atlassiano https://www.isostech.com/solutions/y luego más tarde de Atlassian

Objetivo: Desea establecer quién hace los trabajos para cada paso en un problema

Resumen: use un complemento para copiar valores de campos personalizados en el campo Asignado siempre que el problema pase a un nuevo paso.

Cómo: 1. Instale el complemento de utilidades de Suite: este complemento agrega un montón de nuevas funcionalidades a los flujos de trabajo.

Utilizará el complemento para copiar el valor de un campo personalizado al cesionario:

2. Cree un campo personalizado como seleccionador de usuario único para cada rol, es decir, dev, probador, revisor que se asignará en diferentes pasos en el tema

3. Agregue estos campos a la pantalla del tipo de problema

4. Modifique la post-función en la transición del flujo de trabajo entre cada paso Agregue una función de publicación "Copiar valor de otro campo" y configure para copiar el valor del campo personalizado apropiado en el campo Asignado.