Requisitos de seguimiento en múltiples proyectos con JIRA (u otras herramientas)

Question

Mi empresa ha estado utilizando JIRA como una herramienta de seguimiento de requisitos, así como un rastreador de errores, y ha estado funcionando bastante bien mientras trabajábamos en un proyecto en una hora.

Ahora tenemos un escenario donde tenemos tres propuestas de proyectos diferentes cuyos requisitos se solapan parcialmente (por ejemplo, el requisito 1 se aplica a los proyectos A y B, el requisito 2 se aplica a los proyectos B y C, etc.). Me gustaría poder ingresar un único problema de JIRA para cada requisito, pero eso no parece posible ya que los problemas y los proyectos de JIRA tienen una relación de uno a uno.

¿Alguien ha encontrado una manera de hacer esto en JIRA, o tal vez con alguna otra herramienta que se integre con JIRA?

Answer 1

Si bien no hay una sola respuesta correcta, puedo ofrecer una idea. No tengo suficiente información sobre su proceso de trabajo, pero menciona que tiene propuestas de proyectos. Entonces asumo que los proyectos A, B y C están en etapas tempranas. Recopilación de requisitos y tal, no hay errores todavía.

Configure un solo proyecto JIRA, por ejemplo, "Requisitos previos". Ponga todos los requisitos para los proyectos A, B y C en ese proyecto JIRA. Para permitir una relación de muchos a muchos entre los requisitos y los proyectos reales, configure un campo personalizado de tipo "múltiples casillas de verificación" o equivalentes, y configure "proyectos A", "proyecto B" y "proyecto C" como sus valores. Para cualquier requisito, puede verificar a qué proyecto se aplica.

Ahora, y estoy haciendo más suposiciones aquí, digamos que algunas propuestas avanzan y otras desaparecen. Necesitará un proceso para a) extraer todos los requisitos para el proyecto real A en un proyecto JIRA recién creado para A: esto se puede hacer mediante la búsqueda & problema de clonación masiva; b) purgar todos los requisitos que no tengan ningún proyecto activo asociado a ellos: buscar & eliminación masiva.

Advertencias: si necesita compartir requisitos con diferentes clientes, se pondrá complicado. Los permisos se configuran por proyecto JIRA & tipo de problema.

Habiendo dicho todo eso, JIRA carece de características para la gestión de los requisitos decente, como las líneas de base y la trazabilidad. Pero puede estar bien solo por recopilar datos para seguir trabajando.

Answer 2

Utilizamos la función "duplicados" o "se refiere a" de jira.

Por lo tanto, plantea un problema en cada proyecto, pero los relaciona entre sí. De esta forma, puede tener un problema "propiedad" de un proyecto y puede cerrar todos los proyectos relacionados una vez que los cambios se prueban en cada uno.

Incluso puede usar depende de la vinculación si esto tiene sentido en la configuración de su proyecto.

Answer 3

Probablemente sea mejor usar confluencia además de jira, en este caso.

Usa a Jira para saber qué es lo mejor y usa Confluence para todo lo demás.

Divida sus diversos proyectos en "submódulos compartidos" si lo considera útil, sin embargo, me inclino a sugerir el uso de Jira principalmente para rastrear la implementación real y los errores asociados.

Answer 4

Otro enfoque es crear un campo personalizado de selección múltiple con hipervínculos (como 'XYZ-123') a los problemas como opciones.

Answer 5

Tenemos el mismo problema.En el caso de que tenga un problema (un error o una nueva característica) que involucre múltiples productos y que tengan dependencias entre ellos. (Como ejemplo digamos que tenemos un servidor, una API de conexión y una aplicación de cliente). Si hay una nueva idea sobre la extensión de la aplicación cliente de cierta manera, es muy posible que también la conexión API y el servidor necesiten algún tipo de extensión. Probablemente sean desarrollados por diferentes equipos ... Por lo tanto, no se manejan en el mismo sprint/iteración, pero como propietario de un producto, desea realizar un seguimiento de todas estas nuevas características como un grupo.

Lo que hicimos fue en realidad creado algunos campos personalizados. El primer campo que presentamos fue un 'Seleccionar en cascada', como 'Programa' y 'Fase'. Esto le da a los propietarios del producto la posibilidad de agrupar los problemas bajo un programa y hacer una planificación aproximada a largo plazo (varias iteraciones).

Luego agregamos otro campo (Campo de texto) para 'Epic' (o 'Tema') que agrupa los problemas relacionados con un cierto Epic/Theme. La idea es usar 'Epics' dentro de un 'Programa'. En el caso de un "Programa" más grande, probablemente puedas separarlo en diferentes partes, que luego se reflejarán en estos "Épicos". (Una especie de historia. Un grupo de historias (que pueden extenderse sobre múltiples productos) que agregan valor como un agujero a la serie de productos).

Ambos campos hacen que ahora sea más fácil filtrar los problemas, que cruzan múltiples productos, según el Programa (con o sin su Fase) y el Epic.

De hecho, con la vinculación habilitada, ahora también puede crear dependencias entre los diferentes problemas, en los diferentes productos. Y está completamente separado del control de versiones del producto Jira predeterminado. Lo cual es genial, por lo que el proceso de lanzamiento normal se mantiene como está.

Otra idea que estoy pensando presentar es el campo 'Iteración'. Al entrar en la sesión de planificación (o justo después). Este campo podría actualizarse con el nombre de ese sprint (Jira es excelente en la edición/actualización de múltiples ejemplares). Que luego hace que sea fácil filtrar todos los problemas para ese sprint.

Lo que más me gusta de usar Jira también como una herramienta de planificación de Sprint/seguimiento de Sprint, es que no tiene una herramienta de planificación y atasco por separado. Los errores son más visibles. No hay una doble administración de errores en la herramienta de planificación o elementos de planificación en la herramienta de seguimiento de errores (para los números correctos de cvs/svn/etc). O la generación de notas de la versión.

Answer 6

Mejor manera es distinguir los problemas utilizados para el seguimiento de desarrollo y los requisitos que a menudo son los mismos en el 80% para todos sus proyectos. existe

Solución: Rmsis a JIRA plugin: