Servicios MR: Monitor de correo electrónico, ID personalizado, indicador de mensajes no leídos
Las funciones adicionales de Modern Requirements4DevOps
En este artículo repasamos algunas de las funciones adicionales que están disponibles en la edición Enterprise Plus de Modern Requirements4DevOps. Estas funciones se denominan «MR Services».
Estas funciones ofrecen un mayor control sobre los cambios realizados en los elementos de trabajo, te permiten conectar tu proyecto a un servicio de correo electrónico y te ayudan a mejorar la trazabilidad y la usabilidad de tu proyecto.
Servicio de monitorización de correo electrónico adaptado a las necesidades actuales
La función «Email Monitor» permite acceder a tu proyecto a través de un medio que no existe en Azure DevOps. Es decir, te permite comunicarte con tu proyecto por correo electrónico. A menudo, los equipos se encuentran con situaciones en las que intercambian correos electrónicos sobre un elemento de trabajo que debería crearse y, con frecuencia, logran utilizar los correos electrónicos para llegar a un requisito definitivo que debería añadirse a su proyecto.
Con la función «Email Monitor», tu equipo ya puede convertir directamente esta comunicación externa en una tarea.
Al activar la función «Email Monitor» en el panel de la extensión Modern Requirements4DevOps, puedes indicar una dirección de correo electrónico que permita interceptar y crear cualquier requisito que se le envíe por correo electrónico.
Caso de uso del servicio de supervisión del correo electrónico
El caso de uso más habitual de la función «Email Monitor» es el siguiente:
Tengo una organización grande y me gustaría que todos los miembros de mi organización añadieran los errores que encuentren en mi software a mi proyecto de Azure DevOps.
Una vez que Email Monitor esté completamente configurado conbugs@myorganization.com, cualquier miembro de mi organización podrá simplemente enviar un correo electrónico abugs@myorganization.comy yo podré indicar que se cree un error en mi proyecto.
Al mismo tiempo, el correo electrónico que ha dado lugar a la creación del error también se envía a las personas pertinentes de ese proyecto. Los miembros pertinentes pueden ahora participar en el debate sobre ese elemento de trabajo por correo electrónico, y todas las comunicaciones por correo electrónico se añadirán a las propiedades de debate de ese elemento de trabajo dentro de tu proyecto.
Esta función única permite a otras personas contribuir al éxito de tu proyecto sin necesidad de tener acceso completo a tu proyecto de Azure DevOps. Ahora, personas externas pueden participar en el debate sobre un elemento de trabajo sin que sea necesario que les concedas acceso a tu proyecto.
Bandera de alerta / Enlaces sospechosos
La función «Dirty Flag / Suspect Link» contribuye al éxito de tus proyectos al permitir consultar los cambios realizados en los elementos de trabajo y, en general, hacerlos más visibles.
Esta función está pensada para resaltar de forma implícita cualquier requisito que pueda verse afectado por la modificación de un requisito vinculado. Puede considerar esta función como un método para evaluar el impacto de los cambios en los requisitos dentro de su proyecto.
¿Cómo funciona Dirty Flag / Suspect Links?
Esta función te permite supervisar los elementos de trabajo que cumplen determinadas condiciones. Cuando estos elementos de trabajo cambien, la función de supervisión marcará cualquier elemento de trabajo vinculado.
Veamos un ejemplo:
La historia de usuario 1 acaba de pasar al estado «Completada». Si el indicador de cambios / enlaces sospechosos se puede configurar para que active una alerta si se realiza algún cambio en las historias de usuario que se encuentran en estado «Completada» (por ejemplo, un cambio en un campo como «Descripción»)
Esto significa que, si en el futuro se modifica el campo «Descripción» de la historia de usuario 1, todos los requisitos vinculados a ella quedarán marcados con un indicador de modificación.
Esto permite a tu equipo detectar fácilmente si cambia un requisito que cumple con un determinado conjunto de criterios (que tú especifiques). Una vez detectado, todos los elementos de trabajo directamente vinculados se marcarán mediante la función «Dirty Flag / Suspect Link».
Siguiendo con nuestro ejemplo, si cambiara el campo«Descripción»de la historia de usuario 1, podríamos marcar como «en espera» todos los casos de prueba vinculados directamente que pudieran necesitar modificarse para comprobar los nuevos criterios.
Los indicadores de error que se activan en esos casos de prueba adoptarían la forma de una etiqueta de elemento de trabajo.
Las etiquetas aparecen en el editor de elementos de trabajo estándar de Azure DevOps.
En el caso de la etiqueta «Dirty Flag» que se aplica a los elementos de trabajo, dicha etiqueta incluye tanto el ID del elemento de trabajo modificado como su revisión, de modo que tu equipo pueda identificar fácilmente qué requisito se modificó y activó la funcionalidad de la etiqueta «Dirty» o el enlace «Suspect».
Identificadores personalizados
Muchas aplicaciones ofrecen la posibilidad de añadir identificadores personalizados a los elementos de trabajo. El objetivo de este tipo de función es hacer que un campo resulte más legible y reconocible.
Nuestra función de ID personalizado ofrece las mismas ventajas, además de las ventajas adicionales que supone el uso del módulo de consultas.
Los identificadores personalizados se pueden configurar como una propiedad personalizada que se incluye en cada uno de tus elementos de trabajo.
La propiedad «ID personalizado» ofrece un método sencillo para identificar toda la información necesaria de un elemento de trabajo concreto en un solo campo. Además, resulta ser una herramienta increíblemente útil para identificar la fuente de los requisitos en consultas que abarcan varios proyectos.
Al permitirle consolidar la información en un solo campo, hace que un elemento de trabajo sea más accesible para los usuarios menos involucrados. La función de ID personalizada se ajusta a las siguientes directrices:
- A los elementos de trabajo se les puede asignar un código único. Por ejemplo, el código del tipo de elemento de trabajo «Requisito» sería REQ, y el del tipo «Historia de usuario» sería US.
- Puedes establecer el número inicial a partir del cual se incrementarán los tipos de elementos de trabajo. Por ejemplo, puedes indicar que la numeración del ID personalizado de las historias de usuario comience en 00001 y que, a partir de ahí, el ID personalizado de cada historia de usuario se incremente.
- También puede añadir un prefijo de proyecto opcional para cualquier ID personalizado. Por ejemplo, a un nombre de proyecto como «Proyecto X» se le podría asignar el prefijo PX.
- Por último, puedes optar por incluir el ámbito de cualquier elemento de trabajo. El número de identificación no se repite en el ámbito; el ámbito puede ser «Equipo», «Proyecto» o «Colección».
Siguiendo el ejemplo que se describe en la directriz anterior, un ID personalizado para el primer elemento de trabajo de requisito (00001) del Proyecto X sería «PX-REQ-00001», que es una concatenación del prefijo del proyecto + el código del elemento de trabajo + el número
¡Solicite una demostración!
- Programe una demostración con uno de nuestros expertos en productos.
- Reciba una demostración personalizada que imita el proceso de su equipo.
- Consulte a nuestros expertos sobre temas como flujos de trabajo o mejores prácticas.
Reducir los esfuerzos de UAT
Reducción del 50 % en los esfuerzos de UAT
Ahorro de tiempo comprobado
Ahorro del 80 % en tiempo de creación del análisis de trazas.
Agilizar las aprobaciones
Reducción significativa de los retrasos en la aprobación
Aumentar el rendimiento
50 % de requisitos de mejora de la productividad
Reducir la repetición del trabajo
Reducción de 10 veces en la reelaboración del desarrollo
Simplifique el cumplimiento normativo
Reducción del 40 % en los esfuerzos de presentación de informes de cumplimiento normativo.
