project management - trabajar - Requisitos de seguimiento en múltiples proyectos con JIRA(u otras herramientas)
jira software login (6)
Otro enfoque es crear un campo personalizado de selección múltiple con hipervínculos (como '' XYZ-123 '') a problemas como opciones.
Mi empresa ha estado usando JIRA como una herramienta de seguimiento de requisitos, así como un rastreador de errores, y ha funcionado bastante bien mientras hemos estado trabajando en un proyecto a la vez.
Ahora tenemos un escenario en el que tenemos tres propuestas de proyectos diferentes cuyos requisitos se superponen 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 solo problema de JIRA para cada requisito, pero eso no parece ser posible ya que los problemas y proyectos de JIRA tienen una relación de uno a uno.
¿Alguien ha encontrado una manera de hacer esto en JIRA, o quizás con alguna otra herramienta que se integre con JIRA?
Probablemente sea mejor usar confluencia además de jira, en este caso.
Usa a Jira para lo que es mejor y usa Confluence para todo lo demás.
Divida sus diversos proyectos en "submódulos" compartidos si cree que es útil, sin embargo, me gustaría sugerir que use Jira principalmente para rastrear la implementación real y los errores asociados.
Si bien no hay una sola respuesta correcta, puedo ofrecer una idea. No tengo suficiente información sobre su proceso de trabajo, pero usted menciona que tiene propuestas de proyectos. Así que estoy asumiendo que los proyectos A, B y C están en etapas iniciales. Recopilación de requisitos y tal, no hay errores todavía.
Configure un solo proyecto JIRA, por ejemplo, "Requisitos iniciales". 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 del tipo "casillas de verificación múltiples" o equivalente, y configure "proyecto A", "proyecto B" y "proyecto C" como sus valores. Para cualquier requerimiento puedes 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 creado recientemente para A - esto puede hacerse a través de la búsqueda y el problema de clonación masiva; b) purgar todos los requisitos que no tengan ningún proyecto activo asociado con ellos: buscar y eliminar de forma masiva.
Advertencias: si necesita compartir requisitos con diferentes clientes, se volverá complicado. Los permisos se configuran por proyecto JIRA y tipo de problema.
Dicho todo esto, JIRA carece de características para la gestión de requisitos decentes, como las líneas de base y la trazabilidad. Pero puede estar bien solo para recopilar datos para trabajo adicional.
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 tenga dependencias entre ellos. (Como ejemplo, digamos que tenemos un servidor, una api de conexión y una aplicación cliente). Si hay una nueva idea acerca de extender 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 estén desarrollados por equipos diferentes ... 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 grupo.
Lo que hicimos fue crear algunos campos personalizados. El primer campo que introdujimos fue un ''Selección en cascada'', como ''Programa'' y ''Fase''. Esto le da a los propietarios del producto la posibilidad de agrupar los problemas en un programa y hacer una planificación aproximada a largo plazo (varias iteraciones).
Luego, agregamos otro campo (Campo de texto) para "Épico" (o "Tema"). Esto incluye los temas relacionados con un determinado Epic / Tema. La idea es usar ''Epopeyas'' dentro de un ''Programa''. En el caso de un ''Programa'' más grande, probablemente pueda separarlo en diferentes partes, que luego se reflejarán en estos ''Épicos''. (Un tipo de historia. Un grupo de historias (que pueden extenderse en múltiples productos) que agregan valor como un agujero a la serie de productos).
Ambos campos facilitan ahora el filtrado de problemas, que atraviesan múltiples productos, según el Programa (con o sin su Fase) y el Epic.
De hecho, con el enlace habilitado, ahora también puede crear dependencias entre los diferentes problemas, en los diferentes productos. Y está completamente separado de la versión por defecto del producto Jira. Lo que es genial, por lo que el proceso de lanzamiento normal se mantiene como está.
Otra idea que estoy pensando en introducir 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 problemas). Lo 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 herramienta de planificación de Scrum / Sprint es que no tiene una herramienta separada de planificación y trabajo pendiente. Los bichos son más visibles. No hay 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 de confirmación de cvs / svn / etc correctos). O la generación de notas de lanzamiento.
Una mejor manera es distinguir los problemas utilizados para el seguimiento del desarrollo y los requisitos que a menudo son iguales al 80% para todos sus proyectos.
La solución existe: Rms es un complemento de JIRA :
Utilizamos los "duplicados" o "se relaciona con" la función de jira.
Entonces planteas un problema en cada proyecto, pero los relacionas. De esa manera, puede tener un problema "de propiedad" de un proyecto y puede cerrar todos los proyectos relacionados una vez que los cambios se prueben en cada uno.
Incluso se podría usar depende del enlace si esto tiene sentido en la configuración de su proyecto.